Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752550AbdLLT5B (ORCPT ); Tue, 12 Dec 2017 14:57:01 -0500 Received: from mail-ua0-f172.google.com ([209.85.217.172]:38211 "EHLO mail-ua0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752263AbdLLT47 (ORCPT ); Tue, 12 Dec 2017 14:56:59 -0500 X-Google-Smtp-Source: ACJfBosV43bk43ZEf8xnkSBopkITxzVb68QDOLZ85Tvqsg20a3zbKyAf9ZZnFyud+JIO+gzR4WwHljwHf6Zzh38FS2c= MIME-Version: 1.0 In-Reply-To: References: <4229475.4Lp8rLWMsd@electra> From: Kees Cook Date: Tue, 12 Dec 2017 11:56:57 -0800 X-Google-Sender-Auth: op_8q4R9XmYN8iXxuFlm-h8q4-c Message-ID: Subject: Re: System-wide hard RLIMIT_STACK in 4.14.4+ w/ SELinux To: Laura Abbott Cc: =?UTF-8?B?VG9tw6HFoSBUcm5rYQ==?= , LKML , Stephen Smalley , Paul Moore , Linus Torvalds Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id vBCJv7jC017779 Content-Length: 2724 Lines: 80 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 -- Kees Cook Pixel Security