From: "Tomáš Trnka" <trnka@scm.com>
To: linux-kernel@vger.kernel.org
Cc: Kees Cook <keescook@chromium.org>
Subject: System-wide hard RLIMIT_STACK in 4.14.4+ w/ SELinux
Date: Tue, 12 Dec 2017 11:58:00 +0100 [thread overview]
Message-ID: <4229475.4Lp8rLWMsd@electra> (raw)
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
next reply other threads:[~2017-12-12 11:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-12 10:58 Tomáš Trnka [this message]
2017-12-12 15:44 ` System-wide hard RLIMIT_STACK in 4.14.4+ w/ SELinux 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4229475.4Lp8rLWMsd@electra \
--to=trnka@scm.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.