Re: System-wide hard RLIMIT_STACK in 4.14.4+ w/ SELinux

[Laura Abbott]

On 12/12/2017 11:56 AM, Kees Cook wrote:
> On Tue, Dec 12, 2017 at 11:52 AM, Laura Abbott <labbott@xxxxxxxxxx> wrote:
> > On 12/12/2017 11:23 AM, Kees Cook wrote:
> > > On Tue, Dec 12, 2017 at 2:58 AM, TomÃÅ Trnka <trnka@xxxxxxx> wrote:
> > > > Hello,
> > > >
> > > > Commit 04e35f4495dd560db30c25efca4eecae8ec8c375 "exec: avoid RLIMIT_STACK
> > > > races with prlimit()" that made it into 4.14.4 effectively changes the
> > > > default
> > > > hard RLIMIT_STACK on machines with SELinux (seen on Fedora 27).
> > > >
> > > > selinux_bprm_set_creds() sets bprm->secureexec for any SELinux domain
> > > > transition that does not have the "noatsecure" permission. The secureexec
> > > > logic thus kicks in for virtually every process launched by PID 1 systemd
> > > > (init_t), including gettys, display managers, etc.
> > >
> > >
> > > Uuugh. Okay, we need to revert that commit. I'll send a patch for 4.15
> > > (with a fix for -stable too).
> > >
> > > I will design an alternative, which was considered much earlier:
> > > keeping a copy of the rlimits in the bprm during exec so it can't
> > > change out from under the execing process. This will avoid needing to
> > > set the hard limit, avoid the locking race that commit was trying to
> > > fix, etc.
> > >
> > > This is an interesting state for the system to be in, though, it means
> > > AT_SECURE is being set for virtually all processes too? I would expect
> > > that might break a lot too (but clearly it hasn't).
> > >
> > > > I can see that 8 MiB "should be enough for everyone" using normal
> > > > software,
> > > > but sadly the HPC stuff around here tends to need a little more (due to a
> > > > deficiency in gfortran).
> > > >
> > > > Minimal example (the actual types are not too important):
> > > >
> > > > # /bin/ulimit -Hs
> > > > unlimited
> > > > # runcon -r system_r -t sysadm_t runcon -t rpm_script_t /bin/ulimit -Hs
> > > > 8192
> > > >
> > > > Of course this can be somewhat worked around by adjusting the SELinux
> > > > policy
> > > > (allowing blanket noatsecure permission for init_t and possibly others)
> > > > or by
> > > > pam_limits (for components using PAM). Unfortunately, systemd's
> > > > LimitSTACK= is
> > > > also broken (calls setrlimit before exec). Anyway, I wasn't expecting any
> > > > of
> > > > that in connection with the 4.14.3->.4 upgrade.
> > > >
> > > > --
> > > > Best regards,
> > > >
> > > > TomÃÅ Trnka
> > > > Software for Chemistry & Materials
> > >
> > >
> > > Thanks for the report and examples!
> > >
> > > -Kees
> >
> > FWIW, the issue I reported offline yesterday
> > https://bugzilla.redhat.com/show_bug.cgi?id=1524083 still happens with
> > selinux disabled. The conclusion there is still that trafficserver
> > needs to be fixed.
>
> I've sent a revert regardless. I think the bprm needs to hold a copy
> of the rlimits so they can't be manipulated during exec. This will
> keep the hardlimit from being messed with, etc.
>
> -Kees

Understood. I just wanted to clarify that the issues were separate
since there was still some question about where the secureexec
was coming from.

Thanks,
Laura