public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Piotr Karbowski <slashbeast@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] pam: thoughts on modernizing pam_limits configuration that Gentoo ships with
Date: Mon, 12 Dec 2022 22:55:45 +0100	[thread overview]
Message-ID: <b881d29b-4754-faa6-b50b-de2006b5783a@gentoo.org> (raw)
In-Reply-To: <robbat2-20221212T054126-100190800Z@orbis-terrarum.net>

Hi,

On 12/12/2022 06.52, Robin H. Johnson wrote:
> Please do file a bug tracking this proposal, and reference the
> discussion thread.
> 
> On Sun, Dec 11, 2022 at 09:28:14AM +0100, Piotr Karbowski wrote:
>> What I'd like to do is to bump the limits.conf we ship with pam to
>> following
>>
>>       * hard nproc 16384
>>       * soft nproc 16384
>>       * hard nofile 16384
>>       * soft nofile 16384
>>
>> Those are still reasonable defaults that are much more suitable the
>> modern systems. I can only see benefits in it and am unable to think
>> about the potential drawbacks of bumping *defaults*.
> Drawbacks:
> - The "*" would apply it to all users on a system, not just the
>    interactive ones, and reduce overall security posture.
> - Does this also need a sysctl change for raising fs.file-max?
> 
> With those in mind, how can we deploy these defaults for interactive
> users, while still trying to maintain the good security posture overall?
> 
> - Is using "@users" instead of "*" good enough? (I think yes)
> - Should it be limited to shiny logins on X or should it also take
>    effect via remote logins? (conceptually yes, but I don't see a way to
>    do it today within the scope of only pam_limits**)
> 
> 
> ** The closest other solution I can find is using a distinct limits.conf
> for interactive logins, selected via pam.d trickery, and I don't like
> that proposal.

Since both you and Sam requested bug[1], so be it -- though I still find 
it excessive and I do not remember any other case where discussion about 
change in package were tracked in bug, I just hope it will not branch 
discussion to be in two places, navigating it would be difficult.

Looks like I have some backtracking to do. I pulled off latest stage3 
and seems like the limits.conf there have no entries by default, I do 
however have the nproc limit there on 2 old gentoo systems dating back 
into 2009, perhaps at some point limits.conf have it and I do not 
remember adding it there, so either it could be default at some point in 
time, or I added it and forgot, with the later being more likely. 
Apologies for confusion.

Regardless I'd like to continue the discussion about the new Gentoo's 
defaults.

Which makes the current defaults being inherited from kernel, though pid 
1 to all the children, which are

For the 32bit x86:

     limit    soft     hard
     nproc    64095    64095
     nofile   1024     4096

And for the 64bit x86

     limit    soft     hard
     nproc    256819   256819
     nofile   1024     4096


The fs.file-max does not need any change, on 32bit x86 it's 1636118 and 
on 64bit x86 it's 6574089

What I propose here is to significantly bump the limit of open files per 
user, and limit the number of PIDs per user to 16k. If anything, the 
current defaults allow you to make a DoS by forkbomb, the current 
defaults are neither secure nor make sense in 2022. Linux kernel is full 
of defaults that beg to be updated, among others, vm.swappiness makes 
absolute no sense in its current defaults either.

As for the remote logins, local logins and X sessions -- I see no value 
in having different limits across those.

[1] https://bugs.gentoo.org/885589

-- Piotr.


  reply	other threads:[~2022-12-12 21:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-11  8:28 [gentoo-dev] pam: thoughts on modernizing pam_limits configuration that Gentoo ships with Piotr Karbowski
2022-12-11 12:46 ` Sam James
2022-12-11 15:38   ` Piotr Karbowski
2022-12-12  5:52 ` Robin H. Johnson
2022-12-12 21:55   ` Piotr Karbowski [this message]
2022-12-12 22:06     ` Sam James
2022-12-12 22:26       ` Piotr Karbowski
2022-12-12 22:53         ` Sam James
2022-12-13  3:24         ` John Helmert III
2022-12-13  5:18         ` Joonas Niilola

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b881d29b-4754-faa6-b50b-de2006b5783a@gentoo.org \
    --to=slashbeast@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox