http://ask.slashdot.org/comments.pl?sid=138603&cid=11599438
A comment in Slashdot reminding me of why ethereal is no longer
ported to OpenBSD, and the fact that I just upgraded my oBSD
firewall (lamenting this exclusion), has prompted me to write
this.
Perhaps it's time to build some firewalls into ethereal. This
would actually consist of two different parts:
One is priveledge seperation.
The other is dissector categorization.
Priveledge seperation would allow the capture and dissection
parts of ethereal to run as a non-root user. Generally the
only reason why you need root prives for ethereal is to open
the ethernet ports. Once this is done, you can safely drop
permissions to a regular user (or 'nobody') to peel apart the
received packets.
This would cut down on the probability of any exploit in
being potentially escalatable into a remote-root exploit.
Categorizing disssectors based on their security would have
two purposes:
1) I propose that, by default, only the most 'secure' of
dissectors be enabled by default. Users who want the
less secure dissectors (because they need them and/or
they'r not in an overtly 'hostile' environment. could
enable the rest explicitly.
This would cut down on the possibly of being remotely
compromised by someone sending a packet that engages
a little=used but buggy dissector to hack your system.
2) It would encourage people to design their code well and
run it thru an audit process. I think that most people
would prefer to have their dissector in the 'tier 1'
class. To do so would require a bit of extra work,
but there would be a noticable increase in the prestige
gained by tneir module by doing so. At the moment,
there seems to be little, if any, impetus to 'clean up'
a dissector once it's been accepted into the ethereal family.
--------------------------------------------------------
Priv sep:
Some things that I can think of: Privelege separation, in
it's first form would take the form of forking off a non-priveldged
child process to do the actual work of dealing with packets.
If ethereal is run natively as root, this would be done after
files are opened. If ethereal is run setuid, then it would
be done after the interface is opened but before the file is
opened. It might be appropriate to give users the option
of switching to 'nobody' permissions to do the processing
even if they're not root. (compile-time switch, I'd guess).
File I/O is a bit more of a sticky wicket when using rotating
logs. I think that this could be handled by having the capture
process write related packets to a pipe. The pipe would be
read by a priv-sep process which would open the appropriate
file, and then fork off a child to do the actual reading.
The child would exet once it's file was full, causing it's
parent to fork off yet another child to write to the next file.
Since the work it does is relatively minimal, the child process
would (should) be relatively easy to audit and keep secure.
Make sense?
--
Stephen Samuel +1(604)876-0426 samnospam@xxxxxxxxxxx
http://www.bcgreen.com/
Powerful committed communication. Transformation touching
the jewel within each person and bringing it to light.