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: Kevin Elliott <email@hidden>
- Date: Tue, 05 Feb 2013 10:55:45 -0800
On Feb 5, 2013, at 8:34 AM, Phil Jordan <email@hidden> wrote:
> 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.
Nothing at the IOMedia layer will work for this, though it might look like it will. Our CD burning APIs would probably honor this sort of change, but all it takes to actually burn a CD is the SCSITaskUserClient which connects well below the media layer.
If you're running on a controlled set of hardware, you could probably make a driver that convinced the SCSI stack that it was looking at a standard CD/DVD drive and not a burner but I'm not sure if even that would solve your problem (I don't remember if non-burners can be accessed via the SCSITaskUserClient).
-Kevin
_______________________________________________
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