[radvd-devel-l] [RFC] Add privilege separation capability on
pekkas at netcore.fi
Thu Jan 24 05:27:00 EST 2008
Thanks again for your extensive work. I've merged all your three
patches with some minor modifications.
I've put out a snapshot at
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
> - 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
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
More information about the radvd-devel-l