From owner-svn-doc-head@FreeBSD.ORG Mon Mar 31 21:09:36 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6EBA9E49; Mon, 31 Mar 2014 21:09:36 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 59C606D8; Mon, 31 Mar 2014 21:09:36 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s2VL9aAx087254; Mon, 31 Mar 2014 21:09:36 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s2VL9aKA087253; Mon, 31 Mar 2014 21:09:36 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201403312109.s2VL9aKA087253@svn.freebsd.org> From: Dru Lavigne Date: Mon, 31 Mar 2014 21:09:36 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44404 - head/en_US.ISO8859-1/books/handbook/security X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 21:09:36 -0000 Author: dru Date: Mon Mar 31 21:09:35 2014 New Revision: 44404 URL: http://svnweb.freebsd.org/changeset/doc/44404 Log: White space fix only. Translators can ignore. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/security/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/security/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/security/chapter.xml Mon Mar 31 20:39:26 2014 (r44403) +++ head/en_US.ISO8859-1/books/handbook/security/chapter.xml Mon Mar 31 21:09:35 2014 (r44404) @@ -2514,12 +2514,12 @@ racoon_enable="yes" compatible with both SSH version 1 and 2 protocols. - When data is sent over the network in an unencrypted form, - network sniffers anywhere in between the client and server - can steal user/password information or data transferred - during the session. OpenSSH offers - a variety of authentication and encryption methods to prevent - this from happening. + When data is sent over the network in an unencrypted form, + network sniffers anywhere in between the client and server can + steal user/password information or data transferred during the + session. OpenSSH offers a variety of + authentication and encryption methods to prevent this from + happening. Using the SSH Client Utilities @@ -2587,14 +2587,14 @@ COPYRIGHT 100% |************* arguments takes the form . - - Key-based Authentication + + Key-based Authentication - Instead of using passwords, &man.ssh-keygen.1; can be used - to generate DSA or RSA - keys to authenticate a user: + Instead of using passwords, &man.ssh-keygen.1; can be + used to generate DSA or + RSA keys to authenticate a user: - &prompt.user; ssh-keygen -t dsa + &prompt.user; ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/user/.ssh/id_dsa): Created directory '/home/user/.ssh'. @@ -2605,179 +2605,182 @@ Your public key has been saved in /home/ The key fingerprint is: bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com - &man.ssh-keygen.1; will create a public and private key - pair for use in authentication. The private key is stored - in ~/.ssh/id_dsa or - ~/.ssh/id_rsa, whereas the public key - is stored in ~/.ssh/id_dsa.pub or - ~/.ssh/id_rsa.pub, respectively for the - DSA and RSA key types. - The public key must be placed in - ~/.ssh/authorized_keys on the - remote machine for both RSA or - DSA keys in order for the setup to - work. - - This setup allows connections to the remote machine based - upon SSH keys instead of passwords. - - - Many users believe that keys are secure by design and - will use a key without a passphrase. This is - dangerous behavior and the method - an administrator may use to verify keys have a passphrase - is to view the key manually. If the private key file - contains the word ENCRYPTED the key - owner is using a passphrase. While it may still be a weak - passphrase, at least if the system is compromised, access - to other sites will still require some level of password - guessing. In addition, to better secure end users, the - from may be placed in the public key - file. For example, adding - from="192.168.10.5 in the front of - ssh-rsa or rsa-dsa - prefix will only allow that specific user to login from - that host IP. - - - - The various options and files can be different according - to the OpenSSH version. To avoid - problems, consult &man.ssh-keygen.1;. - - - If a passphrase is used in &man.ssh-keygen.1;, the user - will be prompted for the passphrase each time in order to use - the private key. To load SSH keys into memory for use, - without needing to type the passphrase each time, use - &man.ssh-agent.1; and &man.ssh-add.1;. - - Authentication is handled by &man.ssh-agent.1;, using the - private key(s) that are loaded into it. Then, - &man.ssh-agent.1; should be used to launch another - application. At the most basic level, it could spawn a shell - or a window manager. - - To use &man.ssh-agent.1; in a shell, start it with a shell - as an argument. Next, add the identity by running - &man.ssh-add.1; and providing it the passphrase for the - private key. Once these steps have been completed, the user - will be able to &man.ssh.1; to any host that has the - corresponding public key installed. For example: + &man.ssh-keygen.1; will create a public and private key + pair for use in authentication. The private key is stored + in ~/.ssh/id_dsa or + ~/.ssh/id_rsa, whereas the public key + is stored in ~/.ssh/id_dsa.pub or + ~/.ssh/id_rsa.pub, respectively for the + DSA and RSA key types. + The public key must be placed in + ~/.ssh/authorized_keys on the remote + machine for both RSA or + DSA keys in order for the setup to + work. + + This setup allows connections to the remote machine + based upon SSH keys instead of + passwords. + + + Many users believe that keys are secure by design and + will use a key without a passphrase. This is + dangerous behavior and the method an + administrator may use to verify keys have a passphrase is + to view the key manually. If the private key file + contains the word ENCRYPTED the key + owner is using a passphrase. While it may still be a weak + passphrase, at least if the system is compromised, access + to other sites will still require some level of password + guessing. In addition, to better secure end users, the + from may be placed in the public key + file. For example, adding + from="192.168.10.5 in the front of + ssh-rsa or rsa-dsa + prefix will only allow that specific user to login from + that host IP. + + + + The various options and files can be different + according to the OpenSSH + version. To avoid problems, consult + &man.ssh-keygen.1;. + + + If a passphrase is used in &man.ssh-keygen.1;, the user + will be prompted for the passphrase each time in order to + use the private key. To load SSH keys + into memory for use, without needing to type the passphrase + each time, use &man.ssh-agent.1; and &man.ssh-add.1;. + + Authentication is handled by &man.ssh-agent.1;, using + the private key(s) that are loaded into it. Then, + &man.ssh-agent.1; should be used to launch another + application. At the most basic level, it could spawn a + shell or a window manager. + + To use &man.ssh-agent.1; in a shell, start it with a + shell as an argument. Next, add the identity by running + &man.ssh-add.1; and providing it the passphrase for the + private key. Once these steps have been completed, the user + will be able to &man.ssh.1; to any host that has the + corresponding public key installed. For example: - &prompt.user; ssh-agent csh + &prompt.user; ssh-agent csh &prompt.user; ssh-add Enter passphrase for /home/user/.ssh/id_dsa: Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa) &prompt.user; - To use &man.ssh-agent.1; in - &xorg;, a call to &man.ssh-agent.1; - needs to be placed in ~/.xinitrc. This - provides the &man.ssh-agent.1; services to all programs - launched in &xorg;. An example - ~/.xinitrc might look like - this: - - exec ssh-agent startxfce4 - - This launches &man.ssh-agent.1;, which in turn launches - XFCE, every time - &xorg; starts. Once - &xorg; has been restarted so that - the changes can take effect, run &man.ssh-add.1; to load all - of the SSH keys. - + To use &man.ssh-agent.1; in + &xorg;, a call to + &man.ssh-agent.1; needs to be placed in + ~/.xinitrc. This provides the + &man.ssh-agent.1; services to all programs launched in + &xorg;. An example + ~/.xinitrc might look like this: + + exec ssh-agent startxfce4 + + This launches &man.ssh-agent.1;, which in turn launches + XFCE, every time + &xorg; starts. Once + &xorg; has been restarted so that + the changes can take effect, run &man.ssh-add.1; to load all + of the SSH keys. + - - <acronym>SSH</acronym> Tunneling + + <acronym>SSH</acronym> Tunneling - - OpenSSH - tunneling - + + OpenSSH + tunneling + + + OpenSSH has the ability to + create a tunnel to encapsulate another protocol in an + encrypted session. - OpenSSH has the ability to - create a tunnel to encapsulate another protocol in an - encrypted session. + The following command tells &man.ssh.1; to create a + tunnel for &man.telnet.1;: - The following command tells &man.ssh.1; to create a - tunnel for &man.telnet.1;: - - &prompt.user; ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com + &prompt.user; ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com &prompt.user; - This example uses the following options: + This example uses the following options: + + + + + + + Forces &man.ssh.1; to use version 2 to connect to + the server. + + + + + + + + Indicates no command, or tunnel only. If omitted, + &man.ssh.1; initiates a normal session. + + + + + + + + Forces &man.ssh.1; to run in the + background. + + + + + + + + Indicates a local tunnel in + localport:remotehost:remoteport + format. + + + + + + + + The login name to use on the specified remote + SSH server. + + + + + An SSH tunnel works by creating a + listen socket on localhost on the + specified port. It then forwards any connections received + on the local host/port via the SSH + connection to the specified remote host and port. + + In the example, port 5023 on + localhost is forwarded to port + 23 on + localhost of the remote machine. + Since 23 is used by + &man.telnet.1;, this creates an encrypted &man.telnet.1; + session through an SSH tunnel. + + This can be used to wrap any number of insecure TCP + protocols such as SMTP, POP3, and FTP. - - - - - - Forces &man.ssh.1; to use version 2 to connect to - the server. - - - - - - - - Indicates no command, or tunnel only. If omitted, - &man.ssh.1; initiates a normal session. - - - - - - - - Forces &man.ssh.1; to run in the background. - - - - - - - - Indicates a local tunnel in - localport:remotehost:remoteport - format. - - - - - - - - The login name to use on the specified remote - SSH server. - - - - - An SSH tunnel works by creating a - listen socket on localhost on the - specified port. It then forwards any connections received on - the local host/port via the SSH connection - to the specified remote host and port. - - In the example, port 5023 on - localhost is forwarded to port - 23 on - localhost of the remote machine. - Since 23 is used by &man.telnet.1;, - this creates an encrypted &man.telnet.1; session through an - SSH tunnel. - - This can be used to wrap any number of insecure TCP - protocols such as SMTP, POP3, and FTP. - - - Using &man.ssh.1; to Create a Secure Tunnel for - SMTP + + Using &man.ssh.1; to Create a Secure Tunnel for + SMTP - &prompt.user; ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com + &prompt.user; ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com user@mailserver.example.com's password: ***** &prompt.user; telnet localhost 5025 Trying 127.0.0.1... @@ -2785,14 +2788,15 @@ Connected to localhost. Escape character is '^]'. 220 mailserver.example.com ESMTP - This can be used in conjunction with &man.ssh-keygen.1; - and additional user accounts to create a more seamless - SSH tunneling environment. Keys can be - used in place of typing a password, and the tunnels can be - run as a separate user. - + This can be used in conjunction with + &man.ssh-keygen.1; and additional user accounts to create + a more seamless SSH tunneling + environment. Keys can be used in place of typing a + password, and the tunnels can be run as a separate + user. + - + Secure Access of a POP3 Server In this example, there is an SSH @@ -2939,11 +2943,10 @@ user@unfirewalled-system.example.org's p ACL - Access Control Lists (ACLs) - extend the standard &unix; permission model in a &posix;.1e - compatible way. This permits an administrator to - take advantage of a more fine-grained permissions - model. + Access Control Lists (ACLs) extend the + standard &unix; permission model in a &posix;.1e compatible way. + This permits an administrator to take advantage of a more + fine-grained permissions model. The &os; GENERIC kernel provides ACL support for UFS file @@ -2956,78 +2959,76 @@ user@unfirewalled-system.example.org's p If this option is not compiled in, a warning message will be displayed when attempting to mount a file system with ACL support. ACLs rely on - extended attributes which - are natively supported in + extended attributes which are natively supported in UFS2. This chapter describes how to enable ACL support and provides some usage examples. - - Enabling <acronym>ACL</acronym> Support + + Enabling <acronym>ACL</acronym> Support - ACLs are enabled by the mount-time - administrative flag, , which may be added - to /etc/fstab. The mount-time flag can - also be automatically set in a persistent manner using - &man.tunefs.8; to modify a superblock ACLs - flag in the file system header. In general, it is preferred - to use the superblock flag for several reasons: - - - - The superblock flag cannot be - changed by a remount using as it - requires a complete umount and fresh mount. - This means that ACLs cannot be enabled on - the root file system after boot. It also means that - ACL support on - a file system cannot be changed while the system is in - use. - - - - Setting the superblock flag causes the file system - to always be mounted with ACLs enabled, - even if there is not an fstab entry - or if the devices re-order. This prevents accidental - mounting of the file system without ACL - support. - - + ACLs are enabled by the mount-time + administrative flag, , which may be added + to /etc/fstab. The mount-time flag can + also be automatically set in a persistent manner using + &man.tunefs.8; to modify a superblock ACLs + flag in the file system header. In general, it is preferred + to use the superblock flag for several reasons: - - It is desirable to discourage accidental mounting without - ACLs enabled because nasty things can - happen if ACLs are enabled, then disabled, - then re-enabled without flushing the extended attributes. In - general, once ACLs are enabled on a - file system, they should not be disabled, as the resulting file - protections may not be compatible with those intended by the - users of the system, and re-enabling ACLs - may re-attach the previous ACLs to files - that have since had their permissions changed, resulting in - unpredictable behavior. - + + + The superblock flag cannot be changed by a remount + using as it requires a complete + umount and fresh + mount. This means that + ACLs cannot be enabled on the root file + system after boot. It also means that + ACL support on a file system cannot be + changed while the system is in use. + - File systems with ACLs enabled will - show a plus (+) sign in their permission - settings: + + Setting the superblock flag causes the file system to + always be mounted with ACLs enabled, + even if there is not an fstab entry + or if the devices re-order. This prevents accidental + mounting of the file system without ACL + support. + + - drwx------ 2 robert robert 512 Dec 27 11:54 private + + It is desirable to discourage accidental mounting + without ACLs enabled because nasty things + can happen if ACLs are enabled, then + disabled, then re-enabled without flushing the extended + attributes. In general, once ACLs are + enabled on a file system, they should not be disabled, as + the resulting file protections may not be compatible with + those intended by the users of the system, and re-enabling + ACLs may re-attach the previous + ACLs to files that have since had their + permissions changed, resulting in unpredictable + behavior. + + + File systems with ACLs enabled will + show a plus (+) sign in their permission + settings: + + drwx------ 2 robert robert 512 Dec 27 11:54 private drwxrwx---+ 2 robert robert 512 Dec 23 10:57 directory1 drwxrwx---+ 2 robert robert 512 Dec 22 10:20 directory2 drwxrwx---+ 2 robert robert 512 Dec 27 11:57 directory3 drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html - In this example, - directory1, - directory2, and - directory3 - are all taking advantage of ACLs, whereas - public_html - is not. + In this example, directory1, + directory2, and + directory3 are all taking advantage of + ACLs, whereas + public_html is not. @@ -3047,11 +3048,11 @@ drwxr-xr-x 2 robert robert 512 Nov 10 other::r-- To change the ACL settings on this - file, use setfacl. To remove all of the currently defined - ACLs from a file or file system, include - . However, the preferred method is to use - as it leaves the basic fields required - for ACLs to work. + file, use setfacl. To remove all of the + currently defined ACLs from a file or file + system, include . However, the preferred + method is to use as it leaves the basic + fields required for ACLs to work. &prompt.user; setfacl -k test @@ -3060,12 +3061,12 @@ drwxr-xr-x 2 robert robert 512 Nov 10 &prompt.user; setfacl -m u:trhodes:rwx,group:web:r--,o::--- test - In this example, there were no - pre-defined entries, as they were removed by the previous - command. This command restores the default options and assigns the - options listed. If a user or group is added which does not - exist on the system, an Invalid - argument error will be displayed. + In this example, there were no pre-defined entries, as + they were removed by the previous command. This command + restores the default options and assigns the options listed. + If a user or group is added which does not exist on the + system, an Invalid argument error will + be displayed. Refer to &man.getfacl.1; and &man.setfacl.1; for more information about the options available for these @@ -3494,13 +3495,13 @@ UWWemqWuz3lAZuORQ9KX their allocation among users, provide for system monitoring, and minimally track a user's commands. - Process accounting has both positive and negative points. One - of the positives is that an intrusion may be narrowed down to - the point of entry. A negative is the amount of logs + Process accounting has both positive and negative points. + One of the positives is that an intrusion may be narrowed down + to the point of entry. A negative is the amount of logs generated by process accounting, and the disk space they may - require. This section walks an administrator through the - basics of process accounting. - + require. This section walks an administrator through the basics + of process accounting. + If more fine-grained accounting is needed, refer to . @@ -3520,16 +3521,16 @@ UWWemqWuz3lAZuORQ9KX Once enabled, accounting will begin to track information such as CPU statistics and executed commands. All accounting logs are in a non-human readable - format which can be viewed using sa. If issued - without any options, sa prints information relating to - the number of per-user calls, the total elapsed time in - minutes, total CPU and user time in - minutes, and the average number of I/O operations. Refer to - &man.sa.8; for the list of available options which control the - output. + format which can be viewed using sa. If + issued without any options, sa prints + information relating to the number of per-user calls, the + total elapsed time in minutes, total CPU + and user time in minutes, and the average number of + I/O operations. Refer to &man.sa.8; for + the list of available options which control the output. - To display the commands issued - by users, use lastcomm. For example, this command + To display the commands issued by users, use + lastcomm. For example, this command prints out all usage of ls by trhodes on the ttyp1 terminal: @@ -3559,102 +3560,96 @@ UWWemqWuz3lAZuORQ9KX controlled through a flat file, /etc/login.conf. While this method is still supported, any changes require a multi-step process of - editing this file in order to divide users into various group labels known as classes, - rebuilding the resource database using - cap_mkdb, making necessary changes - to /etc/master.passwd, and rebuilding - the password database using - pwd_mkdb. This could be - time consuming, depending upon the number of users to + editing this file in order to divide users into various group + labels known as classes, rebuilding the resource database using + cap_mkdb, making necessary changes to + /etc/master.passwd, and rebuilding the + password database using pwd_mkdb. This + could be time consuming, depending upon the number of users to configure. Beginning with &os; 9.0-RELEASE, - rctl can be used to provide a more fine-grained - method of controlling resources limits for users. This - command supports much more than users as it can be used to set - resource constraints on processes, jails, and the original login - class. These advanced features provide administrators and users - with methods to control resources through the command line and - to set rules on system initialization using a configuration + rctl can be used to provide a more + fine-grained method of controlling resources limits for users. + This command supports much more than users as it can be used to + set resource constraints on processes, jails, and the original + login class. These advanced features provide administrators and + users with methods to control resources through the command line + and to set rules on system initialization using a configuration file. - - Enabling and Configuring Resource Limits + + Enabling and Configuring Resource Limits - By default, kernel support for rctl is - not built-in, meaning that the kernel will first need to be - recompiled using the instructions in . Add these lines to either - GENERIC or a custom kernel - configuration file, then rebuild the kernel: + By default, kernel support for rctl is + not built-in, meaning that the kernel will first need to be + recompiled using the instructions in . Add these lines to either + GENERIC or a custom kernel configuration + file, then rebuild the kernel: - options RACCT + options RACCT options RCTL - Once the system has rebooted into the new kernel, - rctl may be used to set rules for the - system. - - Rule syntax is controlled through the use of - a subject, - subject-id, resource, - and action, as seen in this example - rule: - - user:trhodes:maxproc:deny=10/user - - In this rule, the subject - is user, the subject-id is - trhodes, the resource, - maxproc, is the maximum - number of processes, and the - action is deny, which blocks any - new processes from being created. This means that the - user, trhodes, will be constrained to no greater than - 10 processes. Other possible - actions include logging to the console, passing a - notification to &man.devd.8;, or sending a sigterm to the - process. - - Some care must be taken when adding rules. Since this user - is constrained to 10 processes, this example - will prevent the user from performing other - tasks after logging in and executing a - screen session. Once a resource limit has - been hit, an error will be printed, as in this example: + Once the system has rebooted into the new kernel, + rctl may be used to set rules for the + system. + + Rule syntax is controlled through the use of a subject, + subject-id, resource, and action, as seen in this example + rule: + + user:trhodes:maxproc:deny=10/user + + In this rule, the subject is user, the + subject-id is trhodes, the resource, + maxproc, is the maximum number of + processes, and the action is deny, which + blocks any new processes from being created. This means that + the user, trhodes, will be constrained to + no greater than 10 processes. Other + possible actions include logging to the console, passing a + notification to &man.devd.8;, or sending a sigterm to the + process. + + Some care must be taken when adding rules. Since this + user is constrained to 10 processes, this + example will prevent the user from performing other tasks + after logging in and executing a + screen session. Once a resource limit has + been hit, an error will be printed, as in this example: - &prompt.user; man test + &prompt.user; man test /usr/bin/man: Cannot fork: Resource temporarily unavailable eval: Cannot fork: Resource temporarily unavailable - As another example, - a jail can be prevented from exceeding a memory limit. This rule could be - written as: - - &prompt.root; rctl -a jail:httpd:memoryuse:deny=2G/jail - - Rules will persist across reboots if they have been - added to /etc/rctl.conf. The format is a - rule, without the preceding command. For example, the previous - rule could be added as: + As another example, a jail can be prevented from exceeding + a memory limit. This rule could be written as: + + &prompt.root; rctl -a jail:httpd:memoryuse:deny=2G/jail + + Rules will persist across reboots if they have been added + to /etc/rctl.conf. The format is a rule, + without the preceding command. For example, the previous rule + could be added as: - # Block jail from using more than 2G memory: + # Block jail from using more than 2G memory: jail:httpd:memoryuse:deny=2G/jail - To remove a rule, use rctl to - remove it from the list: + To remove a rule, use rctl to remove it + from the list: - &prompt.root; rctl -r user:trhodes:maxproc:deny=10/user + &prompt.root; rctl -r user:trhodes:maxproc:deny=10/user - A method for removing all rules is documented in &man.rctl.8;. - However, if removing all rules for a single user is required, - this command may be issued: + A method for removing all rules is documented in + &man.rctl.8;. However, if removing all rules for a single + user is required, this command may be issued: - &prompt.root; rctl -r user:trhodes + &prompt.root; rctl -r user:trhodes - Many other resources exist which can be used to exert - additional control over various subjects. - See &man.rctl.8; to learn about them. + Many other resources exist which can be used to exert + additional control over various subjects. + See &man.rctl.8; to learn about them.