The first part (setuid capture + normal display) was what I had in mind,
but the second part (setuid capture + nonpriv display + normal file)
sounds even better. Keep in mind that OSes such as Free/Net/OpenBSD
and Solaris can restrict capture access at the filesystem level, so root
privileges may not be needed in those environments. It may not even be
needed on Linux if and when POSIX capabilities ever see the light of day.
Adding an IPC layer between capture and display implies that we'd have
some sort of (adjustable) buffer for transferring frame data. This is
a feature most other protocol analyzers have that we don't.
Also, the Windows universe doesn't have setuid(). To add equivalent
functionality we could create a capture service. It looks like the
rpcapd daemon that ships with the latest version of WinPcap may be
something we can use.
On 28 Aug 2003, Devin Heitmueller wrote:
> The first part is clearly the more critical, especially given that I
> believe many people, and definitely most people not conscious of
> security, will run Ethereal as root, and any malformed packet can crash
> their system or worse. I believe this is consistent with Gerald's
> vision, given that this requires splitting out the display/dissection
> code from the capture code. My initial thought regarding how to address
> this problem is to allow the binary to be run setuid root (determining
> who can run the binary will be dictated by group membership for a group
> named ethereal). The program will start setuid root and start two
> children. The first child will be responsible for operating the capture
> interface. The second child will be responsible for the
> display/dissection interface. The two can communicate via unnamed pipes
> or some other transport. This will create a model where only the
> capture code itself runs as root, everything else runs as the
> non-privileged account. Further, only a problem in the capture library
> itself, or the transport between the two daemons, can result in root
> compromise.
>
> The second phase is more ambitious, because it would require the bulk of
> the dissection code to not run as either root or the non-privileged
> user, but rather a third user account that does not have the privilege
> of the regular user. We could have a user called "ethereal". The
> setuid root copy of Ethereal starts, forks off the capture subprocess
> (uid=root), forks off the dissection/display process (uid=ethereal), and
> forks off the filesystem access process (uid=original user). The
> filesystem access process is required in order to read captures that the
> original user has access to, and to be able to save captures back to
> disk. In this model, a compromise of the display/dissection code
> results in arbitrary code execution as the "ethereal" user, which
> effectively has no permissions. We might even be able to chroot the
> process.
>
> Ok, I've rambled enough for one afternoon -- I'm just trying to get a
> dialog going on this issue, given that Gerald brought it up and I've
> been thinking about it for a few weeks.
>
> --
> Devin Heitmueller
> Senior Software Engineer
> Netilla Networks Inc.
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
