From: Joshua Brindle <method@manicmethod.com>
To: Paul Nuzzi <pjnuzzi@tycho.ncsc.mil>
Cc: 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, 18 Dec 2009 10:38:28 -0500 [thread overview]
Message-ID: <4B2BA1F4.6090709@manicmethod.com> (raw)
In-Reply-To: <1260206511.2630.10.camel@moss-stripedbass.epoch.ncsc.mil>
Paul Nuzzi wrote:
> On Fri, 2009-12-04 at 11:03 -0500, Joshua Brindle wrote:
>> effect at once.
>>
>> I don't know though, I may be overthinking this. Right now isn't ideal,
>> portcons have to be stored in a libsemanage "database" and they get
>> added to the policydb at policy build time. You could generate out a
>> portcon file that sits next to the policy.24 and gets fed in at load
>> time but making modifications to that and keeping them in sync would be
>> a pain, unless libsemanage made the change and regenerated the file (it
>> would be cheaper than rebuilding the entire policy) but that would also
>> mean you'd have to modify libsemanage which I typically don't wish on
>> anyone.
>>
>
> Sounds like your idea would present some a few problems. To implement
> this functionality user-space would have to take out a policy lock in
> the kernel for an indefinite amount of time. That brings up some issues
> on scalability. Typically atomic operations are small and fast. This
> also sounds like a toolchain issue. The proposed functionality can be
> done in the front end of semanage or setportcon.
>
Thanks to Kyle for digging this thread back up.
I understand there are issues (though I disagree with your assertion
above wrt policy lock, you'd just need to fill in an ocontext and take a
lock to switch the pointer IIUC). I don't like this "well, its a
toolchain issue". Sure it is, and the toolchain issue should be solved
before the kernel code goes forward.
Adding something to the kernel and then figuring out how to use it in
userspace later is a recipe for disaster, at best it accidentally works
but at worst the userspace interface is broken and cumbersome or the
kernel part has to be completely rewritten to work the way userspace
needs it to.
Not that you need my ACK but I'd need to see the expected userspace
interface and how it works with the kernel interface to support this.
The expected userspace interface from my perspective would be semanage
since we already have multiple ways of setting portcons and adding
another hurts usability.
next prev parent reply other threads:[~2009-12-18 15:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-30 21:27 [PATCH] Dynamic port labeling V2 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
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 [this message]
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=4B2BA1F4.6090709@manicmethod.com \
--to=method@manicmethod.com \
--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=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