robert at linuxfromscratch.org
Fri Sep 12 18:38:16 PDT 2008
On Friday September 12 2008 02:38:43 am Jan Dvorak wrote:
> On Friday 12 September 2008 02:14:33 Robert Connolly wrote:
> > Some daemons still run as root, even with privilege separation, like
> > fcron, dhclient, etc.
> fcron has to run with full set anyway, or not?
Almost always no. crond only needs to do what you need it to do. If the only
thing in root's crontab is to run /sbin/ldconfig, then almost all
cababilities can be removed.
In practice we can disable all capabilities on /usr/sbin/fcron, try to start
it, and from the errors we can figure out the minimum capabilities it needs.
Normally, fcron would not need the capability of loading kernel modules, for
example. Grsecurity can nail it down futher.
As far as I know, any process running as root can have some of its
capabilities stripped and work properly after. The reverse works too, in that
a normal user could run a daemon with some of root's capabilities. With
enough trial and error, even udevd and agetty can run as non-root users, or
root with limited capabilities.
None of these daemons needs all the privileges of a root shell, like having
write permission on every file.
I want to write a set of rules for the onward-branch (new trunk) wiki/book...
like don't add packages with suid-root until you have caps or grsecurity
rules (or both) to limit it, don't break test suites by upgrading or adding
patches (fix the testsuite if you have to), add as many details/comments as
possible to all patches (especially origin). Start over, again, but better
prepared this time.
> > Installing packages as regular
> > users would limit this, so I think it'd be a good idea to integrate the
> > more_control_and_pkg_man.txt in the final system.
> I've had two systems with package users ~2 years back. One of them being
> HLFS. You don't want to do that, believe me, you don't want it. Besides,
> if you insist on having binaries installed as non-root, you have
> historical user called bin for this.
I don't know of competitive alternative.
Everything could be installed at user 'bin'. This doesn't stop files from
being overwritten, but it's a step in the right direction.
Installing as a package-installer-user, like the more_control_and_pkg_man hint
does, makes it easy to identify all new files for backups or checksums (with
find(1)), without any advance information about exactly what files will be
installed. If you're creating a package, from scratch, this is the best
system to use.
This is not package management, it's filesystem management.
The more_control_and_pkg_man.txt hint system is tedious, but it identifies
every problem with filesystem permissions and packages, for us. It's a big
I admit that this starts getting very complicated on multi-purpose systems
like a desktop, but it can be done one step at a time. It needs to be well
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
More information about the hlfs-dev