Hi, Sabayon, as 99,9% other distros, doesn't limit in any way the number of running processes per user, this leads to potential vulnerability to fork bombs, buggy code and other malicious code. Thus I suggest to offer some nice and safe defaults for /etc/security/limits.conf.
A user with particular needs could very well disable those settings for its own purposes, this kind of users is most likely aware of how to configure its system, while the average user could be unable to setup it's system in a safe way. Probably the addition of more relaxed settings for particular groups can be considered (like gaming groups, development groups and so on), here I describe a simpler approach. There are some issues that could arise from this kind of configuration: 1) Sabayon is desktop oriented (but it also provides ServerBase isos) 2) Different machines have different capabilities 3) emerge (even if entropy is Sabayon's default package manager), as well as other multithreaded/multiprocess application could spawn a lot of processes and threads. 4) equo install sys-apps/pam will suggest to overwrite /etc/security/limits.conf with the default (empty) one. point 1 could be easily satisfied having the process limit at a very high value (in other words, considering that only 1 or at most 2 users will be logged in the machine), maybe Sabayon could offer different defaults for the ServerBase iso. about point 2 the limits.conf file can be generated at installation time, the installer could probe the CPU cores and GHz, creating sensible process number limits. We could also offer an option to disable this security feature. For example Sabayon could create the default limits like this, assuming GHz to be a floating point value: soft_limit = 400 * (GHz / 1.5) + 70 * cpu_cores hard_limit = soft_limit + 100 point 3 could be solved allowing users in the root group to have unlimited processes. point 4 could be solved either splitting the pam ebuild or preventing the package manager to replace that file (like it probably already does with hostname and other similar configuration files). I am currently experimenting on an Xfce4 environment with a dual core HT Intel i5 CPU (2.40 GHz turbo), with the attached limits.conf, I experimented some fork bombs and I was able to recover very well, the system didn't slow down at all during the simulated attack and I was able to recover very well. Is this idea worth implementing in Sabayon? -- Lorenzo Cogotti
# /etc/security/limits.conf # #Each line describes a limit for a user in the form: # #<domain> <type> <item> <value> # #Where: #<domain> can be: # - an user name # - a group name, with @group syntax # - the wildcard *, for default entry # - the wildcard %, can be also used with %group syntax, # for maxlogin limit # #<type> can have the two values: # - "soft" for enforcing the soft limits # - "hard" for enforcing hard limits # #<item> can be one of the following: # - core - limits the core file size (KB) # - data - max data size (KB) # - fsize - maximum filesize (KB) # - memlock - max locked-in-memory address space (KB) # - nofile - max number of open files # - rss - max resident set size (KB) # - stack - max stack size (KB) # - cpu - max CPU time (MIN) # - nproc - max number of processes # - as - address space limit (KB) # - maxlogins - max number of logins for this user # - maxsyslogins - max number of logins on the system # - priority - the priority to run user process with # - locks - max number of file locks the user can hold # - sigpending - max number of pending signals # - msgqueue - max memory used by POSIX message queues (bytes) # - nice - max nice priority allowed to raise to values: [-20, 19] # - rtprio - max realtime priority # #<domain> <type> <item> <value> # #* soft core 0 #* hard rss 10000 #@student hard nproc 20 #@faculty soft nproc 20 #@faculty hard nproc 50 #ftp hard nproc 0 #@student - maxlogins 4 # End of file * soft nproc 700 * hard nproc 900 * soft maxlogins 20 * hard maxlogins 60 @root - nproc infinity @root - maxlogins 10 @dev soft nproc 1500 @dev hard nproc 2000
