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

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

[Paul Moore]

At some point in the Fedora 6 timeframe the "flow_in" and "flow_out"
permissions were added to the "packet" class, most likely as part of the
ill-fated secid-reconciliation effort.  Despite the fact that these permissions
are not currently used they should be included in the Reference Policy as they
are now a permanent fixture in Fedora and it is crucial that the FLASK
defines be kept in sync.

This patch needs to be applied before any other patches that affect the
"packet" class, otherwise the resulting policy may not load.

Signed-off-by: Paul Moore <paul.moore@hp.com>
---
 policy/flask/access_vectors |    2 ++
 1 file changed, 2 insertions(+)

Index: refpolicy_svn_repo/policy/flask/access_vectors
===================================================================
--- refpolicy_svn_repo.orig/policy/flask/access_vectors
+++ refpolicy_svn_repo/policy/flask/access_vectors
@@ -644,6 +644,8 @@ class packet
 	send
 	recv
 	relabelto
+	flow_in		# not currently in use
+	flow_out	# not currently in use
 }
 
 class key

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

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

[Eric Paris]

On 1/17/08, Paul Moore <paul.moore@hp.com> wrote:
> At some point in the Fedora 6 timeframe the "flow_in" and "flow_out"
> permissions were added to the "packet" class, most likely as part of the
> ill-fated secid-reconciliation effort.  Despite the fact that these permissions
> are not currently used they should be included in the Reference Policy as they
> are now a permanent fixture in Fedora and it is crucial that the FLASK
> defines be kept in sync.
>
> This patch needs to be applied before any other patches that affect the
> "packet" class, otherwise the resulting policy may not load.
>
> Signed-off-by: Paul Moore <paul.moore@hp.com>
Acked-by: Eric Paris <eparis@redhat.com>

And sorry about us getting a bit overzelous but as long as these are
in gen_requires statements we can't drop them  :(

-Eric

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

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

[Joshua Brindle]

Paul Moore wrote:
> At some point in the Fedora 6 timeframe the "flow_in" and "flow_out"
> permissions were added to the "packet" class, most likely as part of the
> ill-fated secid-reconciliation effort.  Despite the fact that these permissions
> are not currently used they should be included in the Reference Policy as they
> are now a permanent fixture in Fedora and it is crucial that the FLASK
> defines be kept in sync.
>
> This patch needs to be applied before any other patches that affect the
> "packet" class, otherwise the resulting policy may not load.
>
>   

Hrm, they are last in the class definitions so until new perms are added 
to that class it is fairly irrelevant. The policy upgrade to remove them 
would only require a reboot to get rid of them so adding them to 
upstream refpolicy doesn't seem necessary at all.

This also points out how much of a bad idea it is to add object 
class/perm definitions into distro policies before they are in 
refpolicy, I hope that this will be avoided in the future.

I'm not sure what Chris feels about this but I'm opposed to adding 
definitions to the policy like this.

> Signed-off-by: Paul Moore <paul.moore@hp.com>
> ---
>  policy/flask/access_vectors |    2 ++
>  1 file changed, 2 insertions(+)
>
> Index: refpolicy_svn_repo/policy/flask/access_vectors
> ===================================================================
> --- refpolicy_svn_repo.orig/policy/flask/access_vectors
> +++ refpolicy_svn_repo/policy/flask/access_vectors
> @@ -644,6 +644,8 @@ class packet
>  	send
>  	recv
>  	relabelto
> +	flow_in		# not currently in use
> +	flow_out	# not currently in use
>  }
>  
>  class key
>
>   



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

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

[Paul Moore]

On Thursday 17 January 2008 2:13:07 pm Joshua Brindle wrote:
> Paul Moore wrote:
> > At some point in the Fedora 6 timeframe the "flow_in" and
> > "flow_out" permissions were added to the "packet" class, most
> > likely as part of the ill-fated secid-reconciliation effort. 
> > Despite the fact that these permissions are not currently used they
> > should be included in the Reference Policy as they are now a
> > permanent fixture in Fedora and it is crucial that the FLASK
> > defines be kept in sync.
> >
> > This patch needs to be applied before any other patches that affect
> > the "packet" class, otherwise the resulting policy may not load.
>
> Hrm, they are last in the class definitions so until new perms are
> added to that class it is fairly irrelevant. The policy upgrade to
> remove them would only require a reboot to get rid of them so adding
> them to upstream refpolicy doesn't seem necessary at all.
>
> This also points out how much of a bad idea it is to add object
> class/perm definitions into distro policies before they are in
> refpolicy, I hope that this will be avoided in the future.
>
> I'm not sure what Chris feels about this but I'm opposed to adding
> definitions to the policy like this.

It turns out it's not quite as irrelevant as you think.  The labeled 
networking work targeted for 2.6.25 adds two new permissions to the 
packet class, "forward_in" and "forward_out", (see patch on January 
10th, "Add forwarding permissions to the packet object class") which 
conflict with the existing permissions in Fedora.  Failure to add these 
permissions to the upstream reference policy will result in Fedora 
forever having to patch both the policy and the kernel to get a 
bootable system.  It also makes life much more difficult for people 
experimenting with SELinux on Fedora based systems.

I understand this isn't a patch anyone is going to be excited about (I 
know I'm not) but it is necessary if we hope to move forward.

For clarity, here is what the packet class _should_ look like with both 
the Fedora "flow" permissions and the new "forward" permissions:

	class packet
	{
        	send
	        recv
        	relabelto
	        flow_in         # not currently in use
        	flow_out        # not currently in use
	        forward_in
        	forward_out
	}

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

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

[Stephen Smalley]

On Thu, 2008-01-17 at 14:13 -0500, Joshua Brindle wrote:
> Paul Moore wrote:
> > At some point in the Fedora 6 timeframe the "flow_in" and "flow_out"
> > permissions were added to the "packet" class, most likely as part of the
> > ill-fated secid-reconciliation effort.  Despite the fact that these permissions
> > are not currently used they should be included in the Reference Policy as they
> > are now a permanent fixture in Fedora and it is crucial that the FLASK
> > defines be kept in sync.
> >
> > This patch needs to be applied before any other patches that affect the
> > "packet" class, otherwise the resulting policy may not load.
> >
> >   
> 
> Hrm, they are last in the class definitions so until new perms are added 
> to that class it is fairly irrelevant. The policy upgrade to remove them 
> would only require a reboot to get rid of them so adding them to 
> upstream refpolicy doesn't seem necessary at all.
> 
> This also points out how much of a bad idea it is to add object 
> class/perm definitions into distro policies before they are in 
> refpolicy, I hope that this will be avoided in the future.
> 
> I'm not sure what Chris feels about this but I'm opposed to adding 
> definitions to the policy like this.

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.

-- 
Stephen Smalley
National Security Agency


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

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

[Christopher J. PeBenito]

On Thu, 2008-01-17 at 14:33 -0500, Stephen Smalley wrote:
> On Thu, 2008-01-17 at 14:13 -0500, Joshua Brindle wrote:
> > Paul Moore wrote:
> > > At some point in the Fedora 6 timeframe the "flow_in" and "flow_out"
> > > permissions were added to the "packet" class, most likely as part of the
> > > ill-fated secid-reconciliation effort.  Despite the fact that these permissions
> > > are not currently used they should be included in the Reference Policy as they
> > > are now a permanent fixture in Fedora and it is crucial that the FLASK
> > > defines be kept in sync.
> > >
> > > This patch needs to be applied before any other patches that affect the
> > > "packet" class, otherwise the resulting policy may not load.

> > This also points out how much of a bad idea it is to add object 
> > class/perm definitions into distro policies before they are in 
> > refpolicy, I hope that this will be avoided in the future.

Definitely.

> 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.  Do we have a strategy for
eventually reclaiming these permissions if we don't reuse them right
now?

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

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

[Paul Moore]

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.

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

[Christopher J. PeBenito]

On Fri, 2008-01-18 at 09:11 -0500, Paul Moore wrote:
> 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?

No, if I meant that, I would have said that.

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

I'm not completely unreasonable :) Also that would be an abuse of power.

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

I just don't like these rogue permissions filtering up to upstream.  One
thing that I'm also looking ahead to is that explicit require blocks
will be ignored by policyrep (requirements will be implicit).  So the
hack that I had to add that requires all of the kernel object classes
will also be going away, and only classes/perms actually being used will
be required.

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

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

[Paul Moore]

On Friday 18 January 2008 9:38:50 am Christopher J. PeBenito wrote:
> On Fri, 2008-01-18 at 09:11 -0500, Paul Moore wrote:
> > On Friday 18 January 2008 8:32:07 am Christopher J. PeBenito wrote:
> > > 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?
>
> No, if I meant that, I would have said that.

Okay, just wanted to clarify.

I suppose I'm a little hyper sensitive to problems right now because the merge 
window for 2.6.25 is very close and I don't want there to be any known issues 
with the labeled networking code when the window opens.

> >   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.
>
> I'm not completely unreasonable :) Also that would be an abuse of power.

Yes, you're right - you are a very reasonable guy, despite all the crap Josh 
says about you when you're not around :)  Re-reading the text above I went a 
little crazy there, sorry about that.

> > > 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.
>
> I just don't like these rogue permissions filtering up to upstream.  One
> thing that I'm also looking ahead to is that explicit require blocks
> will be ignored by policyrep (requirements will be implicit).  So the
> hack that I had to add that requires all of the kernel object classes
> will also be going away, and only classes/perms actually being used will
> be required.

This sounds like a good idea, and I definitely owe you one, so if there is 
anything I can do to help (I see that Eric offered to) let me know.

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

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

[Eric Paris]

On 1/18/08, Christopher J. PeBenito <cpebenito@tresys.com> wrote:
> On Thu, 2008-01-17 at 14:33 -0500, Stephen Smalley wrote:
> > On Thu, 2008-01-17 at 14:13 -0500, Joshua Brindle wrote:
> > > Paul Moore wrote:
> > > > At some point in the Fedora 6 timeframe the "flow_in" and "flow_out"
> > > > permissions were added to the "packet" class, most likely as part of the
> > > > ill-fated secid-reconciliation effort.  Despite the fact that these permissions
> > > > are not currently used they should be included in the Reference Policy as they
> > > > are now a permanent fixture in Fedora and it is crucial that the FLASK
> > > > defines be kept in sync.
> > > >
> > > > This patch needs to be applied before any other patches that affect the
> > > > "packet" class, otherwise the resulting policy may not load.
>
> > > This also points out how much of a bad idea it is to add object
> > > class/perm definitions into distro policies before they are in
> > > refpolicy, I hope that this will be avoided in the future.
>
> Definitely.

Dan and I are both well aware of this and I think we can all be
certain it won't happen again.

> > This all came up because akpm reported the failure on his FC6 test box
> > with latest -mm.

failure == kernel panic

> > 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.  Do we have a strategy for
> eventually reclaiming these permissions if we don't reuse them right
> now?

I'm willing to do the kernel work to support NULL names for these
permissions and maybe in 5 years or so we will all feel comfortable
reusing them (basically the same situation we are in for things like
unused classes we carry around for PAX, we can't reclaim it till we
can be sure everything that ever used it is dead).  But labeled net is
convoluted and difficult enough without even the slightest of
misdirection of permission names.  If down the road people search teh
intarwebz on flow_in they are going to get back to all of venkat's old
discussions of 'flow.'  This isn't what we want.

I know it sucks and fedora screwed up on this one getting a little
overzelous trying to stay ahead of the development game but at this
point lets waste that 50 bytes of memory or whatever so down the road
we don't have issues.

-Eric

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

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

[Joshua Brindle]

Eric Paris wrote:
> On 1/18/08, Christopher J. PeBenito <cpebenito@tresys.com> wrote:
>   
>> On Thu, 2008-01-17 at 14:33 -0500, Stephen Smalley wrote:
>>     
>>> On Thu, 2008-01-17 at 14:13 -0500, Joshua Brindle wrote:
>>>       
>>>> Paul Moore wrote:
>>>>         
>>>>> At some point in the Fedora 6 timeframe the "flow_in" and "flow_out"
>>>>> permissions were added to the "packet" class, most likely as part of the
>>>>> ill-fated secid-reconciliation effort.  Despite the fact that these permissions
>>>>> are not currently used they should be included in the Reference Policy as they
>>>>> are now a permanent fixture in Fedora and it is crucial that the FLASK
>>>>> defines be kept in sync.
>>>>>
>>>>> This patch needs to be applied before any other patches that affect the
>>>>> "packet" class, otherwise the resulting policy may not load.
>>>>>           
>>>> This also points out how much of a bad idea it is to add object
>>>> class/perm definitions into distro policies before they are in
>>>> refpolicy, I hope that this will be avoided in the future.
>>>>         
>> Definitely.
>>     
>
> Dan and I are both well aware of this and I think we can all be
> certain it won't happen again.
>
>   

I'm fine with drilling it in just to make sure ;)

>>> This all came up because akpm reported the failure on his FC6 test box
>>> with latest -mm.
>>>       
>
> failure == kernel panic
>
>   
>>> 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.  Do we have a strategy for
>> eventually reclaiming these permissions if we don't reuse them right
>> now?
>>     
>
> I'm willing to do the kernel work to support NULL names for these
> permissions and maybe in 5 years or so we will all feel comfortable
> reusing them (basically the same situation we are in for things like
> unused classes we carry around for PAX, we can't reclaim it till we
> can be sure everything that ever used it is dead).  But labeled net is
> convoluted and difficult enough without even the slightest of
> misdirection of permission names.  If down the road people search teh
> intarwebz on flow_in they are going to get back to all of venkat's old
> discussions of 'flow.'  This isn't what we want.
>
>   

I think we know the Pax object class isn't being used anymore. One thing 
on our long list is to fix up the kernel to request object class and 
perm values similarly to the work done to do that from userspace last 
year. Once that is done we can hopefully do a wholesale cleaning of 
unused values.

> I know it sucks and fedora screwed up on this one getting a little
> overzelous trying to stay ahead of the development game but at this
> point lets waste that 50 bytes of memory or whatever so down the road
> we don't have issues.
>   




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