When a user runs a program on Linux, the program runs with the same permissions as that user account. For example, if user Joe doesn’t have permission to modify the files in /etc, any program that Joe runs won’t have permission either. There’s an exception to every rule. Files that have the SetUID bit set can run with the permissions of the user that owns them. For example, if the /usr/bin/xcdroast program was owned by the user root, and had the SetUID option turned on, and Joe ran X-CD-Roast, then X-CD-Roast would be able to do anything that the root user could. In this way, SetUID is handy to allow programs to run with permissions ordinary users don’t have. In the case of X-CD-Roast, the burning software needs root access in order to use devices attached to the system. Another example is SSH. Like X-CD-Roast, it needs to be able to perform tasks that are normally the province of the root user, so the SSH program file is owned by root, and it has the SetUID bit set. This way any user can run SSH and it will work fine. A listing for /usr/bin/ssh will show something like this:
┌──[jason@192.168.1.2]─[~/Documents/sysinfo] └──╼ (master) ╼ $ ls -l /usr/bin/ssh -rwxr-xr-x 1 root root 789448 May 29 2020 /usr/bin/ssh |
Looks like a normal listing? Check again. Where you’d expect an ‘x’ for the owner, there’s an ‘s’. This is the SetUID bit. You can set the bit this way.
chmod u+s [file] chmod u-s [file] |
This will add or remove the bit respectively. But keep reading before you add this bit to a file because SetUID programs (especially those owned by root) have some important security implications. If X-CD-Roast or SSH had a security hole, a cracker could perhaps use them to start other programs. Since these programs run as root, so do other programs started from them. Once a cracker can do this on your system, they have free reign to view, modify, move and delete any file on your filesystem. SetUID programs (especially those owned by the root user) should be limited to vital servers that are exposed to the outside world. Even though you have a firewall (you do have a firewall, don’t you? If not, see the Networking chapter!), being extra cautious about security is always a good thing. Hence users who own server machines, even with firewalls, should avoid installing applications that use SetUID unnecessarily. For example, on Linux systems, to make a server program listen on a particular port below 1024, root permission is necessary. The older Sendmail system does this and also uses SetUID root programs to handle other tasks such as queuing outgoing mail that does not need root permission at all. If a bug was found in the part of Sendmail that queues mail, it could have disastrous effects. Postfix (which we set up in the Networking chapter), for example, is smarter. It only runs as root to bind Postfix to port 25 and then uses programs that run as other user accounts to handle mail queuing and all other tasks. So how do you find files with SetUID activated? As described in the previous Linux Pocketbook, you can use the find command to find all sorts of information. Before you start chewing up your disk access searching your entire system (you’re not going to find any SetUID programs in your MP3 archive directory), think about where SetUID programs might be placed, and search those directories…
Unless you have reason to believe otherwise, restrict your search recursively to /usr and /sbin. Run the following command as root:
┌──[jason@192.168.1.2]─[~/Documents/sysinfo] └──╼ (master) ╼ $ find /usr -perm -u=s /usr/bin/pmount /usr/bin/su /usr/bin/newgrp /usr/bin/passwd /usr/bin/gpasswd /usr/bin/mount /usr/bin/pkexec /usr/bin/umount /usr/bin/sudo /usr/bin/pumount /usr/bin/chsh /usr/bin/fusermount /usr/bin/chfn |
This is an excerpt from the output, this shows all setuid programs in your /usr directory.
Chances are you won’t know the purposes of all the displayed programs, and you’re going to need to read up on each (through its Web site, man page or accompanying documentation, or on Linux Web sites) to determine if it’ll run smoothly with SetUID tuned off. This is why this step of security is only appropriate if it’s absolutely imperative to close off all possible exploits on a system, no matter how remote the possibility (that is if you’re running a publicly accessible server). Security can be hard work! This will be very helpful in the long run. Making sure that there are no executable files on your system that should not be there. Although if a rootkit is installed, it is almost impossible to find as the Linux utilities you would use to look for it would be replaced and will only show you what they want you to see… Each software package you install, from CD or the Net, is a potential hole. So how do you go about reducing the size of that hole to minimize the risk? First, know what you are installing, what it does and what files it uses to do it, where it puts these files and who has access to them. Whether you are using rpm, dpkg or tarballs, you will have a list of files or at least a README file. Read the README, skim the doc files and the man page, and check the file list. You are looking for configuration files and passwords. If the software uses a configuration file, then run an eye over it, looking for any useful information. If the package listens on a port, why? Does the whole world need access to that port or should you apply a firewall so that only people you know can access it? If it uses passwords that are in
cleartext, can normal users find and read them, or are they visible only to users of your Web site? If so, can you move them or change the permissions to stop that? Is there an option to use encrypted passwords? Are you happy with the risk those passwords present, or will you find a different package? Do you have control over who can run the program? Is it OK for anyone who logs in to run it, or should you change permissions so only certain people can? What are the permissions on the data files and are those safe enough for you? Should you change the ownership and permissions so only certain people can read the data or run the program, and will the program run if you do? Is the setUID bit set and does it need to be? How much effort you put into permissions will depend on who else uses your machine.
But get into the habit of at least looking. Not every bit of software you get from the Net has been put together by someone with security as their priority. And shrinkwrap is no protection; off-the-shelf programs are just as liable to have gaping holes as those downloaded from the Web. If you install something that requires configuration, then configure it and back up the config files to floppy or CD, or some other removable medium. Label it and store it and update it when you change the config. That way, should your hard disk die or your system succumb to a cracker, you can recreate it the way you like it without the hard slog. If you have a large-capacity backup device such as a Zip drive or a CD, then you can make regular copies of /etc which will catch almost all configuration files. Naturally, don’t assume it will. Check each package you use to find out where it keeps its config files and add that to your backup. If you install something that uses a password — MySQL, for example — then immediately change the default. Immediately. Do not let anything even sit on your system, let alone run, with the default password. Choosing decent passwords can be a chore. There are many different methods for choosing passwords, but an easy one is to take a simple phrase — the line of a song or poem — and use the first letters from each word, including capitals and perhaps punctuation. So, ‘Australians all let us rejoice for we are young and free!’ becomes this 12-character password: AalurFwayaf!. The song verse means it’s easy for you to remember but hard for anyone to guess, and it’s unlikely that such a combination would be easily worked out by a cracking program. Similarly, anyone who has access to your system should have a sensible password. It doesn’t have to be complex — the easier it is to remember the less likely a user is to write it down where it can be found.
But given a choice, many people will choose silly passwords: ‘hello’, ‘football’, ‘please-crack-me’. Remember, cracking software works from dictionary files. That’s why when choosing a password for your ISP account you were asked to mix numbers and letters, using both capitals and lowercase. This is good advice to follow. Even He11o65’ is infinitely harder to determine by software or mental prowess than ‘hello’. Although ‘HUV%^RTT^FG%^376534765373567hebeuhfbguebg’ is a very good password, it is very hard to memorize unless you are Commander Data and then users are tempted to write down passwords. So check that your users have chosen a good password. All the firewalling configurations in the world will mean naught if a cracker gets in using a legitimate account. All that said, if Linux is just a hobby for you on the home PC, then you can get by without being too stringent. However, if you’re planning to configure systems for a business, or anywhere where information is important, the habits you learn now are the ones that will stick with you in the future.