On Tuesday, October 19, 2004 12:23 PM, Ulf Lamping wrote:
James Walden wrote:
[...]
>> When looking at Ethereal about this topic, I think about two main
>> parts:
>>
>> - live capturing from the network (usually requires root privileges)
>> and put that data on the harddisk. As the capturing code amount is
>> limited, this code could be reviewed with safety in mind, so it
>> should be possible to make it "bullet proof " (well, you will never
>> have 100% safe code)
>>
>> - decoding of protocols, showing them on the screen and all the other
>> GUI related things (requires only user privileges, like open files
>> and such). As the dissection is spreaded about a lot of code,
>> provided and maintained by a lot of different persons, it might be
>> nearly impossible to get really bullet proof code from this (of
>> course, trying to achieve security is always a good idea anyway).
>>
>> So this indicates, that we should split the capturing of data from
>> dissecting and showing it.
>
>
> I agree that those are the essential two cases, separating root
> privileges from user privileges, but I think Devin's idea of an
> additional separation of user file privileges from the protocol
> dissection part of ethereal, which doesn't need to touch files itself,
> is also good, as it would prevent malicious packets from trashing the
> running user's files or subverting his account.
>
Well, I do agree on Devin's idea for the reasons already explained.
But, what I always search for is getting the most benefit from the least
effort (yes, I'm usually working on win32 :-). Separating the capturing
engine from the rest shouldn't be too hard to achieve, I already have an
idea about how to do that (will outline that in another mail) and this
will get the most security benefit I would think.
There might be simpler and more performant ways to accomplish the goal of
having minimal privileges.
Specifically, on Win32 systems prior to NT, there is no point trying
(everything is root equivalent). On Win32 systems from WinNT onward,
winpcap accesses things through a driver which is internally accessing some
sort of device. Security Attributes could be set on such a device which
granted access to specific users or groups (which can be disjoint from
general administrator privs).
Likewise, on Unix/Unix-like systems which use BPF devices, packet capture
can be done by any user who has access rights based on the permissions of
the bpf devices. These permissions can be set in relatively normal ways,
but default to root only access.
The remaining platforms with significant numbers of systems are Linux. I'm
not sure of the details here, but I seem to recall some plans for selinux to
be able to provide some abstract permissioning disjoint from root (I thing
the term was capabilities or something).
Some platforms don't necessarily have device specific permission s available
to access there kernel level packet capturing facilities. These platforms
could either continue to require root or someone could devise interesting
ways to help with these.
So, in the end, most of this problem can be addresses by external setup of
something about your capture environment, which oncec done can leave all of
the capture programs not requiring root privs.
The ethereal project may want to proviide a tool which helps users (admins)
do the permissioning setup on all of the available platforms, so then normal
(possible specific) users can use the capture tools.
Seperating the dissection engine from the rest of the Ethereal code will
be possible, of course. But that will be a lot of work IMHO (I don't
have an idea how to do, and to be honest don't even want to know for
now), but that solution wouldn't get the security boost compared to the
solution I've outlined.
The disection separation issue is clearly important, but certainly not as
significant once the root problem is gone. I also agree that this will be
harder to do.
It's just about judging the effort to do and the benefit getting from
it. I'm just talking about what I'm able (and maybe going) to implement.
Of course, I would be happy if someone assist me on this topic.
Regards, ULFL
- Mark Pizzolato
