All of lore.kernel.org
 help / color / mirror / Atom feed
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

             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.