On 07/17/2015 08:41 AM, Stephen Smalley wrote:
> On 07/17/2015 06:46 AM, Colin Powers wrote:
>> Hi,
>>
>> I have a case where I want to apply a more restrictive policy to the samba daemon, smbd. I am not sure what the best way to approach this problem is, any ideas?
>>
>> My situation is:
>> * I have two network interfaces
>> * I am using iptables to label packets based on the network interface. E.g. all packets on eth0 are eth0_packet_t and all packets on eth1 are eth1_packet_t
>> * I want smbd to be able to interact with only one of the network interfaces
>> * I have a policy module that allows smbd_t to send/recv eth0_packet_t
>> * Problem: if the firewall is off, I would like smbd to be unable to communicate on the network.
>> * However, it seems in default targeted policy smbd can communicate over the network using unlabelled packets, so it can talk to either network interface in this state.
>> * How do I alter things so samba can only communicate on the network using eth0_packet_t - therefore making it impossible for smbd to communicate on the network unless the iptables is labelling packets as eth0_packet_t?
>>
>>
>> Possible ideas:
>> * take ownership of the whole policy rather than build on top of the default RHEL policy, and customise the samba policy that is delivered?
>> * make a copy or symlink of the smbd daemon and apply custom policy to it?
>> * somehow relabel the existing smbd executable with a custom type that can only communicate on eth0_packet_t?
>> * but what's the best way to "override" the default policy? must I unload the samba policy module with semodule to allow smbd to be labelled with some other type?
>> * something else?
>>
>> Potentially it seems like any of those ideas can work but I'm trying to figure out which one is the path of least resistance - i.e. which one causes the smallest maintenance headache e.g. when default targeted policy is updated. Any thoughts/recommendations?
>
> There are two reasons why it can communicate when the iptables SECMARK
> rules are flushed:
> 1. Policy allows it (there is an allow domain unlabeled_t:packet { send
> recv }; rule in the unlabelednet policy module.
>
> 2. The kernel disables the packet permission checks entirely when there
> are no iptables SECMARK rules loaded (this is for both performance and
> compatibility) _unless_ the policy defines the always_check_network
> policy capability (cat
> /sys/fs/selinux/policy_capabilities/always_check_network). The policy
> capabilities are defined in the base policy module.
>
> This assumes that your kernel even supports this policy capability. You
> didn't mention your RHEL version or kernel version.
>
> So to enforce this restriction even when iptables rules are flushed, you
> would need to rebuild both the base module (with a modified
> policy/policy_capabilities file that defines always_check_network), and
> you would need to remove the unlabelednet module. At that point, you
> are basically maintaining your own forked policy and should probably
> install it with a different policy NAME (build.conf) / SELINUXTYPE
> (/etc/selinux/config), and switch your /etc/selinux/config to refer to
> it so that any selinux-policy-targeted updates will not affect your
> system. Then you would need to manually merge updates into your custom
> policy.
>
> A possible alternative would be to use peer labeling (NetLabel or
> labeled IPSEC) configured only for loopback labeling and the net
> egress/ingress permission checks instead of SECMARK. Examples of
> configuring those mechanisms for loopback only labeling can be found in
> the selinux-testsuite (under tests/inet_socket) and in The SELinux
> Notebook. However, those checks are also subject to being disabled if
> the peer labeling configuration (NetLabel or labeled IPSEC) is unloaded
> unless always_check_network is set (but they wouldn't be affected by
> flushing iptables).
Actually, a quick look at the RHEL kernel versions suggests that none of
them is new enough to include the always_check_network policy capability
support. That's unfortunate; maybe it should be submitted as a RFE for
RHEL7.
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
