Hi, On Tue, Feb 5, 2013 at 12:41 AM, Guy Helmer <guy.helmer@gmail.com> 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 (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.... This email sent to site_archiver@lists.apple.com