Feature request: module [pam_limits]

John Moser john.r.moser at gmail.com
Sat Feb 27 21:19:17 UTC 2016

On 02/27/2016 04:06 PM, Ralf Mardorf wrote:
> #<domain>      <type>  <item>         <value>
> @foo           soft    nproc          20
> @foo           hard    nproc          50
> Every user who is _not_ in the group "foo", simply is _not_ in
> this group, it makes completely no sense to introduce a negation of
> being in a group, since the negation is already not being member of this
> group.

The short explanation here is "complexity and design decisions".  The
naive approach is probably to check for negations first, and skip the
line if a user is in a negated group.  The application of a rule to all
except those in a group is a form of that:  negation, all.

The bigger question is what purpose does this serve?  Limits are not so
much a security feature as an administrative resource feature, and
they're flaky as hell.  They're set by a privileged process (such as
login) and inherited by children.  That's why MySQL or Apache can start
up, set their own ulimit (as root), and then drop privileges and switch
to the mysql or www-data user and keep their limits:  no interposing
process makes any further decisions.

The general limit of "don't create 80,000 processes" stops fork bombs;
everything else is academic.  Even then, it just stops :(){ :|:; } and
not a thread-creating perl script.

I use limits to keep those little boxes around and make sure my system
behaves in cases where it's being erratic.  When it's under attack,
ulimits don't really offer any considerable protection.  They're part of
a list of pointless security dogma, like running chmod go= on mount,
ping, and other setuid binaries.  Everyone wants a checklist so they can
claim they've "hardened" their system without actually bothering to
identify threats and set up things like network-level firewalling,
privilege separation, and the like.

It's the same reason people encrypt data in databases with the key
stored in the application config file or, as with Miva Merchant, in the
"AESKey" column right next to the encrypted credit card numbers:  "It's
encrypted and encryption is security!"

More information about the Ubuntu-devel-discuss mailing list