> I am attempting to implement a security policy for my machine which i
> like to think of as "neutering root".
>
> The basic idea is simple...dangeerous(and sometimes not so dangerous)
> system utilities can be made completely unavailable to the system by
> locating them on encrypted loop devices.those facilities so located
> can be switched out of the syustem at anytime by simply unmounting
> the loop device.this is incredibly more secure than the joke which
> is unix file permissions/group access, yet still maintains complete
> compatibility with it.
The existence of "dangerous" programs is unimportant, setuid bit on
some of them is what makes system vulnerable. And most of
remote-exploitable security bugs allow file transfer to the victim's
system, so there is no point disabling an access to non-setuid programs
(not to mention that they are necessary for the base system
functionality). Once anything started as root, and can execute a code,
sent to it (like, in all buffer overflow bugs), removing access
to any executables is completely ridiculous. The only two solutions I can
imagine, are:
1. (obvious): make it impossible to get a root access for the intruder.
root is always root, and if it can execute code, and code can modify
memory and do data transfer, there is no protection against it. The idea
of allowing access to uid-changing to selected sections of code, and
allow changing uid _to_ 0 in some section instead of making executable
setuid, can limit the amount of code that is running as root, thus
reducing the amount of work to clean it.
2. Create absolutely closed environment, where what looks like root
locally, is a regular user for the rest of the system. Discussion about
improving chroot jail (limiting access to system calls for chrooted
processes) contains some good ideas about that.
[skipped]
> in order to complete the development of the concept.. i need the ability to
> mount encrypted loop devices ONLY on a PER SESSION basis.in order to
> effect some convenience in the use of multiple sessions by the authorized
> root eg through screen... we would have a selectable option to allow
> only interactive child sessions to have equivalent loop device access to the
> root parent mounter. logging on in another terminal, however, would
> entail giving the loop password again in order to gain access.
This looks like VMS feature... But even though it probably could be done
by some kernel rewriting, the problem is not actual mounts or encryption
processes, the need of having working system will require such access to
be present on almost every process that is running as root.
> further...this would allow the system users to have their home directories
> set up on encrypted loop devices and thus unaccessible in a substantial
> and real sense to anyone else on the system... even root.
This is useless -- root can always intercept loop and see unencrypted
data when it's accessed locally and all keys when they are transferred.
Only remote access where data is encrypted/decrypted on another,
unavailable for local root physically box, can be secured that way (and
encrypting RPC when running NFS over it will do that).
[skipped]
-- Alex