Shawn Mckay's Perspective on Computer Security

Basic security problems with various mostly UNIX systems

Some more general topics

I will attempt to give examples for the above problems as they relate to some popular operating systems currently on the market. However I wont mention any by name (You know who you are).

Overuse of SETUID root programs

In general you should find very few reason to be root, for the most part the more root programs you have the more likely one of them has a bug that someone can exploit to get root permissions.

The vast majority of system tasks can be handed out based on group permission or special directory / file permissions. A well designed UNIX should have a handful of setuid root programs. But if you use a commercial product, I am willing to bet you have some extra setuid bits floating around.

If you wish to find out how much extra, Try the following command on your UNIX: 

   find / -name "*" -type f -user root -perm -4000 -exec ls -ls {} \;
If you wish to discover how many files you saw fly by, then try adding the line: 
  | wc -l
to the end of the above command and try again.
Its very hard to ensure each of this many programs is really "safe". Its much better to limit the use of setuid permissions whenever possible. Sadly, few people spend the few extra steps to avoid setuid/setgid use. They use it because its easy, not because its the right thing to do in most cases.

Overuse of SETGID root programs

Ok, now try changing the mode above from "-4000" to "-2000" and try again. This should list the files on your system that are "setgid" to root. In general there is VERY little reason to do this. Usually a separate group could easily be created for the given function but usually its not.

Failure to use "groups" more in file permissions

On most UNIX products you will find a handful of groups listed in /etc/group, there are many reasons for this in general, but few of them are really valid. The most serious problem with having lots of groups is with some versions of NFS, which limit the number of groups a user may belong to. I also seem to remember some versions of UNIX with the initgroups(3) call also limit the group membership.

Never the less this remains a powerful tool to be used by the educated. An example might be with one specific type of UNIX that restricts the use of the dump(8) command. They require that you must be root to perform a system backup.

This is crazy, you do not. But using their software they require it. I have yet to see a version of UNIX where the following wont work if done with care:

There are a number of variants on the above, non of which involve root access. But I think you can see root is not generally required.

Making system binary files world readable

Sometime try using the strings(1) command on every file in /bin, or /usr/bin, or /etc and imagine the wealth of information a cracker could get from doing this. No system is totally secure, but giving away this much of the system is also not a good idea. One of the most powerful commands to violate UNIX system security works just fine for any user on most UNIX systems:
		strings /bin/* | grep '/' | more
Its good for finding paths to "secret" system databases and private areas. Its very easy to protect against this abuse and yet so few sites / vendors do.

Some have raised the good point that this restricts legitimate users from being able to force secrets they need from various system programs which might be poorly documented. I tend to agree, but would rather have good manual pages and limit my security problems as much as possible.

You could however meet half way and just do this with setuid/setgid programs, anyone who has to debug on of these can probably bypass the read protection.

On most modern UNIX systems, programs (binaries) need only have the "x" bit set to be used by people. Hence the permission of:

  11 ---x--x--x  1 shawn    staff           11264 Aug 24 12:37 /bin/foo
will protect /bin/foo and yet will not allow random users to "pump" it for information.

This does not always however work on shell scripts, so be careful.

Failing to remove read permission when its not needed

You would do well to consider all system files and areas to be on a need to know access basis. In some cases you will find both security and privacy reasons for this. Here is a dual example.

On most UNIX systems there is a directory called /var/adm. Within its confines you will usually find system accounting data and log files of system activity. In general you will also find it protected poorly with even worse protections inside.

Some of the files within are poorly protected for good reason, but a few simple steps could render it much more secure:

What you end up with is a directory everyone may access (and non-setuid programs may access without the user knowing the exact filename when needed) and yet is not casually searchable by the user. Combined with good system binary protection this makes a very good log area.

I would also go one step beyond with the system accounting data by giving it a mode of say 440 and a group all its own. Using these few tools and basic philosophy you may now grant access on an "as needed" basis and greatly limit your risk of mistakes by authorized users and security violations.

In general when you create a system file, directory or special area you should take a moment to think "Who needs access to this area?" "Why?" and can I resolve the access issues with a group and clever use of file permissions?

What about RCS and people who forget to use the right permissions?

There is a thing called a "firewall" which may be used to address this issue, here we like to be able to edit the /etc/printcap file.. To do this we have done the following:

Using the above we now have a printcap everyone in the "lprcap" group may edit using RCS an which is still referenced "correctly" by the system. You could go one step beyond and make the directory mode 770 if you wanted to protect the printcap file from general access, or 771 if you didnt want people to randomly read other files within. If more people did this, I think we would have much less reliance on setuid programs.

Placing limits on group memberships, making them hard to use

By limiting the number of possible groups a user may belong to, you curtail the number of different types of "special access" the system manager can deal out. This causes some to give up and give out "root" access. This is much like giving a child a loaded gun, its almost always a poor idea. And the cases where root access are really needed are few and far between.

Forcing the sysadmin to use root when its not really required

I think you will find the dump example above is typical. Here, when the vendor had the choice of making the program "normal" and creating a special group of users with read-only access to the special resource in question, they chose the easy yet dangerous solution instead. If you look at the manual page for restore(8) in the manual you will also find that the dump command is a resource for the average user on some systems. Depending on the type of UNIX it can be used like the tar(1) command. Yet you would hardly require a user to be root to use tar(1).

The power of root

Sometimes we forget the power of the root user. Its not uncommon for even a seasoned system manager to blow away major parts of the system with a slightly mis-typed command. Yet on some systems this hazard is given away casually. The root user is a time-bomb and should be only used with the greatest of reservation. In general only a few things really require you to be root: Of the above listed items, ONLY cannot easily be avoided. Many programs are available in the public domain to handle the other functions either in a single setuid root program or a few cautious setuid programs.

A word on setuid permissions

In general when people write a program to be setuid they put all of the protection for it "within" the confines of the program. With a historical perspective on UNIX security its easy to see where this "all or nothing" philosophy comes from but its a general weakness that needs to go away.

The typical setuid program internally checks a few things:

They also do a few things like protect themselfs from unexpected failures and signals the user might use against them to cause a security breach. Then they are installed onto the system in some cases as:

   288 -r-sr-xr-x   1 root      bin  139264 Dec 21  1992 /bin/su
I would propose an alternative protection of: 
   200 -r-s--x---  1 root     binsu  192512 Sep 10  1991 /usr/bin/su
I would consider removing the world-read permission in the first example to be a bare minimum for such an important and powerful program.

In my alternative you will notice that only people who belong to the "binsu" group may run the /bin/su program. You could make it a little broader by say changing the group name to something like "setuid" and making the permissions on MOST setuid programs as above. Thus only a small group of users may even try to run the software in question.

This is what is sometimes called defense in depth, its a concept from emergency management and is very valid in computer security. Its also something found in many non-unix systems of the past.

Anonymous FTP problems and notes

Select with care the version of ftpd you are going to use if you will be offering anonymous ftp. Never under estimate the power of logging.

Also, the "ls" program that anonymous ftp users have access to use should NEVER return real user id/group id information. Always have it return dummy info in these areas.

This should remove the need for you to maintain a copy of ~ftp/etc/passwd and it should thus be removed along with the ~ftp/etc/group file. You should of course NEVER use a real passwd file in this location.

The ever insecure sendmail program

Anything below sendmail v8.6.9 should be used with great care. You might also consider if you can run MMDF IIb, which is a much more security (yet complex) mail system.

A word about cron and a new way to use it

The cron clock daemon runs as root on most UNIX systems, and has no real method to permit users access to it except the at(1) command. Here is an example of how to grant multiple levels of access to cron without having to change much in the system, yet yielding a much more flexible layout.

Imagine if you will the following lines in /etc/crontab: 

0 * * * * /bin/su daemon /usr/eecs/lib/cron/daemon.hourly.sh
0 0 * * * /bin/su daemon /usr/eecs/lib/cron/daemon.daily.sh
0 1 * * 1 /bin/su daemon /usr/eecs/lib/cron/daemon.weekly.sh
0 2 1 * * /bin/su daemon /usr/eecs/lib/cron/daemon.monthly.sh
0 3 1 1 * /bin/su daemon /usr/eecs/lib/cron/daemon.yearly.sh
Then, also imagine the following directory structure in /usr/eecs/lib/cron: 
total 11
   1 drwxrwxr-x  4 shawn    crncap        512 May 27 19:27 .
   1 drwxrwxr-x 32 shawn    ecfmaint     1024 Jul 18 14:00 ..
   1 -rwxrwxr-x  1 shawn    crncap        335 Oct  2  1991 0-README-0
   1 drwxrwxr-x  2 shawn    crncap        512 May 27 19:27 RCS
   2 -r-xr-xr-x  1 shawn    crncap       1080 Oct 24  1993 daemon.daily.sh
   1 -r-xr-xr-x  1 shawn    crncap        403 May 27 19:26 daemon.hourly.sh
   1 -r-xr-xr-x  1 shawn    crncap        351 Sep  2  1993 daemon.monthly.sh
   1 -r-xr-xr-x  1 shawn    crncap        426 Sep  2  1993 daemon.weekly.sh
   1 -r-xr-xr-x  1 shawn    crncap        346 Sep  2  1993 daemon.yearly.sh
   1 drwxrwxr-x  2 shawn    crncap        512 Jan  1  1994 run
Now, instead of having to issue root privilegeds to people using cron you can simply have them added to the "crncap" group and they may now use cron as the user "daemon" (or you could make a user called "cron").

This change can be made to any UNIX cron facility, though its less useful on System-V based UNIX systems as the cron system in use there has a more general usage model already.

The "run" directory simply contains a file updated with the touch(1) command to verify when each of the above scripts ran.

Poor Network Security

If you are on a network there are a few things you should consider hard and long:

I like to describe the Internet as the great frontier, with about the security of the Old West. Though there are marshals out there, they by no means outnumber the bad guys and the bad guys have the edge on most folks.

At the moment, most sites have taken the approach of locking their doors to the outside world and only using one way traffic. The problem with this approach is that if we all used it we wouldnt need a net anymore.

Things like Kerberos, and Prospero with Kerberos can help a great deal, and if people would start to uniformly embed Kerberos into their applications it would mean much less to suffer a break in.

Of course, this means little if the operating system fails to include Kerberos at virtually all its levels as well. This is a lot of work, and is probably not the perfect solution. But its proven, and will work to make things MUCH safer.

The Central Cracking Intelligence Agency

We need an agency / group that can really help get a handle on the long and short term issues of system and network security.

This group might provide:

There are a lot of agencies that do some of the above, but none that I have seen do most / all of the above. It would take a lot of resources to provide such a service but I dont expect the need for such a thing to go away any time soon. With the size of the net growing daily and the dependence on it also growing in all parts of the world to not have such a thing is a bit risky.

If I were to pick, I'd say here is a good "peacetime" use of the CIA (are you listening Langley?) if it could be modified somewhat. The need is for world wide coverage and interaction / aid. And could provide a reason to exist for a really long time. Although its very unclear how good they are at SHARING the information they gather :-).

The Cyber world, its the next battle front. Lets get going before we end up wondering "what happened?".

I will add things here as time permits

Please send your comments to shawn@eddie.mit.edu
Page Last Updated: 94-11-25