Re: [PATCH] allow root to modify raw scsi command permissions list

From: Kai Makisara (Kai.Makisara_at_kolumbus.fi)
Date: 09/15/04

  • Next message: Theodore Ts'o: "Re: [PATCH] hvc_console fix to protect hvc_write against ldisc write after hvc_close" 
    Date:	Wed, 15 Sep 2004 23:49:21 +0300 (EEST)
To: Peter Jones <pjones@redhat.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
    > belongs.
    >
    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 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/
  • Next message: Theodore Ts'o: "Re: [PATCH] hvc_console fix to protect hvc_write against ldisc write after hvc_close"

    Relevant Pages

    • Re: [PATCH] allow root to modify raw scsi command permissions list
      ... Your patch allows updating the filters for each device. ... In the current scsi_ioctl filter it applies to everything. ... Looking at the command list reveals a couple of other problems: ... but would be safe for others. ...
      (Linux-Kernel)
    • Re: XPe SP2 with Domain Participation losing after 30 days
      ... Debbie, ... I knew about the new Filter but I didn't know it was officially released. ... I didn't know the EWF Registry filter patch was officially released. ... I do know that EWF version in SP2 does not have the functionality of the Registry filter. ...
      (microsoft.public.windowsxp.embedded)
    • Re: coretemp - take3
      ... CONFIG_CPU_HOTPLUG y/n ... versions of the functions (safe and unsafe). ... I attached the patch here. ... #ifdef CONFIG_PARAVIRT ...
      (Debian-User)
    • Re: floating check boxes on web pages
      ... Might re-read my post, the patch IS sp1. ... for Publisher help: ... The form control check boxes looked fine ... > the whole filter web ...
      (microsoft.public.publisher.webdesign)
    • Re: fuel tank leak - epoxy question
      ... Since YOU choose to effect such a feeble, potentially dangerous patch ... repair, and continue to drive the vehicle, I could only assume that YOU had ... A car with a leaking/patched/weak gas tank is neither incredibly reliable ... nor is it incredibly safe. ...
      (rec.autos.tech)