Statement precedence/priority (neverallow)

[Mr Dash Four]

>>> There is work in progress for policy language support for
>>> transformations of policy, including the ability to delete rules, but it
>>> is still in the early development stages.
>>>
>>> For what you want to do, there is unfortunately no good mechanism at
>>> present other than creating your own custom policy.
>>>
>>> What you might do though is to wrap the problematic allow rules under
>>> tunable_policy blocks with some new policy boolean, and then you could
>>> enable/disable those rules by setting the boolean.  That might be
>>> acceptable as a patch to the current policy that wouldn't disrupt
>>> current users.
>>>   
>>>       
>> That, frankly, is hair-raising stuff! It means that I would have to edit 
>> every single .te/.if file and encapsulate those blocks, not very nice... 
>> I think I already asked this before, but isn't there another - easier - 
>> way of doing this?
>>     
>
> Not today.  That's why there is ongoing work on extensions to the policy
> language to support such transformations, as well as work on the policy
> infrastructure to support notions of priorities and localization.
>   
OK, I found 'a solution' which is to define a distinct packet type (say 
'type unnamed_packet_t, packet_type, client_packet_t, server_packet_t;') 
and label all traffic which is not already labelled with this new type. 
Any domains in the default policy not already 'caught' by the traffic 
labelling where their traffic is explicitly named and enabled (through 
iptables) will not be allowed access to packets.

I do not like this 'solution' for at least two reasons:

1. It does not fix the initial problem and completely deny access to 
domains who are defined to have access to unlabelled interfaces, nodes 
and packets (for example they can still bind to unlabelled 
nodes/interfaces); and

2. It still allows domains which have been allowed access to the general 
'packet_type' (with or without 'server_packet_t' and/or 
'client_packet_t' attributes set) as the above type (unnamed_t) has 
these attributes as well.

I am open to any better suggestions that might be out there (except for 
going through every single policy file and manually 'wrapping' the 
offensive code with booleans - this, for me, is not a solution at all).