Re: secmark integration

["Christopher J. PeBenito" <cpebenito@tresys.com>]

On Thu, 2007-04-05 at 11:48 -0400, Karl MacMillan wrote:
> On Wed, 2007-04-04 at 16:51 -0400, Daniel J Walsh wrote:
> > Karl MacMillan wrote:
> > > On Wed, 2007-04-04 at 17:22 +0000, Christopher J. PeBenito wrote:
> > >> On Mon, 2007-04-02 at 13:15 -0400, Karl MacMillan wrote:
> > >>> I don't think that there are particularly good restrictions that we can
> > >>> do out of the box. I think that we should instead focus on making it
> > >>> fairly easy to do customization with some documentation / recipes that
> > >>> people can follow.
> > >>>       
> > >> I still think the set that refpolicy can generate is fine.  It provides
> > >> the default ports for services on all interfaces.  This is better than
> > >> almost unconfined as it is now.  The incoming connections rules mirror
> > >> the name_bind rules, and the outgoing connections mirrors the
> > >> name_connect rules.  Since UDP doesn't have a connect we can cover that
> > >> reasonably too.  Then we get the connection tracking on all these too.
> > >
> > > The problem is moving from this default to a customized version. How
> > > will a packet type be redefined? Additive rules are fine, but changing
> > > or removing rules is problematic.

These are two separate issues.  My argument was about the quality of the
default rules, not about how well they could be managed.

> > >>> To that end, Chris / Dan, can you comment on my policy example? What I
> > >>> posted doesn't exactly work now and I would like to know what the
> > >>> suggested method for allowing almost all network facing daemons to
> > >>> receive unlabeled_t packets is going to be.
> > >>>       
> > >> Actually, my current idea is to make a tunable for each domain that
> > >> networks.  If we were to go the negation route, it would be something
> > >> like this in corenetwork:
> > >>
> > >> corenet_sendrecv_unlabeled_packets({ networking_domain -confined_networking_domain })
> > >>
> > >> Then corenetwork would provide interfaces to gain these attributes.
> > >>     
> > >
> > > Is this actively being worked on?
> > >
> > > Karl
> > >
> > >   
> > 
> > The other problem here is that it is not so clear what it means to be a 
> > networking domain.
> > 
> 
> Yep.
> 
> > Any application that does dns is a networking domain?  Any app that 
> > resolves a uid?
> > 
> 
> I think it is going to have to be all of these - basically any app that,
> by default, can receive unlabeled packets. BTW, we are going to need the
> interface that grants access to unlabeled packets but has a boolean and
> an interface that unconditionally allows that access (for use during
> customizations).

No, two interfaces aren't going to be needed.  If you go the negation
route, then users will be putting the interface call that gets the
confined_networking_domain attribute in their local.te when they want to
confine it.  If you go with my original idea, then the tunable will be
in the module itself.  The closest thing I can think of to what you're
saying would be to make a template that declares a tunable and then
encases a call to corenet_sendrecv_unlabeled_packets() inside of it,
which would be useful for my idea.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
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.