From: Joshua Brindle <method@manicmethod.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Todd Miller <Tmiller@tresys.com>, Paul Moore <paul.moore@hp.com>,
selinux@tycho.nsa.gov, Daniel J Walsh <dwalsh@redhat.com>,
"Christopher J. PeBenito" <cpebenito@tresys.com>,
Karl MacMillan <kmacmillan@mentalrootkit.com>
Subject: Re: [patch 0/2] policy capability support
Date: Thu, 06 Dec 2007 16:23:24 -0500 [thread overview]
Message-ID: <4758684C.9040409@manicmethod.com> (raw)
In-Reply-To: <1196964486.27508.107.camel@moss-spartans.epoch.ncsc.mil>
Stephen Smalley wrote:
> On Thu, 2007-12-06 at 11:44 -0500, Joshua Brindle wrote:
>
>> Stephen Smalley wrote:
>>
>>> Overall, I have to wonder if we are really buying anything via
>>> per-module capability declaration vs. per-policy. The only reason you
>>> tried to make it per-module was you were trying to drop distinctions
>>> between base and non-base, right? But maybe we shouldn't be so
>>> concerned with having a notion of a base module even if we reduce the
>>> differences between what is supported by base vs. non-base
>>>
>> At first that was my reason but after talking it seems like doing it in
>> base is bad for the same reason that allowing a single module to turn on
>> a cap is. Why should base be able to turn on the cap if all the other
>> modules aren't written wrt the cap?
>>
>
> Upgrade of base usually reflects a full policy update, whereas inserting
> a random module does not. And if base doesn't work (e.g. doesn't have
> the capabilities it requires), then the system likely won't boot or
> function at all (modulo legacy rules). I'm more comfortable with
> letting base dictate the policy capabilities than other modules.
>
>
I am not comfortable with base changing anything about other modules. If
base can turn on capabilities without regard to the modules being
installed then everything built as modules that uses network controls
(or whatever future caps affect) suddenly don't work. I also don't want
to just punt on this decision for now because we don't know the answer,
we'll have to answer it eventually if we successfully get rid of the
base vs. module distinction.
--
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-12-06 21:23 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-05 18:48 [patch 0/2] policy capability support tmiller
2007-12-05 18:48 ` [patch 1/2] library " tmiller
2007-12-05 18:48 ` [patch 2/2] checkpolicy " tmiller
2007-12-05 19:21 ` [patch 0/2] policy " Paul Moore
2007-12-05 19:30 ` Todd Miller
2007-12-05 19:41 ` Stephen Smalley
2007-12-05 20:16 ` Joshua Brindle
2007-12-05 20:34 ` Stephen Smalley
2007-12-05 20:35 ` Joshua Brindle
2007-12-05 20:50 ` Stephen Smalley
2007-12-05 20:56 ` Joshua Brindle
2007-12-06 15:21 ` Stephen Smalley
2007-12-06 16:44 ` Joshua Brindle
2007-12-06 18:08 ` Stephen Smalley
2007-12-06 20:24 ` Todd Miller
2007-12-06 21:24 ` Stephen Smalley
2007-12-06 21:23 ` Joshua Brindle [this message]
2007-12-06 21:42 ` Stephen Smalley
2007-12-07 14:47 ` Joshua Brindle
2007-12-07 16:26 ` Stephen Smalley
2007-12-07 21:17 ` Daniel J Walsh
2007-12-07 21:30 ` Joshua Brindle
2007-12-07 21:35 ` Stephen Smalley
2007-12-08 11:53 ` Daniel J Walsh
2007-12-05 21:41 ` Todd Miller
2007-12-06 15:44 ` Christopher J. PeBenito
2007-12-06 16:48 ` Stephen Smalley
2007-12-06 18:34 ` Christopher J. PeBenito
2007-12-06 20:02 ` Stephen Smalley
2007-12-06 20:09 ` Stephen Smalley
2007-12-06 18:50 ` Paul Moore
-- strict thread matches above, loose matches on Subject: below --
2007-12-06 21:38 tmiller
2008-01-08 17:05 ` Paul Moore
2008-01-08 19:01 ` Stephen Smalley
2008-01-08 19:07 ` Paul Moore
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=4758684C.9040409@manicmethod.com \
--to=method@manicmethod.com \
--cc=Tmiller@tresys.com \
--cc=cpebenito@tresys.com \
--cc=dwalsh@redhat.com \
--cc=kmacmillan@mentalrootkit.com \
--cc=paul.moore@hp.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.