* System-wide hard RLIMIT_STACK in 4.14.4+ w/ SELinux @ 2017-12-12 10:58 Tomáš Trnka 2017-12-12 15:44 ` Tomáš Trnka 2017-12-12 19:23 ` Kees Cook 0 siblings, 2 replies; 7+ messages in thread From: Tomáš Trnka @ 2017-12-12 10:58 UTC (permalink / raw) To: linux-kernel; +Cc: Kees Cook 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. 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: System-wide hard RLIMIT_STACK in 4.14.4+ w/ SELinux 2017-12-12 10:58 System-wide hard RLIMIT_STACK in 4.14.4+ w/ SELinux Tomáš Trnka @ 2017-12-12 15:44 ` Tomáš Trnka 2017-12-12 19:23 ` Kees Cook 1 sibling, 0 replies; 7+ messages in thread From: Tomáš Trnka @ 2017-12-12 15:44 UTC (permalink / raw) To: linux-kernel; +Cc: Kees Cook > 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). Correction: pam_limits also usually doesn't help here, as it's often followed by another secureexec (for example when login (local_login_t) executes the shell with transition to unconfined_t). 2T ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: System-wide hard RLIMIT_STACK in 4.14.4+ w/ SELinux 2017-12-12 10:58 System-wide hard RLIMIT_STACK in 4.14.4+ w/ SELinux Tomáš Trnka 2017-12-12 15:44 ` Tomáš Trnka @ 2017-12-12 19:23 ` Kees Cook 2017-12-12 19:36 ` Tomáš Trnka 2017-12-12 19:52 ` Laura Abbott 1 sibling, 2 replies; 7+ messages in thread From: Kees Cook @ 2017-12-12 19:23 UTC (permalink / raw) To: Tomáš Trnka Cc: LKML, Stephen Smalley, Paul Moore, Linus Torvalds, Laura Abbott On Tue, Dec 12, 2017 at 2:58 AM, Tomáš Trnka <trnka@scm.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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: System-wide hard RLIMIT_STACK in 4.14.4+ w/ SELinux 2017-12-12 19:23 ` Kees Cook @ 2017-12-12 19:36 ` Tomáš Trnka 2017-12-12 19:52 ` Laura Abbott 1 sibling, 0 replies; 7+ messages in thread From: Tomáš Trnka @ 2017-12-12 19:36 UTC (permalink / raw) To: Kees Cook; +Cc: LKML, Stephen Smalley, Paul Moore, Linus Torvalds, Laura Abbott On Tuesday, 12 December 2017 20:23:47 CET Kees Cook wrote: > 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). Not really. AT_SECURE is set only for the exec that triggers a domain transition, but unlike the rlimits it's not inherited by descendants (as long as they stay within the same SELinux domain). 2T ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: System-wide hard RLIMIT_STACK in 4.14.4+ w/ SELinux 2017-12-12 19:23 ` Kees Cook 2017-12-12 19:36 ` Tomáš Trnka @ 2017-12-12 19:52 ` Laura Abbott 2017-12-12 19:56 ` Kees Cook 1 sibling, 1 reply; 7+ messages in thread From: Laura Abbott @ 2017-12-12 19:52 UTC (permalink / raw) To: Kees Cook, Tomáš Trnka Cc: LKML, Stephen Smalley, Paul Moore, Linus Torvalds On 12/12/2017 11:23 AM, Kees Cook wrote: > On Tue, Dec 12, 2017 at 2:58 AM, Tomáš Trnka <trnka@scm.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. Thanks, Laura ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: System-wide hard RLIMIT_STACK in 4.14.4+ w/ SELinux 2017-12-12 19:52 ` Laura Abbott @ 2017-12-12 19:56 ` Kees Cook 2017-12-12 20:10 ` Laura Abbott 0 siblings, 1 reply; 7+ messages in thread From: Kees Cook @ 2017-12-12 19:56 UTC (permalink / raw) To: Laura Abbott Cc: Tomáš Trnka, LKML, Stephen Smalley, Paul Moore, Linus Torvalds On Tue, Dec 12, 2017 at 11:52 AM, Laura Abbott <labbott@redhat.com> wrote: > On 12/12/2017 11:23 AM, Kees Cook wrote: >> >> On Tue, Dec 12, 2017 at 2:58 AM, Tomáš Trnka <trnka@scm.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 -- Kees Cook Pixel Security ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: System-wide hard RLIMIT_STACK in 4.14.4+ w/ SELinux 2017-12-12 19:56 ` Kees Cook @ 2017-12-12 20:10 ` Laura Abbott 0 siblings, 0 replies; 7+ messages in thread From: Laura Abbott @ 2017-12-12 20:10 UTC (permalink / raw) To: Kees Cook Cc: Tomáš Trnka, LKML, Stephen Smalley, Paul Moore, Linus Torvalds On 12/12/2017 11:56 AM, Kees Cook wrote: > On Tue, Dec 12, 2017 at 11:52 AM, Laura Abbott <labbott@redhat.com> wrote: >> On 12/12/2017 11:23 AM, Kees Cook wrote: >>> >>> On Tue, Dec 12, 2017 at 2:58 AM, Tomáš Trnka <trnka@scm.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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-12-12 20:10 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-12-12 10:58 System-wide hard RLIMIT_STACK in 4.14.4+ w/ SELinux Tomáš Trnka 2017-12-12 15:44 ` Tomáš Trnka 2017-12-12 19:23 ` Kees Cook 2017-12-12 19:36 ` Tomáš Trnka 2017-12-12 19:52 ` Laura Abbott 2017-12-12 19:56 ` Kees Cook 2017-12-12 20:10 ` Laura Abbott
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox