[lkml]   [2004]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: PATCH: cdrecord: avoiding scsi device numbering for ide devices
    Hash: SHA1


    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[*].

    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! :-)
    Version: GnuPG v1.2.5 (GNU/Linux)
    Comment: Using GnuPG with Thunderbird -

    -----END PGP SIGNATURE-----
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

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