Re: why doesn't tcpdump drop privileges?

[Andrew Pimlott <andrew () pimlott net>]

On Tue, Jan 20, 2004 at 11:57:42PM -0500, Jefferson Ogata wrote:
> Andrew Pimlott wrote:
> > On Tue, Jan 20, 2004 at 07:20:13PM -0500, Jefferson Ogata wrote:
> > > Andrew Pimlott wrote:
> > > No, they couldn't. You'll still end up executing arbitrary code, and a 
> > > user shell is almost as bad as a root shell.
> >
> > *boggle*
> >
> > No offense, but you seem to have a very academic view of security.
> > "The unix security model is ugly, therefore it is useless."
>
> No offense taken, but my view is extremely practical, as I handle 
> compromises all the time. Also, I don't find the UNIX security model ugly 
> or useless; I'm not sure where you got that.

Sorry, I interpreted that in the wrong direction.  But the unix
security model is based upon userids, so if you think access to an
unprivileged userid is "almost" the same as root, it seems
tantamount to calling unix security "useless".

Anyway, can we at least agree that giving the attacker nobody is
a little better than giving him root?  :-)

> Oh yeah, sorry, I got the semantics of setuid mixed up -- that came from 
> some of the older brain cells.

I don't blame you: there are so many variants of the call, and the
interaction between all the ids is hard to keep track of.  Which is
why I double check the man pages every time I use them.  :-)

> But you really need to handle groups. 

Yup, I realized this later.

> > > Why do you think "nobody" is "safest"?
> >
> > Because nobody is conventionally defined to be a user who owns no
> > files.
>
> Better not to assume that. Files often end up belonging to nobody, 
> especially in NFS environments. Furthermore, there might not be a nobody, 
> especially if you chroot.
>
> Where I was going was that if you're going to do it this way, make the user 
> specify what uid to run as. Don't assume nobody is okay. As suggested by 
> others, if you have a dedicated user you're in better shape.

I agree that a dedicated user is better.  However, I still think
that defaulting to nobody will protect people (to some degree) on
most systems, and I think the risk of nobody being a bad choice is
low (certainly it can't be worse than remaining root).  If nobody
doesn't exist, oh well.

> There's a big problem domain you're not fully treating, which is what 
> happens when one process captures and writes to a pcap file, and someone 
> else comes along and runs a protocol dissector on the saved file later. 
> First, your patch is dropping privileges before opening the pcap file, 
> which looks out of order to me.

This is important so that a setuid tcpdump (I can't imagine why
anyone would do that, but it seems to be supported in the code)
can't open root trace files, as mentioned in the existing comments.
I didn't change this from the old behavior.

> Second, you can't protect an ordinary user 
> from compromising himself and exposing his "personal data" using "tcpdump 
> -r" on a bogus pcap file because that user can't setuid to the "safe" user.

I can't so I don't.  But at least if root uses -r, it will drop
privs.  I agree that the situation is imperfect, but I think the
change I'm suggesting can be done a long time before all tcpdump
protocol analyzers are redesigned to be robust.

> If you want to drop access to all files, chroot to an empty directory, then 
> setuid to a user that can't write to the directory. Then, for good measure, 
> rmdir the directory.

I'll look at Wietse Venema's code for this (thanks).  Of course, we
need to drop root as well, in which case we may as well still switch
to nobody.

Andrew
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe