adding port restrictions to policy generated by sepolgen

[Mr Dash Four]

> Sounds good, could you get this upstreamed.
I could (it is one gigantic patch, dynamically generated - using bash 
script - depending on the policy source version as I use 3 different 
ones), but it is system specific and I very much doubt that it would 
work on machines which have "generic" configurations. For starters, I 
have redefined 98% of the "standard" ports used in corenetwork.te.in, 
redefined the two packet and port types as I stated in my previous post, 
and then patched *only* the policies (.te, .if files in particular) I 
use for the machine(s) on which this policy is deployed.

By doing this, I avoid the general port and packet definitions (and 
allowing access to these ports "by default") which exist in all other 
modules and use/define only those I *specifically* use on the target 
machines. It is a very simple principle, driven by the lack of 
flexibility in the current SELinux policies with regards to network 
support (nodes, interfaces, ports and packet types).

One customary look in a .te file will tell you that access to *any* 
(general) node is most likely granted, access to *any* general network 
interface is also most-likely granted and the chances are, that there 
would be one statement or another in the net policy section which grants 
access to a port, or variety of ports, to which the given policy file 
may not be needed, hence why I redefine these for my specific 
configuration - saves a lot of headaches. Currently, there is no other 
way for me to do this!

It would have been better if the SELinux policies were more flexible and 
in addition to grant/deny access to particular ports *I use*, I could 
also remove all the unnecessary modules from the policy (better 
performance, better memory footprint) without nasty side effects, but it 
is not to be and I have to revert to such gimmicks like the above in 
order to do what I want in the end.

>   My only problem would be
> with unconfined_domains, since I am not crazy about confining
> something we say is unconfined.  Secondly you might want to allow
> processes to connect to port 2222 on  a different machine but not at
> localhost.
>   
That is where the "local" (or any other) nd_type comes in (the 
"standard" node_type for you and me - oh yes, I redefined that as well) 
- I alter only the policies to which a given set of processes/domains 
need access and leave out the rest as they have no knowledge/access 
granted "by default" to the new node, port or packet definitions, so 
there is no danger of me granting something I shouldn't.

> Yes I have changed some of this handling in Fedora but not upstreamed
>   
Yeah, it needed to - it was a nasty shock when I first looked at it.