7.4 Protecting Files and the Filesystem

In general, the goal of every security measure on a system is to prevent people from doing things they shouldn't. Given the all-or-nothing structure of Unix privileges, in practical terms this means you are trying to prevent unauthorized access to the root account it also implies that the root account is what the bad guys are trying to gain access to. When they cannot do so directly because the root password has been well chosen, they may try other, indirect routes through the filesystem to gain superuser status.

So, how can you get root access from an ordinary, unprivileged user account? One way is to get root to execute commands like these:

# cp /bin/sh /tmp/.junk # chmod 4755 /tmp/.junk 

These commands create a setuid root version of the Bourne shell: any user can start a shell with this file, and every command that he runs within it will be executed as if he were root. Of course, no reputable system administrator will run these commands on demand, so a cracker will have to trick her into doing it anyway by hiding these commands or other commands just as deadly within something that she will execute. One large class of system attack revolves around substituting hacked, pernicious copies of normally benign system entities: Unix command executables, login or other initialization files, and so on. Making sure that the filesystem is protected will prevent many of them from succeeding.

In this section, we'll consider the types of vulnerabilities that come from poorly-chosen filesystem protections and general system disorganization. In the next section, we'll look at ways of finding potential problems and fixing them.

7.4.1 Search Path Issues

It is important to place the current directory and the bin subdirectory of the user's home directory at the end of the path list, after the standard locations for Unix commands:

$ echo $PATH  /usr/ucb:/bin:/usr/bin:/usr/bin/X11:/usr/local/bin:$HOME/bin:.

This placement closes a potential security hole associated with search paths. If, for example, the current directory is searched before the standard command locations, it is possible for someone to sneak a file named, say, ls into a seemingly innocuous directory (like /tmp), which then performs some nefarious action instead of or in addition to giving a directory listing. Similar effects are possible with a user's bin subdirectory if it or any of its components is writable.

Most importantly, the current directory should not even appear in root's search path, nor should any relative pathname appear there. In addition, none of the directories in root's search path, nor any of their higher-level components, should be writable by anyone but root; otherwise someone could again substitute something else for a standard command, which would be unintentionally run by and as root.



Scripts should always set the search path as their first action (which includes only system directories protected from unauthorized write access). Alternatively, a script can use the full pathname for every command, but it's easy to slip up using the latter approach.

7.4.2 Small Mistakes Compound into Large Holes

It is possible, and probably even common, for large security problems to arise from small mistakes, an effect tangentially related to the one described in the science fiction story "Spell My Name with an S" by Isaac Asimov. Consider these two small file protection errors:

  • User chavez's .login file is writable by its group owner (chem).

  • The directory /etc is writable by its user and group owners (root and system, respectively).

Suppose user chavez is also a member of group system: now you have a situation where anyone in the chem group has a very good chance of rep lacing the password file.

How does that work? Since ~chavez/.login is writable by group chem, anyone in that group can edit it, adding commands like:

rm -f /etc/passwd  cp /tmp/data526 /etc/passwd

Since chavez is a member of the system group and /etc is writable by group system, both commands will succeed the next time chavez logs in (unless she notices that the file has been altered would you?). Keep in mind how powerful write access to a directory is.

More subtle variations on this theme are what usually happen in practice; /etc being writable is not really a small mistake. Suppose instead that the system administrator had been careless and had the wrong umask in effect when she installed a new program, xpostit (which creates memo pad windows under X), into /usr/local/bin, and that file was writable by group system. Now the bad guy is able to replace only the xpostit executable. Exploiting this weakness will take more work than in the previous case but is ultimately just as successful: writing a program that merely starts the real xpostit when most users run it but does something else first when root runs it. (A smart version would replace itself with the real xpostit after root has used it to cover its tracks.)

It usually isn't hard to get root to run the doctored xpostit. The system administrator may already use it anyway. If not, and if the bad guy is bold enough, he will walk over to the system administrator's desk and say he's having trouble with it and hope she tries it herself to see if it works. I'm sure you can imagine other ways.

In addition to once again pointing out the importance of the appropriate ownership and protection for all important files and directories on the system, the preceding story highlights several other points:

  • Because it is always world-writable, don't use /tmp as any user's home directory, not even a pseudo-user who should never actually log in.

  • Think carefully about which users are supplementary members of group and any other system groups, and make sure that they understand the implications.

  • root's umask should be 077 or a more restrictive setting. System administrators should turn on additional access by hand when necessary.

7.4.3 The setuid and setgid Access Modes

The set user ID ( setuid) and set group ID (setgid) file access modes provide a way to grant users increased system access for a particular command. However, setuid access especially is a double-edged sword. Used properly, it allows users access to certain system files and resources under controlled circumstances, but if it is misused, there can be serious negative security consequences.

setuid and setgid access are added with chmod's s access code (and they can similarly be recognized in long directory listings):

# chmod u+s  files                       setuid access # chmod g+s  files                       setgid access 

When a file with setuid access is executed, the process' effective UID (E UID) is changed to that of the user owner of the file, and it uses that UID's access rights for subsequent file and resource access. In the same way, when a file with setgid access is executed, the process' effective GID is changed to the group owner of the file, acquiring that group's access rights.

The passwd command is a good example of a command that uses setuid access. The command's executable image, /bin/passwd, typically has the following permissions:

$ ls -lo /bin/passwd  -rwsr-xr-x 3 root 55552 Jan 29 2002 /bin/passwd

The file is owned by root and has the setuid access mode set, so when someone executes this command, his EUID is changed to root while that command is running. setuid access is necessary for passwd, because the command must write the user's new password to the password file, and only root has write access to the password file (or the shadow password file).

The various commands to access line printer queues are also usually setuid files. On systems with BSD-style printing subsystems, the printer commands are usually setuid to user root because they need to access the printer port /dev/printer (which is owned by root). In the System V scheme, the printing-related commands are sometimes setuid to the special user lp. In general, setuid access to a special user is preferable to setuid root because it grants fewer unnecessary privileges to the process.

Other common uses of the setuid access mode are the at, batch, and mailer facilities, all of which must write to central spooling directories to which users are normally denied access.

setgid works the same way, but it applies to the group owner of the command file rather than to the user owner. For example, the wall command is setgid to group tty, the group owner of the special files used to access user terminals. When a user runs wall, the process' EGID is set to the group owner of /usr/bin/wall, allowing him to write to all TTY devices.

As the examples we've considered have illustrated, setuid and setgid access for system files varies quite a bit from system to system (as does file ownership and even directory location). You should familiarize yourself with the setuid and setgid files on your system (finding all of them is discussed later in this chapter).

To be secure, a setuid or setgid command or program must not allow the user to perform any action other than what it was designed to do, including retaining the setuid or setgid status after it completes. The threat is obviously greatest with programs that are setuid to root.

Aside from commands that are part of Unix, other setuid and setgid programs should be added to the system with care. If at all possible, get the source code for any new setuid or setgid program being considered and examine it carefully before installing the program. It's not always possible to do so for programs from third-party application vendors, but such programs are usually less risky than free programs. Ideally, the part requiring privileged access will be isolated to a small portion of the package (if it isn't, I'd ask a lot of questions before buying it). Methods to ensure security when creating your own setuid and setgid programs are discussed in the next section. Writing setuid/setgid programs

Two principles should guide you in those rare instances where you need to write a setuid or setgid program:

Use the minimum privilege required for the job.

Whenever possible, make the program setgid instead of setuid. 99 percent of all problems can be solved by creating a special group (or using an existing one) and making the program setgid. Almost all of the remaining 1 percent can be solved by creating a special user and using setuid to that special user ID. Using setuid to root is a bad idea because of the difficulty in foreseeing and preventing every possible complication, system call interaction, or other obscure situation that will turn your nice program into a security hole. Also, if the program doesn't need setuid or setgid access for its entire lifetime, reset its effective UID or GID back to the process' real UID or GID at the appropriate point.

Avoid extra program entrances and exits.

In addition to writing in an explicit back door, this principle rules out many different features and programming practices. For example, the program should not support shell escapes,[5] which allow a shell command to be executed inside another program. If a setuid program has a shell escape, any shell command executed from within it will be run using the process' effective UID (in other words, as root if the program is setuid to root). To be completely secure, the program should not call any other programs (if it does so, it inherits the security holes of the secondary program). Thus, if a setuid program lets you call an editor and the editor has shell escapes, it's just as if the first program had shell escapes.

[5] Strictly speaking, as long as the program ensured that any created child processes did not inherit the parent's setuid or setgid status (by resetting it between the fork and the exec), shell escapes would be OK.

This principle also means that you should avoidsystem calls that invoke a shell (popen, system, exec{vp,lp,ve}, and so on). These calls are susceptible to attacks by clever users.

7.4.4 Access Control Lists

Access control lists (ACLs) offer a further refinement to the standard Unix file permissions capabilities. ACLs enable you to specify file access for completely arbitrary subsets of users and/or groups. All of our reference operating systems provide ACLs, with the exception of FreeBSD.[6]

[6] Actually, POSIX ACL functionality is partially present in current releases of FreeBSD, but the facility is still considered experimental.

The first part of this section covers AIX ACLs. It also serves as a general introduction to ACLs and should be read by all administrators encountering this topic for the first time. Table 7-1 lists features of the ACL implementations on the systems we are considering.

Table 7-1. ACL features by operating system








Follows POSIX standard?







chmod deletes extended ACEs?

numeric mode only






ACL inheritance from parentdirectory's default ACL?







NFS support?







ACL backup/restore support

backup (by inode)






[7] ACL support in FreeBSD is preliminary.

[8] The most recent versions of chmod support the -A option, which retains ACL settings

[9] See http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/star.html.

Note that the NFS support listed in the table refers to whether NFS file operations respect ACLs for other systems running the same operating system (homogeneous NFS, if you will). Heterogeneous NFS support is seldom offered. Even when NFS is supported, there can still be privilege glitches arising from NFS's practice of caching files and their permissions for read purposes in a user-independent manner. Consult the documentation for your systems to determine how such situations are handled. Introducing access control lists

On anAIX system, an access control list looks like this:

attributes:                              Special modes like setuid. base permissions                         Normal Unix file modes:    owner(chavez): rw-                    User access.    group(chem): rw-                      Group access    others: r--                           Other access. extended permissions                     More specific permission entries:    enabled                                Whether they're used or not.    specify r-- u:harvey                   Permissions for user harvey.     deny -w- g:organic                     Permissions for group organic.     permit rw- u:hill, g:bio               Permissions for hill when group bio is active. 

The first line specifies any special attributes on the file (or directory). The possible attribute keywords are SETUID, SETGID, and SVTX (the sticky bit is set on a directory). Multiple attributes are all placed on one line, separated by commas.

The next section of the ACL lists the base permissions for the file or directory. These correspond exactly to the Unix file modes. Thus, for the file we're looking at, the owner (who is chavez) has read and write access, members of the group chem (which is the group owner of the file) also have read and write access, and all others have read access.

The final section specifies extended permissions for the file: access information specified by user and group name. The first line in this section is the word enabled or disabled, indicating whether the extended permissions that follow are actually used to determine file access. In our example, extended permissions are in use.

The rest of the lines in the ACL are access control entries (ACEs), which have the following format:

operation  access-types  user-and-group-info 

The operation is one of the keywords permit, deny, and specify, which correspond to chmod's +, -, and = operators, respectively. permit says to add the specified permissions to the ones the user already has, based on the base permissions; deny says to take away the specified access; and specify sets the access for the user to the listed value. The access-types are the same as those for normal Unix file modes. The user-and-group-info consists of a user name (preceded by u:) or one or more group names (each preceded by g:) or both. Multiple items are separated by commas.

Let's look again at the ACEs in our sample ACL:

specify  r--  u:harvey                Permissions for user harvey.  deny     -w-  g:organic               Permissions for group organic.  permit   rw-  u:hill, g:bio           Permissions for hill when group bio is active.

The first line grants read-only access to user harvey on this file. The second line removes write access for the organic group from whatever permissions a user in that group already has. The final line adds read and write access to user hill while group bio is part of the currentgroup set (see Section 6.1). By default, the current group set is all of the groups to which the user belongs.

ACLs that specify a username and group are useful mostly for accounting purposes; the previous ACL ensures that user hill has group bio active when working with this file. They are also useful if you add a user to a group on a temporary basis, ensuring that the added file access goes away if the user is later removed from the group. In the previous example, user hill would no longer have access to the file if she were removed from the bio group (unless, of course, the file's base permissions grant it to her).

If more than one item is included in the user-and-group-info, all of the items must be true for the entry to be applied to a process (Boolean AND logic). For example, the first ACE below is applied only to users who have both bio and chem in their group sets (which is often equivalent to "are members of both the chem and bio groups"):

permit   r--  g:chem, g:bio permit   rw-  u:hill, g:chem, g:bio

The second ACE applies to user hill only when both groups are in the current group set. If you wanted to grant write access to anyone who was a member of either group chem or group bio, you would specify two separate entries:

permit   rw-  g:bio permit   rw-  g:chem

At this point, it is natural to wonder what happens when more than one entry applies. When a process requests access to a file with extended permissions, the permitted accesses from the base permissions and all applicable ACEs all ACEs that match the user and group identity of the process are combined with a union operation. The denied accesses from the base permissions and all applicable ACEs are also combined. If the requested access is permitted and it is not explicitly denied, then it is granted. Thus, contradictions among ACEs are resolved in the most conservative way: access is denied unless it is both permitted and not denied.

This conservative, least-privilege approach is true for all the ACL implementations we are considering.

For example, consider the ACL below:

attributes:  base permissions     owner(chavez): rw-     group(chem):   r--    others:        ---  extended permissions     enabled     specify r-- u:stein     permit  rw- g:organic, g:bio     deny    rwx g:physics

Now suppose that the user stein, who is a member of both the organic and bio groups (and not a member of the chem group), wants write access to this file. The base permissions clearly grant stein no access at all to the file. The ACEs in lines one and two of the extended permissions apply to stein. These ACEs grant him read access (lines one and two) and write access (line two). They also deny him write and execute access (implicit in line one). Thus, stein will not be given write access, because while the combined ACEs do grant it to him, they also deny write access, and so the request will fail. Manipulating AIX ACLs

ACLs may be applied and modified with the acledit command. acledit retrieves the current ACL for the file specified as its argument and opens the ACL for editing, using the text editor specified by the EDITOR environment variable. The use of this variable under AIX is different than in other systems. For one thing, there is no default (most Unix implementations use vi when EDITOR is unset). Second, AIX requires that the full pathname to the editor be supplied, /usr/bin/vi, not just its name. Once in the editor, make any changes to the ACL that you wish. If you are adding extended permissions ACEs, be sure to change disabled to enabled in the first line of that section. When you are finished, exit from the editor normally. AIX will then print the message:

Should the modified ACL be applied? (y)

If you wish to discard your changes to the ACL, enter "n"; otherwise, you should press Return. AIX then checks the new ACL and, if it has no errors, applies it to the file. If there are errors in the ACL (misspelled keywords or usernames are the most common), you are placed back in the editor, where you can correct them and try again. AIX puts error messages like this one at the bottom of the file, describing the errors it found:

* line number 9: unknown keyword: spceify  * line number 10: unknown user: chavze

You don't have to delete the error messages themselves from the ACL.

But this is the slow way of applying an ACL. The aclget and aclput commands offer alternative ways to display and apply ACLs to files. aclget takes a filename as its argument and displays the corresponding ACL on standard output (or to the file specified to its -o option). The aclput command is used to read an ACL in from a text file. By default, it takes its input from standard input or from an input file specified with the -i option. Thus, to set the ACL for the file gold to the ACL stored in the file metal.acl, you could use this command:

$ aclput -i metal.acl gold

This form of aclput is useful if you use only a few different ACLs, all of which are saved as separate files to be applied as needed.

To copy an ACL from one file to another, put aclget and aclput together in a pipe. For example, the command below copies the ACL from the file silver to the file emerald:

$ aclget silver | aclput emerald

To copy an ACL from one file to a group of files, use xargs:

$ ls *.dat *.old | xargs -i /bin/sh -c "aclget silver | aclput {}"

These commands copy the ACL in silver to all the files ending in .dat and .old in the current directory.

You can use the ls -le command to quickly determine whether a file has an extended permissions set or not:

-rw-r-----+ 1 chavez chem  51 Mar 20 13:27 has_acl  -rwxrws---- 2 chavez chem 512 Feb 08 17:58 no_acl

The plus sign appended to the normal mode string indicates the presence of extended permissions; a minus sign indicates that there are no extended permissions.

Additional AIX ACL notes:

  • The base permissions on a file with an extended access control list may be changed with chmod's symbolic mode, and any changes made in this way will be reflected in the base permissions section of the ACL. However, chmod's numeric mode must not be used for files with extended permissions, because using it automatically removes any existing ACEs.

  • Only the backup command in backup-by-inode mode will backup and restore the ACLs along with the files.

Unlike other ACL implementations, files do not inherit their initial ACL from their parent directory. Needless to say, this is a very poor design. HP-UX ACLs

The lsacl command may be used to view the ACL for a file. For a file with only normal Unix file modes set, the output looks like this:

(chavez.%,rw-)(%.chem,r--)(%.%,---) bronze

This shows the format an ACL takes under HP-UX. Each parenthesized item is known as an access control list entry, although I'm just going to call them "entries." The percent sign is a wildcard within an entry, and the three entries in the previous listing specify the access for user chavez as a member of any group, for any user in group chem, and for all other users and groups, respectively.

A file can have up to 16 ACL entries: three base entries corresponding to normal file modes and up to 13 optional entries. Here is the ACL for another file (generated this time by lsacl -l):

silver:  rwx chavez.%  r-x %.chem  r-x %.phys  r-x hill.bio  rwx harvey.%  --- %.%

This ACL grants all access to user chavez with any current group membership (she is the file's owner). It grants read and execute access to members of the chem and phys groups and to user hill when a member of group bio, and it grants user harvey read, write and execute access regardless of his group membership and no access to any other user or group.

Entries within an HP-UX access control list are examined in order of decreasing specificity: entries with a specific user and group are considered first, followed by those with only a specific user, those with only a specific group, and the other entry last of all. Within a class, entries are examined in order. When determining whether to permit file access, the first applicable entry is used. Thus, user harvey will be given write access to the file silver even if he is a member of the chem or phys group.

The chacl command is used to modify the ACL for a file. ACLs can be specified to chacl in two distinct forms: as a list of entries or with a chmod-like syntax. By default, chacl adds entries to the current ACL. For example, these two commands both add read access for the bio group and read and execute access for user hill to the ACL on the file silver:

$ chacl "(%.bio,r--) (hill.%,r-x)" silver  $ chacl "%.bio = r, hill.% = rx" silver

In either format, the ACL must be passed to chacl as a single argument. The second format also includes + and - operators, as in chmod. For example, this command adds read access for group chem and user harvey and removes write access for group chem, adding or modifying ACL entries as needed:

$ chacl "%.chem -w+r, harvey.% +r" silver

chacl's -r option may be used to replace the current ACL:

$ chacl -r "@.% = 7, %.@ = rx, %.bio = r, %.% = " *.dat

The @ sign is a shorthand for the current user or group owner, as appropriate, and it also enables user-independent ACLs to be constructed. chacl's -f option may be used to copy an ACL from one file to another file or group of files. This command applies the ACL from the file silver to all files with the extension .dat in the current directory:

$ chacl -f silver *.dat

Be careful with this option: it changes the ownership of target files if necessary so that the ACL exactly matches that of the specified file. If you merely want to apply a standard ACL to a set of files, you're better off creating a file containing the desired ACL, using @ characters as appropriate, and then applying it to files in this way:

$ chacl -r "`cat acl.metal`" *.dat

You can create the initial template file by using lsacl on an existing file and capturing the output.

You can still use chmod to change the base entries of a file with an ACL if you include the -A option. Files with optional entries are marked with a plus sign appended to the mode string in long directory listings:

-rw-------+ 1 chavez chem 8684 Jun 20 16:08 has_one  -rw-r--r-- 1 chavez chem 648205 Jun 20 11:12 none_here

Some HP-UX ACL notes:

  • ACLs for new files are not inherited from the parent directory.

  • NFS support for ACLs is not included in the implementation.

  • Using any form of the chmod command on a file will remove all ACEs except those for the user owner, group owner, and other access. POSIX access control lists: Linux, Solaris, and Tru64

Solaris, Linux, and Tru64 all provide a version of POSIX ACLs, and a stable FreeBSD implementation is forthcoming. On Linux systems, ACL support must be added manually (see http://acl.bestbits.ac); the same is true for the preliminaryFreeBSD version, part of the TrustedBSD project (e.g., see http://www.freebsd.org/news/status/report-dec-2001-jan-2002.html, as well as the project's home page at http://www.trustedbsd.org). Linux systems also require that the filesystem be mounted with the option -o acl.

Here is what a simple POSIX access control list looks like:

u::rwx                           Owner access. g::rwx                           Group owner access. o:---                            Other access. u:chavez:rw-                     Access for user chavez. g:chem:r-x                       Access for group chem. g:bio:rw-                        Access for group bio. g:phys:-w-                       Access for group phys. m:r-x                            Access mask: sets maximum allowed access.

The first three items correspond to the usual Unix file modes. The next four entries illustrate the ACEs for specific users and groups; note that only one name can be included in each entry. The final entry specifies a protection mask. This item sets the maximum allowed access level for all but user owner and other access.

In general, if a required permission is not granted within the ACL, the corresponding access will be denied. Let's consider some examples using the preceding ACL. Suppose that harvey is the owner of the file and the group owner is prog. The ACL will be applied as follows:

  • The user owner, harvey in this case, always uses the u:: entry, so harvey has rwx access to the file. All group entries are ignored for the user owner.

  • Any user with a specific u: entry always uses that entry (and all group entries are ignored for her). Thus, user chavez uses the corresponding entry. However, it is subject to the mask entry, so her actual access will be read-only (the assigned write mode is masked out).

  • Users without specific entries use any applying group entry. Thus, members of the prog group have r-x access, and members of the bio group have r-- access (the mask applies in both cases). Under Solaris and Tru64, all applicable group entries are combined (and then the mask is applied). However, on Linux systems, group entries do not accumulate (more on this in a minute).

  • Everyone else uses the specified other access. In this case, that means no access to the file is allowed.

On Linux systems, users without specific entries who belong to more than one group specified in the ACL can use all of the entries, but the group entries are not combined prior to application. Consider this partial ACL:

g:chem:r-- g:phys:--x m:rwx

The mask is now set to rwx, so the permissions in the ACEs are what will be granted. In this case, the access for users who are members of group chem and group phys can use either ACE. If this file is a script, they will not be able to execute it because they do not have rx access. If they try to read the file, they will be successful, because the ACE for chem gives them read access. However, when they try to execute the file, neither ACE gives them both r and x. The separate permissions in the two ACEs are not combined.

New files are given ACLs derived from the directory in which they reside. However, the directory's own access permission set is not used. Rather, separate ACEs are defined for use with new items. Here are some examples of these default ACEs:

d:u::rwx                         Default user owner ACE. d:g::r-x                         Default group owner ACE. d:o:r--                          Default other ACE. d:m:rwx                          Default mask. d:u:chavez:rwx                   Default ACE for user chavez. d:g:chem:r-x                     Default ACE for group chem.

Each entry begins with d:, indicating that it is a default entry. The desired ACE follows this prefix.

We'll now turn to some examples of ACL-related commands. The following commands apply two access control entries to the file gold:

Solaris and Linux # setfacl -m user:harvey:r-x,group:geo:r-- gold Tru64 # setacl -u user:harvey:r-x,group:geo:r-- gold

The following commands apply the ACL from gold to silver:

Solaris # getfacl gold > acl; setfacl -f acl silver Linux # getfacl gold > acl; setfacl -S acl silver Tru64 # getacl gold > acl; setacl -b -U acl silver

As the preceding commands indicate, the getfacl command is used to display an ACL under Solaris and Linux, and getacl is used on Tru64 systems.

The following commands specify the default other ACE for the directory /metals:

Solaris # setfacl -m d:o:r-x /metals Linux # setfacl -d -m o:r-x /metals Tru64 # setacl -d -u o:r-x /metals

Table 7-2 lists other useful options for these commands.

Table 7-2. Useful ACL manipulation commands





Add/modify ACEs

setfacl -m entries setfacl -M acl-file
setfacl -m entries setfacl -m -f acl-file
setacl -u entries setacl -U acl-file

Replace ACL

setfacl -s entries setfacl -S acl-file
setfacl -s entries setfacl -s -f acl-file
setacl -b -u entries setacl -b -U acl-file

Remove ACEs

setfacl -x entries setfacl -X acl-file
setfacl -d entries
setacl -x entries setacl -X acl-file

Remove entire ACL

setfacl -b
setacl -b

Operate on directory default ACL

setfacl -d
setfacl -m d:entry
setacl -d

Remove default ACL

setfacl -k
setacl -k

Edit ACL in editor

setacl -E

On Linux systems, you can also backup and restore ACLs using commands like these:

# getfacl -R --skip-base / > backup.acl # setfacl --restore=backup.acl

The first command backs up the ACLs from all files into the file backup.acl, and the second command restores the ACLs saved in that file.

OnTru64 systems, the acl_mode setting must be enabled in the kernel for ACL support.

7.4.5 Encryption

Encryption provides another method of protection for some types of files. Encryption involves transforming the original file (the plain or clear text) using a mathematical function or technique. Encryption can potentially protect the data stored in files in several circumstances, including:

  • Someone breaking into the root account on your system and copying the files (or tampering with them), or an authorized root user doing similar things

  • Someone stealing your disk or backup tapes (or floppies) or the computer itself in an effort to get the data

  • Someone acquiring the files via a network

The common theme here is that encryption can protect the security of your data even if the files themselves somehow fall into the wrong hands. (It can't prevent all mishaps, however, such as an unauthorized root user deleting the files, but backups will cover that scenario.

Most encryption algorithms use some sort of key as part of the transformation, and the same key is needed to decrypt the file later. The simplest kinds of encryption algorithms use external keys that function much like passwords; more sophisticated encryption methods use part of the input data as the part of the key. The crypt command

Most Unix systems provide a simple encryption program, crypt.[10] The crypt command takes the encryption key as its argument and encrypts standard input to standard output using that key. When decrypting a file, crypt is again used with the same key. It's important to remove the original file after encryption, because having both the clear and encrypted versions makes it very easy for someone to discover the keys used to encrypt the original file.

[10] U.S. government regulations forbid the inclusion of encryption software on systems shipped to foreign sites in many circumstances.

crypt is a very poor encryption program (it uses the same basic encryption scheme as the World War IIEnigma machine, which tells you that, at the very least, it is 50 years out of date). crypt can be made a little more secure by running it multiple times on the same file, for example:

$ crypt  key1  <  clear-file  | crypt  key2  | crypt  key3  >  encr-file   $ rm  clear-file 

Each successive invocation of crypt is equivalent to adding an additional rotor to an Enigma machine (the real machines had three or four rotors). When the file is decrypted, the keys are specified in the reverse order. Another way to make crypt more secure is to compress the text file before encrypting it (encrypted binary data is somewhat harder to decrypt than encrypted ASCII characters).

In any case, crypt is no match for anyone with any encryption-breaking skills or access to the cbw package.[11] Nevertheless, it is still useful in some circumstances. I use crypt to encrypt files that I don't want anyone to see accidentally or as a result of snooping around on the system as root. My assumption here is that the people I'm protecting the files against might try to look at protected files as root but won't bother trying to decrypt them. It's the same philosophy behind many simple automobile protection systems; the sticker on the window or the device on the steering wheel is meant to discourage prospective thieves and to encourage them to spend their energy elsewhere, but it doesn't really place more than a trivial barrier in their way. For cases like these, crypt is fine. If you anticipate any sort of attempt to decode the encrypted files, as would be the case if someone is specifically targeting your system, don't rely on crypt.

[11] See, for example, http://www.jjtc.com/Security/cryptanalysis.htm for information about various tools and web sites of this general sort. Public key encryption: PGP and GnuPG

Another encryption option is to use the freepublic key encryption packages. The first and best known of these is Pretty Good Privacy ( PGP) written by PhilZimmerman (http://www.pgpi.com). More recently, the Gnu Privacy Guard (GnuPG) has been developed to fulfill the same function while avoiding some of the legal and commercial entanglements that affect PGP (see http://www.gnupg.org).

In contrast to the simple encoding schemes that use only a single key for both encryption and decryption, public key encryption systems use two mathematically-related keys. One key typically the public key, which is available to anyone is used to encrypt the file or message, but this key cannot be used to decrypt it. Rather, the message can be decrypted only with the other key in the pair: the private key that is kept secret from everyone but its owner. For example, someone who wants to send you an encrypted file encrypts it with your public key. When you receive the message, you decrypt it with your private key.

Public keys can be sent to people with whom you want to communicate securely, but the private key remains secret, available only to the user to whom it belongs. The advantage of a two-key system is that public keys can be published and disseminated without any compromise in security, because these keys can be used only to encode messages but not to decode them. There are various public key repositories on the Internet; two of the best known public key servers are http://pgp.mit.edu and http://www.keyserver.net. The former is illustrated in Figure 7-2.

Both PGP and GnuPG have the following uses:

They can be used to secure data against prying eyes.
Messages and files can be digitally signed to ensure that they actually came from the source that they claim to.

These programs can be used as standalone utilities, and either package can also be integrated with popular mail programs to protect and sign electronic mail messages in an automated way.

Figure 7-2. Accessing a public key server

Using either package begins with a user creating his key pair:

$ pgp -kg
$ gpg --gen-key

Each of these commands is followed by a lot of informational messages and several prompts. The most important prompts are the identification string to be associated with the key and the passphrase. The identifier generally has the form:

Harvey Thomas <harvey@ahania.com>

Sometimes an additional, parenthesized comment item is inserted between the full name and the email address. Pay attention to the prompts when you are asked for this item, because both programs are quite particular about how and when the various parts of it are entered.

The passphrase is a password that identifies the user to the encryption system. Thus, the passphrase functions like a password, and you will need to enter it when performing most PGP or GnuPG functions. The security of your encrypted messages and files relies on selecting a phrase that cannot be broken. Choose something that is at least several words long.

Once your keys have been created, several files will be created in your $HOME/.pgp or $HOME/.gnupg subdirectory. The most important of these files are pubring.pgp (or .gpg), which is the user's public key ring, and secring.pgp (or .gpg), which holds the private key. The public key ring stores the user's public key as well as any other public keys that he acquires.

All files in this key subdirectory should have the protection mode 600.

When a key has been acquired, either from a public key server or directly from another user, the following commands can be used to add it to a user's public key ring:

$ pgp -ka key-file
$ gpg --import key-file

The following commands extract a user's own public key into a file for transmission to a key server or to another person:

$ pgp -kxa key-file
$ gpg -a --export -o key-file username

Both packages are easy to use for encryption and digital signatures. For example, user harvey could use the following commands to encrypt (-e) and digitally sign (-s) a file destined for user chavez:

$ pgp -e -s file  chavez@ahania.com
$ gpg -e -s -r chavez@ahania.com file

Simply encrypting a file for privacy purposes is much simpler; you just use the -c option with either command:

$ pgp -c file
$ gpg -c file   

These commands result in the file being encrypted with a key that you specify, using a conventional symmetric encryption algorithm (i.e., the same key will be used for decryption). Should you decide to use this encryption method, be sure to remove the clear-text file after encrypting. You can have the pgp command do it automatically by adding the -w ("wipe") option.

I don't recommend using your normal passphrase to encrypt files using conventional cryptography. It is all too easy to inadvertently have both the clear text and encrypted versions of a file on the system at the same time. Should such a mistake cause the passphrase to be discovered, using a passphrase that is different from that used for the public key encryption functions will at least contain the damage.

These commands can be used to decrypt a file:

$ pgp encrypted-file
$ gpg -d  encrypted-file     

If the file was encrypted with your public key, it is automatically decrypted, and both commands also automatically verify the file's digital signature as well, provided that the sender's public key is in your public key ring. If the file was encrypted using the conventional algorithm, you will be prompted for the appropriate passphrase. Selecting passphrases

For all encryption schemes, the choice of good keys or passphrases is imperative. In general, the same guidelines that apply to passwords apply to encryption keys. As always, longer keys are generally better than shorter ones. Finally, don't use any of your passwords as an encryption key; that's the first thing that someone who breaks into your account will try.

It's also important to make sure that your key is not inadvertently discovered by being displayed to other users on the system. In particular, be careful about the following:

  • Clear your terminal screen as soon as possible if a passphrase appears on it.

  • Don't use a key as a parameter to a command, script, or program, or it may show up in ps displays (or in lastcomm output).

  • Although the crypt command ensures that the key doesn't appear in ps displays, it does nothing about shell command history records. If you use crypt in a shell that has a command history feature, turn history off before using crypt, or run crypt via a script that prompts for it (and accepts input only from /dev/tty).

Essential System Administration
Essential System Administration, Third Edition
ISBN: 0596003439
EAN: 2147483647
Year: 2002
Pages: 162

Similar book on Amazon

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