Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752338AbdLLUKk (ORCPT ); Tue, 12 Dec 2017 15:10:40 -0500 Received: from mail-oi0-f48.google.com ([209.85.218.48]:35875 "EHLO mail-oi0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751554AbdLLUKj (ORCPT ); Tue, 12 Dec 2017 15:10:39 -0500 X-Google-Smtp-Source: ACJfBoveaMH+c47SFo0QXKZFznEHvYXkEEXhNk6/GR+S/axDsMEj+/IuOSrUER8fmZrv8W1YkezZZA== Subject: Re: System-wide hard RLIMIT_STACK in 4.14.4+ w/ SELinux To: Kees Cook Cc: =?UTF-8?B?VG9tw6HFoSBUcm5rYQ==?= , LKML , Stephen Smalley , Paul Moore , Linus Torvalds References: <4229475.4Lp8rLWMsd@electra> From: Laura Abbott Message-ID: Date: Tue, 12 Dec 2017 12:10:35 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2984 Lines: 85 On 12/12/2017 11:56 AM, Kees Cook wrote: > On Tue, Dec 12, 2017 at 11:52 AM, Laura Abbott wrote: >> On 12/12/2017 11:23 AM, Kees Cook wrote: >>> >>> On Tue, Dec 12, 2017 at 2:58 AM, Tomáš Trnka 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