[radvd-devel-l] [RFC] Add privilege separation capability on Linux hosts.

[Pekka Savola]

Thanks again for your extensive work.  I've merged all your three 
patches with some minor modifications.

I've put out a snapshot at 
http://www.netcore.fi/pekkas/linux/radvd-1.1rc3.tar.gz

On Wed, 23 Jan 2008, Jim Paris wrote:
> - it probably should be made a runtime option whether to enable
>  privsep, for those who really don't like to see an extra "root"
>  process lying around

I added an -s toggle to force singleprocess operation.

> - I hardcoded limits in the priviliged section (privsep_linux.c) so
>  the passed values wouldn't be inappropriate.  For some of them,
>  limits were already defined, but for others I had to make them up.
>  They should be checked for sanity, especially
>  MIN/MAX_AdvRetransTimer, as I have no idea about that one.

I've extended the range a bit to allow more testing (e.g., large MTU 
with jumbograms).

> - The communication with the pipe is one-way to keep things simple.
>  There's therefore no error indication if the writes fail.  Maybe
>  another pipe could be set up in the reverse direction (deadlocks
>  could be an issue), or the unprivileged code could wait a second and
>  read-back the /proc file to see if it's changed.  Or the priviliged
>  code could log it, but I wanted to keep that loop as straightforward
>  as possible.

Syslog seems to work, but some other mechanisms (e.g. stderr with 
debugging mode, or file logging) may or may not work as well.

> - The privsep happens after the chroot, so users would still need
>  /proc mounted in there.

Yep.  Some of my own thoughts:

  - it would be great if the master root process could be more confined 
as it currently basically needs to just write to proc and log if there 
are errors.  But I'm not sure if there is an easy way to do that.  I 
was thinking of Linux kernel capabilities (used e.g. by ntpd to allow 
adjusting the clock) but the controls are likely too coarse for this. 
(On second thought, if kernel capabilities would have been sufficient, 
we probably wouldn't even have needed the privsep to begin with.)

  - due to code duplication, I removed privsep_set and replaced it with 
an improved version of set_interface_var.  I'm not completely happy 
with code structure as it is (two different codepaths in two different 
files, when privsep is on/off, two different error messages; variable 
max/min checking only happens with privsep), but it's probably good 
enough.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings