Re: Why you should avoid world-writable directories

[avalon () COOMBS ANU EDU AU (Darren Reed)]

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