From: Russell Coker <russell@coker.com.au>
To: Joshua Brindle <method@manicmethod.com>
Cc: Paul Nuzzi <pjnuzzi@tycho.ncsc.mil>,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org, jmorris@namei.org,
selinux@tycho.nsa.gov, "George S. Coker,
II" <gscoker@alpha.ncsc.mil>, Eamon Walsh <ewalsh@tycho.nsa.gov>,
Stephen Smalley <sds@tycho.nsa.gov>
Subject: Re: [PATCH] Dynamic port labeling V2
Date: Fri, 4 Dec 2009 11:12:41 +1100 [thread overview]
Message-ID: <200912041112.56570.russell@coker.com.au> (raw)
In-Reply-To: <4B181228.6080600@manicmethod.com>
On Fri, 4 Dec 2009, Joshua Brindle <method@manicmethod.com> wrote:
> Aside from the conversation Dave and Casey are having I still think this
> isn't quite right. First, while you can atomically change a single port
> label with the add command above you can't atomically change multiple
> entries, which I think is completely necessary (you don't want to have
> strange labeling states when changing a set of ports to a new label.
Why is it necessary to change multiple ports at the same time?
We support atomic changes of multiple booleans at the same time due to
possible interactions between them. But I don't think that we have any such
issues with port contexts.
> Also, while having a text parser in the kernel makes it easier to use
> with echo I think it is alot of code in the kernel for no good reason.
> There is no reason not to make a userspace tool that converts the
> textual representation into a serialized struct and feed it to the
> kernel. We typically tell users not to mess around in /selinux anyway,
> since we have a libselinux interface to do that.
It does seem likely that significant code complexity can be avoided by not
having a plain text interface in this case.
--
russell@coker.com.au
http://etbe.coker.com.au/ My Main Blog
http://doc.coker.com.au/ My Documents Blog
next prev parent reply other threads:[~2009-12-04 0:21 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-30 21:27 Paul Nuzzi
2009-12-01 4:52 ` Casey Schaufler
2009-12-01 15:06 ` David P. Quigley
2009-12-01 15:29 ` Paul Nuzzi
2009-12-02 2:38 ` Casey Schaufler
2009-12-03 19:31 ` Joshua Brindle
2009-12-04 0:12 ` Russell Coker [this message]
2009-12-04 14:30 ` Paul Nuzzi
2009-12-04 16:03 ` Joshua Brindle
2009-12-07 17:21 ` Paul Nuzzi
2009-12-18 15:38 ` Joshua Brindle
2009-12-18 5:33 ` Kyle Moffett
2009-12-18 18:46 ` 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=200912041112.56570.russell@coker.com.au \
--to=russell@coker.com.au \
--cc=ewalsh@tycho.nsa.gov \
--cc=gscoker@alpha.ncsc.mil \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=method@manicmethod.com \
--cc=pjnuzzi@tycho.ncsc.mil \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®