From: Stephen Smalley <sds@tycho.nsa.gov>
To: "Minear, Spencer" <Spencer_Minear@mcafee.com>,
"SELinux (selinux@tycho.nsa.gov)" <selinux@tycho.nsa.gov>
Subject: Re: What did I do wrong?
Date: Wed, 21 Jan 2015 08:41:42 -0500 [thread overview]
Message-ID: <54BFAC96.1010302@tycho.nsa.gov> (raw)
In-Reply-To: <2cd599239cf54fb0956fa8de9f849c6b@MIVEXUSR1N02.corpzone.internalzone.com>
On 01/20/2015 11:28 PM, Minear, Spencer wrote:
> Wonder if someone could give me a pointer to what my policy file is missing that would result in the /sys/fs/selinux/user API not providing a context when the sshd process context is written to that API? I can see the behavior in a strace capture. I believe that the action is a call from sshd to the security_compute_user entry in libselinux.
>
> On a clean working system with the available default policy sshd writes in the sshd process's context and reads back the context that is ultimately applied to the shell process started by sshd.
>
> Obviously I'm missing something or not including some critical information into the policy but I haven't been able to find any documentation that describes what goes on behind the scenes of this API.
Did the write() to /sys/fs/selinux/user return an error code (if so,
what errno), or a string specifying that there are 0 contexts?
The underlying function first computes the maximal set of possible
contexts based on the user's role authorizations and the role's type
authorizations in the policy. Then it filters that set to only include
contexts for which process transition permission is allowed in policy
from the caller's context (i.e. sshd in this case).
There is some further complication for the MLS field; it prefers the
user's default level from the policy if that falls within the range of
the caller's MLS range. But if the user's default level is not within
that range, it tries to find a level that is both consistent with the
caller's MLS range limitations and the user's authorized range. If it
cannot do so, it will ultimately fail with an error.
This has long been on our todo as something to take to userspace and
simplify.
next prev parent reply other threads:[~2015-01-21 13:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-21 4:28 What did I do wrong? Minear, Spencer
2015-01-21 13:41 ` Stephen Smalley [this message]
2015-01-21 14:18 ` Minear, Spencer
2015-01-21 14:21 ` Stephen Smalley
2015-01-21 14:24 ` Stephen Smalley
2015-01-21 14:43 ` Stephen Smalley
2015-01-21 15:08 ` Minear, Spencer
2015-01-21 15:15 ` Stephen Smalley
2015-01-21 17:38 ` Minear, Spencer
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=54BFAC96.1010302@tycho.nsa.gov \
--to=sds@tycho.nsa.gov \
--cc=Spencer_Minear@mcafee.com \
--cc=selinux@tycho.nsa.gov \
/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.