From: Stephen Smalley <sds@tycho.nsa.gov>
To: Srivatsa Vaddagiri <vatsa.ml@gmail.com>, selinux@vger.kernel.org
Subject: Re: Changing selinux enforcing mode at runtime
Date: Mon, 9 Sep 2019 16:05:37 -0400 [thread overview]
Message-ID: <45562434-a8bc-ba91-2eee-7407dab4a97f@tycho.nsa.gov> (raw)
In-Reply-To: <CAMHO8so3mL4hOLd12gg=DZQz7=1auXQET6dVip+r=9GGPjec+Q@mail.gmail.com>
On 9/9/19 1:16 PM, Srivatsa Vaddagiri wrote:
> Hello,
> I wanted to know the behavior when selinux enforcing mode is
> changed at runtime via security_setenforce() API. Lets say we boot
> with selinux in permissive mode and after bootup we change it to
> enforcing mode. My question is related to the tasks that were created
> before we enabled enforcing mode. Would their subsequent file
> operations fail once selinux is set to enforcing mode (even though the
> policy may have been set to allow their access to say a file)?
No, they would not fail if the operation is allowed by the policy. In
fact, this scenario is typical; commonly, the init process e.g. systemd
performs the initial policy load and switches to enforcing mode.
Further, you can fully boot a Linux distro e.g. Fedora in permissive
mode and then switch to enforcing mode, and nothing should fail unless
denied by policy.
The more complicated scenario is tasks created before initial policy
load, because those may not be assigned the correct security context. To
avoid this, the init process is typically responsible for loading policy
initially and then either re-exec'ing itself or dynamically switching
its own security context to the right value before proceeding.
next prev parent reply other threads:[~2019-09-09 20:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-09 17:16 Changing selinux enforcing mode at runtime Srivatsa Vaddagiri
2019-09-09 20:05 ` Stephen Smalley [this message]
2019-09-10 11:04 ` Srivatsa Vaddagiri
2019-09-10 12:37 ` Stephen Smalley
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=45562434-a8bc-ba91-2eee-7407dab4a97f@tycho.nsa.gov \
--to=sds@tycho.nsa.gov \
--cc=selinux@vger.kernel.org \
--cc=vatsa.ml@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).