SECMARK unlabeled_t & application access

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

 

I have a question about using SECMARK within iptables and the effect it has on the applications that don’t have a ‘allow DOMAIN unlabeled_t:packet { send recv };’ rule specified.

 

 

In the article that Dan wrote (https://www.linux.com/learn/tutorials/421152-using-selinux-and-iptables-together) the following is written:

 

Currently, by default, we do not label any packets in policy, so the kernel labels these packets as unlabeled_t. Because of this every SELinux domain on the system that uses the network, has the rules:

allow MYDOMAIN unlabed_t:packet { send recv };

(I assume that is a typo and should be unlabeled_t.)

To my understanding, what this means is when I create a policy for a program (for example, an FTP server) and start using SECMARK to label these packets (ftp_packet_t), no other program on the system would be allowed access to this label, since they don’t have such a rule in the policy. Fairly logical.

 

I know that the moment you start labeling, everything will be labeled with unlabeled_t. But that shouldn’t be a problem, should it? Because like Dan wrote, every program should have a rule like the one above. Just to verify this information, I started searching for this rule in a couple of application that make use of the network (SSH, IPSec). Nowhere is the policy (.te) can I find such a rule. There isn’t even a ‘:packet’ rule defined. Have I misinterpreted this segment of the article?

 

In the article written by Sven Vermeulen (http://blog.siphos.be/2015/08/filtering-network-access-per-application/), the following statement was made:

“But be warned: the moment iptables starts with its SECMARK support, all packets will be labeled. Those that are not explicitly labeled through one of the above commands will be labeled with the unlabeled_t type, and most domains are not allowed any access to unlabeled_t.”

 

Also, the SELinux Cookbook stated that “Some domains are allowed to handle the unlabeled_t packets through the corenet_sendrecv_unlabeled_packets interface […]. However if that is not the case, then those domains will not be able to handle network traffic anymore.”

 

This is more in line with what I concluded from my search in the policies, however these two article contradict each other and I would kindly appreciate it if anyone could provide me with some clarification. Are domains allowed access to unlabeled_t packets by default or not? If not and only a select few, which ones (types of applications)? I have tried using sesearch to find this rule, but every time I try the following:

sesearch –A “unlabeled_t:packet { send recv };”

It throws an error saying that is thinks I specified the policy name, which it can’t find. The man page says the policy name should be at the end, however the error doesn’t change.

 

uname –a:

Linux testlapJeroen 3.10.0-299.14.1.el7.x86_64 #1 SMP Tue Sep 15 15:05:51 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

 

 

Second short question, is there a search function for the mailing list archive or do I have to click a link for every month to find some information?

 

 

 

Thanks in advance,

Jeroen

------------------------------------------------------------------------------------------------------------
Disclaimer:

If you are not the intended recipient of this email, please notify the sender and
delete it. 
Any unauthorized copying, disclosure or distribution of this email or its
attachment(s) is forbidden. 
Thales Nederland BV will not accept liability for any damage caused by this email or
its attachment(s). 
Thales Nederland BV is seated in Hengelo and is registered at the Chamber of
Commerce under number 06061578.
------------------------------------------------------------------------------------------------------------
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux

[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux