Sam Steingold wrote:
> Suppose one has an application which is installed setuid root.
> Suppose also the application has a feature (e.g., spawn an interactive user
> shell) which should NOT be run as root - but as an unprivileged user instead.
> I suppose this is a fairly common operation ...
The general opinion, among security aware developers, already for 10 years,
is that the amount of code which is executed with setuid root permissions
should be minimal.
Instead of considering a large program running as root, with a few
functionalities running unprivileged, it is better to run only those little
parts of the program with setuid root that need it.
There are multiple reasons for this:
- Less code to review for security flaws,
- Smaller probability that a stack overflow based exploit can be used
to get root privileges,
- Makes it easier to add new features without thinking about security.
A good example of this architecture is the glibc function that creates a
new pty/tty pair. It uses a setuid program /usr/lib/pt_chown which has
very little code.
More generally, you can split any program into a "main" part and a "setuid-root"
part. Let the latter run as a child process of the former one, and let them
communicate through a protocol as simple as possible (command line options or
pipes).
gnulib has the modules 'posix_spawn', 'execute', and 'pipe', to help
creating child processes.
Bruno
