REFPOL: Add "rogue" Fedora packet class permissions

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 <[email protected]>

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 <[email protected]>

---
 policy/flask/access_vectors |    2 ++
 1 file changed, 2 insertions(+)

Index: refpolicy_svn_repo/policy/flask/access_vectors
===================================================================

Quoted 10 lines · 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.

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.

Quoted 11 lines · 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.

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.

Quoted 8 lines · Joshua Brindle

Quoted 7 lines · 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.

Quoted 6 lines

Quoted 2 lines

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.

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.

Quoted 13 lines · Stephen Smalley

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

Quoted 6 lines

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?

Quoted 17 lines · Christopher J. PeBenito

Quoted 16 lines · Stephen Smalley

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.

Quoted 5 lines

Quoted 3 lines

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.

Quoted 2 lines

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.

Quoted 5 lines · Paul Moore

Quoted 1 line · Christopher J. PeBenito

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.

Quoted 6 lines

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.

Quoted 7 lines

Quoted 2 lines

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.

Quoted 9 lines · Stephen Smalley

Quoted 8 lines · Joshua Brindle

Quoted 7 lines · 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.

Quoted 6 lines

Quoted 6 lines

Quoted 2 lines

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.

Quoted 2 lines

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

Quoted 3 lines

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?

Quoted 20 lines · Christopher J. PeBenito

Quoted 18 lines · Stephen Smalley

Quoted 16 lines · Joshua Brindle

Quoted 10 lines · 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.

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.

Quoted 2 lines

Definitely.

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

Quoted 3 lines

Quoted 3 lines

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

failure == kernel panic

Quoted 8 lines

Quoted 4 lines

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.