Re: [PATCH] allow root to modify raw scsi command permissions list
From: Kai Makisara (Kai.Makisara_at_kolumbus.fi)
Date: Wed, 15 Sep 2004 23:49:21 +0300 (EEST) To: Peter Jones <email@example.com>
On Wed, 15 Sep 2004, Peter Jones wrote:
> On Wed, 2004-09-15 at 22:14 +0300, Kai Makisara wrote:
> My patch leaves the defaults as what are currently in the kernel.
Yes but what I wanted to say the filter currently in the kernel is not
safe for all devices.
> > I have already commented on MODE SELECT. I still think it is dangerous.
> It's only marked as being allowed if you have write access; /dev/hda
> usually isn't a+w, last I checked.
I am thinking about other devices than disks. Tapes are what I know best
but there are also other device types (all that support SG_IO).
For tapes it is fairly common to allow users read/write permissions for
reading/writing tapes. MODE SELECT allows a user to mess up the drive
parameters so that the next user thinks it is broken. This is not the
purpose of giving read/write permissions in this case.
> I'd actually say that this isn't suitable for CD drives. To do CDDA
> reads in many cases you need MODE_SELECT. As such, CD drives should
> have MODE_SELECT in the list of things allowed to read. But the point
> is that this gives control of the policy to the userland, where it
This is why I like your approach.
> My intent with the patch isn't really to take any stance on which
> commands should and shouldn't be allowed. In fact, it's quite the
> opposite -- this allows initscripts/hotplug to install an appropriate
> list of commands for each device.
If you are not taking a stance, then the default list should be empty.
The starting point must be safe and it can be relaxed. I am just trying to
have a safe enough starting point.
In an ideal world the initscripts/hotplug scripts would be updated
instantaneously and the empty default would not be a problem. In the real
world this does not happen and we have decide how far we want to relax the
default security. I think this is why Linus added the filter: he wanted
to allow users to burn CDs without special permissions. This is why I
suggested that the default filter should allow the current default for
CDs. It is a compromise.
> > This could also be done in your approach. One possibility would be to
> > start with empty filter and call from CD/DVD registering a function that
> > sets the filter you currently have as default. This would be both flexible
> > and safe.
> I don't want to do an empty filter, because that'll mean existing users
> of SG_IO and such break for no real reason. The approach my patch takes
> is not to change *any* of the existing policy, but to enable distros to
> change it to their hearts' content. It's *dead* simple to make
> initscripts and hotplug pick "correct" lists for each device.
I don't know any other SG_IO users than CD/DVD software that try to use
passthrough without CAP_RAWIO. This is probably politically incorrect, but
no sane software developer expects to be able to send raw commands without
proper permissions. If this kind of security hole is present, it will be
plugged sooner or later.
-- Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/