From owner-svn-doc-all@FreeBSD.ORG Wed Apr 30 21:29:04 2014 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F05A494; Wed, 30 Apr 2014 21:29:04 +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 5A5E318C0; Wed, 30 Apr 2014 21:29:04 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s3ULT4of061275; Wed, 30 Apr 2014 21:29:04 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s3ULT4iu061274; Wed, 30 Apr 2014 21:29:04 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201404302129.s3ULT4iu061274@svn.freebsd.org> From: Dru Lavigne Date: Wed, 30 Apr 2014 21:29:04 +0000 (UTC) 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 X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 21:29:04 -0000 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 - CIA triad, which stands for the Confidentiality, - Integrity, and Availability of information systems. + CIA triad, which stands for the + Confidentiality, Integrity, and Availability of information + systems. The CIA 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). + 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). To provide CIA, 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. - - 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. - - 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. - - 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 (SOPs) already exist. - When in doubt, ask the security team. + 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. + + 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. + + 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. + + 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 + (SOPs) already exist. When in doubt, ask the + security team. 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. + be used when implementing a security policy on a &os; + system. Preventing Logins @@ -178,55 +178,57 @@ In securing a system, a good starting point is an audit of accounts. Ensure that root has a strong password and - that this password is not shared. - Disable any accounts that do not need login access. + that this password is not shared. Disable any accounts that + do not need login access. - To deny login access to accounts, two methods exist. The first - is to lock the account. This example locks the toor account: + To deny login access to accounts, two methods exist. The + first is to lock the account. This example locks the + toor account: &prompt.root; pw lock toor - The second method is to prevent login access - by changing the shell to /sbin/nologin. - Only the superuser can change the shell for other users: + The second method is to prevent login access by changing + the shell to /sbin/nologin. Only the + superuser can change the shell for other users: &prompt.root; chsh -s /usr/sbin/nologin toor The /usr/sbin/nologin shell prevents - the system from assigning a shell to the - user when they attempt to login. + the system from assigning a shell to the user when they + attempt to login. Permitted Account Escalation - 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 wheel group. With this method, - a user types su and enters the password for - wheel whenever - superuser access is needed. The user should then type - exit to leave privileged access after - finishing the commands that required administrative access. To add a user - to this group, edit /etc/group and add the - user to the end of the wheel entry. The user must be + 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 wheel group. With this + method, a user types su and enters the + password for wheel + whenever superuser access is needed. The user should then + type exit to leave privileged access after + finishing the commands that required administrative access. + To add a user to this group, edit + /etc/group and add the user to the end of + the wheel entry. The user must be separated by a comma character with no space. - The second, and recommended, method to permit privilege escalation is - to install the security/sudo 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 + The second, and recommended, method to permit privilege + escalation is to install the security/sudo + 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. After installation, use visudo to edit - /usr/local/etc/sudoers. - This example creates - a new webadmin group, adds the trhodes account to that group, and - configures that group access to restart + /usr/local/etc/sudoers. This example + creates a new webadmin group, adds the + trhodes account to + that group, and configures that group access to restart apache24: &prompt.root; pw groupadd webadmin -M trhodes -g 6000 @@ -237,45 +239,42 @@ Password Hashes - 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 + 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 DES, MD5, - SHA256, SHA512, and Blowfish hash algorithms in its - crypt() library. The default of - SHA512 should not be changed to a less - secure hashing algorithm, but can be changed to the more secure - Blowfish algorithm. + SHA256, SHA512, and + Blowfish hash algorithms in its crypt() + library. The default of SHA512 should not + be changed to a less secure hashing algorithm, but can be + changed to the more secure Blowfish algorithm. - Blowfish is not part of - AES and is not considered compliant with - any Federal Information - Processing Standards (FIPS). Its use may not be - permitted in some environments. + Blowfish is not part of AES and is + not considered compliant with any Federal Information + Processing Standards (FIPS). Its use may + not be permitted in some environments. 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 - DES is used, there is no beginning symbol. - For - MD5, 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 DES is used, there is no + beginning symbol. For MD5, the symbol is $. For SHA256 and - SHA512, the symbol is $6$. - For Blowfish, the symbol is $2a$. In this - example, the password for dru is hashed using the default - SHA512 algorithm as the hash starts with - $6$. Note that the encrypted hash, not the password - itself, is stored in the password database: + SHA512, the symbol is + $6$. For Blowfish, the symbol is + $2a$. In this example, the password for + dru is hashed using + the default SHA512 algorithm as the hash + starts with $6$. Note that the encrypted + hash, not the password itself, is stored in the password + database: &prompt.root; grep dru /etc/master.passwd -dru:$6$pzIjSvCAn.PBYQBA$PXpSeWPx3g5kscj3IMiM7tUEUSPmGexxta.8Lt9TGSi2lNQqYGKszsBPuGME0:1001:1001::0:0:dru:/usr/home/dru:/bin/csh - +dru:$6$pzIjSvCAn.PBYQBA$PXpSeWPx3g5kscj3IMiM7tUEUSPmGexxta.8Lt9TGSi2lNQqYGKszsBPuGME0:1001:1001::0:0:dru:/usr/home/dru:/bin/csh The hash mechanism is set in the user's login class. For this example, the user is in the default @@ -286,83 +285,79 @@ dru:$6$pzIjSvCAn.PBYQBA$PXpSeWPx3g5kscj3 To change the algorithm to Blowfish, modify that line to look like this: - - :passwd_format=blf:\ - - Then run cap_mkdb /etc/login.conf as + + :passwd_format=blf:\ + + Then run cap_mkdb /etc/login.conf as described in . 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 passwd - in order to change their password. + means that all passwords should be re-hashed by asking users + to run passwd in order to change their + password. - For remote logins, two-factor - authentication should be used. An example of two-factor authentication is + For remote logins, two-factor authentication should be + used. An example of two-factor authentication is something you have, such as a key, and - something you know, such as the passphrase for that key. Since - OpenSSH 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 . - Kerberos users may need to make additional - changes to implement OpenSSH in - their network. These changes are described in . - - - - Password Policy Enforcement - - 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 (PAM). - - This section demonstrates how to configure the minimum - and maximum password length and the - enforcement of mixed characters using the - pam_passwdqc.so module. This module is enforced when - a user changes their password. - - To configure this module, become the superuser and uncomment the line containing - pam_passwdqc.so in - /etc/pam.d/passwd. Then, edit that - line to match the password policy: - - password requisite pam_passwdqc.so min=disabled,disabled,disabled,12,10 similar=deny retry=3 enforce=users - - This example - sets several requirements for new passwords. The min - 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 12 sets a minimum password policy of - at least twelve characters, if the password also contains - characters with three types of complexity. The - 10 sets the password policy to also allow - passwords of at least ten characters, if the password - contains characters with four types of complexity. - - The similar setting denies passwords that - are similar to the user's previous password. The - retry setting provides a user with - three opportunities to enter a new password. - - Once this file is saved, a user - changing their password will see a message similar to the - following: + something you know, such as the passphrase for + that key. Since OpenSSH 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 . Kerberos users may need to make + additional changes to implement + OpenSSH in their network. These + changes are described in . + + + + Password Policy Enforcement + + 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 + (PAM). + + This section demonstrates how to configure the minimum and + maximum password length and the enforcement of mixed + characters using the pam_passwdqc.so + module. This module is enforced when a user changes their + password. - &prompt.user; passwd + To configure this module, become the superuser and + uncomment the line containing + pam_passwdqc.so in + /etc/pam.d/passwd. Then, edit that line + to match the password policy: + + password requisite pam_passwdqc.so min=disabled,disabled,disabled,12,10 similar=deny retry=3 enforce=users + + This example sets several requirements for new passwords. + The min 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 12 sets a minimum + password policy of at least twelve characters, if the password + also contains characters with three types of complexity. The + 10 sets the password policy to also allow + passwords of at least ten characters, if the password contains + characters with four types of complexity. + + The similar setting denies passwords + that are similar to the user's previous password. The + retry setting provides a user with three + opportunities to enter a new password. + + Once this file is saved, a user changing their password + will see a message similar to the following: + + &prompt.user; passwd 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: - 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. - - Most password policies require passwords to - expire after so many days. To set a - password age time in &os;, set - for the user's login class in - /etc/login.conf. The - default login class contains an example: - - # :passwordtime=90d:\ - - So, to set an expiry of 90 days for this login class, - remove the comment symbol (#), save the - edit, and run cap_mkdb /etc/login.conf. - - To set the expiration on individual users, pass an - expiration date or the number of days to expiry - and a username to pw: - - &prompt.root; pw usermod -p 30-apr-2015 -n trhodes - - As seen here, an expiration date is set in the form of - day, month, and year. For more information, see - &man.pw.8;. + 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. + + Most password policies require passwords to expire after + so many days. To set a password age time in &os;, set + for the user's login class in + /etc/login.conf. The + default login class contains an + example: + + # :passwordtime=90d:\ + + So, to set an expiry of 90 days for this login class, + remove the comment symbol (#), save the + edit, and run cap_mkdb + /etc/login.conf. + + To set the expiration on individual users, pass an + expiration date or the number of days to expiry and a username + to pw: + + &prompt.root; pw usermod -p 30-apr-2015 -n trhodes + + As seen here, an expiration date is set in the form of + day, month, and year. For more information, see + &man.pw.8;. @@ -2053,18 +2050,18 @@ Connection closed by foreign host. Encapsulated Security Payload - (ESP): this protocol protects - the IP packet data from third party - interference by encrypting the contents using symmetric - cryptography algorithms such as Blowfish and + (ESP): this protocol + protects the IP packet data from third + party interference by encrypting the contents using + symmetric cryptography algorithms such as Blowfish and 3DES. Authentication Header - (AH)): this protocol protects - the IP packet header from third party - interference and spoofing by computing a cryptographic + (AH)): this protocol + protects the IP packet header from third + party interference and spoofing by computing a cryptographic checksum and hashing the IP 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. IP Payload Compression Protocol - (IPComp): this protocol tries - to increase communication performance by compressing the - IP payload in order ro reduce the + (IPComp): this protocol + tries to increase communication performance by compressing + the IP payload in order ro reduce the amount of data sent. @@ -3532,9 +3529,8 @@ UWWemqWuz3lAZuORQ9KX &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 - . + Disk quotas limit the amount of disk space available to users. + Quotas are discussed in . quotas @@ -3548,21 +3544,21 @@ UWWemqWuz3lAZuORQ9KX Limits to other resources, such as CPU - 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 - /etc/login.conf. 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 - /etc/master.passwd, 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 + /etc/login.conf. 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 /etc/master.passwd, + and rebuilding the password database. This can become 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 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. This section demonstrates both methods for controlling @@ -3584,10 +3580,11 @@ UWWemqWuz3lAZuORQ9KX In the traditional method, login classes and the resource limits to apply to a login class are defined in - /etc/login.conf. Each user account can be assigned - to a login class, where default is the default - login class. Each login class has a set of login capabilities associated - with it. A login capability is a + /etc/login.conf. Each user account can + be assigned to a login class, where default + is the default login class. Each login class has a set of + login capabilities associated with it. A login capability is + a name=value pair, where name is a well-known identifier and value is an @@ -3595,63 +3592,63 @@ UWWemqWuz3lAZuORQ9KX the name. - Whenever - /etc/login.conf is edited, the - /etc/login.conf.db must be updated by - executing the following command: + Whenever /etc/login.conf is edited, + the /etc/login.conf.db must be updated + by executing the following command: &prompt.root; cap_mkdb /etc/login.conf Resource limits differ from the default login capabilities - in two ways. First, for every limit, there is a soft - and hard 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. + in two ways. First, for every limit, there is a + soft and hard + 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. lists the most commonly - used resource limits. All of the available - resource limits and capabilities are described in - detail in &man.login.conf.5;. - - - limiting users - coredumpsize - - - limiting users - cputime - - - limiting users - filesize - - - limiting users - maxproc - - - limiting users - memorylocked - - - limiting users - memoryuse - - - limiting users - openfiles - - - limiting users - sbsize - - - limiting users - stacksize - + used resource limits. All of the available resource limits + and capabilities are described in detail in + &man.login.conf.5;. + + + limiting users + coredumpsize + + + limiting users + cputime + + + limiting users + filesize + + + limiting users + maxproc + + + limiting users + memorylocked + + + limiting users + memoryuse + + + limiting users + openfiles + + + limiting users + sbsize + + + limiting users + stacksize + Login Class Resource Limits @@ -3666,93 +3663,94 @@ UWWemqWuz3lAZuORQ9KX - coredumpsize - The limit on the size of a core file - generated by a program is subordinate to other limits - on disk usage, such as filesize 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. - - - - cputime - The maximum amount of CPU - time a user's process may consume. Offending processes - will be killed by the kernel. This is a limit on - CPU time - consumed, not the percentage of the CPU as displayed in - some of the fields generated by top - and ps. + coredumpsize + The limit on the size of a core file generated by + a program is subordinate to other limits on disk + usage, such as filesize 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. + + + + cputime + The maximum amount of CPU time + a user's process may consume. Offending processes + will be killed by the kernel. This is a limit on + CPU time + consumed, not the percentage of the + CPU as displayed in some of the + fields generated by top and + ps. + + + + filesize + The maximum size of a file the user may own. + Unlike disk quotas (), this + limit is enforced on individual files, not the set of + all files a user owns. + + + + maxproc + The maximum number of foreground and background + processes a user can run. This limit may not be + larger than the system limit specified by + kern.maxproc. Setting this limit + too small may hinder a user's productivity as some + tasks, such as compiling a large program, start lots + of processes. - - filesize - The maximum size of a file - the user may own. Unlike disk quotas - (), this limit is - enforced on individual files, not the set of all files a - user owns. - - - - maxproc - The maximum number of foreground and background processes - a user can run. This limit may not be larger than the system - limit specified by kern.maxproc. - Setting this limit too small may hinder - a user's productivity as some tasks, - such as compiling a large program, start lots of - processes. - - - - memorylocked - 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. - - - - memoryuse - 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. - - - - openfiles - The maximum number of files a process may have open. - In &os;, files are used to represent sockets and IPC - channels, so be careful not to set this too low. The - system-wide limit for this is defined by - kern.maxfiles. - - - - sbsize - The limit on the amount of network memory - a user may consume. This can be generally used to limit - network communications. - - - - stacksize - 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. - - - + + memorylocked + 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. + + + + memoryuse + 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. + + + + openfiles + The maximum number of files a process may have + open. In &os;, files are used to represent sockets + and IPC channels, so be careful not + to set this too low. The system-wide limit for this + is defined by + kern.maxfiles. + + + + sbsize + The limit on the amount of network memory a user + may consume. This can be generally used to limit + network communications. + + + + stacksize + 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. + + +
There are a few other things to remember when setting @@ -3766,29 +3764,29 @@ UWWemqWuz3lAZuORQ9KX - Although the default /etc/login.conf - 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. + Although the default + /etc/login.conf 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. &xorg; takes a lot of - resources and encourages users to run more - programs simultaneously. + resources and encourages users to run more programs + simultaneously. Many limits apply to individual processes, not the user as a whole. For example, setting - openfiles to 50 means that each process - the user runs may open up to 50 files. The total amount - of files a user may open is the value of - openfiles multiplied by the value of - maxproc. This also applies to memory - consumption. + openfiles to 50 + means that each process the user runs may open up to + 50 files. The total amount of files a + user may open is the value of openfiles + multiplied by the value of maxproc. + This also applies to memory consumption.