Re: Feature request: module [pam_limits]
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
#
1000-1011- nproc 120
1013-1099- nproc 120
could be replaced with:
#Proposed syntax addition
#
!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:
#
@foo softnproc 20
@foo hardnproc 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
Re: Feature request: module [pam_limits]
I really did not intend my suggestion to be a thermonuclear device. I take yr comments seriously though; you have a point. That said, the (perhaps weak) rationale behind introducing "group negation" in the `pam_limits` syntax is certainly not muddying waters, but rather change default values for all groups but the "negated" one. The same applies to users. (I noticed yr comments only focused on groups. Does it mean you would second the feature request for syntax applying to users ?) Perhaps that makes no sense to some/most/you, but I would consider it handy and an alternative to group range limit specification, around a specific group, whose limit(s) you don't want to change. As it stands, the existing pam_limits syntax allows us to express everything. I suggest an alternate way of expressing things in certain cases where blanket rules introduces concision. It may not conform to the spirit or the habits of devs, perhaps breaking a rule unknown to me, along the lines of: "You shan't provide alternative syntax to something that has one and ain't broken." But that I don't know. I am just a user, not a dev. If this was not already a burial, then the community will decide. Tis all. Cheers. -ced On 27/02/16 at 22:06, Ralf Mardorf wrote: # @foo softnproc 20 @foo hardnproc 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. [foo@linux ~]$ id foo uid=1000(foo) gid=1000(foo) groups=1000(foo) [foo@linux ~]$ id bar uid=1001(bar) gid=1001(bar) groups=1001(bar),1000(foo) [foo@linux ~]$ id jane_doe uid=1002(jane_doe) gid=1002(jane_doe) groups=1002(jane_doe) What would you gain by introducing a negation of being in a group? You only would lose clarity? You could set up a new group, if nobody should be in the group "foo", but the user "foo". # @npgroup softnproc 20 @npgroup hardnproc 50 [foo@linux ~]$ id foo uid=1000(foo) gid=1000(foo) groups=1000(foo),50(npgroup) [foo@linux ~]$ id bar uid=1001(bar) gid=1001(bar) groups=1001(bar),50(npgroup) [foo@linux ~]$ id jane_doe uid=1002(jane_doe) gid=1002(jane_doe) groups=1002(jane_doe) -- 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
Re: Feature request: module [pam_limits]
On 02/27/2016 04:06 PM, Ralf Mardorf wrote:
> #
> @foo softnproc 20
> @foo hardnproc 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
Re: Feature request: module [pam_limits]
# @foo softnproc 20 @foo hardnproc 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. [foo@linux ~]$ id foo uid=1000(foo) gid=1000(foo) groups=1000(foo) [foo@linux ~]$ id bar uid=1001(bar) gid=1001(bar) groups=1001(bar),1000(foo) [foo@linux ~]$ id jane_doe uid=1002(jane_doe) gid=1002(jane_doe) groups=1002(jane_doe) What would you gain by introducing a negation of being in a group? You only would lose clarity? You could set up a new group, if nobody should be in the group "foo", but the user "foo". # @npgroup softnproc 20 @npgroup hardnproc 50 [foo@linux ~]$ id foo uid=1000(foo) gid=1000(foo) groups=1000(foo),50(npgroup) [foo@linux ~]$ id bar uid=1001(bar) gid=1001(bar) groups=1001(bar),50(npgroup) [foo@linux ~]$ id jane_doe uid=1002(jane_doe) gid=1002(jane_doe) groups=1002(jane_doe) -- 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
Feature request: module [pam_limits]
Lately I've been exploring how to harden an Ubuntu OS against possible external attacks. I am still at the level of basic recipes, but I noticed one tiny thing, that I consider unwieldy... Looking at "limits" for users on a system, I noticed that to configure the pam_limits module |/etc/security/limits.conf|, one can arrange for something as simple as: |#* soft nproc 300 * hard nproc 600 | where the domain wild-card applies to all non-root users. But what happens when one tries to enforce limits to all non-root user but one, say userX (non-root) ? Right now, one might simply write something such as: |#* soft nproc 300 * hard nproc 600 userX - nproc 1500 | ... explicitly adding specific different limits for that specific userX. My *_feature request_* is to introduce a GNU syntax extension to the POSIX syntax, where NEGATING user-id (e.g. !userX or ^userX) or group-id (e.g. !@groupY or ^@groupY) would be a valid domain entry. For instance: |#!userX soft nproc 300| |!userX hard nproc 600 ^@groupY - fsize 450 # File-size limit applies to all groups but groupY | would mean - `nproc` soft and hard limits apply to all non-root users, to the exception of userX - `fsize` soft and hard limits apply to all groups, but groupY In the above case userX's `nproc` limit and groupY's `fsize` limit would be the system's default unless otherwise explicitly defined. The same extended syntax suggestion can apply to ranges of UIDs and GIDs. Hope this gets followed. Cheers, -ced -- 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
