Securing the Windows File System

In this section you’ll see how to secure your server’s file system against malicious intruders who could 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.

Windows implements a file system security architecture that uses permissions. You can use file system permissions to control the files users are allowed to view, execute, and manipulate. This means that users can’t access the file system in any way without being given explicit permission to do so.

Windows has several different file system types, as shown in Table 12-1.

Table 12-1: Windows File System Types

File System Type	Description
FAT	All early versions of Windows are based on the File Allocation Table (FAT) file system. FAT is capable of associating bytes with files and directories but not much more. FAT is the reason for good old filenames that couldn’t be longer than eight characters.
NTFS	The NT file system (NTFS) is better than FAT in every way, as it was developed for Microsoft’s enterprise NT systems. The latest incarnation of NTFS (available on Windows 2000/XP) supports permissions and encryption, long filenames, networking, disk quotas, and so on. NTFS also stores files in a much more efficient way than FAT and is much more reliable.
FAT32	FAT can handle only up to 2 gigabytes of information, so it’s unusable with any decent modern computer. NTFS was intrinsically linked with the Windows NT family, so it was inappropriate for Windows 9x. As a result, Microsoft created FAT32, which supports 2 terabytes of space and stores data in a more efficient way. FAT32 is available on Windows 95, Windows 98, Windows ME, Windows 2000, and Windows XP.

As you can see, only NTFS is appropriate for this discussion, as no other Windows file system supports security features such as encryption or permissions. This also means that if you run Tomcat on Windows, and you want to implement security properly, you’ll have to use the NTFS file system and thus Windows 2000/XP. This isn’t to say that you could run a decent server setup on another operating system, but your file system will be more vulnerable.

Note 

Your Windows 2000/XP setup may use the FAT32 file system. It’s fairly straightforward to change this, however.

Right-click your C: drive (or equivalent), and select Properties. You will see the properties page, as in Figure 12-1.

Figure 12-1: The properties page showing the file system type

In this case, the drive in question uses the NTFS file system. If your drive uses FAT32, you can upgrade your file system with the convert command-line conversion utility.

 > convert C: /FS:NTFS 

Replace C: with your hard drive as appropriate. This utility is designed to be fail-safe and won’t damage your data; but if you are in any way concerned and have vital data, then you should back up your drive before you run the command. Also, once you’ve converted a file system to NTFS, you can’t convert it back to FAT32.

You must have some disk space free if you want to convert your file system, because the convert utility will need space to work with to build the NTFS structures. The amount of space depends mainly on the initial size of the drive and the number of files and directories on the drive. The details are on http://support.microsoft.com/default.aspx?scid=KB;en-us;q156560, but Table 12-2 shows a summary and the calculation for the drive shown in Figure 12-1.

Table 12-2: Calculating the Space Needed for an NTFS Conversion

Component of Calculation	Value for Drive C: in Figure 12-1 (in Bytes)
The size of the volume in bytes divided by 100. If this value is less than 1,048,576, use 1,048,576. If it’s larger than 4,194,304, use 4,194,304.	4,194,304
The size of the volume in bytes divided by 803.	18,704,021
The number of files and directories on the volume multiplied by 1280.	184,695,040
Add 196,096.	196,096
Total (bytes)	207,789,461
Total (megabytes)	198.16

This calculation shows that you don’t need a huge amount of space on a drive for a successful conversion, though this largely depends on the number of files you have. One way to calculate this is to use the following command:

 C:\> dir /S 

This will cycle through all the files and directories on C: and display the totals, as shown in Figure 12-2.

Figure 12-2: The total number of files and directories on C:

Now that you have an NTFS file system, let’s discuss the individual NTFS permissions you can use. The permissions are divided into two categories: folder permissions and file permissions. Table 12-3 describes folder permissions, and Table 12-4 describes file permissions.

Table 12-3: Folder Permissions for Windows

Permission	Actions Permitted
Read	View files and subfolders; view folder ownership, permissions, and file system attributes (read-only, hidden, and so on).
Write	Create files and subfolders; view folder ownership and permissions, change folder attributes.
List Folder Contents	View names of files and subfolders in folder.
Read and Execute	Move through folder to get to subfolders and files; includes permissions from Read and List Folder Contents.
Modify	Delete the folder; rename the folder; includes permissions from Read and Execute and Write.
Full Control	Includes all other folder permissions; delete files and subfolders; take ownership; change permissions.

Table 12-4: File Permissions for Windows

Permission	Actions Permitted
Read	View the file contents; view file ownership, permissions, and file system attributes.
Write	Overwrite the file; view file ownership and permissions; change file attributes.
Read and Execute	Execute the file; includes permissions from Read.
Modify	Modify file; delete file; includes permissions from Read and Execute and Write.
Full Control	Includes all other file permissions; take ownership; change permissions.

Controlling Users, Groups, and Owners in Windows

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

Working with Users

Anyone who wants to log onto a Windows 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

Windows 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, Windows 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. Windows has superuser accounts, which have complete and unrestricted access to your system, regardless of any other permission that has been set. On Windows, the default superuser account is called Administrator.

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 Windows

You now need to create users and groups to implement the details mentioned earlier. To do this, select Control Panel Administrative Tools Computer Management to open the console, as shown in Figure 12-3.

Figure 12-3: The Computer Management tool

Now, click the Local Users and Groups icon. You can add, modify, and delete users and groups by selecting either of the two folders revealed and right-clicking the list of users or groups shown on the right.

Command-Line Users and Groups

In addition to the graphical user interface (GUI), Windows also has some command-line utilities for working with users and groups. You won’t see how to use it in detail here because the GUI is easier, though the command-line tools allow you to automate user and group tasks.

You have two utilities for working with groups at the command line: net group and net localgroup. Their syntax is identical, except that they operate on domain users and local users, respectively, though you can induce net localgroup to work with domain users by adding the /DOMAIN switch to all commands. To list existing groups on the local machine, use the following:

 C:\>net localgroup 

The equivalent net group command will list groups in the current NT domain.

To add a group to the local machine, run the following, where "Tomcat Group" is the name of the new group:

 C:\>net localgroup "Tomcat Group" /ADD 

If you wanted to add a description for this group, run the following, where the description is always in quotes:

 C:\>net localgroup "Tomcat Group" /ADD /COMMENT:"A Tomcat group" 

To delete the same group, run the following:

 C:\>net localgroup "Tomcat Group" /DELETE 

You can also use these utilities to add users to groups. When adding a user with net localgroup, make sure that the user exists, that domain users have their domain prefix (for example, TOMCAT\matthewm), and that any groups you’re adding to this group aren’t local groups. You can specify more than one user after the group’s name, as long as all the usernames are separated by spaces.

 C:\>net localgroup "Tomcat Group" matthewm /ADD 

This adds the local user matthewm to the Tomcat Group. To check that the user was added successfully, run the following:

 C:\>net localgroup "Tomcat Group"  Alias name     Tomcat Group  Comment        A Tomcat group  Members  ----------------------------------- matthewm 

To add a user account at the command line, use the net user command. This is a powerful command, though you’ll see only its basic functions here. To add a new user called tomcat with a specified password of meow, run the following:

 C:\>net user tomcat meow /ADD 

If you’re uneasy about displaying passwords in plain text on the screen, you can ask for a password prompt. The following won’t display the password as you type it in:

 C:\>net user tomcat * /ADD  Type a password for the user:  Retype the password to confirm: 

Again, you can add a description to this user with the same utility.

 C:\>net user tomcat /ADD /COMMENT:"A Tomcat user" 

To check the user’s details, just supply their username to the net user command.

 C:\>net user tomcat  User name                    tomcat  Full Name  Comment                      A Tomcat user  User's comment  Country code                 000 (System Default)  Account active               Yes  Account expires              Never  Password last set            10/22/2004 5:49 PM  Password expires             12/4/2004 4:37 PM  Password changeable          10/22/2004 5:49 PM  Password required            Yes  User may change password     Yes  Workstations allowed         All  Logon script  User profile  Home directory  Last logon                   Never  Logon hours allowed          All  Local Group Memberships      *Tomcat Group         *Users  Global Group memberships     *None 

You can of course set all these parameters shown. See http://www.microsoft.com/WINDOWSXP/home/using/productdoc/en/net_user.asp for more details.

To delete the tomcat user, run the following:

 C:\>net user tomcat /DELETE 

If you delete the user, it will be removed from any groups of which it was a member.

Microsoft also provides the addusers utility for creating users from a comma-delimited file. However, this is provided only in the Windows Resource Kit. See http://support.microsoft.com/default.aspx?scid=kb;en-us;199878 for more details.

Assigning Permissions in Windows

Windows gives you much more flexibility when assigning permissions than Unix does. However, this flexibility comes with a steep price: your security configuration can rapidly deteriorate into chaos if you aren’t careful. The Unix model, on the other hand, trades the complexity of Windows for a simplicity that’s easy to understand and easy to administer.

You have two ways to manipulate a file’s permissions in Windows: a GUI and a command-line interface. To view permissions in the GUI, open Windows Explorer, pick the file or directory whose permissions you want to view, right-click it, and choose Properties. Click the Security tab of the resulting window, and you’ll see something similar to Figure 12-4.

Figure 12-4: A directory’s permissions

The top section has all the users and groups with explicit permissions for this object. If you click a user or a group, the Permissions section will show the permissions assigned.

The default configurations of Windows XP Professional often hide this Security tab. To enable it, go to Control Panel Folder Options. Click the View tab, scroll to the bottom of the Advanced Settings list, and uncheck the Use Simple File Sharing (Recommended) option.

Inherited Permissions

Some checkboxes that accompany permissions are disabled, which indicates that the permissions in question have been inherited from a parent folder. By default, all files and directories inherit the permissions that have been assigned to their parent object.

Permission inheritance is recursive, so a folder inherits permissions from its parent, all the way to the root directory of the file system. When a file or folder inherits a permission, you can’t clear the Allow checkbox. You can, however, explicitly deny a permission with the Deny checkbox. Deny settings always override Allow settings, for this reason.

You can also turn off permission inheritance for an object. To do so, uncheck the Allow inheritable permissions from parent to propagate to this object box, and you’ll no longer inherit permissions and can explicitly define them all for your objects.

Group Permissions

A user may inherit permissions from group membership. This means you may want to assign additional explicit permissions to a user over and above their group permissions. Therefore, you can allow certain users to have access to a file while other members of their group don’t.

In the event that you assign conflicting permissions, through multiple group membership, permission denials always take precedence over permission allowances.

Verifying Permissions

Windows provides a feature that you can use to verify a user’s permissions. You can do this by clicking the Advanced button and selecting the Permissions tab from the Access Control Settings window that appears. You can then select a group or user to verify by double-clicking or clicking View/Edit..., as shown in Figure 12-5.

Figure 12-5: Verifying a group’s permissions

You can now verify permissions, even if they were obtained via inheritance or group membership. You should note that the permissions here are more numerous and have different names than in other dialog boxes. Windows 2000 added some additional, finer-grained permissions to the NTFS security model.

Command-Line Permissions

In addition to the GUI, Windows has the cacls command-line utility, which you can use to modify permissions. You won’t see how to use it in detail here, though, because the GUI is easier and has more features.

You can view the permissions for the Tomcat folder with the following:

 C:\>cacls jakarta-tomcat  C:\jakarta-tomcat Everyone:(OI)(CI)F                    NT AUTHORITY\SYSTEM:(OI)(CI)F                    BUILTIN\Administrators:(OI)(CI)F 

Here F donates full control for these groups. You can use the same utility to deny or change access.

 C:\>cacls jakarta-tomcat /E /P Everyone:R  processed dir: C:\jakarta-tomcat 

The /E switch indicates that this command should edit the configuration, not overwrite it. /P sets a permission, in this case to R, which is read access. Check that this command has worked with the following:

 C:\>cacls jakarta-tomcat  C:\jakarta-tomcat Everyone:(OI)(CI)R                    NT AUTHORITY\SYSTEM:(OI)(CI)F                    BUILTIN\Administrators:(OI)(CI)F 

To revoke access for a user, run the following:

 C:\>cacls jakarta-tomcat /E /R Everyone 

For more information on cacls, you can execute it with no options and see all the parameters it supports.

Planning Security Permissions in Windows

Now it’s time to talk about how to secure your system by using wise permission 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 is ever 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 account should be assigned only those permissions necessary to run Tomcat and nothing more.

Suggested Account Settings for Windows

You should create a new user named tomcat. Make sure that the tomcat account doesn’t belong to any groups, including the default user group. Also, make sure you give the account a password. Windows can’t use the tomcat account to launch services without you giving it a password. For maximum security, the password should be at least six characters long and consist of mixed-case letters, numbers, and special characters.

The only way for Tomcat to run as a user in Windows is if it’s installed as a service. Chapter 3 covered this process. You’ll need to give it permissions to run services and nothing else.

Windows exposes many additional permissions, mostly unrelated to the file system. These permissions are defined in a security policy. Windows security policies may be defined on the machine itself (a local security policy) or may be defined in a central network location (a domain security policy).

You can modify your machine’s local security policy by selecting Control Panel Administrative Tools Local Security Policy. You will see a screen similar to that in Figure 12-6.

Figure 12-6: The local security policy settings

You’ll need to make two changes to your local security policy.

• Disable the tomcat account’s ability to log in: Although tomcat’s lack of membership in any group implicitly denies tomcat this ability, you should still explicitly deny this privilege. Double-click the Deny Logon Locally setting in the Policy column. In the screen that appears, add the tomcat account. Do the same for the following policies: Deny Access to This Computer from the Network, Deny Logon As a Batch Job, and Deny Logon Through Terminal Services, if it’s present.

• Grant permission to tomcat to run services: Double-click Log On As a Service, and add tomcat to this policy.

When Tomcat was installed as a service, it should start automatically. Check Chapter 2 for details.

Configuring File Permissions in Windows

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

Your tomcat user account will by default be given read access to many locations on the file system. So the best place to start is revoking all file system permissions for the root directory of all your drives. You can accomplish this by going to My Computer and viewing the properties for each hard disk partition. In the Security tab, add the tomcat account and disable all of its permissions, as shown in Figure 12-7.

Figure 12-7: The tomcat user is denied all rights.

Now you need to grant read access to the JDK directory so that Java can execute Tomcat. Locate the directory where you’ve installed Java (identified by the %JAVA_HOME% variable) and give the tomcat account the Read & Execute, List Folder Contents, and Read permissions. Depending on where you’ve installed your JDK, you may first need to set the folder not to inherit security permissions from its parent. The best way to do this is to instruct Windows to copy (not remove) the formerly inherited permissions and then remove any conflicting entry for the tomcat account.

Finally, you need to grant various permissions to the Tomcat directory hierarchy, as shown in Table 12-5.

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

Tomcat Directories	Permissions for Tomcat Account
%CATALINA_HOME% %CATALINA_HOME%\bin	Allow: Read & Execute, List Folder Contents, and Read
%CATALINA_HOME%\common %CATALINA_HOME%\server %CATALINA_HOME%\shared %CATALINA_HOME%\webapps	Deny: Write
%CATALINA_HOME%\conf	Allow: Read & Execute, List Folder Contents, Read, Write (only if using the admin application or a user database) Deny: Write (otherwise)
%CATALINA_HOME%\logs %CATALINA_HOME%\temp %CATALINA_HOME%\work	Allow: Modify, Read & Execute, List Folder Contents, Read, Write

Everything is read-only except those locations that Tomcat needs to modify: the conf directory where the admin application may edit server.xml and context XML files, the temp directory for temporary files, the logs directory, and the work directory for Tomcat’s own temporary working files.

The next few pages are devoted to Unix issues, so feel free to skip to the “Examining General Tomcat Security Principles” section.