All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joshua Brindle <method@manicmethod.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: SE Linux <selinux@tycho.nsa.gov>
Subject: Re: role dominance
Date: Mon, 07 Jan 2008 13:28:07 -0500	[thread overview]
Message-ID: <47826F37.9030003@manicmethod.com> (raw)
In-Reply-To: <1199728427.2944.167.camel@moss-spartans.epoch.ncsc.mil>

Stephen Smalley wrote:
> On Mon, 2008-01-07 at 10:41 -0500, Joshua Brindle wrote:
>   
>> While working on policyrep we've found that role dominance is pretty 
>> difficult to implement correctly, and apparently there is some ambiguity 
>> about how it works. The main problem we are running into now is that 
>> converting the role bitmaps of an old module (compatibility) back to a 
>> role dominance statement is very difficult.
>>     
>
> And likely unnecessary.  It isn't required that a conversion yield the
> same source representation, but only that it yield the same end result
> when you ultimately generate a kernel binary policy.  Or are you saying
> that you can't even do the latter?
>
>   

The latter is possible.

>> Also it seems like noone has really used role dominance. During 
>> conversations about it here Chris PeBenito suggests that he wants 
>> something like it for refpolicy but a role attribute kind of system may 
>> be much simpler and easier to implement/understand.
>>
>> Thoughts?
>>     
>
> Any language feature that isn't actually being used should probably be
> deprecated.
>   

I vote for deprecation in the current compiler and no implementation in 
policyrep. If we want to add role attribute that would be fine too. 
Chris wants some way to group roles and I never really thought role 
dominance was the right way to do it.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

  parent reply	other threads:[~2008-01-07 18:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-07 15:41 role dominance Joshua Brindle
2008-01-07 17:53 ` Stephen Smalley
2008-01-07 18:22   ` Christopher J. PeBenito
2008-01-07 18:28   ` Joshua Brindle [this message]
2008-01-08 20:48     ` Joshua Brindle
  -- strict thread matches above, loose matches on Subject: below --
2002-11-27 14:48 Stephen D. Smalley
2002-11-27 14:07 Stephen D. Smalley
2002-11-27 14:19 ` Joshua D. Guttman

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=47826F37.9030003@manicmethod.com \
    --to=method@manicmethod.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.