LWN: Comments on "SCSI command filtering"

SCSI command filtering

cortana — Mon, 14 Aug 2006 15:00:50 +0000

So, I haven't been able to use cdrecord as a non-root user since 2.6.8.1 was released. I assumed that this was intended, and that everyone changed to running cdrecord as root. Is this not the case? Should I instead file a bug against the SCSI command filtering?

SCSI command filtering

addw — Sun, 06 Aug 2006 09:27:17 +0000

But the modified firmware could return something different on a read than what is on the CD, so when the sysadmin thinks that he is loading some new program he is actually loading something else.

Would not be easy to do this, but ....

SCSI command filtering

sbergman27 — Thu, 03 Aug 2006 23:31:48 +0000

In case anyone missed it:

http://www.gnu.org/music/free-software-song.ogg

I wonder how Barbra Streisand would have sung that?

SCSI command filtering

roelofs — Thu, 03 Aug 2006 22:47:37 +0000

That was probably the first time that our editor's famous deadpan humour actually made me laugh out loud and prevented me from reading on the article for a little while.

Yes, the distinction between "music tracks" and "RMS-singing tracks" was elegant and pithy.

Greg

SCSI command filtering

ddaa — Thu, 03 Aug 2006 20:38:01 +0000

> Some of those commands could lead the drive to rewrite its firmware, catch fire, or replace music tracks with recordings of Richard Stallman singing.

That was probably the first time that our editor's famous deadpan humour actually made me laugh out loud and prevented me from reading on the article for a little while.

Thank you.

They do it as root

wilck — Thu, 03 Aug 2006 20:17:23 +0000

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.

isn't something wrong with cdrecord then?

joey — Thu, 03 Aug 2006 18:54:59 +0000

IANAKH, but doesn't this show that there is something fundamentally wrong with needing a userspace program that knows about different drive hardware, the scsi commands each needs etc and sends raw commands to the hardware? Why arn't they considering an abstraction layer? Fer instance:

cat foo.iso >/dev/cd_burn

Seems to me that device drivers exist to avoid exactly this kind of problem..

SCSI command filtering

pjones — Thu, 03 Aug 2006 14:47:11 +0000

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.

SCSI command filtering

abatters — Thu, 03 Aug 2006 13:38:06 +0000

> Presumably if you can rewrite the firmware, then with a bit of effort you can create some firmware which will use DMA to overwrite arbitrary sections of memory

Not really. SCSI devices are connected through HBAs (i.e. SCSI cards); the HBA has DMA access but the SCSI device itself does not. Rewriting the firmware of the SCSI device wouldn't grant arbirtary access to system memory; you would have to alter the firmware on the HBA or change the HBA driver to do that.

SCSI command filtering

rwmj — Thu, 03 Aug 2006 11:05:34 +0000

Presumably if you can rewrite the firmware, then with a bit of effort you can create some firmware which will use DMA to overwrite arbitrary sections of memory - in other words, all your security has just gone out the window on any machine with local users and an attached CD/DVD drive.

Sounds like Linus is right ...

Rich.

SCSI command filtering

NRArnot — Thu, 03 Aug 2006 11:02:52 +0000

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?