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-t...) 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(a)lists.fedoraproject.org
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.