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.
so, eg, there is one loop device which holds the compiler and development
tools, another than contains most of the utilities in the sbin directories,
another for net stuff, etc.
imagine the hackers' surprise upon breaking into your web server as root
and finding that basic facilities like ls, cp, mv, etc are not available
on the system, and that there is no way to either compile them or place
them there.what fun!
in combination with judicious use of the ext2 immutability flag
(naturally chattr is made unavailable to the system) it is my
feeling that a linux system can be made VERY secure... except for one
problem....mount makes the loop devices available to potentially everyone
on the system.
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.
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.
my question is this... will this single session mount/drive access
capability entail extensive kernel/mount() mods or is it just a matter
of changing the mount utilities? Is it doable,does it make sense, and
would anyone be interested in pursuing this?
since there is a performance hit( but not as bad as i
expected!) when using encrypted loop devices...there is the issue of what
needs to be done (and where) in order to stop the loop access processes
from dominating the cpu.curently it is obvious that this will not allow
a _very_ large number of users on a system so protected to use these
facilities and still have acceptable overall system performance... but it is
nowhere near as bad as you might think(using idea), and certainly will be
functional on smaller systems with a few users.i run multiple encrypted loop
devices on a 386/40, and i am convinced that it is a resolvable issue given
the performance i am seeing on my little dinosaur -perhaps on a more modern
and faster system this is not even a real concern.
finally, are there alternatives available to messing with mount and the kernel
that would allow me to achieve the same goals?
Bill Stone