From: Paul Moore <paul.moore@hp.com>
To: Stephen Smalley <sds@tycho.nsa.gov>,
Joshua Brindle <method@manicmethod.com>
Cc: James Morris <jmorris@namei.org>, selinux@tycho.nsa.gov
Subject: Re: [RFC PATCH 0/2] Series short description
Date: Wed, 26 Sep 2007 12:00:09 -0400 [thread overview]
Message-ID: <200709261200.09547.paul.moore@hp.com> (raw)
In-Reply-To: <1190813392.15779.58.camel@moss-spartans.epoch.ncsc.mil>
On Wednesday 26 September 2007 9:29:52 am Stephen Smalley wrote:
> On Tue, 2007-09-25 at 23:12 -0400, Paul Moore wrote:
> > On Tuesday 25 September 2007 10:19:50 pm Joshua Brindle wrote:
> > > A while back someone (I can't remember if it was me or not) suggested a
> > > bitmap of policy capabilities that would be determined at compile time
> > > (eg., does this policy have conditional expressions? turn that bit on.
> > > Does this policy use class foo? turn that bit on, etc). Why is your
> > > version scheme better than something like that?
> >
> > Well, like I said earlier, forget the versioning scheme I proposed.
> > However, for the sake or argument one advantage that I can see to a
> > version number or a capability bitmap (it would most likely need to be an
> > ebitmap to allow for future growth) is that it is much easier/quicker to
> > check in the security server. Comparing two integers is much faster then
> > checking for a single bit in an ebitmap.
> >
> > That said, I agree that your idea of a policy capability bitmap is
> > interesting and would allow a lot of flexibility. I'm just not sure the
> > implementation would be practical, but then again, you have much more
> > experience in the policy compiler/toolchain than I do.
>
> I think we'd need a separate content/feature version or bitmap from the
> format version.
>
> The bitmap seems better if we want to support independent selection of
> subsets. The version seems better if we want to incrementally build
> upon each new feature and always require the prior ones to exist or to
> be obsoleted by the new one.
Okay, it looks like its probably at least worth investigating the bitmap
concept with some RFC patches.
Josh, since you brought up the idea and you have a better grasp of the
toolchain, can I talk/bribe/make-you-an-offer-you-can't-refuse into working
up some patches for the toolchain if I come up with the matching kernel
piece?
--
paul moore
linux security @ hp
--
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.
next prev parent reply other threads:[~2007-09-26 16:00 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-25 20:48 [RFC PATCH 0/2] Series short description Paul Moore
2007-09-25 20:48 ` [RFC PATCH 1/2] [SELINUX] Add a functionality version number Paul Moore
2007-09-25 21:12 ` Eric Paris
2007-09-25 21:16 ` Paul Moore
2007-09-25 20:48 ` [RFC PATCH 2/2] [SELINUX] Better integration between peer labeling subsystems Paul Moore
2007-09-25 21:37 ` Eric Paris
2007-09-25 22:01 ` Paul Moore
2007-09-25 22:38 ` James Morris
2007-09-25 22:48 ` Paul Moore
2007-09-26 12:41 ` Stephen Smalley
2007-09-26 15:46 ` Paul Moore
2007-09-26 16:18 ` Paul Moore
2007-09-25 22:28 ` [RFC PATCH 0/2] Series short description James Morris
2007-09-25 22:38 ` Paul Moore
2007-09-26 2:19 ` Joshua Brindle
2007-09-26 3:12 ` Paul Moore
2007-09-26 13:18 ` Joshua Brindle
2007-09-26 13:29 ` Stephen Smalley
2007-09-26 16:00 ` Paul Moore [this message]
2007-09-26 16:43 ` Joshua Brindle
2007-09-26 16:48 ` Stephen Smalley
2007-09-26 16:54 ` Paul Moore
2007-09-26 16:57 ` Joshua Brindle
2007-09-26 17:04 ` Paul Moore
2007-09-26 20:39 ` Joshua Brindle
2007-09-26 20:46 ` Paul Moore
2007-09-26 20:36 ` Joshua Brindle
2007-09-26 20:32 ` 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=200709261200.09547.paul.moore@hp.com \
--to=paul.moore@hp.com \
--cc=jmorris@namei.org \
--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.