Essential System Administration, Third Edition
| 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. NOTE 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:
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:
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.
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. 7.4.3.1 Writing setuid/setgid programs
Two principles should guide you in those rare instances where you need to write a setuid or setgid program:
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.
[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. 7.4.4.1 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.
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. 7.4.4.2 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:
Unlike other ACL implementations, files do not inherit their initial ACL from their parent directory. Needless to say, this is a very poor design. 7.4.4.3 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:
7.4.4.4 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:
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.
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.
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:
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. 7.4.5.1 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. 7.4.5.2 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:
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:
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.
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:
The following commands extract a user's own public key into a file for transmission to a key server or to another person:
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:
Simply encrypting a file for privacy purposes is much simpler; you just use the -c option with either command:
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.
These commands can be used to decrypt a 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. 7.4.5.3 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:
|