Feature request: module [pam_limits]

[Cedric Bhihe]

John,
Do you mean to do away with limits in GNU linux on the basis that it is 
weak security ?
Nobody I know has ever claimed it was anything but weak security. As you 
point
out  as security goes, it does not get you very far beyond keeping yr 
box(es) a little
under control when they are at the hands of scripting noobs.
Agreed, but that is so completely beside the point of my suggestion on 
syntax...

Say you have 100 users on any given box concerned: user1000 to user1099. Yr
context is one where you keep creating and terminating users.
Default `nproc` limits are:  13400 soft and hard for all non-root, right 
from the
start, i.e. at new user creation time.
One needs bringing that limit down to 120 for all but one user, say user1012

#Existing syntax
#<domain>      <type>    <item>         <value>
1000-1011        -       nproc          120
1013-1099        -       nproc          120

could be replaced  with:

#Proposed syntax addition
#<domain>      <type>    <item>         <value>
!1012            -       nproc          120

Not to mention that every time you add a new user, you'd have to up the 
upper bound
(1099  -> 1100)  of the second range when using the existing syntax. it 
makes for
rather tedious work, plus you either need to remember doing it as part 
of a manual
new user creation routine or invest time in a delicate wrapper script 
around 'adduser'
to automate limits tweaking.

Negation could just as well apply to a range of UIDs or GIDs.

This is compatible with existing pam_limits module syntax. It is not 
meant to replace or
displace any of it.
-ced

On 27/02/16 at 22:19, John Moser wrote:
> 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!"
>