Messages in this thread | ![/](/images/icornerl.gif) | | From | kutek@cybercom ... | Subject | per session access to drives | Date | Mon, 12 May 1997 14:51:59 +0000 (GMT) |
| |
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.
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
| ![\](/images/icornerr.gif) |