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
selinux@lists.fedoraproject.org