Re: IOMedia filter scheme and CD/DVD media
Re: IOMedia filter scheme and CD/DVD media
- Subject: Re: IOMedia filter scheme and CD/DVD media
- From: Phil Jordan <email@hidden>
- Date: Tue, 05 Feb 2013 17:34:27 +0100
Hi,
On Tue, Feb 5, 2013 at 12:41 AM, Guy Helmer <email@hidden> wrote:
> I'm looking into a way to thoroughly disable writing to CD or DVD media on OS X to support data security requirements, and it seems like an IOMedia filter scheme that simply manipulates the media's isWritable value would do the trick.
>
> However, in reading the Mass Storage Device Driver Programming Guide's section Developing a Filter Scheme, I've found this warning:
>
> "a filter-scheme driver should not produce an IOCDMedia or IODVDMedia object, because these objects have provider requirements specific to CD and DVD media that can be met only by an IOCDBlockStorageDriver or IODVDBlockStorageDriver, respectively."
If you look at the source for IOCDMedia, it does indeed cast its
provider IOService to IOCDBlockStorageDriver without checking, and
then calls IOCDBlockStorageDriver methods. So this warning is
definitely to be heeded.
> As a newbie in IOKit, there is probably something obvious that I am missing… For my purposes, does this mean that I am unable to create a filter that could sit in the CD/DVD storage driver stack, even if it just uses the IOMedia interface? If so, are there any likely alternatives I should pursue?
IOKit is maybe not the ideal place to do security-related stuff as Ben
Gollmer has already suggested. I guess it depends on what you're
trying to do; I've never tried it, but you could probably implement a
forwarding "filter" IOCDBlockStorageDriver that sits on top of the
"real" IOCDMedia. Another disadvantage of a filter scheme for security
purposes is that both the original and the new device nodes are
created in /dev/ (via the IOMediaBSDClient). The "real" node should
deny access with exclusive access errors, but that might not apply to
all operations.
However, there may be a better way: the CD/DVD/etc. specific behaviour
is largely made available to userspace via ioctl()s on the media
device node. (see: IOCDMediaBSDClient etc) ioctl() calls are routed
through the Mandatory Access Control (MAC/TrustedBSD) layer before
they run, so I think you should be able to make your security
decisions there rather than via an IOKit hack. The callbacks to look
into would be mpo_vnode_check_ioctl and mpo_file_check_ioctl. I don't
know if enough information is provided via those callbacks, but it's
worth finding out.
Another option is hooking in at the BSDClient layer: you could
subclass IOCDMediaBSDClient and friends, and make your version take
precedence over the default via the probe score. This would certainly
be less work than the IOCDBlockStorageDriver route and also avoids the
device node duplication.
Hope that helps,
phil
--
http://philjordan.eu/ - Phil Jordan, software development contractor
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden