From: Karl MacMillan <kmacmillan@mentalrootkit.com>
To: jwcart2@tycho.nsa.gov
Cc: SELinux <selinux@tycho.nsa.gov>, Steve Smalley <sds@epoch.ncsc.mil>
Subject: Re: Are the reference policy abstractions the right ones?
Date: Wed, 10 Oct 2007 11:09:59 -0400 [thread overview]
Message-ID: <1192028999.2898.19.camel@localhost.localdomain> (raw)
In-Reply-To: <1191942521.2794.89.camel@moss-lions.epoch.ncsc.mil>
On Tue, 2007-10-09 at 11:08 -0400, James Carter wrote:
> I would like to start a discussion on whether reference policy is
> providing the right abstractions for writing policy.
>
> This is not intended to be an attack on Chris or Dan, or their work. I
> think that it is obvious that reference policy is much better organized,
> far more useful, and works way better than the old example policy. We
> don't want to go back to example policy.
>
> One of the goals of reference policy is to provide a more modern feel to
> the policy by eliminating the use of types in a global manner across the
> whole policy. It does this by allowing interfaces to be defined through
> which permissions can be granted to the types of a module. There seems
> to be several problems with this.
>
Let me ask a different question. Both the old example policy and the
reference policy accomplish the same basic thing: comprehensive
least-privilege. The challenge with this approach is that the policy is
closely tied to applications and brittle in the face of application
changes.
So - are there other useful approaches that we could take? Some modified
form of integrity policies like BIBA? Perhaps just for portions of the
policy - things like hal/udev that are basically in the TCB but need to
be protected from applications.
Seems like a long-shot, but I thought I would ask.
Karl
--
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-10-10 15:09 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-09 15:08 Are the reference policy abstractions the right ones? James Carter
2007-10-09 17:10 ` Karl MacMillan
2007-10-09 18:54 ` James Carter
2007-10-09 19:07 ` Karl MacMillan
2007-10-09 19:44 ` James Carter
2007-10-09 20:00 ` Karl MacMillan
2007-10-10 15:23 ` Karl MacMillan
2007-10-10 15:47 ` Joshua Brindle
2007-10-10 16:52 ` James Carter
2007-10-10 20:39 ` Karl MacMillan
2007-10-11 17:00 ` Karl MacMillan
2007-10-11 17:32 ` James Carter
2007-10-12 16:45 ` Chad Sellers
2007-10-12 19:53 ` James Carter
2007-10-12 19:59 ` Karl MacMillan
2007-10-12 20:48 ` Chad Sellers
2007-10-15 2:50 ` James Morris
2007-10-15 3:45 ` Joe Nall
2007-10-15 4:06 ` James Morris
2007-10-15 14:30 ` David P. Quigley
2007-10-15 18:55 ` Karl MacMillan
2007-10-15 21:15 ` James Morris
2007-10-15 22:23 ` Karl MacMillan
2007-10-11 23:30 ` Daniel J Walsh
2007-10-09 17:34 ` Joshua Brindle
2007-10-09 18:18 ` Christopher J. PeBenito
2007-10-10 15:09 ` Karl MacMillan [this message]
2007-10-10 16:25 ` Casey Schaufler
2007-10-10 18:26 ` Paul Moore
2007-10-11 7:18 ` Frank L. Mayer
2007-10-11 20:26 ` James Carter
2007-10-12 16:45 ` Chad Sellers
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=1192028999.2898.19.camel@localhost.localdomain \
--to=kmacmillan@mentalrootkit.com \
--cc=jwcart2@tycho.nsa.gov \
--cc=sds@epoch.ncsc.mil \
--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.