Wednesday, June 2, 2010

SUDO JUST WON'T DO!

I recently installed Ubuntu Linux 10.04 on one of my machines and since I am used to a SYS-V way of doing things (I have worked on one variant of Unix or Linux all the way back into the late 1970s) it wasn't without its set of gotchas. I actually cut my teeth on BSD, so a BSD style Linux isn't all that much of a problem in terms of me being happy working on it (it is much better than attempting to use CPM or old DOS) - except for one thing!

Ubuntu, Macintosh, Knoppix, and others have a sudo only way of doing things. Given what Knoppix is normally doing I can understand it there. Knoppix is not really a normal desktop system except perhaps for its author and some other devotees. Most of us other mere mortals use Knoppix to fix some catastrophic problem that isn't easily fixed any other way. I do not understand a sudo only way of doing things on a desktop system and these are the reasons why.

One: I installed Ubuntu and did my usual of importing my ~/bin folder with its set of scripts (had a gotcha with the location of sh - don't always count on /bin/sh or even /usr/bin/sh - I handle it in a very non-standard way by creating a symlink where it isn't to point to where it does exist) and programs which I had to get the rest of the gcc environment to create them. I still need to handle the g++ and other things but one thing at a time. I went to modify the .bash_profile or .bash_login only to find it defaulted back to .profile. With all of the variations of BASH, no big deal. But in .profile I see:

if [ -d "$HOME/bin" ] ; then
PATH="$HOME/bin:$PATH"
fi

I suppose it could be worse. They could have had put dot (".") first in the ${PATH} which is sometimes what I would swear Microsoft Windows does (addendum on 2010-10-09: in fact "." is implicitly first in both the *.exe, *.scr et al path and also first for the DLL path which you can search for information on it and find it):

if [ -d "$HOME/bin" ] ; then
PATH=".:$HOME/bin:$PATH"
fi

I changed it to:

if [ -d "$HOME/bin" ] ; then
PATH="$PATH:$HOME/bin"
fi

If you want ".", add it last. I have used ./exe-file for so many years it is second nature to me now. Why did I change the $PATH? I don't want somebody slipping in some replacements for ps, ls, and other sytem commands so that they can hide their processes and presence in case of me being slipped the mickey and not knowing it is there. Even though there will be some idiots that fall for something to install things outside of the ${HOME} file space, I strongly suspect that most malware on Unix and Linux if it ever arrives will just install into the ${HOME} file space. That is after all where the credit card numbers, phone numbers, addresses and other good stuff are anyway. So far, so good. I will hopefully not have some sleazy trojan stuck into my user account's ${HOME}/bin folder. If it is I should not run a substitute ps command instead so it will show up. I check those startup files for my shell all the time people! I also install ksh so it will be available. Some people use ksh (Korn SHell) as their default shell. With its wonderful integer accessible arrays and lots of other great features I can understand why.

Two: I did the following without giving it too much thought. After all, just because Ubuntu is a BSD style Linux, it still has a root login, right? Wrong? Anyway I added the following for myself in my .bashrc at the end:

umask 077

and altered it to this in .profile:

# umask 022
# the next one is at the end of the file
umask 077

I always save the originals as ${FILE}-MYDATESTRING and put them in an old folder.

Now I am all set to go with things closed down by default with Ubuntu doing it correctly by putting me by default into my own group. Or at least I think I am ready to go.

Three: Now I did the unthinkable. First, I tried to do my usual on a SYSV style 'nix system which was to attempt to do a "su -l root". Despite me typing what I thought was root's password it failed. So I started an xterm from my custom launcher and in it typed:

sudo xterm -bg ${A-DIFFERENT-COLOR-THAN-WHAT-I-HAVE} -fg black +sb

I type in the sudo password and I get a root xterm which I set to have the largest font size possible and enlarge it to fit almost the entire screen. Then I minimize it to the bar and close the xterm that started it. The root xterm doesn't die immediately. There is no telling how long it will take for init to kill it on Ubuntu or launchd to kill it on the Macintosh. I do know I have run it for at least two consecutive weeks without it dying but we will see how it goes. That isn't the problem. What is root's $HOME and umask?

$HOME is /home/lehobbit
umask is 077

That will not do. Why not? Because if I am correct and what the malware does is install itself into the ${HOME} user space we need to at least partially innoculate the root user from using the same infected stuff. After all, it may change the ${PATH} back to include lehobbit's infected bin folder. Actually, all Ubuntu Linux and Macintosh users need to create a secondary sudo enabled user account which they configure and leave at the default settings to undo the damage done to their full time user account. So I put the following to explicitly set the stuff into a /root folder by adding the following to these files:

/root/.profile:
==========
export HOME=/root
umask 022
# my way of adding /root/bin to the $PATH - LAST!
# more importantly, I do NOT just add to what is there.
# I SET IT so lehobbit's infected bin folder will NOT be
# in the path ANYWHERE!

/root/.bashrc:
==========
umask 022

I also transported my bin folder up there intact and then did the following (using "#" to indicate a root level prompt of that root xterm):

# cd /
# chown -R 0:0 /root
# find /root -type d -exec chmod 700 {} \;
# chmod 755 .
# chmod 755 ..
# find /root -type f -perm 755 -exec chmod 700 {} \;
# find /root -type f -perm 644 -exec chmod 600 {} \;

All of this chmod u+x what ever falderal is insanity at its worst. I am getting sick and tired of seeing it! Set it to be exactly what you want! Here is a tutorial on how to do it (if you don't understand it then write to me and I will point you to the relevant Stevens books):

http://www.SecureMecca.com/public/ChmodTable.txt

Okay, now when I get my xterm with root privs I can type:

# cd /root
# . .profile
# . .bashrc

It has the proper home, my way of starting vim not to give me a history, no darn files ending with tildes, function keys mapped in vim to race around the buffers with saving or not, and most importantly, root now has a umask of 022 and doesn't have that potentially infected /home/lehobbit/bin folder in the $PATH.

Four: Are we out of the woods yet? I would like to say we are but in fact we probably are not! Do you remember that umask of 077 I have for myself? What happens if some idiot does not follow my advice on just setting the file permissions by attempting to add to what I have but counts on me having a umask of 022 when I do a package install via sudo from an xterm in my space? (2010-10-09: guess what, Synaptic did just that and I had to go correct this manually)  A similar situation arises when you start trying to do time zone changes to find a TV feed for example. The solution for the time is to contrast everything to UTC, and my machines are set to UTC time for all operating systems. Daylight savings time needs to be cycled out - just tell people to do things an hour earlier in the spring and do it later again in the fall. So every time I install a package or do anything else requiring sudo to get it done, I now have to always type the following in an xterm first:

$ umask 022

There is no guarantee that the forked process won't have problems if it sources my lehobbit .profile or .bashrc file. In that case we are back to having a umask problem again. I suppose it is okay for people to leave their umask to 022 and they can execute a script that every so often does the following:

# cd ${HOME}
cd
cd ..
find ${HOME} -type d -exec chmod 700 {} \;
for FPERM in 644 640
do
find ${HOME} -type f -perm ${FPERM} -exec chmod 600 {} \;
done
for FPERM in 755 750
do
find ${HOME} -type f -perm ${FPERM} -exec chmod 700 {} \;
done

But wouldn't it be much nicer to just have a umask of 077 and open things up as needed?

Conclusion:
What some people have done is taken a mechanism that was created to give limited access to get certain jobs done and made it into a mantra. Even worse, Apple has hidden entirely that is what is being done by calling it something else. But since Apple has replaced init with launchd and nobody gives me the nitty gritty on how it works I have a lot of problems with the whole thing and no time or space to worry about it. I am sorry, but every time I see people who mandate sudo and disallowing either a su (what my sudo of an xterm did in reality) or a logging in as root they don't understand the following things.

1. These people are in many ways novice users. Once they see me racing around at top speed logged in as root they always have to ask me to slow down and explain what I am doing. I have no idea what they would do if they saw my friend Pieter Bowman going about 10x+ my speed. I can understand their reticence. My only counsel is to go slow and stop and think once, then twice, then thrice before tapping that Enter key. Are you really sure you want to remove user nobody and all of his files and folders on BSD? There is no problem with Ubuntu since nobody's home is "/nonexistent" (on old BSD it is "/"). There is no shame in going slow. OTOH, if you mess things up once you usually will not make the same mistake twice. The problem is they are using sudo as a crutch thinking it will save them. If you have a one megabyte file consisting of nothing but zeros named megazeros in the current folder and the boot disk drive is sda, you better not EVER type:

$ sudo dd bs=65536 count=16 if=megazeros of=/dev/sda

OTOH, it may be quite effective to do that on an infected disk (which means it will be some other device other than sda) to clean off all traces of a boot sector virus. That is not enough to erase all of the information. To do that you need to wipe the disk. My way of doing that is to do this first (write a megabyte of zeros to the start of the drive), then fdisk it and allocate it all to an ext2 file system or as many as needed if you can not make just one huge ext2 partition. Then I attach the disk to a mount point and then keep writing files with zeros in them until I cannot write any more. Then I wait eight hours. Then I remove the files and wait a few hours more. After that I unmount the disk partition and follow that up with another dd of a megabyte of zeros onto the start of the drive. What am I saying? I am saying don't depend on users to be protected from learning all of this by sudo! Instead provide some training and help. The reason why is sudo causes just as many if not more problems than the ones it gets rid of if you use it as the only privilege escalation method.

2. sudo should not be hid like it is on a Macintosh.

3. sudo is not a good general purpose mechanism in handling all problems. The best way to clear out a user only infection is to login as somebody else that has the privileges to fix the problem. That user's name is normally root. You can do what I did, but how many Ubuntu Linux users can handle it in this way? How many even know you can do it? Well, all of the ones that just read this know how to do it now until they put in a way to stop it from being done. I am sure that the instant somebody at Ubuntu reads this that my trick of getting a sudo'd xterm that is running as root will be gone. If they do it, so will I (be gone and never use Ubuntu again).

4. sudo creates big problems in doing things in a big lab or work environment unless you can guarantee that only one user uses a machine for the duration of their entire employment / use span at that organization. If you cannot guarantee that to be the case then you will want some other general purpose mechanism other than sudo. You will also want all user's default umask to be 077 and open the folders / files as needed.

5. I don't mind if you limit the su access to only certain accounts. That is fine. But I should not have to bypass it by sudo'ing an xterm (2010-10-09: you can sudo su as explained in a comment here). It only works, sort of; you still have the umask problem. I am still not happy that I can not just login as root some of the time. When I do that I am not using the machine - I am configuring it. OpenSUSE doesn't use sudo as the control mechanism but I haven't found yet where they SET the IP address statically. But then I haven't exhaustively searched for where it is done either. But hiding things usually only creates more problems than it solves. Something that is transparent is always better.

6. The root user really should have a /root folder with it's own startup stuff and that folder should be just as tightly controlled as I am trying to make the lehobbit folder. It is just that root must close its own new folders and files down manually because for everything else root needs - you guessed it, a default umask of 022. I strongly suspect the umask of a normal user was set to 022 by default becuase of the problems it creates for sudo to have it anything else. Unless sudo will automatically reset the umask for the one needed we have a problem. Usually, it doesn't.

7. Nix newbies need some training in how to handle all of this. Most of them want to login and do everything as root. I am changing a lot of things that require it all of the time but I only use the root xterm for those tasks that need it. For everything else, lehobbit is just fine. Unlike Microsoft Windows, 99% of the time I don't need to do anything as root. If I was not doing security work that figure would probably drop to 1% or less for root and 99.9% or more for lehobbit. For example, in using my OpenPGP keys, it doesn't even make sense to use them as root. But for those times when using root is really needed like in cleaning out the new malware to come which will probably be in a user's $HOME folder you need to go at getting rid of it coming at it as anything but that user that is infected. Normally, root would be best. That is what we need the LUGs for - they need to educate people in how to handle this. But we need to banish the idea that sudo is the best general purpose privilege elevation control. We need to send the sudo only way of doing things to /dev/null.