Re: SG_IO and security

[Kai Makisara]

On Fri, 13 Aug 2004, Jeff Garzik wrote:

> Peter Jones wrote:
> > On Thu, 12 Aug 2004 22:22:36 +0300 (EEST), Kai Makisara
> > <kai.makisara@xxxxxxxxxxx> wrote:
> > 
> >>On Thu, 12 Aug 2004, Linus Torvalds wrote:
> >>
> >>>Let's see now:
> >>>
> >>>      brw-rw----    1 root     disk       3,   0 Jan 30  2003 /dev/hda
> >>>
> >>>would you put people you don't trust with your disk in the "disk" group?
> >>>
> >>
> >>This protects disks in practice but SG_IO is currently supported by other
> >>devices, at least SCSI tapes. It is reasonable in some organizations to
> >>give r/w access to ordinary users so that they can read/write tapes. I
> >>would be worried if this would enable the users, for instance, to mess up
> >>the mode page contents of the drive or change the firmware.
> > 
> > 
> > Sure, but for that we need command based filtering.
> 
> We have that now (sigh).  See attached patch, which is in BK...
> 

This patch looks OK except that it includes the command WRITE BUFFER. It 
is used to flash the firmware for many devices. Even the SCSI standard 
(draft) specifies that mode 06h is "Download microcode and save". This 
command _should be removed_ from the list of allowed commands.

> A similar approach could be applied to tape as well.
> 
As far as I can read the code, the filtering applies to all devices. 
Except WRITE BUFFER, the commands are acceptable for tapes considering the 
opening mode or undefined for tapes. The undefined commands may cause a 
device with bad firmware to lock the SCSI bus and in this way to cause DoS. 
However, this applies also to commands defined for a type of device but 
not implemented because they are optional.

I am ready to accept this risk of DoS (provided that allowing the filtered 
commands is really useful for somebody) but this is a risk we must 
recognize.

> Though in general I think command-based filtering is not scalable...  at 
> the very least I would prefer a list loaded from userspace at boot.
> 
I think always requiring CAP_RAWIO would be the approach of least 
surprise.

-- 
Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/