Re: [PATCH] REFPOL: Add "rogue" Fedora packet class permissions

[Paul Moore <paul.moore@hp.com>]

On Friday 18 January 2008 8:32:07 am Christopher J. PeBenito wrote:
> On Thu, 2008-01-17 at 14:33 -0500, Stephen Smalley wrote:
> > The situation is this:
> > - policy shipped in Fedora 6 and later had these flow_in/flow_out
> > permissions defined in their base modules and in their gen_requires.
> > - Paul Moore is adding new permissions to that class in his labeled
> > networking tree that is included in -mm and queued for 2.6.25,
> > - when you try to load those policies into the resulting kernel, the
> > class validation logic rejects the policies,
> > - any policy modules built by any third parties also have these perms
> > defined in their requires and will fail if we remove them from base,
> > - we can't make any changes to the kernel that break existing userspace
> > and policy (which is why handle_unknown is largely useless to us until
> > all legacy distros that predate it are sufficiently dead and gone).
> >
> > This all came up because akpm reported the failure on his FC6 test box
> > with latest -mm.
> >
> > I suggested just using flow_in/flow_out instead of
> > forward_in/forward_out for Paul's new controls so that we don't have any
> > unused permissions, but Paul and Eric want the more precise names.
>
> I strongly agree with Stephen's suggestion.

So, does the "strongly agree" position mean you won't accept the patch adding 
both "flow" and "forward" permissions to the packet class?  I'll reiterate my 
belief that using "flow" instead of "forward" for the new permission checks 
is a mistake which will cause more confusion in the long run than the 
addition of two unused permissions.  However, you hold the key to the policy 
and if changing the permissions to use "flow" is the only way for us to 
enable the new network access controls then I have little choice.

> Do we have a strategy for eventually reclaiming these permissions if we
> don't reuse them right now?

I'm not aware of one, but it is always possible that future work might find a 
use for the packet "flow" permissions.  It's also highly doubtful from where 
I sit now that we'll come even remotely close to hitting the 32 permission 
limit in the packet class.

-- 
paul moore
linux security @ hp

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