On Thu, 16 Jan 2025 at 15:12:01 -0700, Sam Hartman wrote:
> I do think it would be good if su and other privilege gates would
> consider using set_all.
If so, that's surely a decision for those privilege gates' PAM stacks,
not PAM in general.
> I think it wouldbe be desirable to see if there's some other pid besides
> pid 1 we could use for looking at default limits. At least on systemd
> systems, pid 1 is a singularly bad choice for looking at limits. I
> wonder if looking at pid 2 if it exists might be a better choice.
In principle there is absolutely nothing special about pid 2. It *might*
be a service that happens to have been started during early boot and
retained default limits, but equally it might be a service that has
set its limits to non-default values, or even an unprivileged process
belonging to an attacker. I can imagine that an attacker could arrange
to obtain pid 2 by exploiting pid reuse, with limits carefully chosen
to help the attacker to carry out some attack.
(On systems with a recent systemd, by default systemd configures the kernel
to let process IDs become large, instead of wrapping around at 32K as they
historically did, and this mitigates attacks based on pid reuse.)
If PAM wants to know the "default default" rlimits that were given to
pid 1 by the kernel, the only way I can think of to achieve that would
be to ask the pid 1 maintainers to make it record those rlimits before
it changes them, and write them into /run or something so that PAM can
retrieve them later.
Even that would not be completely reliable, though: on a typical Debian
system, systemd is not directly run by the kernel. Instead, the kernel
runs the top-level executable or script in the initramfs as pid 1, and
the initramfs init does some setup, mounts the root filesystem, and
eventually pivots into the root filesystem to exec systemd. We can't
assume that the initramfs init didn't change some of its rlimits before
it exec'd systemd.
smcv
