linux-kernel - Re: System-wide hard RLIMIT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 12 Dec 2017 11:23:47 -0800
From:   Kees Cook <keescook@...omium.org>
To:     Tomáš Trnka <trnka@....com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Stephen Smalley <sds@...ho.nsa.gov>,
        Paul Moore <pmoore@...hat.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Laura Abbott <labbott@...hat.com>
Subject: Re: System-wide hard RLIMIT_STACK in 4.14.4+ w/ SELinux

On Tue, Dec 12, 2017 at 2:58 AM, Tomáš Trnka <trnka@....com> 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

-- 
Kees Cook
Pixel Security