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!"
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
