Messages in this thread | | | Date | Sat, 14 Aug 2004 10:22:56 +0300 (EEST) | From | Kai Makisara <> | Subject | Re: SG_IO and security |
| |
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@kolumbus.fi> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |