lkml.org 
[lkml]   [2004]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: PATCH: cdrecord: avoiding scsi device numbering for ide devices
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Hi!

    Bill Davidsen wrote:
    | Tonnerre wrote:
    |
    |> Well, for that it might be a nice feature to register and delete such
    |> filters online, using a register/remove_scsi_filter interface, but
    |> well, otoh that might be undesirable security-wise.
    |
    |
    | Let me throw out two ideas to see if anyone find them useful.
    |
    | 1 - loadable command filters in the kernel.
    |
    | Each device could have a filter set, which could be empty to require
    | RAWIO capability, or set to a kernel default. Access could be made to
    | modify a filter via proc, sysfs, or ioctl. The set method is not
    | relevant to the idea.
    |
    | 2 - a filter program.
    |
    | This one can be done right now, no kernel mod needed. A program with
    | appropriate permissions can be started, and will create a command/status
    | fifo pair with permissions which allow only programs with group
    | permission to open. This allows the admin to put in any filter desired,
    | know about vendor commands, etc. It also allows various security setups,
    | the group can be on the user (trusted users) or on a setgid program
    | (which limits the security issues).
    |
    | Note that the permissions on individual devices need not be the same; I
    | can have one group for disk, another for CD/DVD. You caould even be anal
    | and have the filter time sensitive, etc.
    |
    | A 'standard" place for the fifos helps portability, /var/sgio/dev/hda
    | might be a directory, with fifos command and status.
    |
    |
    | Okay, did I miss something, or can this be solved without any additional
    | kernel hacks?

    Sorry for jumping in this (hot) thread, but I just want to say something:

    This is, IMHO, the way to go. Keeping static white-lists in the kernel
    is bad and goes against the 2.6 moto: "do it in userspace".

    Anyway, I can imagine that the distros are thinking about the problem
    very hard. They can't just delete the cd-burn feature as non-root :-)

    Also, many things can be affected by this, right? Scanners, jukeboxes,
    ip-over-scsi, etc... A programmable kernel interface or a userspace
    helper is the only way. To keep things _fast_, I'd be happy with a simple
    # echo 1 > /sys/block/hdd/rawio/enable_rawio_if_user_can_write
    brw-rw---- 1 root disk 22, 64 Mar 14 2002 /dev/hdd
    Now every member of @disk can trash your data and your cdrom's firmware.

    If the admin sets this flag it's his responsability[*].

    Peace,
    Nuno Silva

    [*] Once you start refusing to let root shoot himself in the foot
    there's no way back. You must "fix" 60% of Linux! :-)
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.5 (GNU/Linux)
    Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

    iD8DBQFBKqZVOPig54MP17wRAgE0AJ9LjIKpK+S1nqBYYbOZywVontBdggCdGbF6
    Uf2Ok3aFvCbXp6k4Wq7Pn2A=
    =cEo2
    -----END PGP SIGNATURE-----
    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 14:05    [W:0.026 / U:0.360 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site