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] [day] [month] [year] [list]

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

On 12/12/2017 11:56 AM, Kees Cook wrote:
> On Tue, Dec 12, 2017 at 11:52 AM, Laura Abbott <labbott@...hat.com> wrote:
>> On 12/12/2017 11:23 AM, Kees Cook wrote:
>>>
>>> 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
>>>
>>
>> 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