Restrict Logins with Likewise on Linux/Unix

I'm a pretty big fan of Likewise. I am currently using the likewise open version on many of my linux boxes so that I can authenticate against Active Directory. This makes my life easier in the fact that I don't have to deal with adding and removing users from these boxes.

Our standard build consists of a build that has sudo installed. Root cannot login over SSH and we have a default local account that the sysadmins know and can use if in a pinch. We do, however, use our own accounts so it can leave a sudo log trail.

Now, when we installed likewise-open on our default ubuntu image, we had one concern, any user with an Active Directory account can now login to our Ubuntu servers. While they will just be a dummy user with minimal privileges, what is to stop these users from using an exploit to escalate their privileges to root, or filling up their home directory and owning some of the boxes that don't keep those partitions separate. While I don't think any of my users would do anything like that, its always better to allow minimal privileges and lets face it, my sales, accounting, managers, and many others have absolutely no business in ever logging into any of the production linux/unix servers.

I did some strategic Googling query building and I was able to stumble on a thread (sorry I lost the original link) that pointed me to a specific line in a configuration file (/etc/security/pam_lwidentity.conf). By uncommenting this line and putting a group in there, I can restrict who can login to my servers. So I set it to the following and simply created a security group called 'unix admins' in Active Directory to hold the people who can admin these boxes. Piece of cake.

require_membership_of = GCA\unix^admins

Linux Kernel Vulnerability

Found the following article on slashdot and immediately jumped over to my linux boxes to ensure we aren't vulnerable.

http://linux.slashdot.org/story/09/11/04/0320254/Bug-In-Most-Linuxes-Can-Give-Untrusted-Users-Root?from=rss

More information can be found at securityfocus here:

http://www.securityfocus.com/bid/26831/info

From what I understand, you can fix this vulnerability by simply setting the vm.mmap_min_addr setting to a value of 4096 or greater ( in short, if this value is 0, you are vulnerable). I also read that if you install wine (winehq.com) that it will automatically set this value to 0 and make you vulnerable.

To check the value of this variable on your linux system to see if you are currently vulnerable, just run this command and ensure it is not set to a value of 0:

sysctl vm.mmap_min_addr

On debian based installations, check the following site for how to fix this for the current boot and how to make it persist a reboot.

http://wiki.debian.org/mmap_min_addr

For those that are really concerned right now, I checked my Ubuntu 8.04.3 LTS servers and they all are defaulted to 65535 for this value, so they should not be vulnerable to this bug. Keep in mind what I stated above though, if you install wine, you become vulnerable.

Encrypted Filesystems

I am doing work on a project and the client has a requirement that all data, including documentation, config data, and anything else related to the project be stored on an encrypted filesystem. We are going to be using a Microsoft Project Server 2007 with project web access and webdav for document libraries. So, I need to figure out how to encrypt the data stored in the SQL Server 2005, and all the other places.

The easiest way to architect this solution was to simply install the whole standalone project server as a virtual machine and have the virtual machine files reside on an encrypted filesystem.

So, step 1, install a box with an encrypted volume. I am going to use my current OS of choice, Ubuntu Server 8.04.1. I found a great reference article using the Google debugger to use as a guide, see https://help.ubuntu.com/community/EncryptedFilesystemOnIntrepid. My implementation is going to vary slightly, but this is the document I am using as my reference.

So the first thing I did was install Ubuntu Server 8.04.1 from the CD. My partitioning is somewhat complicated, but nothing crazy. The box I am using has 6 drive bays filled with drives. I used the onboard raid controller to make two arrays, the first is a mirror of two 36 GB drives and the second is a raid 5 array of the other four 320 GB drives. Ubuntu sees two drives, /dev/sda and /dev/sdb. I formatted /dev/sda into two filesystems, a SWAP partition with 4GB and the rest was made as the / partition. The /dev/sdb drive I left unformatted, I will be using that for my encrypted filesystem.

When going through the install, I selected all of the defaults, only adding the openssh-server so I don't have to use the console in the server room. Once the install finished, I SSH'd into the box from my desk and ran the following two commands to update my server to the latest patches and reboot.

sudo apt-get update
sudo apt-get dist-upgrade
sudo init 6

After the reboot, I needed to add a couple additional packages, so I ran the following command to add them.

sudo apt-get install cryptsetup hashalot initramfs-tools

After those packages were added, I skipped down the document to the "Create the encrypted partition" section and started with those steps.

sudo modprobe dm_crypt
sudo modprobe sha256
sudo luksformat -t ext3 /dev/sdb

Note: I did get a warning, but it has not seemed to cause any problems.

WARNING: Error inserting padlock_sha (/lib/modules/2.6.24-24-server/kernel/drive
rs/crypto/padlock-sha.ko): No such device

After the volume has been formatted, I created a new mount point for it on /cryptvol. I ran the following commands to mount the volume where I wanted it.

sudo mkdir /cryptvol
sudo cryptsetup luksOpen /dev/sdb cryptvol
sudo mount /dev/mapper/cryptvol /cryptvol

When I ran the cryptsetup command, I was prompted or my password. After entering it the command finish and I was able to mount my new volume. Next order of business is to create some kind of documentation on the box to tell me those two commands. I opted to create a file called /readme.cryptedfs with the commands to mount this file system. I did not want to have it automatically mounted, I want a user to be forced to log into this box and enter the password manually to mount this volume after a (re)boot. I also created a sym link to this file in the /cryptvol directory when the filesystem is not mounted to the directory, just in case someone goes there looking for something, they see one file.

And its that simple, I now have a completely encrypted volume on a server. In order to mount this volume a password must be provided.