lkml.org 
[lkml]   [2004]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: dynamic /dev security hole?
    From
    Date
    On Sun, 2004-08-08 at 11:58, Marc Ballarin wrote:
    > On 08 Aug 2004 08:47:40 -0400
    > Albert Cahalan <albert@users.sf.net> wrote:
    >
    > > Suppose I have access to a device, for whatever legit
    > > reason. Maybe I'm given access to a USB key with
    > > some particular serial number.
    > >
    > > I hard link this to somewhere else. Never mind that an
    > > admin could in theory use 42 separate partitions and
    > > mount most of the system with the "nodev" option. This
    > > is rarely done.
    > >
    > > Now the device is removed. The /dev entry goes away.
    > > A new device is added, and it gets the same device
    > > number as the device I had legit access to. Hmmm?
    >
    > This would require (1) /dev to be inside the root filesystem and (2) users
    > having write access somewhere in that filesystem.
    >
    > (1) is uncommon, often a separate filesystem is used for udev
    > (2) is very bad practice anyway and should never be seen on a true
    > multi-user machine

    Sure, blame the admins. This is like leaving landmines
    in your front yard, then blaming people who step on them.

    > Besides, this is nothing new. Dynamic permission updates through PAM have
    > the same issue, and anyone calling themselves "admin" should be well aware
    > of those issues. This is basic Unix-security, after all.

    This isn't, or at least shouldn't, be basic UNIX security.

    PAM should call revoke(), except that Linux still doesn't
    have this system call. It's been in BSD since 4.3BSD-Reno.
    Calling revoke() would fully solve the PAM problems. Any
    open file descriptors would be useless. Any hard links to
    the device file would get the new permission bits via the
    shared inode.

    IMHO, hard links need to be severely restricted by default.
    It's a waste to make this even a boot option, since almost
    nobody would have a legitimate need for the current behavior.
    Perhaps there are other ways to deal with the problem though.

    > Yet, this issue should probably mentioned in documentation. It certainly
    > should be mentioned in the udev-HOWTO.

    You don't have to document problems if you fix them.


    -
    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:3.909 / U:0.088 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site