On Tue, Feb 24, 2004 at 10:40:39PM +0200, Pekka Savola wrote:
> Yep, setuid is possibly borked in a few corner cases -- I haven't
> tested it.  I assume folks don't compile with --with-user when they
> want to enable setuid (pretty seldom, I guess).  But with extra
> checking, this might be avoidable.
> 
> My threat analysis is that dropping root and chrooting when tcpdump is 
> run as setuid is not worth the trouble.  Switching to the getuid() is 
> sufficient: you'll just hose the account you run tcpdump as, not root.

I'm fine with that.  I think all we need to do is make sure we only try
droproot() when euid is still 0.

> > In my patch, I tried to handle this by only dropping euid before opening
> > files, so that we can later restore euid and do a full droproot(), which
> > is (arguably) better than just dropping back to ruid.  
> 
> My argument against this is that even if you drop euid, if
> compromised, the attacker can restore the privileges, so you aren't
> adding much security, just more complexity.  I'd either drop the
> privileges alltogether, or don't drop them at all.

Note that after all the files have been opened, I restore euid, then
drop privileges permanently.

> > -/* Drop root privileges */
> > +/* 
> > + * Drop privileges.  Assumes we currently have euid 0.
> > + * Parts cribbed from Wietse Venema's chrootuid.
> > + */
> 
> IMHO, dropping root and chrooting should be two separate functions, as 
> they serve two distinct purposes.

I think they serve exactly the same purpose:  To lower the privilege
level of the process as much as possible.  That's why, when I wrote it,
I called it drop_privileges().  I don't think there is any time you'd
want to do one and not the other.

> > +   if (mkdtemp(chrootdir) == NULL)
> > +           error("couldn't create %s", chrootdir);
> > +   if (chdir(chrootdir) != 0)
> > +           error("couldn't chdir to %s", chrootdir);
> > +   if (rmdir(chrootdir) != 0)
> > +           error("couldn't remove %s", chrootdir);
> > +   if (chroot(".") != 0)
> > +           error("couldn't chroot");
> 
> you're rmdir'ing before chroot'ing ?

It works on my Linux system and prevents the directory from being left
behind as garbage.  I bet it works on most unix-like systems, but I
would be interested to see counter-examples.  :-)

Andrew
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]

Reply via email to