Re: [PATCH] drivers/block/scsi_ioctl.c, Video DVD playback support

[Elias da Silva <silva@aurigatec.de>]

On Monday 24 January 2005 21:39, you wrote:
[snip]
: > This is true for protected media because of the authentication
: > process needed between "host" 	and DVD device. IMHO,
: > the classification of the opcodes
: > 
: > 	a. GPCMD_SEND_KEY and
: > 	b. GPCMD_SET_STREAMING
: > 
: > as only "save for write" is wrong.
: 
: You need to explain why you think that is so, since this is the core of
: the argument. The only thing I can say is that perhaps SEND_KEY should
: even be root only, since it has a fairly large scope.

This is exactly the point: if the kernel wants to be safe, the
authentication procedure should be totally implemented in the kernel
and be protected against further changes via "alternative" ways...
but it isn't now and probably won't be although it could be.

On the other hand I don't think it is a good idea to let only
root read a video DVD an a Linux system.

[snip]
: > Furthermore, if you use
: > 	a. cdrom_ioctl (..., DVD_AUTH,...) instead of
: > 	b. cdrom_ioctl (..., CDROM_SEND_PACKET,...)
: > 	-> scsi_cmd_ioctl()-> sg_io()-> verify_command()
: > 
: > the same authentication procedure works as expected on a
: > RONLY opened device!
: 
: DVD_AUTH by-passes scsi_ioctl.c, so yes.
[snip]
:The problem is that it is policy, and it has to
: be restrictive to be safe.

Yes, and with this "alternative" way to to things in the kernel
a user can complete circumvent the restrictive policy now
implemented in verify_command(). So you are securing
the backdoor and leaving the frontdoor completely open, right?

Now if safety is top priority, than

  a. the authentication must be implemented by the kernel and

  b. there should be no other way to access the device and
	completely circumvent the policy enforcement.

or

we both agree, that in a situation where a user has exclusive
access to the device it would be OK to issue a SEND_KEY, even
if he uses RONLY mode for access.

It is as you wrote a silly situation but the current implementation
don't augment security but instead prevents "innocent" software
to continue to run.

Regards,

Elias