Unix Web Hosting for Developers

……………………………………………………………………………… #chown dns:dns file1 #chmod 664 file1 #ls -l file1 -rw-rw-r– 1 root dns 1188 Sep 14 09:35 file1 # ……………………………………………………………………………… Your staff can now do their jobs without the root password, and your files are immune to tampering by the system process that uses them. [3]In UNIX, “simplify” frequently means “make easier to say and faster to type, but more difficult to understand.” [4]You can have four-digit modes in special circumstances. See chmod(1) for details. You don’t normally use four-digit modes except on device nodes and other special files. File Flags UNIX filesystem permissions are standard across various versions of UNIX, and BSD extends the permissions scheme with file flags. These flags work with permissions to increase your system’s security. Some of these flags are used for non-security-related functions, but the ones we’re interested in here are security related. Note Many of the flags have different effects depending on the system securelevel, which will be covered shortly in the “Securelevels” section. For the moment, just nod and smile when you encounter a mention of securelevel; all will become clear in the next few pages. The following are the security-related file systems flags: sappnd The system-level append-only flag can only be set by root. Files with this flag can be added to, but cannot be removed or otherwise edited (which is particularly useful for log files). Setting sappnd on a .history file can be interesting if your system is compromised. Since a common intruder tactic is to remove.history or to symlink it to /dev/null so that the admin cannot see what was done, sappnd ensures that script kiddies cannot cover their tracks in this manner. It’s almost funny to watch the record of someone trying to remove a sappnd file. You can see the attacker’s frustration grow with the various things she tries. (It is better, of course, for your system not to be hacked at all!) This flag cannot be altered when the system is running at securelevel 1 or higher. schg The system-level immutable flag can only be set by root. Files with this flag set cannot be changed in any way, neither edited, moved, nor replaced. Basically, the filesystem itself will prevent all attempts to touch this file in any way. This flag cannot be altered when the system is running at securelevel 1 or higher. sunlnk The system undeletable flag can only be set by root. The file can be edited or altered, but it cannot be deleted. This is not as secure as the previous two flags because if a file can be edited, it can be emptied. It’s still useful for certain circumstances, however. I’ve used it to solve problems when a program insisted on deleting its own log files when it crashed. It’s not generally useful to set on any standard system flags. This flag cannot be altered when the system is running at securelevel 1 or higher. 148

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services

uappnd The user append-only flag can only be set by the file owner or root. Like the system append-only flag, sappnd, a file with this flag set can be added to but not otherwise edited or removed. This is most useful for logs from personal programs and the like, and is primarily a means to keep users from shooting themselves in the foot. The owner or root can remove this flag at any time. uchg The user immutable flag can only be set by the owner or root. Like the schg flag described earlier, the user immutable flag prevents a user from changing the file. Again, root can override this, and it can be disabled by the user at any securelevel. This flag helps to prevent mistakes, but not to secure the system. uunlnk The user undeletable flag can only be set by the owner or root. A file with this flag set cannot be deleted by the owner, though root can override that, and this flag can be turned off. This flag is mostly useless, but like the other user flags can be helpful in preventing mistakes. Viewing a File’s Flags You can see a file’s flags with ls -lo: ……………………………………………………………………………… # ls -lo important -rw-r–r– 1 mwlucas mwlucas uchg 0 May 11 19:51 important ……………………………………………………………………………… The uchg in the preceding listing tells us that the user immutable flag is set. In comparison, if a file has no flags set, it looks like this: ……………………………………………………………………………… # ls -lo unimportant -rw-r–r– 1 mwlucas mwlucas - 0 May 11 19:52 unimportant # ……………………………………………………………………………… The dash in place of the flag name tells us that no filesystem flag has been set. An out-of-the-box FreeBSD doesn’t have many files marked in this way. You can certainly mark anything you want in any way desired, however. On one system that I fully expected to be hacked, I went berserk with chflags -R schg in various system directories to prevent anyone from replacing system binaries with Trojaned versions. It might not stop an attacker from getting in, but it made me feel better to imagine how frustrated an attacker would be once he got a command prompt. Setting Flags You can set flags with the chflags(1) command. For example, to be sure that your kernel isn’t replaced, you could do this: ……………………………………………………………………………… # chflags schg /kernel ……………………………………………………………………………… This would keep anyone from replacing your kernel: both an intruder and you. 149

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services

……………………………………………………………………………… #chown bind:wheel file2 # ……………………………………………………………………………… Note Only root can give away files. If you’re logged in as a regular user and want someone else to own your files, you cannot do chown otheruser filename. Similarly, if you’re not in a group, you cannot give that group ownership of the file. Assigning Permissions So, now you know how to set permissions and change file owners and groups. What should you set or change? Well, for one thing, many sysadmins set files needed by vital system resources, such as DNS server zone files (see Chapter 11), to be owned by root and writable only by root. Thus, regular users cannot access them. While this approach works acceptably when you only have one administrator, it fails when delegating tasks. Some administrators work around this with add-ons like sudo(8) (in /usr/ports/security/sudo), but these programs are easily misconfigured. In the past, I’ve had assistants who, while not yet competent sysadmins, needed to edit vital files, but under no circumstances could they be given the root password. My solution has been to use groups, which lets me restrict access to these files without giving out root. (I’ll use DNS in this example, but this approach applies to any system where a restricted list of users needs to edit a set of files.) First, consider what sort of access you want people to have to the files. In this DNS example, the file owner must be able to read and write the files, and people in the group need to be able to read and write the files as well. Other users must be able to view them but not edit them. Since DNS files are plain text files, not programs, nobody should be able to execute the files. (It does no harm to set executable permissions on a file that isn’t a program, but it can confuse people.) So our permissions string will look like rw-rw-r–. The owner’s permissions include read (4) and write (2), the group has read (4) and write (2), and others have read-only permissions (4). So, we can set the permissions on the files with chmod 664 filename. Then you need to assign an owner to the file, bearing in mind that many system programs run as a particular user. For example, the named DNS server runs as bind, while the Apache Web server runs as nobody. While you might think that the server user is a logical owner, that’s not necessarily the case, because if someone broke into your DNS server, he could execute commands as the user bind. You may not mind if someone reads these files, but you don’t want anyone unauthorized to change them. The simplest solution is to create a separate user to own them. Creating a New User You can create a new user with adduser(8). (In Chapter 9, we will discuss adduser(8) and some /etc/login.conf tricks that ensure nobody can actually log in as this user.) Use vipw(8) to disable the password entirely (we will also discuss vipw(8) in Chapter 9), and then change the group on the affected file to “dns”. Next, set the permissions for the owner and the group to read and write, but for others to read-only, as shown here: 147

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services

Finally, others can only read the file. Read is 4, giving us a total of 4, so the third digit of our mode is 4. To change the mode, enter the chmod command: ……………………………………………………………………………… # chmod 754 file1 # ls -l file1 -rwxr-xr– 1 mwlucas admin 1188 Sep 14 09:35 file1 # ……………………………………………………………………………… You’ll most commonly see permissions documented by their mode. Once you’ve worked with mode for a while, it’ll be second nature. Log into your FreeBSD box and play with the permissions on a test file for a while to get the hang of it. Changing File Ownership Use chown(1) to change who owns a file, and use chgrp(1) to change the group. Both programs take two arguments: a username and the filename. In the following listing, we see that file1 is owned by mwlucas, and it is in the group wheel: ……………………………………………………………………………… # ls -l file1 -rwxrwxr– 1 mwlucas wheel 1188 Sep 14 09:35 file1 # ……………………………………………………………………………… You can change the group with chgrp by entering the following command: ……………………………………………………………………………… # chgrp dns file1 # ls -l file1 -rwxrwxr– 1 mwlucas dns 1188 Sep 14 09:35 file1 # ……………………………………………………………………………… Now, the file is in the group dns. You can change both owner and group with chown. To change the owner, use chown as shown here: ……………………………………………………………………………… # ls -l file1 -rwxrwxr– 1 mwlucas wheel 1188 Sep 14 09:35 file1 # chown bind file1 # ls -l file1 -rwxrwxr– 1 bind wheel 1188 Sep 14 09:35 file1 # ……………………………………………………………………………… To change both the owner and the group with chown, separate the names with a colon: 146

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services

The permissions string is ten characters long, the first character of which indicates whether the item is a directory. The other nine characters are broken into three groups of three that display privileges: The first group shows permissions for the file owner, the second group permissions for the group, and the third permissions for all other users. The first character in each group represents read, the second write, and the third execute. Consider this listing: ……………………………………………………………………………… -rwxr-xr– 1 mwlucas admins 1188 Sep 14 09:35 file1 ……………………………………………………………………………… You can see that the first group of three characters is rwx. This tells us that the owner, mwlucas, can read, write, and execute the file. The second group of characters, r-x, tells us that people in the admins group can read and execute the file, but cannot write it. And the final group, r–, tells us that anyone on the system can read the file, but may not write or execute it. Changing Permissions The permissions on a file are also called its mode. Chmod(1), or “change mode,” lets anyone with write permission on a file change its permissions. Chmod can be used in many different ways (see the man page for a full listing), but we’ll concentrate on the most common way to change permissions. Although this is not necessarily the easiest method to learn, it is the one you’ll see most often and the one that all sysadmins should understand. The modes as shown in the ls output are kind of clumsy-looking. They’re difficult to say, difficult to type, and just all-around difficult to work with. UNIX professionals don’t generally put up with that sort of thing for long, especially when it’s easy to simplify.[3] You have to know how to read the permissions that were shown earlier, but when you use chmod you can use the short form. In its short form, the mode is given as a three-digit number, with a range of digits from 0 to 7.[4] The first number represents the owner’s permissions, the second the group permissions, and the third everyone else’s permissions. (This is octal (base-8) math, much like the binary math we played with in Chapter 5 on networking.) The number 4 means “read,” 2 means “write,” and 1 means “execute.” To set the permissions on a file, add the appropriate numbers together. Clear as mud, eh? Don’t worry, we’re going to go very slowly here; if you already understand modes, you might want to skip ahead a couple of paragraphs. Assume that you want a file to be readable, writable, and executable by the owner, readable and executable by the group, and readable to others. This means that our permissions string would look like this: rwxr-xr–. The first digit of our mode is made up of the owner’s permissions, the initial three-letter “rwx” chunk of the permissions string. Read is 4, write is 2, and execute is 1; 4 + 2 + 1 is 7, so the first digit of our mode is 7. The group permissions are read and execute. Read is 4 and execute is 1; 4 + 1 is 5, so the second digit of our mode is 5. 145

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services

nogroup Group with no privileges operator Group that can access drives, generally for backup purposes staff Group for system staff tty Group for programs that can write to terminals, such as wall(1) wheel Group for users permitted to use the root password. If a user has the root password, but is not in the wheel group, she cannot use su to become root. Group Permissions You can assign particular permissions to groups, and all users in that group inherit those permissions. The permissions on a file are also called its mode. The UNIX permission scheme says that every file has three sets of permissions: owner, group, and other. View the existing file permissions with the -l flag to ls(1): ……………………………………………………………………………… # ls -l total 29 -rwxr-xr– 1 mwlucas admins 1188 Sep 14 09:35 file1 -rw——- 1 mwlucas admins 27136 Sep 14 09:36 file2 drwxr-xr-x 2 mwlucas admins 512 Sep 14 09:52 otherstuff # ……………………………………………………………………………… As seen in this listing, the first line (”total 29″) displays the number of 512-byte disk blocks the files use. (One block in this case is half a KB, or about a two-thousandth of a MB.) This particular directory has two files, file1 and file2, each of which appears on its own line, with some basic information and its permissions. The permissions on these files appear at the beginning of each line, in the long lines with r’s, w’s, and x’s, like “-rwxr-xr–”. The permissions control how each group can use the file, and they’re of three types: read (r), write (w), and execute (x). The right to read means that you can view or copy the file. Permission to write means that you can alter or overwrite the file. Execute permission means that you can run the file as a program all programs are executable files. Any entry that is a hyphen (-) means that the user does not have execute permission on that file. The last entry, otherstuff, is a directory. You can tell it’s a directory because the first entry in the permissions line is the letter “d”. Directory permissions control who can use the directory in the same way file permissions control who can use the file. Following the permissions is the number of links to the file. We will discuss links in Chapter 13. Then you’ll see the file’s owner and group. The number of bytes in the file comes next, followed by the date and time the file was last modified. Finally, you have the actual filename. When combined with owners and groups, permissions are very flexible. For example, you could place a set of files in a group called www, then give the www group permission to read and write to those files, thereby allowing anyone in the www group to edit them. With this setup, you could give your webmasters control of your company Web site, not allow other users to tamper with the pages, and avoid giving root access to the www group. 144

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services

The second field contains the group’s encrypted password. Group passwords encouraged poor security practices, so most modern UNIXes don’t support them. However, some old software expects to find a password field in /etc/groups, so rather than leave this field blank or remove it entirely, use an asterisk (*) as a placeholder. The third field holds the group’s unique numeric ID (GID). Many of FreeBSD’s internal programs use this GID, rather than names, to identify groups. Last is a list of all the users in that group. To add a user to a group, simply add the username to this list, separated from other names with commas. After editing /etc/group, it’s a good idea to make sure you haven’t made a mistake. To double-check your work, use chkgrp(8). It will double-check your work for you; if it runs silently, you haven’t shot yourself in the foot. Primary Group The group file does not contain a complete list of all users in every group. When you create a new user, a group is created that contains just that user, and it has the same name as the user. This is the user’s “primary group.” A user is automatically a member of his or her primary group, as listed in /etc/passwd (see Chapter 9). These primary groups do not appear in /etc/group. The only record of their existence is in the primary group field of /etc/passwd. This is arguably one of the most annoying things about primary groups, but adding a line to /etc/group for every single user can make the group file difficult to manage. For example, when the user “pbardaville” is added, the system creates a group “pbardaville” and assigns the user pbardaville to it. This entry appears only in /etc/passwd. This might seem complicated, but just remember that /etc/passwd trumps /etc/group, and you’ll have it. Some Interesting Default Groups FreeBSD ships with several default groups. Most are used by the system, and aren’t of huge concern to a sysadmin. Still, rather than have them remain mysterious, I present for your amusement the most useful, interesting, and curious. Adding your own groups simplifies administration, but the groups listed here are available on every FreeBSD system. bin Group for general programs daemon Group used by various system services, such as the printing system dialer Group of users who can access serial ports games Group for games programs and files kmem Group used by programs that have to access kernel memory, such as fstat(1), netstat(1), and so on mail Group for programs that handle mail operations man Unused in modern BSD, but corresponds to the man user news Group for Usenet news programs nobody Group for user ID with no privileges 143

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Unix Web Hosting services

The root Password Some actions require absolute control of the system, including manipulating core system files such as the kernel, device drivers, and authentication systems. The root account is designed to perform these actions. To use the root password, you can either log in as root at an actual login prompt or, if you are a member of the group wheel, use the switch user command su(1). (We’ll discuss groups in the next section.) I recommend su; it logs who uses it, and it can be used on a remote system. The command is very simple to use: ……………………………………………………………………………… # su Password: # Next, check your current username with the id(1) command: ……………………………………………………………………………… # id uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem), 3(sys), 4(tty), 5(operator), 20(staff), 31(guest) # ……………………………………………………………………………… You now own the system and I do mean own it. Consider every keystroke very carefully; carelessness can return your hard drive to the unformatted empty metal it shipped with. And use the root password sparingly, because anyone who has the root password can inflict unlimited damage upon the system. Do not give it to anyone who does not strictly need it! This naturally leads to the question “Who needs root access?” Much of the configuration discussed in Absolute BSD requires the use of the root password. Once you have the system running the way you like it, however, you can greatly decrease or discontinue the use of the root password. One of the simplest ways to do this is with the proper use of groups. Groups of Users UNIX classifies users into groups, each group consisting of people who perform similar administrative functions. You can have a group called “www”, which includes the people who edit Web pages, and a group called “email”, which includes the people who manage your mail server. You can set files and directories to be accessible to specific groups. Most group information is defined in the file /etc/group. Each line in the group file contains four colon-delimited fields. The first is the group name. Group names are fairly arbitrary: You could call a certain group of users “xyzzy” if you wished. It’s a good idea, however, to choose group names that give you some idea of what they’re for; while you might remember that the group xyzzy manages your email system today, will you remember it six months from now? Choose group names that mean something. 142

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Unix Web Hosting services

keep its users secure. If you haven’t installed the software discussed by the advisory, you don’t have to worry. Both types of security advisories generally contain a description of the problem, fixes, and workarounds. Read advisories carefully, since you can be sure that some script kiddie is looking for a vulnerable machine to break into. The best thing to do is to be invulnerable to these problems. Note We will discuss many security tools in this chapter. While none is sufficient, all are desirable. Treat everything you learn about in this chapter as a tool in a kit, not as the answer to all of your problems. For example, while simply raising the securelevel will not make your system secure, it can help when combined with reasonable permissions, file flags, patching your systems, password control, and all the other things that make up a good security policy. Installation Security Profiles When you first install FreeBSD (version 4.2 or later), you have the option to set a security profile, which basically enables and disables network services and sets the default system security according to some common defaults provided by the FreeBSD Project. (Everything the security profile changes is set in /etc/rc.conf.) In most cases, you should use these profiles as a starting point and edit the configuration set by the profile to meet your needs. The following sections give a rough description of the two security profiles: moderate and extreme. Moderate The moderate security profile enables inetd, sendmail, and sshd. This way, the system can send and receive email and allow people to connect remotely via ssh. Also, if you’ve previously configured the system to use NFS, portmap will be running so that the system can provide NFS services. The securelevel remains at the default of -1. Extreme With the extreme security profile, no basic system network daemons are running, except for extra software you specifically install, and the system securelevel is set to 2. The system will not receive or send email out of the box, and you cannot connect to it remotely. It’s unhackable, because it’s sitting there with nothing coming in or out. While security profiles provide useful templates, you need to know how to configure each of these services yourself. Take a look at rc.conf (explained in Chapter 9) to learn how. Root, Groups, and Permissions UNIX security has been considered somewhat coarse because one superuser, root, can do anything. Other users are lowly peons who endure the shackles root places upon them. While there is some truth to this, a decent administrator can combine groups and permissions to handle almost any security issue in a secure manner. 141

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Unix Web Hosting services

watching for security issues with both the base operating system and add-on software. These developers maintain a very low-volume mailing list, FreeBSD-security-notifications@FreeBSD.org, and it’s a good idea to subscribe to it. While you can monitor other mailing lists (such as BugTraq and CERT) for general announcements, the security-notifications list is a handy single source for FreeBSD-specific information. Subscribing To subscribe to the security-notifications mailing list, send a message to major-domo@FreeBSD.org containing the following: ……………………………………………………………………………………….. subscribe FreeBSD-security-notifications ……………………………………………………………………………………….. You’ll receive a confirmation message, and buried somewhere in it there’ll be a command string something like this: ……………………………………………………………………………………….. auth abax55b3 subscribe FreeBSD-security-notifications mwlucas@AbsoluteBSD.com ……………………………………………………………………………………….. Reply to majordomo@FreeBSD.org with a message containing just that string, and you’ll be subscribed. To unsubscribe, send a similar message to majordomo@FreeBSD.org with the following body text: ……………………………………………………………………………………….. unsubscribe FreeBSD-security-notifications ……………………………………………………………………………………….. You’ll get a message back with a confirmation string to send back to the mail server. Return it, and you’ll be unsubscribed. What You’ll Get Two sorts of messages come across the security-notifications mailing list: FreeBSD security advisories and FreeBSD ports-collection security advisories. The two have very different purposes. FreeBSD security advisories apply to the base operating system. When a FreeBSD component has a security hole, the security team releases a security advisory. Read the advisory carefully to determine what you need to do. The ports collection contains literally thousands of programs that can be easily installed on FreeBSD. While it’s not the definitive guide to what can work on the system, it’s certainly a big chunk of it. When the security team finds a hole in one of these software packages, they notify the vendor and issue a ports-collection security advisory. These pieces of software are beyond the FreeBSD Project’s control, but since they’re distributed with FreeBSD, FreeBSD frequently catches the blame when one of them is broken. The security team issues these advisories in an effort to 140

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services