Re: secmark integration

[Karl MacMillan <kmacmillan@mentalrootkit.com>]

On Fri, 2007-03-30 at 17:47 -0400, Eric Paris wrote:
> On Fri, 2007-03-30 at 16:36 -0400, Karl MacMillan wrote:
> > On Fri, 2007-03-30 at 16:25 -0400, Eric Paris wrote:
> > > On Fri, 2007-03-30 at 15:47 -0400, Karl MacMillan wrote:
> > > > On Mon, 2007-03-19 at 10:57 -0400, James Morris wrote:
> > > > > Following some discussion of secmark integration at the developer summit, 
> > > > > one of the ideas proposed by Joshua (IIRC) was that it would be desirable 
> > > > > to have a separate table for managing the secmark rules.
> > > > > 
> [snip]
> > > > > Is there a consensus, particularly from distro folk, that having a 
> > > > > separate table would be of great benefit ?  I can post a rudimentary patch 
> > > > > soon, if needed.
> > > > > 
> > > > 
> > > > Is this really needed as long as the distro provides a way to customize
> > > > the iptables rules?
> > > 
> > > It's not just that.  The reason a new table was proposed was because
> > > people may want to iptables -F and flush their rules.  If the secmark
> > > stuff is on the main tables (filter and nat) that people use it will get
> > > blown away and there will be no automation of a boolean setting you talk
> > > about later.
> > > 
> > 
> > If we add the custom table won't we need a way to flush that? 
> 
> Sure it would still be flushable, just not how people normally go about
> turning off iptables rules.  Now to flush rules users would
> 
> iptables -F
> iptables -F -t nat
> 
> to get the secmark stuff they would also have to do
> iptables -F -t secmark
> 

That sounds fine to me, but James mentioned that the upstream acceptance
might be hard. So how do we experiment in the short term? Just don't
worry about rules getting flushed?


<snip>

> 
> 4) Find some guy who works in userspace and get him to write a tool that
> will allow you to fill in some blanks and it will create the policy,
> iptables labeling rule, and boolean settings for you.

I don't think this is a good idea for the initial rollout of secmark.
Again, the whole idea is to use the power of iptables for labeling. If
you hide that behind higher-level abstractions I think that people will
just be frustrated because they won't be able to accomplish what they
want.

Writing iptables rules is *not* the problem for acceptance. Just having
a clear way to use secmark is enough initially.
After that, we can get a good idea of what types of things people want
out of secmark and can put some tools on top.

<snip>

> 
> Maybe at some point we can ship labeling rules by default (and i don't
> know if these belong with the other 'normal' firewall rules as opposed
> to a seperate init script which just sets the secmark rules) which match
> little other than we already match in the name_{bind,connect} checks and
> can eliminate the boolean step.

Why would we? The name_* checks are effective at what they do and are
easily managed by semanage. I would rather push secmark towards things
that are currently hard to enforce (like separating traffic from two
nics).

>   But for now it seems that making it so
> that a user won't accidentally shoot themselves in the foot and products
> like 'webmin' can't hurt anything would be a good step....

Not certain that I agree. Let's make it usable for knowledgeable
sysadmins first and then try to wrap higher-level tools around this. If
it solves peoples problems they will use it with or without a gui.

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.