Date: Wed, 30 Apr 2014 21:29:04 +0000 (UTC) From: Dru Lavigne <dru@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44726 - head/en_US.ISO8859-1/books/handbook/security Message-ID: <201404302129.s3ULT4iu061274@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: dru Date: Wed Apr 30 21:29:03 2014 New Revision: 44726 URL: http://svnweb.freebsd.org/changeset/doc/44726 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 Wed Apr 30 20:50:57 2014 (r44725) +++ head/en_US.ISO8859-1/books/handbook/security/chapter.xml Wed Apr 30 21:29:03 2014 (r44726) @@ -116,61 +116,61 @@ in any system could allow intruders to gain access to critical information and cause havoc on an entire network. One of the core principles of information security is the - <acronym>CIA</acronym> triad, which stands for the Confidentiality, - Integrity, and Availability of information systems.</para> + <acronym>CIA</acronym> triad, which stands for the + Confidentiality, Integrity, and Availability of information + systems.</para> <para>The <acronym>CIA</acronym> triad is a bedrock concept of computer security as customers and users expect their data to be - protected. For example, a customer expects that their credit card - information is securely stored (confidentiality), that their - orders are not changed behind the scenes (integrity), and that they have - access to their order information at all times (availablility).</para> + protected. For example, a customer expects that their credit + card information is securely stored (confidentiality), that + their orders are not changed behind the scenes (integrity), and + that they have access to their order information at all times + (availablility).</para> <para>To provide <acronym>CIA</acronym>, security professionals - apply a defense in depth strategy. The idea of defense in - depth is to add several layers of security to prevent one single - layer failing and the entire security system collapsing. For example, a - system administrator cannot simply turn on a firewall and - consider the network or system secure. One must also audit accounts, - check the integrity of binaries, and ensure malicious tools are - not installed. To implement an effective security strategy, one must understand - threats and how to defend against them.</para> - - <para>What is a threat as it pertains to computer security? Threats - are not limited to remote attackers who - attempt to access a system without permission - from a remote location. Threats also include - employees, malicious software, unauthorized - network devices, natural disasters, security vulnerabilities, - and even competing corporations.</para> - - <para>Systems and networks can be - accessed without permission, - sometimes by accident, or by remote attackers, and - in some cases, via corporate espionage or former employees. As a - user, it is important to prepare for and admit when a - mistake has lead to a security breach and report possible - issues to the security team. As an administrator, it is - important to know of the threats and be prepared to mitigate - them.</para> - - <para>When applying security to systems, it is recommended to - start by securing the basic - accounts and system configuration, and then to secure - the network layer so that it adheres to the system policy - and the organization's security procedures. Many organizations already have a security policy - that covers the configuration of technology devices. The policy - should include the security configuration of - workstations, desktops, mobile devices, phones, - production servers, and development servers. In - many cases, standard - operating procedures (<acronym>SOP</acronym>s) already exist. - When in doubt, ask the security team.</para> + apply a defense in depth strategy. The idea of defense in depth + is to add several layers of security to prevent one single layer + failing and the entire security system collapsing. For example, + a system administrator cannot simply turn on a firewall and + consider the network or system secure. One must also audit + accounts, check the integrity of binaries, and ensure malicious + tools are not installed. To implement an effective security + strategy, one must understand threats and how to defend against + them.</para> + + <para>What is a threat as it pertains to computer security? + Threats are not limited to remote attackers who attempt to + access a system without permission from a remote location. + Threats also include employees, malicious software, unauthorized + network devices, natural disasters, security vulnerabilities, + and even competing corporations.</para> + + <para>Systems and networks can be accessed without permission, + sometimes by accident, or by remote attackers, and in some + cases, via corporate espionage or former employees. As a user, + it is important to prepare for and admit when a mistake has lead + to a security breach and report possible issues to the security + team. As an administrator, it is important to know of the + threats and be prepared to mitigate them.</para> + + <para>When applying security to systems, it is recommended to + start by securing the basic accounts and system configuration, + and then to secure the network layer so that it adheres to the + system policy and the organization's security procedures. Many + organizations already have a security policy that covers the + configuration of technology devices. The policy should include + the security configuration of workstations, desktops, mobile + devices, phones, production servers, and development servers. + In many cases, standard operating procedures + (<acronym>SOP</acronym>s) already exist. When in doubt, ask the + security team.</para> <para>The rest of this introduction describes how some of these basic security configurations are performed on a &os; system. The rest of this chapter describes some specific tools which can - be used when implementing a security policy on a &os; system.</para> + be used when implementing a security policy on a &os; + system.</para> <sect2 xml:id="security-accounts"> <title>Preventing Logins</title> @@ -178,55 +178,57 @@ <para>In securing a system, a good starting point is an audit of accounts. Ensure that <systemitem class="username">root</systemitem> has a strong password and - that this password is not shared. - Disable any accounts that do not need login access.</para> + that this password is not shared. Disable any accounts that + do not need login access.</para> - <para>To deny login access to accounts, two methods exist. The first - is to lock the account. This example locks the <systemitem - class="username">toor</systemitem> account:</para> + <para>To deny login access to accounts, two methods exist. The + first is to lock the account. This example locks the + <systemitem class="username">toor</systemitem> account:</para> <screen>&prompt.root; <userinput>pw lock <replaceable>toor</replaceable></userinput></screen> - <para>The second method is to prevent login access - by changing the shell to <filename>/sbin/nologin</filename>. - Only the superuser can change the shell for other users:</para> + <para>The second method is to prevent login access by changing + the shell to <filename>/sbin/nologin</filename>. Only the + superuser can change the shell for other users:</para> <screen>&prompt.root; <userinput>chsh -s /usr/sbin/nologin <replaceable>toor</replaceable></userinput></screen> <para>The <filename>/usr/sbin/nologin</filename> shell prevents - the system from assigning a shell to the - user when they attempt to login.</para> + the system from assigning a shell to the user when they + attempt to login.</para> </sect2> <sect2 xml:id="security-sudo"> <title>Permitted Account Escalation</title> - <para>In some cases, system administration needs to be - shared with other users. &os; has two methods to handle this. - The first one, which is not recommended, is a shared root - password used by members of the <systemitem - class="groupname">wheel</systemitem> group. With this method, - a user types <command>su</command> and enters the password for - <systemitem class="groupname">wheel</systemitem> whenever - superuser access is needed. The user should then type - <command>exit</command> to leave privileged access after - finishing the commands that required administrative access. To add a user - to this group, edit <filename>/etc/group</filename> and add the - user to the end of the <literal>wheel</literal> entry. The user must be + <para>In some cases, system administration needs to be shared + with other users. &os; has two methods to handle this. The + first one, which is not recommended, is a shared root password + used by members of the <systemitem + class="groupname">wheel</systemitem> group. With this + method, a user types <command>su</command> and enters the + password for <systemitem class="groupname">wheel</systemitem> + whenever superuser access is needed. The user should then + type <command>exit</command> to leave privileged access after + finishing the commands that required administrative access. + To add a user to this group, edit + <filename>/etc/group</filename> and add the user to the end of + the <literal>wheel</literal> entry. The user must be separated by a comma character with no space.</para> - <para>The second, and recommended, method to permit privilege escalation is - to install the <package>security/sudo</package> package or port. - This software provides additional auditing, more fine-grained user control, - and can be configured to lock users into running only the specified privileged + <para>The second, and recommended, method to permit privilege + escalation is to install the <package>security/sudo</package> + package or port. This software provides additional auditing, + more fine-grained user control, and can be configured to lock + users into running only the specified privileged commands.</para> <para>After installation, use <command>visudo</command> to edit - <filename>/usr/local/etc/sudoers</filename>. - This example creates - a new <systemitem class="groupname">webadmin</systemitem> group, adds the <systemitem - class="username">trhodes</systemitem> account to that group, and - configures that group access to restart + <filename>/usr/local/etc/sudoers</filename>. This example + creates a new <systemitem + class="groupname">webadmin</systemitem> group, adds the + <systemitem class="username">trhodes</systemitem> account to + that group, and configures that group access to restart <package>apache24</package>:</para> <screen>&prompt.root; <userinput>pw groupadd webadmin -M trhodes -g 6000</userinput> @@ -237,45 +239,42 @@ <sect2 xml:id="security-passwords"> <title>Password Hashes</title> - <para>Passwords are a necessary evil of technology. When - they must be used, they should be - complex and a powerful hash mechanism should be used to - encrypt the version that is stored in the password database. &os; supports the + <para>Passwords are a necessary evil of technology. When they + must be used, they should be complex and a powerful hash + mechanism should be used to encrypt the version that is stored + in the password database. &os; supports the <acronym>DES</acronym>, <acronym>MD5</acronym>, - <acronym>SHA256</acronym>, <acronym>SHA512</acronym>, and Blowfish hash algorithms in its - <function>crypt()</function> library. The default of - <acronym>SHA512</acronym> should not be changed to a less - secure hashing algorithm, but can be changed to the more secure - Blowfish algorithm.</para> + <acronym>SHA256</acronym>, <acronym>SHA512</acronym>, and + Blowfish hash algorithms in its <function>crypt()</function> + library. The default of <acronym>SHA512</acronym> should not + be changed to a less secure hashing algorithm, but can be + changed to the more secure Blowfish algorithm.</para> <note> - <para>Blowfish is not part of - <acronym>AES</acronym> and is not considered compliant with - any Federal Information - Processing Standards (<acronym>FIPS</acronym>). Its use may not be - permitted in some environments.</para> + <para>Blowfish is not part of <acronym>AES</acronym> and is + not considered compliant with any Federal Information + Processing Standards (<acronym>FIPS</acronym>). Its use may + not be permitted in some environments.</para> </note> <para>To determine which hash algorithm is used to encrypt a user's password, the superuser can view the hash for the user - in the &os; password database. Each hash - starts with a symbol which indicates the type of hash - mechanism used to encrypt the password. If - <acronym>DES</acronym> is used, there is no beginning symbol. - For - <acronym>MD5</acronym>, the symbol is + in the &os; password database. Each hash starts with a symbol + which indicates the type of hash mechanism used to encrypt the + password. If <acronym>DES</acronym> is used, there is no + beginning symbol. For <acronym>MD5</acronym>, the symbol is <literal>$</literal>. For <acronym>SHA256</acronym> and - <acronym>SHA512</acronym>, the symbol is <literal>$6$</literal>. - For Blowfish, the symbol is <literal>$2a$</literal>. In this - example, the password for <systemitem - class="username">dru</systemitem> is hashed using the default - <acronym>SHA512</acronym> algorithm as the hash starts with - <literal>$6$</literal>. Note that the encrypted hash, not the password - itself, is stored in the password database:</para> + <acronym>SHA512</acronym>, the symbol is + <literal>$6$</literal>. For Blowfish, the symbol is + <literal>$2a$</literal>. In this example, the password for + <systemitem class="username">dru</systemitem> is hashed using + the default <acronym>SHA512</acronym> algorithm as the hash + starts with <literal>$6$</literal>. Note that the encrypted + hash, not the password itself, is stored in the password + database:</para> <screen>&prompt.root; <userinput>grep dru /etc/master.passwd</userinput> -dru:$6$pzIjSvCAn.PBYQBA$PXpSeWPx3g5kscj3IMiM7tUEUSPmGexxta.8Lt9TGSi2lNQqYGKszsBPuGME0:1001:1001::0:0:dru:/usr/home/dru:/bin/csh -</screen> +dru:$6$pzIjSvCAn.PBYQBA$PXpSeWPx3g5kscj3IMiM7tUEUSPmGexxta.8Lt9TGSi2lNQqYGKszsBPuGME0:1001:1001::0:0:dru:/usr/home/dru:/bin/csh</screen> <para>The hash mechanism is set in the user's login class. For this example, the user is in the <literal>default</literal> @@ -286,83 +285,79 @@ dru:$6$pzIjSvCAn.PBYQBA$PXpSeWPx3g5kscj3 <para>To change the algorithm to Blowfish, modify that line to look like this:</para> - - <programlisting> :passwd_format=blf:\</programlisting> - - <para>Then run <command>cap_mkdb /etc/login.conf</command> as + + <programlisting> :passwd_format=blf:\</programlisting> + + <para>Then run <command>cap_mkdb /etc/login.conf</command> as described in <xref linkend="users-limiting"/>. Note that this change will not affect any existing password hashes. This - means that all passwords should - be re-hashed by asking users to run <command>passwd</command> - in order to change their password.</para> + means that all passwords should be re-hashed by asking users + to run <command>passwd</command> in order to change their + password.</para> - <para>For remote logins, two-factor - authentication should be used. An example of two-factor authentication is + <para>For remote logins, two-factor authentication should be + used. An example of two-factor authentication is <quote>something you have</quote>, such as a key, and - <quote>something you know</quote>, such as the passphrase for that key. Since - <application>OpenSSH</application> is part of the &os; - base system, all network logins should be over an encrypted - connection and use key-based authentication instead of passwords. - For - more information, refer to <xref linkend="openssh"/>. - Kerberos users may need to make additional - changes to implement <application>OpenSSH</application> in - their network. These changes are described in <xref - linkend="kerberos5"/>.</para> - </sect2> - - <sect2 xml:id="security-pwpolicy"> - <title>Password Policy Enforcement</title> - - <para>Enforcing a strong password policy for local accounts - is a fundamental aspect of system security. - In &os;, password length, - password strength, and password complexity - can be implemented using built-in Pluggable Authentication - Modules (<acronym>PAM</acronym>).</para> - - <para>This section demonstrates how to configure the minimum - and maximum password length and the - enforcement of mixed characters using the - <filename>pam_passwdqc.so</filename> module. This module is enforced when - a user changes their password.</para> - - <para>To configure this module, become the superuser and uncomment the line containing - <literal>pam_passwdqc.so</literal> in - <filename>/etc/pam.d/passwd</filename>. Then, edit that - line to match the password policy:</para> - - <programlisting>password requisite pam_passwdqc.so <replaceable>min=disabled,disabled,disabled,12,10 similar=deny retry=3</replaceable> enforce=users</programlisting> - - <para>This example - sets several requirements for new passwords. The <literal>min</literal> - setting controls the minimum - password length. It has five values because this module - defines five different types of passwords based on their - complexity. Complexity is defined by the type of characters - that must exist in a password, such as letters, numbers, - symbols, and case. The types of passwords are described in - &man.pam.passwdqc.8;. In this example, the first three - types of passwords are disabled, meaning that passwords that - meet those complexity requirements will not be accepted, - regardless of their length. - The <literal>12</literal> sets a minimum password policy of - at least twelve characters, if the password also contains - characters with three types of complexity. The - <literal>10</literal> sets the password policy to also allow - passwords of at least ten characters, if the password - contains characters with four types of complexity.</para> - - <para>The <literal>similar</literal> setting denies passwords that - are similar to the user's previous password. The - <literal>retry</literal> setting provides a user with - three opportunities to enter a new password.</para> - - <para>Once this file is saved, a user - changing their password will see a message similar to the - following:</para> + <quote>something you know</quote>, such as the passphrase for + that key. Since <application>OpenSSH</application> is part of + the &os; base system, all network logins should be over an + encrypted connection and use key-based authentication instead + of passwords. For more information, refer to <xref + linkend="openssh"/>. Kerberos users may need to make + additional changes to implement + <application>OpenSSH</application> in their network. These + changes are described in <xref linkend="kerberos5"/>.</para> + </sect2> + + <sect2 xml:id="security-pwpolicy"> + <title>Password Policy Enforcement</title> + + <para>Enforcing a strong password policy for local accounts is a + fundamental aspect of system security. In &os;, password + length, password strength, and password complexity can be + implemented using built-in Pluggable Authentication Modules + (<acronym>PAM</acronym>).</para> + + <para>This section demonstrates how to configure the minimum and + maximum password length and the enforcement of mixed + characters using the <filename>pam_passwdqc.so</filename> + module. This module is enforced when a user changes their + password.</para> - <screen>&prompt.user; <userinput>passwd</userinput> + <para>To configure this module, become the superuser and + uncomment the line containing + <literal>pam_passwdqc.so</literal> in + <filename>/etc/pam.d/passwd</filename>. Then, edit that line + to match the password policy:</para> + + <programlisting>password requisite pam_passwdqc.so <replaceable>min=disabled,disabled,disabled,12,10 similar=deny retry=3</replaceable> enforce=users</programlisting> + + <para>This example sets several requirements for new passwords. + The <literal>min</literal> setting controls the minimum + password length. It has five values because this module + defines five different types of passwords based on their + complexity. Complexity is defined by the type of characters + that must exist in a password, such as letters, numbers, + symbols, and case. The types of passwords are described in + &man.pam.passwdqc.8;. In this example, the first three types + of passwords are disabled, meaning that passwords that meet + those complexity requirements will not be accepted, regardless + of their length. The <literal>12</literal> sets a minimum + password policy of at least twelve characters, if the password + also contains characters with three types of complexity. The + <literal>10</literal> sets the password policy to also allow + passwords of at least ten characters, if the password contains + characters with four types of complexity.</para> + + <para>The <literal>similar</literal> setting denies passwords + that are similar to the user's previous password. The + <literal>retry</literal> setting provides a user with three + opportunities to enter a new password.</para> + + <para>Once this file is saved, a user changing their password + will see a message similar to the following:</para> + + <screen>&prompt.user; <userinput>passwd</userinput> Changing local password for trhodes Old Password: @@ -377,32 +372,34 @@ Alternatively, if noone else can see you pick this as your password: "trait-useful&knob". Enter new password:</screen> - <para>If a password that does not match the policy is entered, it will be rejected with - a warning and the user will have an opportunity to try - again, up to the configured number of retries.</para> - - <para>Most password policies require passwords to - expire after so many days. To set a - password age time in &os;, set - <option>passwordtime</option> for the user's login class in - <filename>/etc/login.conf</filename>. The - <literal>default</literal> login class contains an example:</para> - - <programlisting># :passwordtime=90d:\</programlisting> - - <para>So, to set an expiry of 90 days for this login class, - remove the comment symbol (<literal>#</literal>), save the - edit, and run <command>cap_mkdb /etc/login.conf</command>.</para> - - <para>To set the expiration on individual users, pass an - expiration date or the number of days to expiry - and a username to <command>pw</command>:</para> - - <screen>&prompt.root; <userinput>pw usermod -p <replaceable>30-apr-2015</replaceable> -n <replaceable>trhodes</replaceable></userinput></screen> - - <para>As seen here, an expiration date is set in the form of - day, month, and year. For more information, see - &man.pw.8;.</para> + <para>If a password that does not match the policy is entered, + it will be rejected with a warning and the user will have an + opportunity to try again, up to the configured number of + retries.</para> + + <para>Most password policies require passwords to expire after + so many days. To set a password age time in &os;, set + <option>passwordtime</option> for the user's login class in + <filename>/etc/login.conf</filename>. The + <literal>default</literal> login class contains an + example:</para> + + <programlisting># :passwordtime=90d:\</programlisting> + + <para>So, to set an expiry of 90 days for this login class, + remove the comment symbol (<literal>#</literal>), save the + edit, and run <command>cap_mkdb + /etc/login.conf</command>.</para> + + <para>To set the expiration on individual users, pass an + expiration date or the number of days to expiry and a username + to <command>pw</command>:</para> + + <screen>&prompt.root; <userinput>pw usermod -p <replaceable>30-apr-2015</replaceable> -n <replaceable>trhodes</replaceable></userinput></screen> + + <para>As seen here, an expiration date is set in the form of + day, month, and year. For more information, see + &man.pw.8;.</para> </sect2> <sect2 xml:id="security-rkhunter"> @@ -2053,18 +2050,18 @@ Connection closed by foreign host.</scre <itemizedlist> <listitem> <para><emphasis>Encapsulated Security Payload - (<acronym>ESP</acronym>)</emphasis>: this protocol protects - the <acronym>IP</acronym> packet data from third party - interference by encrypting the contents using symmetric - cryptography algorithms such as Blowfish and + (<acronym>ESP</acronym>)</emphasis>: this protocol + protects the <acronym>IP</acronym> packet data from third + party interference by encrypting the contents using + symmetric cryptography algorithms such as Blowfish and <acronym>3DES</acronym>.</para> </listitem> <listitem> <para><emphasis>Authentication Header - (<acronym>AH</acronym>)</emphasis>): this protocol protects - the <acronym>IP</acronym> packet header from third party - interference and spoofing by computing a cryptographic + (<acronym>AH</acronym>)</emphasis>): this protocol + protects the <acronym>IP</acronym> packet header from third + party interference and spoofing by computing a cryptographic checksum and hashing the <acronym>IP </acronym> packet header fields with a secure hashing function. This is then followed by an additional header that contains the hash, to @@ -2074,9 +2071,9 @@ Connection closed by foreign host.</scre <listitem> <para><emphasis>IP Payload Compression Protocol - (<acronym>IPComp</acronym></emphasis>): this protocol tries - to increase communication performance by compressing the - <acronym>IP </acronym> payload in order ro reduce the + (<acronym>IPComp</acronym></emphasis>): this protocol + tries to increase communication performance by compressing + the <acronym>IP </acronym> payload in order ro reduce the amount of data sent.</para> </listitem> </itemizedlist> @@ -3532,9 +3529,8 @@ UWWemqWuz3lAZuORQ9KX <para>&os; provides several methods for an administrator to limit the amount of system resources an individual may use. - Disk quotas limit the amount of disk space available to - users. Quotas are discussed in - <xref linkend="quotas"/>.</para> + Disk quotas limit the amount of disk space available to users. + Quotas are discussed in <xref linkend="quotas"/>.</para> <indexterm> <primary>quotas</primary> @@ -3548,21 +3544,21 @@ UWWemqWuz3lAZuORQ9KX </indexterm> <para>Limits to other resources, such as <acronym>CPU</acronym> - and memory, can be set using either a flat - file or a command to configure a resource limits database. The - traditional method defines login classes by editing - <filename>/etc/login.conf</filename>. While this method - is still supported, any changes require a multi-step process of - editing this file, rebuilding the resource database, making necessary changes to - <filename>/etc/master.passwd</filename>, and rebuilding the - password database. This - can become time consuming, depending upon the number of users to + and memory, can be set using either a flat file or a command to + configure a resource limits database. The traditional method + defines login classes by editing + <filename>/etc/login.conf</filename>. While this method is + still supported, any changes require a multi-step process of + editing this file, rebuilding the resource database, making + necessary changes to <filename>/etc/master.passwd</filename>, + and rebuilding the password database. This can become time + consuming, depending upon the number of users to configure.</para> <para>Beginning with &os; 9.0-RELEASE, <command>rctl</command> can be used to provide a more - fine-grained method for controlling resource limits. - This command supports more than user limits as it can also be used to + fine-grained method for controlling resource limits. This + command supports more than user limits as it can also be used to set resource constraints on processes and jails.</para> <para>This section demonstrates both methods for controlling @@ -3584,10 +3580,11 @@ UWWemqWuz3lAZuORQ9KX <para>In the traditional method, login classes and the resource limits to apply to a login class are defined in - <filename>/etc/login.conf</filename>. Each user account can be assigned - to a login class, where <literal>default</literal> is the default - login class. Each login class has a set of login capabilities associated - with it. A login capability is a + <filename>/etc/login.conf</filename>. Each user account can + be assigned to a login class, where <literal>default</literal> + is the default login class. Each login class has a set of + login capabilities associated with it. A login capability is + a <literal><replaceable>name</replaceable>=<replaceable>value</replaceable></literal> pair, where <replaceable>name</replaceable> is a well-known identifier and <replaceable>value</replaceable> is an @@ -3595,63 +3592,63 @@ UWWemqWuz3lAZuORQ9KX the <replaceable>name</replaceable>.</para> <note> - <para>Whenever - <filename>/etc/login.conf</filename> is edited, the - <filename>/etc/login.conf.db</filename> must be updated by - executing the following command:</para> + <para>Whenever <filename>/etc/login.conf</filename> is edited, + the <filename>/etc/login.conf.db</filename> must be updated + by executing the following command:</para> <screen>&prompt.root; <userinput>cap_mkdb /etc/login.conf</userinput></screen> </note> <para>Resource limits differ from the default login capabilities - in two ways. First, for every limit, there is a <firstterm>soft</firstterm> - and <firstterm>hard</firstterm> limit. A soft limit may be adjusted by the - user or application, but may not be set higher than the hard - limit. The hard limit may be lowered by the user, but can - only be raised by the superuser. Second, most resource limits - apply per process to a specific user.</para> + in two ways. First, for every limit, there is a + <firstterm>soft</firstterm> and <firstterm>hard</firstterm> + limit. A soft limit may be adjusted by the user or + application, but may not be set higher than the hard limit. + The hard limit may be lowered by the user, but can only be + raised by the superuser. Second, most resource limits apply + per process to a specific user.</para> <para><xref linkend="resource-limits"/> lists the most commonly - used resource limits. All of the available - resource limits and capabilities are described in - detail in &man.login.conf.5;.</para> - - <indexterm> - <primary>limiting users</primary> - <secondary>coredumpsize</secondary> - </indexterm> - <indexterm> - <primary>limiting users</primary> - <secondary>cputime</secondary> - </indexterm> - <indexterm> - <primary>limiting users</primary> - <secondary>filesize</secondary> - </indexterm> - <indexterm> - <primary>limiting users</primary> - <secondary>maxproc</secondary> - </indexterm> - <indexterm> - <primary>limiting users</primary> - <secondary>memorylocked</secondary> - </indexterm> - <indexterm> - <primary>limiting users</primary> - <secondary>memoryuse</secondary> - </indexterm> - <indexterm> - <primary>limiting users</primary> - <secondary>openfiles</secondary> - </indexterm> - <indexterm> - <primary>limiting users</primary> - <secondary>sbsize</secondary> - </indexterm> - <indexterm> - <primary>limiting users</primary> - <secondary>stacksize</secondary> - </indexterm> + used resource limits. All of the available resource limits + and capabilities are described in detail in + &man.login.conf.5;.</para> + + <indexterm> + <primary>limiting users</primary> + <secondary>coredumpsize</secondary> + </indexterm> + <indexterm> + <primary>limiting users</primary> + <secondary>cputime</secondary> + </indexterm> + <indexterm> + <primary>limiting users</primary> + <secondary>filesize</secondary> + </indexterm> + <indexterm> + <primary>limiting users</primary> + <secondary>maxproc</secondary> + </indexterm> + <indexterm> + <primary>limiting users</primary> + <secondary>memorylocked</secondary> + </indexterm> + <indexterm> + <primary>limiting users</primary> + <secondary>memoryuse</secondary> + </indexterm> + <indexterm> + <primary>limiting users</primary> + <secondary>openfiles</secondary> + </indexterm> + <indexterm> + <primary>limiting users</primary> + <secondary>sbsize</secondary> + </indexterm> + <indexterm> + <primary>limiting users</primary> + <secondary>stacksize</secondary> + </indexterm> <table xml:id="resource-limits" frame="none" pgwide="1"> <title>Login Class Resource Limits</title> @@ -3666,93 +3663,94 @@ UWWemqWuz3lAZuORQ9KX <tbody> <row> - <entry>coredumpsize</entry> - <entry>The limit on the size of a core file - generated by a program is subordinate to other limits - on disk usage, such as <literal>filesize</literal> or - disk quotas. This limit is often used as a less severe - method of controlling disk space consumption. Since - users do not generate core files and often - do not delete them, this setting may save them from - running out of disk space should a large program - crash.</entry> - </row> - - <row> - <entry>cputime</entry> - <entry>The maximum amount of <acronym>CPU</acronym> - time a user's process may consume. Offending processes - will be killed by the kernel. This is a limit on - <acronym>CPU</acronym> <emphasis>time</emphasis> - consumed, not the percentage of the <acronym>CPU</acronym> as displayed in - some of the fields generated by <command>top</command> - and <command>ps</command>.</entry> + <entry>coredumpsize</entry> + <entry>The limit on the size of a core file generated by + a program is subordinate to other limits on disk + usage, such as <literal>filesize</literal> or disk + quotas. This limit is often used as a less severe + method of controlling disk space consumption. Since + users do not generate core files and often do not + delete them, this setting may save them from running + out of disk space should a large program + crash.</entry> + </row> + + <row> + <entry>cputime</entry> + <entry>The maximum amount of <acronym>CPU</acronym> time + a user's process may consume. Offending processes + will be killed by the kernel. This is a limit on + <acronym>CPU</acronym> <emphasis>time</emphasis> + consumed, not the percentage of the + <acronym>CPU</acronym> as displayed in some of the + fields generated by <command>top</command> and + <command>ps</command>.</entry> + </row> + + <row> + <entry>filesize</entry> + <entry>The maximum size of a file the user may own. + Unlike disk quotas (<xref linkend="quotas"/>), this + limit is enforced on individual files, not the set of + all files a user owns.</entry> + </row> + + <row> + <entry>maxproc</entry> + <entry>The maximum number of foreground and background + processes a user can run. This limit may not be + larger than the system limit specified by + <varname>kern.maxproc</varname>. Setting this limit + too small may hinder a user's productivity as some + tasks, such as compiling a large program, start lots + of processes.</entry> </row> - <row> - <entry>filesize</entry> - <entry>The maximum size of a file - the user may own. Unlike disk quotas - (<xref linkend="quotas"/>), this limit is - enforced on individual files, not the set of all files a - user owns.</entry> - </row> - - <row> - <entry>maxproc</entry> - <entry>The maximum number of foreground and background processes - a user can run. This limit may not be larger than the system - limit specified by <varname>kern.maxproc</varname>. - Setting this limit too small may hinder - a user's productivity as some tasks, - such as compiling a large program, start lots of - processes.</entry> - </row> - - <row> - <entry>memorylocked</entry> - <entry>The maximum amount of memory - a process may request to be locked into main memory - using &man.mlock.2;. Some system-critical programs, - such as &man.amd.8;, lock into main memory so that if - the system begins to swap, they do not contribute to - disk thrashing.</entry> - </row> - - <row> - <entry>memoryuse</entry> - <entry>The maximum amount of memory - a process may consume at any given time. It includes - both core memory and swap usage. This is not a - catch-all limit for restricting memory consumption, but - is a good start.</entry> - </row> - - <row> - <entry>openfiles</entry> - <entry>The maximum number of files a process may have open. - In &os;, files are used to represent sockets and <acronym>IPC</acronym> - channels, so be careful not to set this too low. The - system-wide limit for this is defined by - <varname>kern.maxfiles</varname>.</entry> - </row> - - <row> - <entry>sbsize</entry> - <entry>The limit on the amount of network memory - a user may consume. This can be generally used to limit - network communications.</entry> - </row> - - <row> - <entry>stacksize</entry> - <entry>The maximum size of a process stack. - This alone is not sufficient to limit the amount of - memory a program may use, so it should be used in - conjunction with other limits.</entry> - </row> - </tbody> - </tgroup> + <row> + <entry>memorylocked</entry> + <entry>The maximum amount of memory a process may + request to be locked into main memory using + &man.mlock.2;. Some system-critical programs, such as + &man.amd.8;, lock into main memory so that if the + system begins to swap, they do not contribute to disk + thrashing.</entry> + </row> + + <row> + <entry>memoryuse</entry> + <entry>The maximum amount of memory a process may + consume at any given time. It includes both core + memory and swap usage. This is not a catch-all limit + for restricting memory consumption, but is a good + start.</entry> + </row> + + <row> + <entry>openfiles</entry> + <entry>The maximum number of files a process may have + open. In &os;, files are used to represent sockets + and <acronym>IPC</acronym> channels, so be careful not + to set this too low. The system-wide limit for this + is defined by + <varname>kern.maxfiles</varname>.</entry> + </row> + + <row> + <entry>sbsize</entry> + <entry>The limit on the amount of network memory a user + may consume. This can be generally used to limit + network communications.</entry> + </row> + + <row> + <entry>stacksize</entry> + <entry>The maximum size of a process stack. This alone + is not sufficient to limit the amount of memory a + program may use, so it should be used in conjunction + with other limits.</entry> + </row> + </tbody> + </tgroup> </table> <para>There are a few other things to remember when setting @@ -3766,29 +3764,29 @@ UWWemqWuz3lAZuORQ9KX </listitem> <listitem> - <para>Although the default <filename>/etc/login.conf</filename> - is a good source of reasonable - values for most limits, they may not be appropriate for - every system. Setting a limit too high may open the - system up to abuse, while setting it too low may put a - strain on productivity.</para> + <para>Although the default + <filename>/etc/login.conf</filename> is a good source of + reasonable values for most limits, they may not be + appropriate for every system. Setting a limit too high + may open the system up to abuse, while setting it too low + may put a strain on productivity.</para> </listitem> <listitem> <para><application>&xorg;</application> takes a lot of - resources and encourages users to run more - programs simultaneously.</para> + resources and encourages users to run more programs + simultaneously.</para> </listitem> <listitem> <para>Many limits apply to individual processes, not the user as a whole. For example, setting - <varname>openfiles</varname> to <literal>50</literal> means that each process - the user runs may open up to <literal>50</literal> files. The total amount - of files a user may open is the value of - <literal>openfiles</literal> multiplied by the value of - <literal>maxproc</literal>. This also applies to memory - consumption.</para> + <varname>openfiles</varname> to <literal>50</literal> + means that each process the user runs may open up to + <literal>50</literal> files. The total amount of files a + user may open is the value of <literal>openfiles</literal> + multiplied by the value of <literal>maxproc</literal>. + This also applies to memory consumption.</para> </listitem> </itemizedlist>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201404302129.s3ULT4iu061274>