Securing the Unix File System

You’ll now see how to secure your server’s file system against malicious intruders who may read and execute sensitive files. You may already know these techniques if you’re a seasoned admin, so feel free to move on to the Tomcat-specific sections.

Security has always been inherent in the Unix file system. The Unix permissions are the same for directories and files because a directory is considered to be a special kind of file. Table 12-6 describes these permissions.

Table 12-6: File Permissions for Unix

Permission

Actions Permitted

Read

View the contents of the file or directory.

Write

Modify or delete if a file; create files if a directory.

Execute

Execution if a file; access for directories.

Controlling Users, Groups, and Owners in Unix

To use these permissions, you need to consider how to assign these permissions to the various users who will be accessing your operating system.

Working with Users

Anyone who wants to log onto a Unix system must know an account name and its associated password. Each user can be assigned one or more of the permissions you saw previously and thus be granted authority to manipulate objects (files or directories) in the file system.

Working with Groups

Unix allows you to add users to a group. Groups can then receive permissions with all the users who belong to a group sharing those permissions.

Working with Owners

Finally, Unix has the concept of a file/directory owner. An owner is a user who ultimately has complete control over what permissions other users or groups have for a given resource, regardless of what permissions the user has been granted.

Working with Superusers

This discussion wouldn’t be complete without including one additional detail. Unix has so-called superuser accounts. These accounts have complete and unrestricted access to your system, regardless of any other permission that has been set. On Unix, the default superuser account is called root.

The password for this account should be well chosen and extremely well guarded. You’re advised not to use these accounts for your day-to-day operations, as any virus or other malicious program may inadvertently execute when running and this account has complete control of your system.

Creating Users and Groups in Unix

On Unix you use command-line utilities to create and manipulate users and groups. Although these are Linux utilities, they have analogs in other Unix-like operating systems, which will offer similar functionality. All these commands require you to be logged in as root.

Alternatively, because of the caveats on superuser accounts expressed previously, you can use the sudo command, which allows you to run commands as if you were logged in as root (or any user you want to configure). This effect wears off after five minutes, though this can also be configured, and you’re returned to your old user permissions. This ensures that you don’t leave a root-enabled terminal unattended for longer than five minutes and that, since you use your own password, you don’t have to use the root password in public.

To run a command under sudo, simply append the appropriate command and supply your password.

 $ sudo useradd lauraj -g users 

sudo gives you many other features, most of which can be used to give auditable responsibility to other users. See http://www.courtesan.com/sudo/ for more details.

You can determine which groups a user belongs to with the groups command, which displays its results as the username followed by the user’s groups.

 $ groups matthewm  matthewm : users abusers 

You add new users with the useradd utility.

 $ useradd lauraj 

This creates a new user in a group with the same name as the user. You can specify which group a user should belong to with the -g parameter, though the group must exist for any of the group assignment commands to work.

 $ useradd lauraj -g users 

Use the -G parameter to add a user to multiple groups and separate each group by a comma.

You can modify the groups to which an existing user belongs with the usermod command. It takes the same -g and -G parameters as the useradd command. The following example of the usermod command will make user matthewm belong only to the users group:

 $ usermod -g users -G "" matthewm 

You can delete users using the userdel command.

 $ userdel matthewm 

You can create groups with the groupadd command.

 $ groupadd abusers 

You can delete groups with the groupdel command.

 $ groupdel lovers 

Assigning Permissions in Unix

The Unix model of security isn’t as flexible as the Windows model, though it trades the complexity of Windows for a simplicity that’s easy to understand and easy to administer.

Setting Permissions in Unix

To view permissions in Unix, all you need is the ls utility. The following command will display the contents of a directory complete with permissions information:

 $ ls -l 

The -l parameter tells the ls command to display the long file directory format, which includes the permissions. The output of this command looks like the following:

 $ ls -l  drwxr-xr-x 2 tomcat tomcat 4096 Oct 22 18:38 bin 

You’ll see a series of columns that correspond to each file or directory in the current directory. You’re concerned only with the first, third, fourth, and last columns. Let’s define each of those, and drop out the other columns that are irrelevant to the discussion.

 Permissions Owner Group Filename  =======================================  drwxr-xr-x tomcat tomcat bin 

Now, let’s break down the values of each entry in the permissions column. The permissions column itself can be viewed as four separate columns: file type, owner permissions, group permissions, and permissions for other users. Let’s take the first and last files from the previous list and break down the permissions column for each.

 File Type Owner Group Other P. Filename  =====================================================  d rwx r-x r-x bin 

The first subcolumn of the permissions column dictates the file type, such as d for directory, l for link, or - for a normal file. All of the remaining columns display whether the owner, group, or other users have read (r), write (w), or executable (x) access to that file (remember that for directories, the executable property indicates whether the user has access to the directory). In the previous case, all three of these groups have read and execute rights, but only the owner of the bin directory can write to the directory.

Changing Permissions

You use the chmod utility to change the permissions of a file. For example, you can change the permissions of a file so that every user can read and write to it by running chmod with the following parameters:

 $ chmod u=rw,g=rw,o=rw file01 

The u parameter sets the permissions for the owner of the file, the g parameter sets the permissions for the group associated with the file, and o sets the permissions for everyone else. You can use one, two, or all three of these parameters. The following is the result of the operation:

 $ chmod u=rw,g=rw,o=rw file01  $ ls -l | grep file01  -rw-rw-rw- ... file01 

Table 12-7 describes the chmod command in more detail.

Table 12-7: chmod’s Parameters

chmod Parameter

Description

[u,g,o,a]=[r,w,x]

This is the parameter you saw in the previous example. On the left side of the equals sign, you choose one of the following to which you can assign permissions: the owner (u), group (g), others (o), or all three of these (a). On the right side, you choose from: read permission, write permission, or execute permission. You can combine the permissions on the right as also shown. You can issue this parameter multiple times if each instance is separated by a comma. Here are some examples:

a=rw

u=rwx,g=rx,o=rx

[u,g,o,a][+,-][r,w,x]

This parameter is the same as the previous one, except it either adds or removes a permission from existing permissions. For example, to remove the group’s write permission without altering its other permissions, you’d use the following parameter:

g-w

-R

This is the recursive parameter, meaning that the permission assignments will be made to the directory and any of its subdirectories and files, and any of their subdirectories, and so forth.

Changing Ownership

You can use the chown command to change the owner of a file and the group with which the file is associated.

 $ chown user[:group] filename 

So, if you want to change the owner of the LICENSE file from tomcat to bobcat, you’d issue this command:

 $ chown bobcat LICENSE 

Unix actually stores two more pieces of metadata with every file that relate to security. These are the SUID and SGUI bits. If a file has the SUID bit set, it indicates that users who execute the file will execute it as though they are the owners of the file. For example, if a file named program was owned by root and it had the SUID bit set, and if another user executed program, the operating system would execute program as though the user were root.

The SGID bit is similar. Any file with the SGID bit will make the user who executes that file a member of the group associated with the file for that file’s execution.

You can set the SUID and SGID bits with the chmod utility. The syntax is as follows:

 $ chmod u+s [filename] (sets the SUID bit)  $ chmod g+s [filename] (sets the SGID bit) 

The SUID and SGID bits show up in the executable column of the permissions of each file as an s, as follows:

 -rwsr-sr-x 2 tomcat tomcat 4096 Aug 25 01:28 program01 

Of course, you should use the SUID/SGID bits with great caution.

Planning Security Permissions

Now it’s time to talk about how to secure your system by using wise permissions configurations.

Separate Tomcat Account

Some users run Tomcat with their normal user account or with the superuser account, both of which are bad ideas. If Tomcat ever becomes compromised, it could use the permissions granted to the account that started it (such as your own account or the all-powerful superuser account) to wreak havoc. Therefore, you vastly improve the security of your file system by creating a special user account just for running Tomcat. This distinct account should be assigned only those permissions necessary to run Tomcat and nothing more.

Suggested Account Settings for Unix

Create an account for running Tomcat called tomcat. You should include tomcat in only one group, also named tomcat. Because you’ll want to run Tomcat as a daemon, you shouldn’t let console logins use this account. Disabling login ability is often achieved by starring the account’s password.

Here are two examples of this technique. The first example is from a BSD-like system that doesn’t use a shadow password file.

 /etc/passwd:  tomcat:*:23102:100:Tomcat:/:/bin/csh 

The second example is from a Linux system that does use a shadow password file.

 /etc/passwd:  tomcat:x:502:502:Tomcat:/:/bin/bash  /etc/shadow:  tomcat:*:12040:0:99999:7::: 

Note how the password column has been given an asterisk (*). This means you can’t log into this account.

The various Unix operating systems have several mechanisms for creating and configuring daemons. Chapter 2 discussed this procedure.

Configuring File Permissions in Unix

Up until now you’ve created a special tomcat account and instructed your operating system to launch the service with your tomcat account. You now need to configure your file system’s permissions.

Table 12-8 shows the recommended directory and owner/group and file permission combinations.

Table 12-8: Assigning Permissions to Tomcat’s Directories

Directory/File

Owner/Group

Permissions

$CATALINA_HOME

root/tomcat

rwxr-x---

$CATALINA_HOME/bin

root/tomcat

rwxr-x---

$CATALINA_HOME/bin/*.sh

root/tomcat

rwxr-x---

$CATALINA_HOME/common

root/tomcat

rwxr-x---

$CATALINA_HOME/conf

root/tomcat

rwxrwx--- (only if using the admin application or a user database)

rwxr-x--- (otherwise)

$CATALINA_HOME/logs

root/tomcat

rwxrwx---

$CATALINA_HOME/logs/*.*

root/tomcat r

w-rw----

$CATALINA_HOME/server

root/tomcat

rwxr-x---

$CATALINA_HOME/shared

root/tomcat

rwxr-x---

$CATALINA_HOME/temp

root/tomcat

rwxrwx---

$CATALINA_HOME/webapps

root/tomcat

rwxr-x---

$CATALINA_HOME/work

root/tomcat

rwxrwx---

If not otherwise indicated, all files in the listed directories should have the same ownership as their parent directory and have rw-r----- permissions.



Pro Jakarta Tomcat 5
Pro Apache Tomcat 5/5.5 (Experts Voice in Java)
ISBN: 1590593316
EAN: 2147483647
Year: 2004
Pages: 94

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net