> Solution: no temporary solution yet, there should be a global per user > file limit, the reserved file descriptors should be given out under > another uid/euid policy. The NR_RESERVED_FILES limit seems to me to be > really low. Huh. Simply limit users, PAM provides this capability, as do most shells. From: http://seifried.org/lasg/users/ PAM Almost all Linux distributions ship with PAM support making it universally available. PAM limits provide a single standardized interface to setting user limits, instead of having to write complex shell configuration files (such as /etc/profile) you simply edit the "limits.conf" file. As well applying limits selectively through the command shell is very difficult, whereas with PAM applying limits globally, on groups or on individual users is quite simple. Documentation is available on PAM usually in the "/usr/share/doc/" tree. To enable PAM limits you need to add a line such as: session required /lib/security/pam_limits.so to the appropriate Pam configuration file (i.e. /etc/pam.d/sshd). You can then define limits, typically these are in "/etc/security/limits.conf" or a similar location. Because most of these limits are enforced by the shell the system cannot log all violations of limits (i.e. you will be notified in syslog when a user exceeds the number of times they are allowed to login, however you will not receive a warning if the user tries to use more disk space then they are allowed to). The available limits are: core -- Limits the core file size (KB); usually set to 0 for most users to prevent core dumps. data -- Maximum data size (KB). fsize -- Maximum file size (KB). memlock -- Maximum locked-in-memory address space (KB). nofile -- Maximum number of open files. rss -- Maximum resident set size (KB). stack -- Maximum stack size (KB). cpu -- Maximum CPU time (MIN). nproc -- Maximum number of processes. as -- Address space limit. maxlogins -- Maximum number of logins for this user or group. priority -- The priority to run user process with. For example you can limit the amount of memory that user "bob" is allowed to use: user hard memlock 4096 This would place a hard (absolute) limit of 4 megabytes on memory usage for "bob". Limits can be placed on users by listing the user name, groups by using the syntax "@group" or globally by using "*". core files can be created when a program crashes. They have been used in security exploits, overwriting system files, or by containing sensitive information (such as passwords). You can easily disable core dumps using PAM, and generally speaking most users will not notice, however if you have software developers they may complain. * hard core 0 fsize is generally a good idea to set, many users will have a large filesystem quota (i.e. tens of megabytes to several hundred or several gigabytes), however if they are allowed to create a single file that is abnormally large they can easily hog disk I/O resources (i.e. create a large file and copy/delete the copy repeatedly). Setting this limit globally can also prevent an attacker from trying to fill up the partitions your log files are stored on, for example if you only have a single / partition an attacker can easily fill it up by generating a lot of log events. @notroot hard data 102400 Of course limiting CPU time is one of the classic administrative tasks, this is very useful for preventing run-away processes from eating up all the cpu time, and it ensures that if a user leaves something running in background (such as a packet sniffer) it will eventually be killed. Limiting CPU time will have several side effects however, once of which will be limiting the amount of time a user can spend logged in (eventually they will run out of CPU time and the session will be killed), this can lead to problems if users spend long periods logged in. As well depending on the CPU(s) present in your machine the limits can vary greatly (one minute on a 386 is quite a bit different then one minute on a 1.3 GHz Athalon). @students hard cpu 2 Limiting the number of times a user can login is strongly advised, for most situations users should not need to log in to a server more then once, and allowing them to do so let's them use more resources then you might intend. As well it can be used to detect suspicious activity, if users know they can only login once then attempts to log in multiple times can be viewed as suspicious activity (i.e. an attacker with a stolen password trying to access the account). @users hard maxlogins 1 Additionally when someone violated this limit it will be logged in syslog: Apr 15 15:09:26 stench PAM_unix[9993]: (sshd) session opened for user test by (uid=0) Apr 15 15:09:32 stench pam_limits[10015]: Too many logins (max 1) for test Soft limit violations will not be logged (i.e. a soft limit of 1 and a hard limit of 2). Bash Bash has built in limits, accessed via "ulimit". Any hard limits cannot be set higher, so if you have limits defined in /etc/profile, or in the users .bash_profile (assuming they cannot edit/delete .bash_profile) you can enforce limits on users with Bash shells. This is useful for older Linux distributions that lack PAM support (however this is increasingly rare and PAM should be used if possible). You must also ensure that the user cannot change their login shell, if they use "chsh" to change their shell to ksh for example the next time they login they will have no limits (assuming you cave not put limits on ksh). Documentation is available on ulimit, log in using bash and issue: [root@server /root]# help ulimit ulimit: ulimit [-SHacdflmnpstuv] [limit] Ulimit provides control over the resources available to processes started by the shell, on systems that allow such control. If an option is given, it is interpreted as follows: -S use the `soft' resource limit -H use the `hard' resource limit -a all current limits are reported -c the maximum size of core files created -d the maximum size of a process's data segment -f the maximum size of files created by the shell -l the maximum size a process may lock into memory -m the maximum resident set size -n the maximum number of open file descriptors -p the pipe buffer size -s the maximum stack size -t the maximum amount of cpu time in seconds -u the maximum number of user processes -v the size of virtual memory If LIMIT is given, it is the new value of the specified resource. Otherwise, the current value of the specified resource is printed. If no option is given, then -f is assumed. Values are in 1024-byte increments, except for -t, which is in seconds, -p, which is in increments of 512 bytes, and -u, which is an unscaled number of processes. To disallow core files (by setting the maximum size to 0) for example you would add: ulimit -Hc 0 To set limits globally you would need to edit "/etc/profile", of course this will also affect root, so be careful! To set limits on groups you would need to add scripting to "/etc/profile" that would check for the user's membership in a group and then apply the statements, however doing this with PAM is recommended as it is a lot simpler. Kurt Seifried, kurtat_private A15B BEE5 B391 B9AD B0EF AEB0 AD63 0B4E AD56 E574 http://seifried.org/security/
This archive was generated by hypermail 2b30 : Mon Jul 08 2002 - 15:52:00 PDT