On Tue, Jan 20, 2004 at 07:20:13PM -0500, Jefferson Ogata wrote:
> Andrew Pimlott wrote:
> >Every once in a while there is a security alert about tcpdump being
> >hackable through one of the many protocol analyzers. Couldn't these
> >be prevented simply by unconditionally dropping privileges as soon
> >as the interface is opened?
>
> 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."
> >+ /* Attempt to drop back to nobody. This is safest. */
> >+ nobody = getpwnam("nobody");
> >+ if (nobody && nobody->pw_uid)
> >+ setuid(nobody->pw_uid);
> >+ /* If there is no nobody (?!), at least drop back to original uid */
> >+ else
> >+ setuid(getuid());
>
> Your patch does not set euid.
I coded according to the documentation on my system:
setuid sets the effective user ID of the current process. If the
effective userid of the caller is root, the real and saved user ID's
are also set.
Are you saying this is wrong? If so, the old code is just as
broken.
> Why do you think "nobody" is "safest"?
Because nobody is conventionally defined to be a user who owns no
files.
> Capabilities are a better approach
> to this particular problem, since they make no assumption about what uid to
> setuid to, and instead can grant the capture capability to a regular user.
First, capabilities are potentially a much better approach, but I
didn't want to think of coding that portably, especially in a trial
patch. Second, even if my userid can be given a capture capability,
I still don't want to give an attacker access to my personal data if
there is a bug in tcpdump.
This is about running with the lowest lever of privilege possible.
One part of that is dropping access to all files. "nobody" is the
best way to do this that will work on a wide range of systems. I'd
love to go further (deny the ability to create sockets, etc), but
there's no portable way.
> The real solution to the periodic dissector vulnerabilities is to devise an
> abstract language and virtual machine which is provably safe for doing
> protocol dissection. If this were done correctly, the virtual machine would
> be BPF (or something better) and the same VM, compiler, and optimizer would
> be used for protocol analysis as for filtering. And with a tiny bit more
> cleverness, the dissector could work in reverse to construct the protocol
> as well. The existing BPF bytecode would be able to do the vast majority of
> protocol dissection, if only the compiler were a bit more generic. A
> successor to BPF with a lot more registers and a mechanism for storing into
> a non-register data structure would be ideal.
You can go do a PhD thesis on this if you want, but I'm interested
in making simple but useful changes. :-)
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]
