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]