How to Mount bin and sbin directories as readonly mounted file systems

Larry James · 10-17-2008, 12:56 PM

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

PTrenholme · 10-17-2008, 01:20 PM

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
UUID=92ff1a1e-9e16-4828-953e-fbdfde536452 /boot ext3    defaults        1 2

To make /boot read only, I'd change that to

Code:

/dev/Fedora/Base        /                       ext3    defaults        1 1
UUID=92ff1a1e-9e16-4828-953e-fbdfde536452 /boot ext3    defaults,ro     1 2

Since you're posting to the Fedora sub-forum, I'd assume that you have SELinux installed on your system, so it would be much simpler to rely on SELinux for your security needs, but, of course, the choice is yours.

Larry James · 10-17-2008, 01:54 PM

Quote:

Originally Posted by PTrenholme

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
UUID=92ff1a1e-9e16-4828-953e-fbdfde536452 /boot ext3    defaults        1 2

To make /boot read only, I'd change that to

Code:

/dev/Fedora/Base        /                       ext3    defaults        1 1
UUID=92ff1a1e-9e16-4828-953e-fbdfde536452 /boot ext3    defaults,ro     1 2

Since you're posting to the Fedora sub-forum, I'd assume that you have SELinux installed on your system, so it would be much simpler to rely on SELinux for your security needs, but, of course, the choice is yours.

Thanks, PTrenholme. I should have posted my fstab. It was:

Code:

LABEL=/                 /                       ext3    defaults        1 1
/dev/sda3              /mnt2/bin                ext3    ro              1 1
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
LABEL=SWAP-sda2         swap                    swap    defaults        0 0

I studied to see what was different between what I had and what you suggedted and changed the bin mount point to:

Code:

 /dev/sda3              /mnt2/bin                ext3    defaults,ro     1 2

I still get the same error. The shutdown process fails with a message,

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

PTrenholme · 10-17-2008, 07:42 PM

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
#!/bin/bash
#
# Check that sudo works for the user. Bypass the check if we're running as "root."
#
# Are we running as "root?"
for root in $(groups);do
  if [ x$root == xroot ]; then
#   Yes, we're running as root. Abort here with success status.
    exit 0
  fi
done
#
# Not "root." Confirm that the user has sudo permission.
#
echo You need root access to run this script. \(I.e.: You must be in the sudoers file.\)
echo If prompted, enter your password for "sudo" to use.
sudo echo OK - now we have root access.
[ 0 != $? ] && echo Aborting. && exit 1
echo
echo Note:      Many commands used in this scrip are proceeded by a "sudo" directive.
echo            On most Linux system a "sudo" is only "good" for a few minutes,so it is
echo            possible that you may receive additional "Password:" prompts as this
echo            script is run.
exit 0

And this is the script to unpack an existing initrd.img file:

Code:

$ cat Scripts/Init/DecompressInitRD
#!/bin/bash                                          
#                                                    
# Check for a -h or --help argument. If found, print the help info and exit
#                                                                          
help()                                                                     
{                                                                          
  cat << eof                                                               
$0 is used to decompress initial RAM disk image files located in /boot or, 
   if an argument is passed, the directory referenced by that argument.    

   The files are stored in a subdirectory of the Initial_RAM_Disk subdirectory
   of the /boot location.                                                     

Usage: $0 [boot directory]

eof
exit 0
}     
if [ "-h" == "$1" ] | [ "--help" == "$1" ]; then
  help                                          
fi                                              
#                                               
# Make sure we can get root access (Note: This assumes CheckForRootAccess is in your current directory)
#                                               
[ -x CheckForRootAccess ] &&  $(./CheckForRootAccess)     
[ 0 != $? ] && echo Aborting. && exit 1         
#                                               
# Find the location containing the RAM disk image(s)
#                                                   
if [ -d "$1" ]; then                                
    boot=$1                                         
else                                                
    boot="/boot"                # Boot directory default location
fi                                                               
#                                                                
# Get a list of all files in the target directory whose name contains "initrd" and which terminate in ".img"                                                    
#                                                                               
declare -a files                                                                
files=($(sudo ls $boot/*initrd*.img))                                           
n=${#files[*]}                                                                  
if [ $n == 0 ];then                                                             
  if [ -d $boot/grub ]; then                                                    
    boot=$boot/grub                                                             
    files=($(sudo ls $boot/*initrd*.img))                                       
    n=${#files[*]}                                                              
  fi                                                                            
fi                                                                              
#                                                                               
# Make sure we have at least one initrd file. If so, present the list and expand each selected one in its own sub-directory of $dir                              
#                                                                               
if [ $n != 0 ]; then                                                            
# Sub-directory of $boot into which the initial RAM disk contents should be decompressed                                                                          
  dir="Initial_RAM_Disk"                                                        
  pushd $boot                                                                   
  echo Enter the number corresponding to the image file you want to have expanded:                                                                              
  select img in quit ${files[@]}; do                                            
    [ $img == quit ] && break;                                                  
# Find the rest of the initrd image file name                                   
    Name=$(echo $img | sed 's/.img//;s/[[:punct:]]*initrd[[:punct:]]*/_/;s/^_//;s/_$//')                                                                        
# Make the subdirectory of $dir to hold the output and move into it             
    sudo mkdir -p $dir/$Name
    [ 0 != $? ] && echo Could not create $dir/$Name. Aborting. && exit 1
    pushd $dir/$Name
# Unpack the initial RAM disk file
    sudo gunzip -c $img | sudo cpio -idmv
    [ 0 != $? ] && echo Could not expand $img. Aborting. && exit 1
# List the directory contents
    echo Contents of $(pwd):
    ls
# Return to the initrd directory
    popd
# Reprint the select options as a convenience to the user.
    echo
    echo Enter the number corresponding to the image file you want to have expanded.
    n=1
    for f in quit ${files[@]};do
      echo $n: $f
      n=$(($n+1))
    done
  done
# Return from whence we came . . .
  popd
  exit 0
else
  echo No initial RAM disk files were found in $boot
  exit 1
fi

And, finally, the script to make a new initrd.img file from the unpacked contents. (Sorry, I haven't got around to properly commenting this one,)

Code:

$ cat Scripts/Init/RebuildInitRD
#!/bin/bash                                        
[ -x CheckForRootAccess ] && $(./CheckForRootAccess)
[ 0 != $? ] && exit 1                              
if [ -d "$1" ]; then                               
    boot="$1"                                      
else                                               
    boot="/boot"                # Boot directory
fi
# Sub-directory of $boot from which the scripts should be re-compressed
if [ -d "$1/$2" ]; then
    dir=$2
else
    dir=Initial_RAM_Disk
fi
# Process the files extracted by the DecompressInitRD scipt
pushd $boot/$dir
# Get the name of the current directory
Name=$(echo $(sudo pwd) | sed 's/.*\///')
# Build the Initial RAM Disk archive in /tmp
sudo find . | grep -v ~$ | sudo cpio -c -o > /tmp/initrd
# Compress the temporary archive and save it in the $boot directory
Name=$boot/initrd.$Name.img
gzip -9 < /tmp/initrd > /tmp/initrd.img
sudo chown root:root /tmp/initrd.img
sudo mv /tmp/inird.img $Name
# Clean up

rm /tmp/initrd
# Report
echo
echo The new initial RAM disk image is in $Name
echo
# And return to where we were before we started
popd

Larry James · 10-18-2008, 11:22 AM

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

PTrenholme · 10-18-2008, 02:05 PM

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.

Larry James · 10-18-2008, 06:13 PM

Quote:

Originally Posted by PTrenholme

O.K., fair enough. But I still think my first response (that you should use SELinux) would be a better solution.

I understand and really appreciate your input and suggestions. I do use the SELinux solution. I hope you’re not saying that studying and implementing additional steps somehow causes the SELinux solution to lose its functionality.

Quote:

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.

This is absolutely true. Once someone logs in as root, they can do whatever they want to do with the mounts, the startup and shutdown files, as well as all the files on the system. They will actually have the same powers that you have. I would think this might be a reason to explore adding blocks and hindrances to intruders and potential intruders rather than put less.

Quote:

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.")

It appears the developers of the distros sees what I’m looking at. They are adding hinderances to the intruders, but as you mentioned, it can hardly be absolute if you are going to configure your system. Once a person breaches the system, he can effectively become you and do whatever you can do.

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:

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."

I’m sure automatic updates for Linux is just as good for most people as it is for most Windows users. However, I configure my Linux system to allow me to determine when and which updates to allow. I do the same for Windows. Most likely I’ll allow the updates, but I prefer to be informed and in control.

Quote:

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?]

Yes. I’m fully aware. I tried to make this clear in my opening message. I also know that no matter what a person does for security, it can really be broken. This is why as you mentioned above updates are important. I don’t know why, but malice developers work just as hard and vigorous as the good developers.

Quote:

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.

I agree. And I would consider getting to learn as much as you can and adding layers to be a good start in removing the key. As I mentioned above, some people have even tried to disable the superuser, but the really appears to cause a system to lose a lot of necessary and normal functionality. Of course, the key is always going to be in actuality left in the lock. It’s just a matter of somebody finding the key. People find it in the most secured systems. Having many layers gives the owner just a little more lead in discovering someone one looking for the key. Any security added in a hindrance for an, being effective based on the ability of the intruder/hacker.

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

zimon · 10-21-2008, 03:34 AM

Quote:

Originally Posted by PTrenholme

O.K., fair enough. But I still think my first response (that you should use SELinux) would be a better solution.

How the same wanted effect/behaviour is then done with SELinux settings?

Larry James · 10-21-2008, 11:40 AM

Quote:

Originally Posted by zimon

Quote:

Originally Posted by PTrenholme View Post
O.K., fair enough. But I still think my first response (that you should use SELinux) would be a better solution.

How the same wanted effect/behaviour is then done with SELinux settings?

Hi, Zimon. He wasn’t describing how to achieve the OP’s objective. I believe he was mainly trying to discourage security redundancy.

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