Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

From: Julien Oster (lkml-7994_at_mc.frodoid.org)
Date: 08/22/04

  • Next message: Julien Oster: "Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices" 
    To: Pascal Schmidt <der.eremit@email.de>
Date:	Sun, 22 Aug 2004 23:27:44 +0200

    Pascal Schmidt <der.eremit@email.de> writes:

    Hello Pascal,

    > The open question is whether write permission really is meaningful
    > enough to allow arbitrary SCSI commands. I personally think "being
    > able to wipe the drive firmware" is too much, and since filtering
    > of vendor commands is generally impossible to do right, sending SG_IO
    > should require CAP_SYS_RAWIO capability.

    But what about the following (the first 3 points are already
    familiar):

    1. require read permission to do read()
    2. require write premission to do write()
    3. require CAP_SYS_RAWIO to do SG_IO
    4. insert an initially blank (i.e. "drop everything") userspace
       controllable filter which allows the administrator to specify
       allowed SG_IO commands to the kernel at any time

    That way there is no security problem, CD burning as root or generally
    with CAP_SYS_RAWIO is always possible *and* admins are able to submit a
    list of allowed commands to the kernel, so that CD burning as user is
    possible again. This list might be specific to the CD writer hardware,
    as we learned that some drives require vendor specific commands.

    Prewritten filter lists for specific hardware can be published on
    internet or even be submitted by cdrecord or other burning software,
    i.e. with a switch "--install-filter" as root.

    The filters should be separate for each SCSI device, so that you won't
    enable dangerous commands on harddisk partitions when you just wanted
    to enable CD burning.

    If nobody else volunteers, I'll see if I can prepare a patch. I guess
    sysfs is the right place for the userspace interface to the filters?

    Regards,
    Julien
    -
    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: Julien Oster: "Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices"

    Relevant Pages

    • Re: [opensuse] wheres novell? (bit of a rant)
      ... On Sunday 27 April 2008 10:29, Kai Ponte wrote: ... Links" filter associated ... Likewise for the HTML interpretation option and two of the three header ... For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx ...
      (SuSE)
    • Re: [PATCH] allow root to modify raw scsi command permissions list
      ... In the current scsi_ioctl filter it applies to everything. ... My patch leaves the defaults as what are currently in the kernel. ... commands should and shouldn't be allowed. ... > only root, allow filtered, allow all? ...
      (Linux-Kernel)
    • Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices
      ... > MODE SELECT could not be in the list of safe ones. ... So a filter would have to be smarter than just checking the command ... commands which filters on accessible mode pages. ... > and vendor unique SCSI commands in order to give nice features. ...
      (Linux-Kernel)
    • Detailed discussion of seeking requested Re: preroll
      ... I'm working on another filter right ... now but hopefully I'll get back to the preroll issue in the next week. ... Commands" are sent upstream from the Renderer; ...
      (microsoft.public.win32.programmer.directx.video)
    • Re: UserRPL Matrix Evaluation functions
      ... While it seemed logical to me to *accept* lists as input ... vs. the "type 29 array" form, ... *but* there are very neat array-oriented UserRPL ... while *none* of those UserRPL commands ...
      (comp.sys.hp48)