1. The libraries are already protected by ownership (root usually).
2. Any penetration is limited to what the user can access.
3. (non-deskop or server) Does the administrator really want users
giving out access to the system to unknown persons? (I know, it's not
prevented in either case.. yet)
4. inetd already does this. Spawned processes do not have to run as root...
5. A chroot environment (to be usefull) must have libraries/executables for any
subprocesses that may do an exec. It doesn't matter whether it is done
by a user or by root, but with root, at least the administrator KNOWS
that the daemon process is untrusted, and how many are there, and what
accounts they are in... And can be assured that each gets a separate
UID, does/does not share files (and which files)...
6. There is no difference in the interpretation of setuid files between a
chroot environment, and outside a chroot environment.
Wait for the Linux Security Module - you may have a better way to define
access controls that DO allow what you want.
> [*] Yes, I know chroot is not sufficient on its own to completely
> protect against this, but it is a useful part of the puzzle, and
> there are other things we can do to deal with the remaining holes.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/