I have not been able to get the shorewall service to start when in restricted mode. I can't find anything at all in any of the logs (including audit logs) that would give me any clue as to why. Works fine in permissive mode. Pardon my ignorance, but how do you find what is causing the problems in this type of situation? I'm a little lost in how I should go about diagnosing the problem when the system is so tightly locked down and the logs aren't useful. By design, it's very hard to poke around in these hardened systems. Reproducible: Always
Created attachment 326352 [details] emerge info
One thought is that perhaps this has something to do with permissions to network devices? I've set up 2 nics on this virtual machine, and I've noticed that when in permissive mode, iptables gives a 0 packet count for the eth1 interface, even though I'm connected via ssh on eth1. Perhaps shorewall/iptables is able to filter traffic from eth0, but not eth1? Just a guess, not sure how to verify it...
It's weird that nothing shows up in the logs... Can you try disabling the dontaudits? ~# semodule -DB You'll find a lot more denials in the logs then, most of them are cosmetic (hence why there were "dontaudit"ed) but perhaps one of them is the cause. Also, check the dmesg output - perhaps a context is wrong, which won't be seen in the denial logs but in dmesg should show up as an SELinux error.
Well, that did reveal quite a few more avc messages. Non of them seem directly related to shorewall, although it may be a parent dependency having conflicts that prevents it from starting. Some of these are probably related to cgroups and nginx, which are also having problems. (cgroups I reported earlier, but this avc.log seems to give me something to work with) Also, the /var/log/shorewall-init.log doesn't even get touched, so shorewall never even gets started. I'm including the section of the avc.log from a bootup in restricted mode. Thanks all the help Sven. Of all the hardened/selinux related issues I've filed the last few weeks, you're the only person directly investigating these bugs. One thing to note, when I read your lates blog post, the section about starting to support XATTR-based PaX flags caught my attention. I had configured the kernel to use XATTR-based PaX flags rather than the elf-header based flags. Is that something that would cause problems that I need to worry about?
Created attachment 326638 [details] avc logs
Indeed, not a single mention of shorewall in them. Can you clear your logs (so we don't get any "old" denials), then try to start the shorewall service, and then give me both the denials in the logs as well as the output on the screen when starting shorewall? Something like so: """ ~# > /var/log/avc.log ~# ls -lZ /etc/init.d/shorewall ~# rc-service shorewall start """ Then tell me the output of the commands as well as the content of the avc.log file then.
I wouldn't worry about PaX, it is almost never the cause of applications failing if you are also struggling with SELinux ;-) If you do suspect paX, you should notice PaX-related failures in your dmesg output.
No output to avc.log :( terminal output: rc-service: Permission denied $ id -Z root:sysadm_r:sysadm_t $ ls -lZ /etc/init.d/shorewall -rwxr-xr-x. 1 root root system_u:object_r:shorewall_initrc_exec_t 1927 Oct 13 03:48 /etc/init.d/shorewall One odd thing to note: it deosn't ask me to authenticate root like it does when starting other services. I'm working through some of the other avc errors and creating se-modules. If changes anything for shorewall, I'll let you know.
Worked though the last of the avc errors. No more of them are being generated. Shorewall still fails. On the positive side of things, cgroups now mount correctly in restricted mode. :) I'll add a note to that bug.
I can't reproduce this, although I did have to add in a few other rules in order to get shorewall working: """ can_exec(sysadm_t, shorewall_exec_t) # needed to setup route filtering # (write access to /proc/sys/net/ipv4/conf/*/rp_filter) allow shorewall_t self:capability sys_admin; # Cannot flush routing cache allow ifconfig_t self:capability sys_admin; """ it also makes sense to add in a shorewall_admin(sysadm_r, sysadm_t) as well. The system doesn't ask for a password because the file is labeled shorewall_initrc_exec_t instead of initrc_exec_t, allowing for the security administrator limited access to the shorewall configuration (& administraton) without granting users the sysadm_r role.
Sorry, it's shorewall_admin(sysadm_t, sysadm_r). Also, the fact that rc-service gives a permission denied is probably because the SELinux user you use does not have the rights to "go into" system_r role. To do so, for the "root" SELinux user, do something like: ~# semanage user -m -R "staff_r sysadm_r system_r" root
Hmmm. Not sure what I'm doing wrong here... (I had already created the ifconfig_t rule earlier) === module shorewallsysadm 1.0; require { type sysadm_t; type shorewall_exec_t; type shorewall_t; role sysadm_r; class capability sys_admin; } can_exec(sysadm_t, shorewall_exec_t) shorewall_admin(sysadm_t, sysadm_r) allow shorewall_t self:capability sys_admin; === That is not compiling for me shorewallsysadm.te":14:ERROR 'unknown class file' at token ';' on line 977: allow sysadm_t shorewall_exec_t:file { { getattr open read execute ioctl } ioctl lock execute_no_trans }; /usr/bin/checkmodule: error(s) encountered while parsing configuration
Ok, my mind does not function correctly that late at night. I added the missing classes to the rule, but it just keeps expanding to want more and more classes / permissions to the point that it's getting pretty crazy. Perhaps you meant to add those rules to an existing sec-module?
I got rid of: shorewall_admin(sysadm_t, sysadm_r) and it was much more sane.
(In reply to comment #11) > > To do so, for the "root" SELinux user, do something like: > > ~# semanage user -m -R "staff_r sysadm_r system_r" root I forgot to mention that if I add system_r to root, then when I try to do newrole -r system_r I get: "Couldn't get default type." If I then add the default type, then I get: "root:system_r:system_t is not a valid context" Not sure where I make that a valid context though. I tried adding some stuff to /etc/selinux/strict/contexts/default_contexts but couldn't make it work.
There's no reason to "newrole -r system_r". The role transition occurs automatically the moment that the shorewall init script is launched. Also, never directly edit files in /etc/selinux/strict or /etc/selinux/targeted (or whatever policy you have); your changes are bound to be overwritten the moment you trigger a policy rebuild, use semanage to manipulate settings or other activities. When you run as, say, root:sysadm_r:sysadm_t and invoke the shorewall init script (shorewall_initrc_exec_t) then there should be an automated role (and domain) transition towards root:system_r:initrc_t. But this requires the shorewall_admin() interface to be assigned. If not, then the default run_init integration within our init scripts will try to be invoked, which will most likely fail, as run_init_t doesn't hold any rights towards shorewall_initrc_exec_t (only initrc_exec_t).
Ok, the mentioned rules (can_exec, shorewall_admin and sys_admin for ifconfig) are scheduled to be included in the next policy release. can_exec & shorewall_admin are already in (see live policy builds), the ifconfig sys_admin one is still pending (upstream acceptance)
I was not yet aware of the "live policy builds". Very nice.
In hardened-dev, r6 release
Sorry for the lack of response, I've been very busy over the past week. I'm up to date with latest from portage and the hardened-development overlay. So I've had time to actually dig around today and may have found some useful info. By starting shorewall manually with tracing enabled I found the the permission denial is happening when trying to run the shellscript /usr/share/shorewall/getparams The context for that file looked wrong: getfilecon /usr/share/shorewall/getparams > getparams system_u:object_r:user_t So after a restorecon it and several other scripts were changed to bin_t. Not sure why they were user_t to begin with. So with that corrected, the next problem I'm running into is ipsets. Shorewall doesn't think ipsets is enabled in the kernel, so something is not working with the ipsets tool itself. In permissive mode I can get a listing of the ipsets using the ipset tool. But when in restricted mode, I get: ipset -L > ipset v6.13: Cannot open session to kernel. I'm not quite yet what I need to do to fix that problem. (I'll file a separate bug for that.) With the shorewall rule removed that references an ipset, I can now start shorewall manually, however the init script is still failing. But at least now the message is about it failing to start rather than permission denied.
In main tree, ~arch'ed
r8 is now stable
