On Thu, 2003-08-28 at 17:10, Gerald Combs wrote:
> 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.
Agreed. In general, I hate the idea of having the binary setuid root,
but I didn't see any other way to gain access to the capture interface.
The only other thought I had was to have the user su to root, run the
program, and then display a dialog asking what user to run the program
as. But I don't think this is very practical.
If we do go setuid root, then I think we should definitly go the extra
mile to restrict access by GID. By default, the permissions for the
binary would be rwsr-x--- UID=root GID=ethereal. Then the admin just
adds whatever users he wants to run the program to the "ethereal"
group. On the other hand, what happens if he wants to allow users to
run the program with no intent to capture. Would we need two copies of
Ethereal -- one setuid root for capturing, and a second that is not
setuid for non-capture use?
Haven't Linux POSIX capabilities been present in the kernel since 2.2?
I have never used them personally, but have kind of wondered why nobody
else has either.
Whatever we come up with, it would be worthwhile for it to be extensible
to operate in these different OS environments while exercising minimum
privilege. I am definitely for only running the capture interface as
root if absolutely necessary, and from what you have said, it would seem
that it is not for the BSD variants.
> 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.
Does it really need to be have an arbitrary limit for the frame size?
It would be nice if it could be dynamic. Can we make the transport
stream based, where we have a series of len+payload+len+payload etc?
> 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.
How does it implement access control? Ideally, on win32 it would be
nice if group membership could be used to dictate who could access the
interface to the capture service. This would allow administrative
control over who can do captures.
One more quick question -- is there any way to get the libpcap library
to allocate whatever resource it is that requires root, then drop
privilege. For example, in most setuid binaries, the program opens
whatever file handles it needs as root, then drops privilege. Is there
an equivalent that can be done for pcap? Perhaps we can have the
capture process start the capture, then fork and drop priv so that the
callbacks do not run as root. Something like this:
ethereal (setuid-root at start, then drop priv)
->ethereal_cap_start (root)
->ethereal_cap_processor (non-root)
->ethereal_display_cap (ethereal)
->ethereal_file_access (original user)
This would further reduce the risk, in that the ethereal_cap_processor,
which would be the process talking to ethereal_display_cap would not be
root, even though it is what is receiving the packets. This would
reduce the chance that a bug in libpcap or the IPC transport could
compromise root.
--
Devin Heitmueller
Senior Software Engineer
Netilla Networks Inc.
