SCSI command filtering

Posted Aug 3, 2006 11:02 UTC (Thu) by NRArnot (subscriber, #3033)
Parent article: SCSI command filtering

Linus is right, as usual.

The kernel should definitely offer the hooks for SCSI command filtering, so that an unprivileged user can't fry the hardware. It's really no different to stopping him from oopsing the OS or corrupting the filestore. However, the details of the filtering for each model of drive need not be the responsibility of the kernel maintainers, when they can be tweaked via a system startup script. Let ZZZ, or someone who maintains ZZZ burners, supply the necessary definitions for a ZZZ-1234 drive, if the defaults are unsafe or over-restrictive. There's an analogy with netfilter here. Who would argue for the removal of netfilter, even though its default state is to do nothing?

SCSI command filtering

Posted Aug 3, 2006 14:47 UTC (Thu) by pjones (subscriber, #31722) [Link]

Its default state isn't to do nothing. By default, for example, you can't do MODE SELECT as a normal user. The reasoning seems good at face value; you can use it to e.g. set hard drive passwords. But for some devices, you have to be able to do that. Some CD drives, for example, can't be used to rip CDs without first issuing a MODE SELECT. So it's not as black and white as one would hope. Sometimes you don't want a user to be able to do something, and sometimes they have to be able to do it.

It really is per-device. Each device's version of the SCSI command set has some variation, and on some you need to do things which on others you do not. The filter needs to be modifiable accordingly.

They do it as root

Posted Aug 3, 2006 20:17 UTC (Thu) by wilck (guest, #29844) [Link]

Linus is right, as usual.

Well... what do you do if you can't figure out how to burn CDs as ordinary user? I, for one, do it as root. Or install cdrecord suid root. My guess is that most people would do it that way. Just bypass the SCSI command filter. You know that it's bad, but being unable to burn is even worse. That's the kind of thing people do if overly repressive security measures get in their way.

If you have a large server with lots of users you can't trust, it'd be a good idea to disable write access to the CD drive for ordinary users altogether.

Or restrict writing to those users you can trust. Or use a security framework such as SELinux to allow only some trusted applications (such as cdrecord) to write to the device.

I really see no need for a kernel-based filter. If CD burning is really the only real world application in which non-priviledged users need to send special SCSI commands, as the joey's comment suggests, moving the cdrecord functionality into a kernel driver seems more approriate than filtering arbitrary commands.