All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christopher J. PeBenito" <cpebenito@tresys.com>
To: "Stephen Smalley" <sds@tycho.nsa.gov>
Cc: "Joshua Brindle" <method@manicmethod.com>,
	"SE Linux" <selinux@tycho.nsa.gov>
Subject: Re: role dominance
Date: Mon, 7 Jan 2008 13:22:48 -0500	[thread overview]
Message-ID: <1199730168.12626.376.camel@gorn> (raw)
In-Reply-To: <1199728427.2944.167.camel@moss-spartans.epoch.ncsc.mil>

On Mon, 2008-01-07 at 12:53 -0500, 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?
> 
> > 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.
> 
> Any language feature that isn't actually being used should probably be
> deprecated.

Last time I tried to use it, the module compiler segfaulted I think.  At
a minimum, I believe it still had ordering issues, making it unusable.
It might see more use if the upcoming experiments on using RBAC for role
separation, rather than derived types, succeeds.  And if it does, the
role attribute might also be useful.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150



--
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.

  reply	other threads:[~2008-01-07 18:22 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 [this message]
2008-01-07 18:28   ` Joshua Brindle
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=1199730168.12626.376.camel@gorn \
    --to=cpebenito@tresys.com \
    --cc=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.