SECMARK type containment strategy

[Philip Seeley]

Hi all,

We're looking to add additional packet type containment when running MLS
(currently selinux-policy-mls-3.7.19-231.el6_5.3) using SECMARK.

For the standard daemons I've looked to see if there are appropriate types
that we can reuse. For example for SSH there is the ssh_server_packet_t
type, so the following iptables rule would suffice:

iptables -t mangle -A INPUT -p tcp --dport 22  -j SECMARK --selctx
system_u:object_r: ssh_server_packet_t

So I checked what domain types could send and recv this type:

[root@build7 ~]# sesearch -A -t ssh_server_packet_t
Found 7 semantic av rules:
   allow vmware_host_t server_packet_type : packet { send recv } ;
   allow corenet_unconfined_type packet_type : packet { send recv relabelto
flow_in flow_out forward_in forward_out } ;
   allow sshd_t ssh_server_packet_t : packet { send recv } ;
   allow iptables_t packet_type : packet relabelto ;
   allow kernel_t packet_type : packet send ;
   allow squid_t packet_type : packet { send recv } ;
   allow git_session_t server_packet_type : packet { send recv } ;

I wasn't expecting the git and squid entries and to a lesser degree the
vmware domain. These seem to stem from the following direct rules:

[root@build7 ~]# sesearch -A -d -t server_packet_type
Found 2 semantic av rules:
   allow vmware_host_t server_packet_type : packet { send recv } ;
   allow git_session_t server_packet_type : packet { send recv } ;

[root@build7 ~]# sesearch -A -d -t packet_type
Found 4 semantic av rules:
   allow corenet_unconfined_type packet_type : packet { send recv relabelto
flow_in flow_out forward_in forward_out } ;
   allow iptables_t packet_type : packet relabelto ;
   allow kernel_t packet_type : packet send ;
   allow squid_t packet_type : packet { send recv } ;

So my 2 questions are:

1) Is the approach of reusing the existing *_server_packet_t types in
SECMARK rules a good one?
2) Are there good reasons for the git and squid entries?

Thanks

Phil