Don't let users run amok with advanced permissions, like SUID, on SUSE Linux Enterprise Server 10, says Sander van Vugt, author of Apress' Definitive Guide to SUSE Linux Enterprise Server. While locking out permissions like SUID (set user ID) isn't necessary, for instance, monitoring them is a must.
In this tip, van Vugt expands upon the uses of SUID and SGID (set user ID), how to make device sharing easier and ways to manage files that live in more than one place.
When setting up advanced group permissions using SUID and SGID, can you recommend some best practices and things to avoid?
Sander van Vugt: Advanced permissions can be very useful, but very dangerous as well. Let's talk about SUID, first. This permission is meant to be used on executable program files only when strictly necessary. In my opinion, it is better not to use them at all. They can provide an excellent backdoor for a hacker if used not in the right way.
An SUID file makes the user that runs it use it with the permission of the owner of the file. Since most program files are owned by root, it would effectively make you the root. This can be very dangerous on programs that have an escape-possibility which allows a user to run shell commands. People that break into your system will absolutely love SUID. Use a file system integrity checker, such as AIDE which is much easier to set up than TripWire, to monitor your files and see if they have changed.
SGID is a very useful permission. If applied to a directory, chmod g+s /somedir, it will automatically make the group-owner of the directory owner of all files in that directory. If that's not powerful enough for you, use access control lists. With access control lists, you can set default permissions masks that apply to all items created in a given directory.
For example, use setfacl -d -m
user:someuser:rw,group:somegroup:rwx /somedir to apply these permissions to new items that are created in the directory automatically. You will see these new permissions coming back in the ACL, which you can read using the getfacl command.
How can IT managers lock down the SUID permission file to protect their SLES 10 server?
Van Vugt: There is no way to switch it off SUID completely and you don't want to do
that; sometimes, it is needed. A utility like passwd wouldn't run anymore without the SUID permission set. What you can do, is monitor the use of SUID. My personal favorite is to monitor it with the find-utility, especially if you use this utility in combination with the -ctime option. You can get a very precise list of all files with the SUID permission set that have changed recently.
For example, use find / -perm u+s -ctime -7 to get a list of all files that do have the SUID
permission set and have changed in the last seven days. On a normal system, this command shouldn't give any result, with the exception of recently installed software. Do you see file that was changed? Time to start an investigation!
How does the mount command on SLES 10 make device sharing easier for networks?
Van Vugt: Using mount, not only can you get access to local devices, but to network
devices as well. I like to use it to perform tests on network services. If you use mount -t
cifs //localhost/someshare /mnt to do a quick test, you can find out if you can connect to a share that you've just created on the Samba server via your local host.
Alternatively, you can use it from /etc/fstab to make automated connections to network services. The advantage is that this way it is possible to connect end users to a network share
automatically. If you do so, however, don't forget the fstab mount
option _netdev. This will tell fstab that the mount is on the network and it will not try to establish the mount immediately when fstab is processed.
Is there any way to reduce the amount of time fsck takes once a non-journaled system has crashed?
Van Vugt: There is some thinking going on about how to do that. In
infohost.nmt.edu/~val/review/ext2fsck.pdf, you can read how the file system-wide dirty bit can be implemented in ext2. This bit can tell the operating system if any changes have happened recently. If no changes have occurred, the e2fsck program can do its work a lot less thoroughly.
This feature hasn't been implemented in the ext2 file system yet. I think you should really make a difference between a file system on a server that crashed and probably has damaged files, and the feature
in which file systems are checked automatically every n days or mounts. The latter option is a pain, you can set the automatic complete checks to be as infrequent as possible using the tune2fs command. In case there is a potential problem with a file system, it is a good idea to check it anyway. Don't like that? Use a journaling file system instead. Ext3 offers enough options to keep the performance loss as low as possible.
How can hard links and symbolic links make administration of SLES 10 easier?
Van Vugt: Hard and symbolic links allow you to put information at the places where you would need it, without losing the option of management in one place. Think of the tmp directory, which is used for temporary files. This directory occurs on many locations in your file system. In general, all those different tmp directories are just links to one single /tmp directory. This allows you to put all temporary files on one centralized location, and to create a special volume for that, which prevents your server from running out of disk space.
Also, links can help you to deal with a program. One example is older graphical utilities that try to locate the X-server in /usr/X11. On a good day, that default location for the X-server changed and
nowadays, /usr/X11R6 is used. Imagine that you have such an old application that still tries to locate program files in /usr/X11. It would be able to find those program files if you created a symbolic link
with the name X11 that refers to the new X11R6 directory.
