From: "Christopher J. PeBenito" <cpebenito@tresys.com>
To: Stephen Smalley <sds@tycho.nsa.gov>,
SELinux List <selinux@tycho.nsa.gov>
Subject: Re: User range vs. context's range
Date: Thu, 21 Jan 2016 08:14:00 -0500 [thread overview]
Message-ID: <56A0D998.7050409@tresys.com> (raw)
In-Reply-To: <569FFA78.2010302@tycho.nsa.gov>
On 1/20/2016 4:22 PM, Stephen Smalley wrote:
> On 01/20/2016 03:59 PM, Christopher J. PeBenito wrote:
>> What is the intended behavior for a user's allowed range in the policy
>> vs. any labels in the policy (e.g. netifcon)? My expectation is that
>> the allowed range should still apply, but it doesn't seem that
>> checkpolicy checks that, based on what I've seen. For example, the new
>> sediff test policies have this user[1]:
>>
>> user added_user roles system level s1 range s1;
>>
>> and checkpolicy doesn't error on this[2] later in the policy:
>>
>> genfscon added_genfs / added_user:object_r:system:s0
>>
>> I think this should fail compilation since s0 is not in added_user's
>> allowed range.
>
> Not for objects (object_r), same as with role-type relation.
I don't understand the logic for that. For the role-type relation, all
types are implicitly added to object_r, which makes that behavior make
sense, but the user has an explicitly-stated allowed range.
--
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com
next prev parent reply other threads:[~2016-01-21 13:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-20 20:59 User range vs. context's range Christopher J. PeBenito
2016-01-20 21:22 ` Stephen Smalley
2016-01-21 13:14 ` Christopher J. PeBenito [this message]
2016-01-21 21:49 ` Stephen Smalley
2016-01-21 22:05 ` Stephen Smalley
2016-01-22 14:00 ` Christopher J. PeBenito
2016-01-22 14:07 ` Stephen Smalley
2016-01-22 15:48 ` James Carter
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=56A0D998.7050409@tresys.com \
--to=cpebenito@tresys.com \
--cc=sds@tycho.nsa.gov \
--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.