Wireshark · Ethereal-dev: Re: [Ethereal-dev] Privilege Seperation for Ethereal

[Devin Heitmueller <dheitmueller@xxxxxxxxxxx>]

Hello Ulf,

I have been giving this some thought for a while as well.  I think a
third privilege level is worthwhile considering (and you touched on this
briefly at the end of your email).  This would be to have a totally
non-privileged user that would do dissection.  This user would not even
run with the permissions of the user running the application.  

So, we would actually have three roles:

1.  Capture (root [or nonpriv on certain BSDs])
2.  Dissection (non priv user that doesn't even have rights of the user
running the application).  We could also look at chroot'ing the
dissection user to minimize filesystem access.
3.  Filesystem (original user running Ethereal)

Permit me to expand on the third role a bit (and the difference between
2 and 3).  In most interactive uses, the user who runs Ethereal will
want to be able to load and save capture files.  This requires the
permissions of the user.  However, it would also be desirable to have it
so that a bug in the dissector does not result in execution of arbitrary
code as the user.  By separating out the two roles, you can allow the
user to access his/her capture files, but still not have a dissector
security hole execute as the original user.

One more thing to consider.  To do any of this, the Ethereal program
will either need to run setuid root so it can setuid to the different
users, or have some sort of daemon facilities that operate in different
roles.  I don't know the best answer to this, but it's something to
consider.

Also, you will need to consider what type of IPC you want to employ
between the different modules.  Whatever type of messaging you use could
be open to attack in terms of the IPC protocol implementation.  There
would also be a performance consideration as well.  The IPC between the
different processes could have a significant impact on performance with
large captures.

One more question, and this is probably best directed at the libpcap
people -- is there any way to get a filehandle to the capture facility,
and then drop privilege?  If so, then this would be a good step in the
right direction.  I suspect though it would require changes to the
kernel interface that reports the packets to userspace.

Just some random thoughts on the subject.  Take it for what it's worth.

Devin

On Tue, 2004-10-19 at 13:29, Ulf Lamping wrote:
> Hi List!
> 
> As that's a requested feature, we might first think about how to achieve 
> this (and I don't have much knowledge on this, but willing to learn :-).
> 
> Having looked at the web about Privilege Seperation at all, didn't found 
> good resources on the web, does someone has a good tip?
> 
> However, as far as I understand it, it's about split a program into 
> parts which then will run at the lowest privilege they need to do the 
> task they have to, but not more.
> 
> 
> 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. The capturing should be hardened and could be 
> run in root mode, while the dissection code runs "only" under user 
> privileges. If security concerns are really huge, even a special 
> ethereal user could be created to get a "sandbox" for the dissection 
> code so it can't do any real harm.
> 
> 
> Do I dig into the right direction?
> 
> Regards, ULFL
> 
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
-- 
Devin Heitmueller
Senior Software Engineer
Netilla Networks Inc.

Attachment: signature.asc
Description: This is a digitally signed message part