tcpdump mailing list archives
Re: why doesn't tcpdump drop privileges?
From: Andrew Pimlott <andrew () pimlott net>
Date: Tue, 20 Jan 2004 21:29:46 -0500
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:tcpdump-workers-request () tcpdump org?body=unsubscribe
Current thread:
- why doesn't tcpdump drop privileges? Andrew Pimlott (Jan 20)
- Re: why doesn't tcpdump drop privileges? Jefferson Ogata (Jan 20)
- Re: why doesn't tcpdump drop privileges? Andrew Pimlott (Jan 20)
- Re: why doesn't tcpdump drop privileges? Jefferson Ogata (Jan 20)
- Re: why doesn't tcpdump drop privileges? Andrew Pimlott (Jan 21)
- Re: why doesn't tcpdump drop privileges? Jefferson Ogata (Jan 21)
- Re: why doesn't tcpdump drop privileges? Andrew Pimlott (Jan 23)
- Re: why doesn't tcpdump drop privileges? Andrew Pimlott (Jan 20)
- Re: why doesn't tcpdump drop privileges? Ryan Mooney (Jan 21)
- Re: why doesn't tcpdump drop privileges? Jefferson Ogata (Jan 21)
- Re: why doesn't tcpdump drop privileges? Jefferson Ogata (Jan 20)
- Re: why doesn't tcpdump drop privileges? Andrew Pimlott (Jan 20)
- Re: why doesn't tcpdump drop privileges? Andrew Pimlott (Jan 20)
- Re: why doesn't tcpdump drop privileges? Pekka Savola (Jan 20)