On 10/09/2015 03:22 PM, RIJKEN Jeroen wrote:
> 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.
>
You can list all rules where a target type is unlabeled_t, a class is
packet and perms are recv,send using the following command:
# sesearch -A -t unlabeled_t -c packet -p recv,send
Found 5 semantic av rules:
allow kern_unconfined unlabeled_t : packet { send recv relabelto
flow_in flow_out forward_in forward_out } ;
allow kernel_t unlabeled_t : packet send ;
allow domain unlabeled_t : packet { send recv } ;
allow pki_apache_domain unlabeled_t : packet { send recv } ;
allow haproxy_t unlabeled_t : packet { send recv } ;
There's a rule :
allow domain unlabeled_t : packet { send recv } ;
which allows it for all types assigned to attribute domain. The domain
attribute identifies every type that can be assigned to a process and
you can list all such types using:
# seinfo -adomain -x
domain
abrt_t
abrt_dump_oops_t
...
zoneminder_t
zoneminder_script_t
zos_remote_t
> 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?
>
AFAIK there's no such option in mailman at fedorepoject.org. But the
list could be mirrored elsewhere.
Petr
--
Petr Lautrbach
>
>
> 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
>
--
Petr Lautrbach
SELinux Solutions
Red Hat
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com.
Attachment:
signature.asc
Description: OpenPGP digital signature
-- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
