How to Mount bin and sbin directories as readonly mounted file systems
Hi. I’m trying to setup a procedure to have my bin and sbin directories. This is for an element of added security against rootkits. I know it won’t be a total protection, but it will be just another hurtle for the intruders.
At present I have mounted them on a readonly mount. I renamed the bin folder to bin.org and the sbin folders to sbin.org and linked them the bin and sbin folders to the readonly mounts. A problem occurs during system shutdown and startup procedures. It seems that during shutdown, the file systems are unmounted before the shutdown completes and the shutdown halts because it can’t find required programs. Similar happens during startup, because it appears the mount doesn’t happen early enough in the process. Can someone advise me on what to check in trying to achieve this objective? Again, I understand that anyone having access to running route kits can just as well remount the file system ad rw, but I consider the added hindrance a plus. Thanks in advance for any suggestions or comments. -- L. James -- L. D. James ljames@apollo3.com www.apollo3.com/~ljames |
In order to mount something, it must, obviously, be on a mountable device as a separate partition. Assuming that you've created partitions to contain /bin, /sbin, /usr/bin, and /usr/sbin, and added references to them in your /etc/fstab, just add ro to the options in the respective lines.
Here's an example of how /boot is mounted from a different partition in a standard Fedora setup: Code:
/dev/Fedora/Base / ext3 defaults 1 1 Code:
/dev/Fedora/Base / ext3 defaults 1 1 |
Quote:
Code:
LABEL=/ / ext3 defaults 1 1 Code:
/dev/sda3 /mnt2/bin ext3 defaults,ro 1 2 Unmount file systems: umount2: Device or resource busy umount: /mnt2/bin: device is busy umount2: Device or resource busy umount:/mnt2/bin: device is busy Then on startup it fails at: /bin/nash Warning: Can’t access(null) This is followed by lots of numbers and other code. Thanks again for looking at this and maybe pointing out what I’m missing. I’m setting up to rely additionally on the SELinux security. -- L. James -- L. D. James ljames@apollo3.com www.apollo3.com/~ljames |
Ah, yes, I forgot that part. Sorry.
The Initial RAM disk image file passed to GRUB contains a nash script used to load Fedora from your hard drive. That script (nash is a "stripped-down" bash) is generated by the mkinitrd command, and contains hard coded locations of things like /bin so they can be accessed during the boot. If you change those locations, you need to generate a new initrd.img file and point GRUB to it. As to the "device is busy" message, there is an option to umount to tell it to wait for the device to become unbusy before doing the unmount (the "lazy" unmout: umount -l), but I don't know how to get shutdown to use it. I find it somewhat easier to just edit the nash script by hand, since then I can test various settings without killing my working system. For your edification, here are three scripts I use so I can edit the nash script. First, a "helper" script that checks that you can obtain "root" privileges when you need them: Code:
$ cat Scripts/Init/CheckForRootAccess Code:
$ cat Scripts/Init/DecompressInitRD Code:
$ cat Scripts/Init/RebuildInitRD |
Thanks, Ptrenholme. From your response it appears that you did a lot of exploration of the question and resolution. I had mentioned the nash error as an example of the number of shutdown errors and as an example. I’m studying the nash routine to learn what it do and how to modify it as per your suggestion. However, there are a number of others that if having each individually patched might just bring the hang to a new one.
I was looking for a way to have the system (I thought it would have been via the fstab configuration) recognize this modified bin mount as a crucial operation point as it does the first line of the fstab and mount and unmount this entry at the same time. I believe the best immediate solution is to modify the startup and shutdown scripts to immediately run a script to move/rename the bin directories (/bin, /sbin, /usr/bin, /usr/sbin) and link the readonly mounted bin’s while I try to learn how the system can use the first line of the fstab during startup and shutdown without errors but can’t use the second line of the fstab during normal startup and shutdown. If I learn the secret I’ll post it here. -- L. James -- L. D. James ljames@apollo3.com www.apollo3.com/~ljames |
O.K., fair enough. But I still think my first response (that you should use SELinux) would be a better solution. After all, a cracker logged in as "root" could put a hidden executable directory anywhere in your file system and add that to your $PATH with a mod to /etc/rc.d/rc.sysinit so the modified commands would be executed in preference to the protected versions in your ro executable directories. They would, of course, need to be logged in as "root" to be able to do that, and, once a cracker can log in a "root," they can do whatever they want. That's why "root" log in (and "sudo" privilege) must be strictly controlled in any multi-user system. Some distributions (e.g., Ubuntu) are shipped with "root" log in disabled so noboty can log in as root. (Ubuntu, however, gives the primary user sudo access, so the protection is only as good as the security of the primary user's password. And anyone who can do a sudo /usr/sbin/lpasswd can enable log in to "root.")
In other words, your proposed "security" system will not provide any protection from anyone with root access to your system(s), and you're already protected from anyone without root access. It will, however, complicate the process of updating your system(s), and failure to keep your system current may be a larger risk than having the bin directories writable by "root." You are, I hope, aware that, unless you've changed the default settings, write access to the system directories is restricted to users logged in as "root," so, in effect, they are already ro for anyone not so logged in. Thus you're only preventing "root" from writing to the "protected" areas, and, of course, "root" can always make the device writable with a simple mount /bin -o remount,rw so what, in fact, have you gained with all the fuss with mounting bin as ro? Again, it's your system and your choice, but I think there are better choices than locking the door and leaving the key in the lock.:D |
Quote:
Quote:
Quote:
I’ve seen people try to disable the root’s account altogether and make some other manner of giving superuser access. However, that method breaks many pertinent applications. Quote:
Quote:
Quote:
I really don’t think the exploration is a detriment to the security of my system. I would be glad to learn how it is that the system can use the first line of the fstab in startup and shutdown but can’t use the second line. Even though I have found a world around for my task, I consider having more understanding of the fstab and mounting system valuable. I’m sure it can be done; I initially thought it was something simple that I just wasn’t seeing. I didn’t know those lines were so intrigue. -- L. James -- L. D. James ljames@apollo3.com www.apollo3.com/~ljames |
Quote:
|
Quote:
I’ll post a resolution as to how to have user’s preferred mounts automatically mounted and unmounted without causes errors when I learn how. If this is something you are interested in, and you happen to find a method, please contribute it, likewise. -- L. James -- L. D. James ljames@apollo3.com www.apollo3.com/~ljames |
All times are GMT -5. The time now is 02:52 AM. |