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-tog…) 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.
------------------------------------------------------------------------------------------------------------
Subgit (www.subgit.com) is a system for reflecting Subversion
repository changes to a Git mirror or vice versa. In the former case,
it uses a pre-commit script to spawn a Java daemon that monitors and
mirrors the updates.
When run in enforcing mode, the daemon fails to start and the commit
fails when the spawn attempt times out. No error appears in the audit
log.
When run in permissive mode, the spawn succeeds d the commit works. The
program that is supposed to spawn the daemon has context
system_u:object_r:httpd_sys_script_exec_t:s0
The directory where the PID file is supposed to write its lock file is
The error reported by Subgit on failure is:
Failed to launch background translation process: timeout waiting
for pid file '/var/www/svn/FlopC++/subgit/daemon.pid
(FlopC++ is the repository name).
What policy change do I need to implement to make this work in
enforcing mode? Or how can I debug the process and what information
should I bring to the list for help?
Thanks in advance.
--
Matthew Saltzman
Clemson University Math Sciences
mjs AT clemson DOT edu
