Re: Why you should avoid world-writable directories

From: Darren Reed (avalonat_private)
Date: Tue Dec 22 1998 - 03:19:27 PST

  • Next message: Alan Cox: "Re: Why you should avoid world-writable directories"

    In some mail from D. J. Bernstein, sie said:
    >
    > 1. Anonymous snooping
    >
    > SECURITY HOLE: Any local user can stat() files in the IBM Secure Mailer
    > drop directory.
    >
    > IMPACT: Any local user can anonymously inspect the uids and sizes of new
    > messages. It doesn't matter how well the system administrator has
    > protected his process list, mail logs, and message transport mechanisms;
    > private information is freely available in the IBM Secure Mailer queue.
    
    Don't know about you, but when I'm not root on a machine which I use
    for mail, being able to view the queue in its entirity is akin to being
    able to use something like "ps" and see all processes, including ones
    which don't belong to you.
    
    Basically, "who cares" about anonymous snooping.  Unless you're in a
    highly secure and compartmentalized environment where you need to worry
    about cover channels, I can't see whether it matters that queue files
    are inspected directly or indirectly.
    
    Then again, I don't want to be so paranoid that I actually care.
    If "they" want to know then the chances are "they" will find out
    regardless of what I do.
    
    [...]
    > 5. Technical notes
    [...]
    > Certainly setuid programs require a great deal of care. They've been
    > involved in many security disasters, though far fewer than (for example)
    > world-writable directories. The security community would love to see
    > another portable IPC mechanism offering guaranteed user identification.
    > (I suggest that kernels add a getpeeruid() system call, showing the real
    > uid that called connect(), for UNIX-domain sockets and for loopback TCP
    > sockets.) However, while we're waiting, we need a few setuid programs.
    
    One is given to wonder why they're required at all, save for the obvious
    performance benefit.  Why not even have the local queuing performed over
    smtp ?  (btw, some systems already have a more enhanced getpeeruid()
    available for Unix-domain sockets - doesn't readily extend itself to
    being applied to TCP/UDP though).
    
    I'm surprised that you didn't mention the possibilities of file descriptor
    passing here.  Surely fstat() on an open file passed from the program with
    the file to queue to the queue daemon would achieve the same result.  If
    the process passing the fd (as the user) has been able to open the file,
    then surely that implies they have authority to send it via mail.  Of course
    that opens avenues of exploit up for programs which spawn subshells without
    revoking all privs/closing all files opened with privs :)
    
    Darren
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:25:43 PDT