Problems combining these 2 to run while SELinux is in 'enforced' mode (policy running is the 'stock' targeted one supplied with FC13). I get 2 audit alerts when Shorewall starts (and fails!) - see logs below. I have x86_64 arch machine with FC13 running. Stock Shorewall is installed. IPSet (xtunnels) is compiled in (though with the 'stock' rpm I am getting the same errors).
The problem seems to be caused by the Shorewall init script (see further below). The relevant part of my syslog when SELinux is in enforced mode is:
=========SELinux=Enforcing================================ Jun 26 23:18:38 dev1 shorewall[2456]: Compiling... Jun 26 23:18:38 dev1 kernel: type=1400 audit(1277590718.634:29543): avc: denied { create } for pid=2577 comm="ipset" scontext=unconfined_u:system_r:shorewall_t:s0 tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket Jun 26 23:18:38 dev1 kernel: type=1400 audit(1277590718.637:29544): avc: denied { create } for pid=2579 comm="ipset" scontext=unconfined_u:system_r:shorewall_t:s0 tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket Jun 26 23:18:38 dev1 shorewall[2456]: Compiling /etc/shorewall/zones... Jun 26 23:18:38 dev1 shorewall[2456]: Compiling /etc/shorewall/interfaces... Jun 26 23:18:38 dev1 shorewall[2456]: Determining Hosts in Zones... Jun 26 23:18:38 dev1 shorewall[2456]: Preprocessing Action Files... Jun 26 23:18:38 dev1 shorewall[2456]: Pre-processing /usr/share/shorewall/action.Drop... Jun 26 23:18:38 dev1 shorewall[2456]: Pre-processing /usr/share/shorewall/action.Reject... Jun 26 23:18:38 dev1 shorewall[2456]: Compiling /etc/shorewall/policy... Jun 26 23:18:38 dev1 shorewall[2456]: Compiling /etc/shorewall/blacklist... Jun 26 23:18:38 dev1 shorewall[2456]: ERROR: ipset names in Shorewall configuration files require Ipset Match in your kernel and iptables : /etc/shorewall/blacklist (line 11) Jun 26 23:18:38 dev1 shorewall[2456]: ERROR: Shorewall start failed ==========================================================
When I switch SELinux to Permissive I get two further errors:
=========SELinux=Permissive=============================== Jun 26 23:32:45 dev1 kernel: type=1400 audit(1277591565.629:29551): avc: denied { create } for pid=3799 comm="ipset" scontext=unconfined_u:system_r:shorewall_t:s0 tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket Jun 26 23:32:45 dev1 kernel: type=1400 audit(1277591565.629:29552): avc: denied { getopt } for pid=3799 comm="ipset" lport=255 scontext=unconfined_u:system_r:shorewall_t:s0 tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket Jun 26 23:32:45 dev1 kernel: type=1400 audit(1277591565.629:29553): avc: denied { setopt } for pid=3799 comm="ipset" lport=255 scontext=unconfined_u:system_r:shorewall_t:s0 tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket Jun 26 23:32:45 dev1 shorewall[3678]: Compiling /etc/shorewall/zones... Jun 26 23:32:45 dev1 shorewall[3678]: Compiling /etc/shorewall/interfaces... Jun 26 23:32:45 dev1 shorewall[3678]: Determining Hosts in Zones... Jun 26 23:32:45 dev1 shorewall[3678]: Preprocessing Action Files... Jun 26 23:32:45 dev1 shorewall[3678]: Pre-processing /usr/share/shorewall/action.Drop... Jun 26 23:32:45 dev1 shorewall[3678]: Pre-processing /usr/share/shorewall/action.Reject... Jun 26 23:32:45 dev1 shorewall[3678]: Compiling /etc/shorewall/policy... Jun 26 23:32:45 dev1 shorewall[3678]: Compiling /etc/shorewall/blacklist... Jun 26 23:32:45 dev1 shorewall[3678]: Adding Anti-smurf Rules Jun 26 23:32:45 dev1 shorewall[3678]: Compiling TCP Flags filtering... Jun 26 23:32:45 dev1 shorewall[3678]: Compiling Kernel Route Filtering... Jun 26 23:32:45 dev1 shorewall[3678]: Compiling Martian Logging... Jun 26 23:32:45 dev1 shorewall[3678]: Compiling MAC Filtration -- Phase 1... Jun 26 23:32:45 dev1 shorewall[3678]: Compiling /etc/shorewall/rules... Jun 26 23:32:45 dev1 shorewall[3678]: Generating Transitive Closure of Used-action List... Jun 26 23:32:45 dev1 shorewall[3678]: Processing /usr/share/shorewall/action.Reject for chain Reject... Jun 26 23:32:45 dev1 shorewall[3678]: Processing /usr/share/shorewall/action.Drop for chain Drop... Jun 26 23:32:45 dev1 shorewall[3678]: Compiling MAC Filtration -- Phase 2... Jun 26 23:32:45 dev1 shorewall[3678]: Applying Policies... Jun 26 23:32:45 dev1 shorewall[3678]: Generating Rule Matrix... Jun 26 23:32:45 dev1 shorewall[3678]: Creating iptables-restore input... Jun 26 23:32:45 dev1 shorewall[3678]: Compiling iptables-restore input for chains blacklst mangle:... Jun 26 23:32:45 dev1 shorewall[3678]: Shorewall configuration compiled to /var/lib/shorewall/.start Jun 26 23:32:45 dev1 shorewall[3678]: Starting Shorewall.... Jun 26 23:32:45 dev1 shorewall[3678]: Initializing... Jun 26 23:32:46 dev1 kernel: u32 classifier Jun 26 23:32:46 dev1 kernel: Performance counters on Jun 26 23:32:46 dev1 kernel: input device check on Jun 26 23:32:46 dev1 kernel: Actions configured Jun 26 23:32:46 dev1 shorewall[3678]: Processing /etc/shorewall/init ... Jun 26 23:32:46 dev1 shorewall[3678]: loading /etc/shorewall/ips/blacklist-x1.ips Jun 26 23:32:46 dev1 shorewall[3678]: loading /etc/shorewall/ips/blacklist-x2.ips Jun 26 23:32:46 dev1 shorewall[3678]: loading /etc/shorewall/ips/blacklist-z1.ips Jun 26 23:32:47 dev1 shorewall[3678]: loading /etc/shorewall/ips/blacklist-z2.ips Jun 26 23:32:49 dev1 shorewall[3678]: Processing /etc/shorewall/tcclear ... Jun 26 23:32:49 dev1 shorewall[3678]: Setting up Route Filtering... Jun 26 23:32:49 dev1 shorewall[3678]: Setting up Martian Logging... Jun 26 23:32:49 dev1 shorewall[3678]: Setting up Proxy ARP... Jun 26 23:32:49 dev1 shorewall[3678]: Setting up Traffic Control... Jun 26 23:32:49 dev1 shorewall[3678]: Preparing iptables-restore input... Jun 26 23:32:49 dev1 shorewall[3678]: Running /sbin/iptables-restore... Jun 26 23:32:49 dev1 shorewall[3678]: IPv4 Forwarding Enabled Jun 26 23:32:49 dev1 shorewall[3678]: Processing /etc/shorewall/start ... Jun 26 23:32:49 dev1 shorewall[3678]: Processing /etc/shorewall/started ... Jun 26 23:32:49 dev1 shorewall[3678]: Shorewall started ==========================================================
The problem seems to be caused by the shorewall init script, which is:
===========Shorewall init script========================== modprobe ifb numifbs=1 ip link set dev ifb0 up
# configure the ipsets sw_ips_mask='/etc/shorewall/ips/*.ips' ipset_exec='/usr/sbin/ipset' if [ "$COMMAND" = start ]; then $ipset_exec -F $ipset_exec -X for c in `/bin/ls $sw_ips_mask 2>/dev/null`; do echo loading $c $ipset_exec -R < $c done fi ==========================================================
The above script executes /usr/sbin/ipset to create my IP Sets needed for running Shorewall (all IP set commands are contained in those *.ips files). These IP sets comprise mainly of IP subnets which are part of my blacklists (banned IP subnets), though they also contain some IP Port sets as well.
Don't know why SELinux denies "create" (and then "getopt" and "setopt") on a, what seems to be, raw ip socket (IPSet do not use/need one as far as I know!)? If I remove the IP Set part of the init script above and rearrange Shorewall to run without IPSets all is well, though its functionality is VERY limited and barely useful to me!
Two questions to the SELinux gurus on here: 1) Why am I getting these alerts? and 2) How can I fix the problem so that I could run both Shorewall and IPSets with SELinux in Enforced mode?
This is important for me as this is a production server and a lot of stuff runs on it and needs to be available 24/7.
Many thanks in advance!
On 06/27/2010 02:37 PM, Mr Dash Four wrote:
Two questions to the SELinux gurus on here: 1) Why am I getting these alerts? and 2) How can I fix the problem so that I could run both Shorewall and IPSets with SELinux in Enforced mode?
1) probably untested functionality.
2) The following should fix it:
mkdir ~/myshorewall; cd ~/myshorewall; echo "policy_module(myshorewall, 1.0.0)" > myshorewall.te; echo "optional_policy(`" >> myshorewall.te; echo "gen_require(`" >> myshorewall.te; echo "type shorewall_t;" >> myshorewall.te; echo "')" >> myshorewall.te; echo "allow shorewall_t self:rawip_socket create_socket_perms;" >> myshorewall.te; echo "')" >> myshorewall.te;
make -f /usr/share/selinux/devel/Makefile myshorewall.pp sudo semodule -i myshorewall.pp
This is important for me as this is a production server and a lot of stuff runs on it and needs to be available 24/7.
Many thanks in advance!
selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Two questions to the SELinux gurus on here: 1) Why am I getting these alerts? and 2) How can I fix the problem so that I could run both Shorewall and IPSets with SELinux in Enforced mode?
probably untested functionality.
The following should fix it:
Job done! It works now, though it was NOT a straight-forward job!
make -f /usr/share/selinux/devel/Makefile myshorewall.pp
After executing this even though it all compiled OK I had an error at the beginning telling me that /selinux/mls does not exist. That was caused by SELinux being disabled (I did that as I was fed up with all the alerts I was getting). I reinstated SELinux in Permissive mode, re-labelled everything and then compiled this again - no error this time. The above command created a lot of additional files though: .fc, .if, as well as all_interfaces.conf, iferror.m4, .mod.role and .tmp files (the last 4 files were placed in ~/myshorewall/tmp for some reason) - do I need these files or should I delete them and just keep the .pp file?
sudo semodule -i myshorewall.pp
When I did that the module was installed, I rebooted, but this time I started getting alerts popping all over the place from a lot of processes running (alerts I did NOT have before). So, what I did then was to do a relabelling again at reboot, but that did not work - still alerts (not from shorewall though).
From experience (I had this happening before, so I know) - what I did then was to uninstall the targeted policy package via yum (made sure I disabled SELinux first!) AND did 'rm -rdf /etc/selinux/targeted' as there were leftovers in that directory (don't know why, but the majority of the stuff was there even though the policy is supposed to be removed - may be this is an issue for the FC RPM admins/maintainers, I don't know), rebooted, installed selinux-targeted-policy package again, did "semodule -i myshorewall.pp", enabled SELinux (in Permissive mode first) and finally did a relabelling at boot again.
Result - no alerts of any kind!
I am now in Enforced mode and everything is going OK so far, so many thanks for the (very prompt) advice - much appreciated.
I have two more queries though - if I want to use this module (the .pp file) on a system which is built from a ks file (using standard kickstart tools) do I just copy myshorewall.pp to /etc/selinux/targeted/modules/active/modules on the target system in order to use this module? Would that be enough?
I also need to mention that the target system's root ('/') is 'read-only' in a sense that even though the content in it can be changed it does NOT survive the boot (it is done as a unionfs of a ram disk and the read-only system where all the files and programs are, so changes get preserved in the ram part for the life of the session, but are gone the next time the machine is rebooted) - this is done for extra security and saved my neck on quite a few occasions!
Second query in relation to this - when I build the system can I do the relabelling on the target system at the time when the image is built? If so, how do I do that (ideally I would like to do that during the image building process, in the %post section perhaps, of the .ks script)?
The reason for that is, as I put it above, the changes made once the image is built are not preserved, and I do not want to be relabelling on every reboot as it is too damn slow!
Thanks again!
On 06/27/2010 06:40 PM, Mr Dash Four wrote:
do I need these files or should I delete them and just keep the .pp file?
You do not really need to contents of ~/myshorewall after youve built/installed the binary presentation (myshorewall.pp)
However it is a good idea to save the myshorewall.{te,if,fc} source policy files, as you may want to extend it or just keep it for reference. It may also be useful for your collegues.
sudo semodule -i myshorewall.pp
When I did that the module was installed, I rebooted, but this time I started getting alerts popping all over the place from a lot of processes running (alerts I did NOT have before). So, what I did then was to do a relabelling again at reboot, but that did not work - still alerts (not from shorewall though).
Never, ever disable SELinux. (atleast that is my opinion). You can also configure SELinux to run in permissive mode. Which is basically a interusion detection system as opposed to intrusing prevention system (selinux in enforcing mode).
By using permissive mode, labeling should not mess up.
From experience (I had this happening before, so I know) - what I did then was to uninstall the targeted policy package via yum (made sure I disabled SELinux first!) AND did 'rm -rdf /etc/selinux/targeted' as there were leftovers in that directory (don't know why, but the majority of the stuff was there even though the policy is supposed to be removed
- may be this is an issue for the FC RPM admins/maintainers, I don't
know), rebooted, installed selinux-targeted-policy package again, did "semodule -i myshorewall.pp", enabled SELinux (in Permissive mode first) and finally did a relabelling at boot again.
Result - no alerts of any kind!
I am now in Enforced mode and everything is going OK so far, so many thanks for the (very prompt) advice - much appreciated.
Yes in some cases de-installation of selinux-policy(-targeted), moving /etc/selinux/targeted, and re-installation of selinux-policy(-targeted) is the only way to fix some corruption. Always make sure to relabel afterwards and also do not forget that local changes will be gone (another good reason to keep the sources of your custom modules)
I have two more queries though - if I want to use this module (the .pp file) on a system which is built from a ks file (using standard kickstart tools) do I just copy myshorewall.pp to /etc/selinux/targeted/modules/active/modules on the target system in order to use this module? Would that be enough?
No i do not think it will be enough (you would need sudo semodule -i myshorewall.pp). But you should report your shorewall issue to bugzilla so that it can be applied to the next selinux-policy package. This will then make your customization no longer needed.
I also need to mention that the target system's root ('/') is 'read-only' in a sense that even though the content in it can be changed it does NOT survive the boot (it is done as a unionfs of a ram disk and the read-only system where all the files and programs are, so changes get preserved in the ram part for the life of the session, but are gone the next time the machine is rebooted) - this is done for extra security and saved my neck on quite a few occasions!
Second query in relation to this - when I build the system can I do the relabelling on the target system at the time when the image is built? If so, how do I do that (ideally I would like to do that during the image building process, in the %post section perhaps, of the .ks script)?
The reason for that is, as I put it above, the changes made once the image is built are not preserved, and I do not want to be relabelling on every reboot as it is too damn slow!
You may (or may not) be able to edit dracut to relabel the filesystem on each bootup (e.g.) generate an initramfs with the relabeling command.
Not exactly sure how to go about that but. you may be able to add it to this file: /usr/share/dracut/modules.d/99base/selinux-loadpolicy.sh and then regenerate initrc (make sure the filesystem is mounted in the chroot at the point of relabeling though) /usr/libexec/plymouth/plymouth-update-initrd (unconfirmed)
Thanks again!
selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
I have two more queries though - if I want to use this module (the .pp file) on a system which is built from a ks file (using standard kickstart tools) do I just copy myshorewall.pp to /etc/selinux/targeted/modules/active/modules on the target system in order to use this module? Would that be enough?
No i do not think it will be enough (you would need sudo semodule -i myshorewall.pp).
See my previous response - I need to know whether I can use semodule on a Linux system, which isn't running yet.
But you should report your shorewall issue to bugzilla so that it can be applied to the next selinux-policy package. This will then make your customization no longer needed.
It is not that simple because xtables is an (unofficial) addon, which has not yet been added to the ip(6)tables packages (though there are plans to do that) and as of now it is distributed separately (nothing to do with shorewall - it just uses it, as it does ip(6)tables). So, I am hoping that ipset would become part of ip(6)tables and then, may be I can remove my custom policy.
[relabelling]
You may (or may not) be able to edit dracut to relabel the filesystem on each bootup (e.g.) generate an initramfs with the relabeling command.
Not exactly sure how to go about that but. you may be able to add it to this file: /usr/share/dracut/modules.d/99base/selinux-loadpolicy.sh and then regenerate initrc (make sure the filesystem is mounted in the chroot at the point of relabeling though) /usr/libexec/plymouth/plymouth-update-initrd (unconfirmed)
OK, the whole reason I would like to do the relabelling is because I am not sure that when the image is built and installed on the target machine (with SELinux enforced!) I am not going to get lots of alerts clogging my logs and preventing the system from operating just because of labelling not done properly. As I am building this image from scratch using kickstart tools, I do not know if I do not relabel the system I won't get any alerts. I just want to be prepared for the worst case scenario, that's all. If I do not get any alerts on the target system after building and deploying the image, then all is well and this relabelling business won't be needed - ever (as I already pointed out - the target system will be read-only)!
Also, by placing '.relabel' (I think that was the file name) in the root ('/') directory this forces SELinux to relabel the whole system at startup. As I mentioned before, if I need to do relabelling I would like to do it when the image is built! I do not want to do that at every boot (doing the relabelling when the target system boots would be a pointless exercise as the changes won't be saved, so the next time I reboot I will be at square 1 and the whole process will start again).
How is the relabelling done? Which program is used for that? If I start that program from chroot-ed environment (from the %post section of my kickstart file - see my previous reply) to relabel the whole image, would that work?
On 06/27/2010 06:40 PM, Mr Dash Four wrote:
I have two more queries though - if I want to use this module (the .pp file) on a system which is built from a ks file (using standard kickstart tools) do I just copy myshorewall.pp to /etc/selinux/targeted/modules/active/modules on the target system in order to use this module? Would that be enough?
You cannot simply copy it (need to install it (semodule -i). But you can use a single binary presentation on most selinux enabled system (e.g. deploy the single myshorewall.pp to various similar configured systems.)
all the modules in active/ are compiled into a policy database file policy/policy.X.
If you just copy it to active it is not compiled into the actual policy database yet.
I also need to mention that the target system's root ('/') is 'read-only' in a sense that even though the content in it can be changed it does NOT survive the boot (it is done as a unionfs of a ram disk and the read-only system where all the files and programs are, so changes get preserved in the ram part for the life of the session, but are gone the next time the machine is rebooted) - this is done for extra security and saved my neck on quite a few occasions!
Second query in relation to this - when I build the system can I do the relabelling on the target system at the time when the image is built? If so, how do I do that (ideally I would like to do that during the image building process, in the %post section perhaps, of the .ks script)?
The reason for that is, as I put it above, the changes made once the image is built are not preserved, and I do not want to be relabelling on every reboot as it is too damn slow!
Thanks again!
selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On 06/27/2010 06:40 PM, Mr Dash Four wrote:
I have two more queries though - if I want to use this module (the .pp file) on a system which is built from a ks file (using standard kickstart tools) do I just copy myshorewall.pp to /etc/selinux/targeted/modules/active/modules on the target system in order to use this module? Would that be enough?
You cannot simply copy it (need to install it (semodule -i). But you can use a single binary presentation on most selinux enabled system (e.g. deploy the single myshorewall.pp to various similar configured systems.)
Does that mean if the policy is compiled on i686-based machine it can then run/be deployed on a x86_64 and visa versa?
Also, does semodule need to have a running SELinux as I need to deploy this module on a Linux system (image) which does NOT have SELinux running (yet)?
In other words, if I issue this command in chroot-ed environment would that be enough? The "%post" section of the kickstart file does just that - it chroots to the image as it has been built and from there I can do whatever I like on the actual image, though this is not a running system - i.e. SELinux on that system is not loaded! If that is possible and if I run on different architectures (say the image is for x86_64 and the machine on which the image is built is i686) would it matter?
On 06/27/2010 08:04 PM, Mr Dash Four wrote:
On 06/27/2010 06:40 PM, Mr Dash Four wrote:
I have two more queries though - if I want to use this module (the .pp file) on a system which is built from a ks file (using standard kickstart tools) do I just copy myshorewall.pp to /etc/selinux/targeted/modules/active/modules on the target system in order to use this module? Would that be enough?
You cannot simply copy it (need to install it (semodule -i). But you can use a single binary presentation on most selinux enabled system (e.g. deploy the single myshorewall.pp to various similar configured systems.)
Does that mean if the policy is compiled on i686-based machine it can then run/be deployed on a x86_64 and visa versa?
Yes policy is arch-independent.
Also, does semodule need to have a running SELinux as I need to deploy this module on a Linux system (image) which does NOT have SELinux running (yet)?
Not sure, try it out.
In other words, if I issue this command in chroot-ed environment would that be enough? The "%post" section of the kickstart file does just that
- it chroots to the image as it has been built and from there I can do
whatever I like on the actual image, though this is not a running system
- i.e. SELinux on that system is not loaded! If that is possible and if
I run on different architectures (say the image is for x86_64 and the machine on which the image is built is i686) would it matter?
The policy is arch-independent but i am not sure if it can be installed on a system that has no selinux enabled. I think it is possible but i am not sure.
You will still have the issue that you would have to relabel the filesystem on each boot though.
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Also, does semodule need to have a running SELinux as I need to deploy this module on a Linux system (image) which does NOT have SELinux running (yet)?
Not sure, try it out.
I will, though I have a gut feeling that it won't work as semodule may be looking for a running SELinux database and I presume it picks up policy (and files) from the running system. Will give it a try though!
In other words, if I issue this command in chroot-ed environment would that be enough? The "%post" section of the kickstart file does just that
- it chroots to the image as it has been built and from there I can do
whatever I like on the actual image, though this is not a running system
- i.e. SELinux on that system is not loaded! If that is possible and if
I run on different architectures (say the image is for x86_64 and the machine on which the image is built is i686) would it matter?
The policy is arch-independent but i am not sure if it can be installed on a system that has no selinux enabled. I think it is possible but i am not sure.
I'll give it a go!
You will still have the issue that you would have to relabel the filesystem on each boot though.
Is that a necessary thing to do after installing a new module? My understanding is that relabelling only corrects the SELinux file attributes on every file on the system, so why would I need to do the relabelling when I have just installed a new policy?
Also, if my assumption is correct then why would I need to have a running SELinux to do that? It is a great inconvenience and a real pain for scenarios I described in my previous posts!
On 06/27/2010 08:37 PM, Mr Dash Four wrote:
Also, does semodule need to have a running SELinux as I need to deploy this module on a Linux system (image) which does NOT have SELinux running (yet)?
Not sure, try it out.
I will, though I have a gut feeling that it won't work as semodule may be looking for a running SELinux database and I presume it picks up policy (and files) from the running system. Will give it a try though!
In other words, if I issue this command in chroot-ed environment would that be enough? The "%post" section of the kickstart file does just that
- it chroots to the image as it has been built and from there I can do
whatever I like on the actual image, though this is not a running system
- i.e. SELinux on that system is not loaded! If that is possible and if
I run on different architectures (say the image is for x86_64 and the machine on which the image is built is i686) would it matter?
The policy is arch-independent but i am not sure if it can be installed on a system that has no selinux enabled. I think it is possible but i am not sure.
I'll give it a go!
You will still have the issue that you would have to relabel the filesystem on each boot though.
Is that a necessary thing to do after installing a new module? My understanding is that relabelling only corrects the SELinux file attributes on every file on the system, so why would I need to do the relabelling when I have just installed a new policy?
Also, if my assumption is correct then why would I need to have a running SELinux to do that? It is a great inconvenience and a real pain for scenarios I described in my previous posts!
Good points. i think you might indeed be able to run restorecon or fixfiles/setfiles in %post, but i am not sure.
I would suggest you try it.
Otherwise wait a day when the professionals can reply to your query.
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Is that a necessary thing to do after installing a new module? My understanding is that relabelling only corrects the SELinux file attributes on every file on the system, so why would I need to do the relabelling when I have just installed a new policy?
Also, if my assumption is correct then why would I need to have a running SELinux to do that? It is a great inconvenience and a real pain for scenarios I described in my previous posts!
Good points. i think you might indeed be able to run restorecon or fixfiles/setfiles in %post, but i am not sure.
I would suggest you try it.
I definitely will, though I am encouraged that I may not need to do the relabelling after all as I have just ran freshly built image with SELinux=Enforced and without shorewall/ipset installed (so that they don't create unnecessary problems) through qemu and it ran happily - no problems. Will see how it goes in practice, fingers crossed.
Otherwise wait a day when the professionals can reply to your query.
Haha! No worries, I am glad there are still people left in the community willing to give you a hand when needed (besides, there is no guarantee that these 'professionals' as you put it would be able to help out - I've ran across all sorts in my career).
Is that a necessary thing to do after installing a new module? My understanding is that relabelling only corrects the SELinux file attributes on every file on the system, so why would I need to do the relabelling when I have just installed a new policy?
Also, if my assumption is correct then why would I need to have a running SELinux to do that? It is a great inconvenience and a real pain for scenarios I described in my previous posts!
Good points. i think you might indeed be able to run restorecon or fixfiles/setfiles in %post, but i am not sure.
I would suggest you try it.
I did and everything works to absolute perfection!
I couldn't help but try it myself. Both "semodule -i" and "restorecon -rivvF /" (this is what I executed to relabel the whole file system - is that right?) ran without any difficulties and did the job as expected. When I later on mounted the image and logged in using qemu everything was there as expected (semodule -lv shows the newly installed module and I also ran cross checks on the SELinux file attributes to see whether they were changed with "ls -Z" and they have).
There is a slight drawback to all of this though - for some (well, most really) processes I use non-standard ports (another security measure I have taken onboard and implemented). sshd for example is not listening on the 'standard' port (tcp/22), but on a different one and this causes SELinux to issue "denied { name_bind }" alert. Also, my syslog-ng is using a directory, which maps to a non-standard directory (through symbolic link - /var/log is a symbolic link to a different/secure partition of the disk) and that also causes "denied { read }" with "tclass=lnk_file" alert.
So, I am guessing I need to grab a good SELinux book and start reading before making alterations to the (standard) SELinux policies. I also take it, altering the relevant (default) policies is the best thing to do in this case, is that right?
What documentation source would you recommend for this kind of job? As all alterations will be done through the kickstart file I am going to use command line tools only - no GUI!
On 06/28/2010 03:00 AM, Mr Dash Four wrote:
Is that a necessary thing to do after installing a new module? My understanding is that relabelling only corrects the SELinux file attributes on every file on the system, so why would I need to do the relabelling when I have just installed a new policy?
Also, if my assumption is correct then why would I need to have a running SELinux to do that? It is a great inconvenience and a real pain for scenarios I described in my previous posts!
Good points. i think you might indeed be able to run restorecon or fixfiles/setfiles in %post, but i am not sure.
I would suggest you try it.
I did and everything works to absolute perfection!
I couldn't help but try it myself. Both "semodule -i" and "restorecon -rivvF /" (this is what I executed to relabel the whole file system - is that right?) ran without any difficulties and did the job as expected. When I later on mounted the image and logged in using qemu everything was there as expected (semodule -lv shows the newly installed module and I also ran cross checks on the SELinux file attributes to see whether they were changed with "ls -Z" and they have).
sudo restorecon -R -v should usually be suffice. The -F (force) option is to force customizable types to be reset. Customizable types are types defined to not relabel by default
There is a slight drawback to all of this though - for some (well, most really) processes I use non-standard ports (another security measure I have taken onboard and implemented). sshd for example is not listening on the 'standard' port (tcp/22), but on a different one and this causes SELinux to issue "denied { name_bind }" alert. Also, my syslog-ng is
For example if ssh bind tcp sockets to port 11000:
sudo semanage port -a -t ssh_port_t -p tcp 11000
using a directory, which maps to a non-standard directory (through symbolic link - /var/log is a symbolic link to a different/secure partition of the disk) and that also causes "denied { read }" with "tclass=lnk_file" alert.
This will require a patch (need more info : avc denials of this event)
So, I am guessing I need to grab a good SELinux book and start reading before making alterations to the (standard) SELinux policies. I also take it, altering the relevant (default) policies is the best thing to do in this case, is that right?
That is what i do, i maintain my own fork of selinux-policy.
What documentation source would you recommend for this kind of job? As all alterations will be done through the kickstart file I am going to use command line tools only - no GUI!
www.selinuxbyexample.com
By the best doc, uptodate and all, is the source policy. writing policy isnt so hard but theres a lot of it usually. and if you focus on the amount of rules then its easy to think that stuff is complex.
If you take away all the types, then it boils down to the core, which are type statements, classes, attributes, types, interfaces, templates, permissions, permission sets, and a few mpre of those things. You can learn all about those by just studying the source policy. www.selinuxproject.org also has some nice docs.
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
I did and everything works to absolute perfection!
I couldn't help but try it myself. Both "semodule -i" and "restorecon -rivvF /" (this is what I executed to relabel the whole file system - is that right?) ran without any difficulties and did the job as expected. When I later on mounted the image and logged in using qemu everything was there as expected (semodule -lv shows the newly installed module and I also ran cross checks on the SELinux file attributes to see whether they were changed with "ls -Z" and they have).
sudo restorecon -R -v should usually be suffice. The -F (force) option is to force customizable types to be reset. Customizable types are types defined to not relabel by default
Noted, thanks.
There is a slight drawback to all of this though - for some (well, most really) processes I use non-standard ports (another security measure I have taken onboard and implemented). sshd for example is not listening on the 'standard' port (tcp/22), but on a different one and this causes SELinux to issue "denied { name_bind }" alert. Also, my syslog-ng is
For example if ssh bind tcp sockets to port 11000:
sudo semanage port -a -t ssh_port_t -p tcp 11000
Is this type "ssh_port_t" something, which is already registered (as part of the targeted policy perhaps?) and I am just modifying it or is this not the case?
using a directory, which maps to a non-standard directory (through symbolic link - /var/log is a symbolic link to a different/secure partition of the disk) and that also causes "denied { read }" with "tclass=lnk_file" alert.
This will require a patch (need more info : avc denials of this event)
I will post it separately as when I run the image with qemu cutting and pasting is not as straightforward.
What documentation source would you recommend for this kind of job? As all alterations will be done through the kickstart file I am going to use command line tools only - no GUI!
www.selinuxbyexample.com
By the best doc, uptodate and all, is the source policy. writing policy isnt so hard but theres a lot of it usually. and if you focus on the amount of rules then its easy to think that stuff is complex.
If you take away all the types, then it boils down to the core, which are type statements, classes, attributes, types, interfaces, templates, permissions, permission sets, and a few mpre of those things. You can learn all about those by just studying the source policy. www.selinuxproject.org also has some nice docs.
Noted, many thanks!
I am really liking this - today tried to execute "semodule -lv > loaded_modules.txt" (as root and pwd -> /root) and instantly got an alert - semodule was prevented from creating that file! Lovely stuff!
On 06/29/2010 01:42 AM, Mr Dash Four wrote:
I did and everything works to absolute perfection!
I couldn't help but try it myself. Both "semodule -i" and "restorecon -rivvF /" (this is what I executed to relabel the whole file system - is that right?) ran without any difficulties and did the job as expected. When I later on mounted the image and logged in using qemu everything was there as expected (semodule -lv shows the newly installed module and I also ran cross checks on the SELinux file attributes to see whether they were changed with "ls -Z" and they have).
sudo restorecon -R -v should usually be suffice. The -F (force) option is to force customizable types to be reset. Customizable types are types defined to not relabel by default
Noted, thanks.
There is a slight drawback to all of this though - for some (well, most really) processes I use non-standard ports (another security measure I have taken onboard and implemented). sshd for example is not listening on the 'standard' port (tcp/22), but on a different one and this causes SELinux to issue "denied { name_bind }" alert. Also, my syslog-ng is
For example if ssh bind tcp sockets to port 11000:
sudo semanage port -a -t ssh_port_t -p tcp 11000
Is this type "ssh_port_t" something, which is already registered (as part of the targeted policy perhaps?) and I am just modifying it or is this not the case?
Yes ssh_port_t is the ssh port type. tcp;22 is labelled with type ssh_port_t, we just label tcp:11000 ssh_port_t so that ssh can bind tcp sockets to that port as well.
using a directory, which maps to a non-standard directory (through symbolic link - /var/log is a symbolic link to a different/secure partition of the disk) and that also causes "denied { read }" with "tclass=lnk_file" alert.
This will require a patch (need more info : avc denials of this event)
I will post it separately as when I run the image with qemu cutting and pasting is not as straightforward.
What documentation source would you recommend for this kind of job? As all alterations will be done through the kickstart file I am going to use command line tools only - no GUI!
www.selinuxbyexample.com
By the best doc, uptodate and all, is the source policy. writing policy isnt so hard but theres a lot of it usually. and if you focus on the amount of rules then its easy to think that stuff is complex.
If you take away all the types, then it boils down to the core, which are type statements, classes, attributes, types, interfaces, templates, permissions, permission sets, and a few mpre of those things. You can learn all about those by just studying the source policy. www.selinuxproject.org also has some nice docs.
Noted, many thanks!
I am really liking this - today tried to execute "semodule -lv > loaded_modules.txt" (as root and pwd -> /root) and instantly got an alert - semodule was prevented from creating that file! Lovely stuff!
Exactly my thought.
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
For example if ssh bind tcp sockets to port 11000:
sudo semanage port -a -t ssh_port_t -p tcp 11000
Is this type "ssh_port_t" something, which is already registered (as part of the targeted policy perhaps?) and I am just modifying it or is this not the case?
Yes ssh_port_t is the ssh port type. tcp;22 is labelled with type ssh_port_t, we just label tcp:11000 ssh_port_t so that ssh can bind tcp sockets to that port as well.
Well, I do not wish to keep the tcp/22 as part of the policy (if left, it creates a loophole!). I tried "semanage port -m -t ssh_port_t -p tcp 222" (to modify it), but got "/usr/sbin/semanage: Port tcp/222 is not defined". I then added tcp/222 as you suggested and then tried to execute "semanage port -d -t ssh_port_t -p tcp 22" to remove the tcp/22 part, but got this: "/usr/sbin/semanage: Port tcp/22 is defined in policy, cannot be deleted". What does that mean exactly?
using a directory, which maps to a non-standard directory (through symbolic link - /var/log is a symbolic link to a different/secure partition of the disk) and that also causes "denied { read }" with "tclass=lnk_file" alert.
This will require a patch (need more info : avc denials of this event)
I will post it separately as when I run the image with qemu cutting and pasting is not as straightforward.
type=1400 audit(1277908958.656.4): avc: denied { read } for pid=906 comm="rsyslogd" name="log" dev=dm-0 ino=16386 scontext=system_u:system_r:syslogd_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=lnk_file
There is a similar one with "mingetty" as well, but scontext=system_u:system_r:getty_t:s0
On 06/30/2010 06:12 PM, Mr Dash Four wrote:
For example if ssh bind tcp sockets to port 11000:
sudo semanage port -a -t ssh_port_t -p tcp 11000
Is this type "ssh_port_t" something, which is already registered (as part of the targeted policy perhaps?) and I am just modifying it or is this not the case?
Yes ssh_port_t is the ssh port type. tcp;22 is labelled with type ssh_port_t, we just label tcp:11000 ssh_port_t so that ssh can bind tcp sockets to that port as well.
Well, I do not wish to keep the tcp/22 as part of the policy (if left, it creates a loophole!). I tried "semanage port -m -t ssh_port_t -p tcp 222" (to modify it), but got "/usr/sbin/semanage: Port tcp/222 is not defined". I then added tcp/222 as you suggested and then tried to execute "semanage port -d -t ssh_port_t -p tcp 22" to remove the tcp/22 part, but got this: "/usr/sbin/semanage: Port tcp/22 is defined in policy, cannot be deleted". What does that mean exactly?
It means that the corenetwork module (which is compiled into the base module) has a port object context specification for type ssh_port_t -- tcp:22
So you would have edit that in the main selinux-policy package.
using a directory, which maps to a non-standard directory (through symbolic link - /var/log is a symbolic link to a different/secure partition of the disk) and that also causes "denied { read }" with "tclass=lnk_file" alert.
This will require a patch (need more info : avc denials of this event)
I will post it separately as when I run the image with qemu cutting and pasting is not as straightforward.
type=1400 audit(1277908958.656.4): avc: denied { read } for pid=906 comm="rsyslogd" name="log" dev=dm-0 ino=16386 scontext=system_u:system_r:syslogd_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=lnk_file
There is a similar one with "mingetty" as well, but scontext=system_u:system_r:getty_t:s0
This symlink is mislabeled. What/who created it? if you , yourself created it, then you may be able to make things work by labeling the symlink type bin_t or type var_log_t, provided that the source of the interaction (in this case syslogd_t and getty_t) have access to the target of the symlink.
Well, I do not wish to keep the tcp/22 as part of the policy (if left, it creates a loophole!). I tried "semanage port -m -t ssh_port_t -p tcp 222" (to modify it), but got "/usr/sbin/semanage: Port tcp/222 is not defined". I then added tcp/222 as you suggested and then tried to execute "semanage port -d -t ssh_port_t -p tcp 22" to remove the tcp/22 part, but got this: "/usr/sbin/semanage: Port tcp/22 is defined in policy, cannot be deleted". What does that mean exactly?
It means that the corenetwork module (which is compiled into the base module) has a port object context specification for type ssh_port_t -- tcp:22
So you would have edit that in the main selinux-policy package.
How do I do that? I looked at /usr/share/selinux/targeted, but could not see anything, which could be edited.
type=1400 audit(1277908958.656.4): avc: denied { read } for pid=906 comm="rsyslogd" name="log" dev=dm-0 ino=16386 scontext=system_u:system_r:syslogd_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=lnk_file
There is a similar one with "mingetty" as well, but scontext=system_u:system_r:getty_t:s0
This symlink is mislabeled. What/who created it? if you , yourself created it, then you may be able to make things work by labeling the symlink type bin_t or type var_log_t, provided that the source of the interaction (in this case syslogd_t and getty_t) have access to the target of the symlink.
I did create it - it was done during the image build (it is empty, but it links to a separate/secure partition on the target machine). Relabelling worked though, I had to link the actual partition in order to make it work!
On 06/30/2010 06:35 PM, Mr Dash Four wrote:
Well, I do not wish to keep the tcp/22 as part of the policy (if left, it creates a loophole!). I tried "semanage port -m -t ssh_port_t -p tcp 222" (to modify it), but got "/usr/sbin/semanage: Port tcp/222 is not defined". I then added tcp/222 as you suggested and then tried to execute "semanage port -d -t ssh_port_t -p tcp 22" to remove the tcp/22 part, but got this: "/usr/sbin/semanage: Port tcp/22 is defined in policy, cannot be deleted". What does that mean exactly?
It means that the corenetwork module (which is compiled into the base module) has a port object context specification for type ssh_port_t -- tcp:22
So you would have edit that in the main selinux-policy package.
How do I do that? I looked at /usr/share/selinux/targeted, but could not see anything, which could be edited.
You would need to edit the source, and rebuild modified selinux-policy packages. The port declaration is located in policy/modules/kernel/corenetwork.te.in.
In the following example it is on line 192:
http://oss.tresys.com/projects/refpolicy/browser/policy/modules/kernel/coren...
To modify it you would:
download the selinux-policy.src.rpm corresponding to the version you have installed.
extract the source rpm.
extract the serefpolicy.tgz that is included in the source rpm.
apply the "*.patch" that is included in the source rpm
make your modifications
edit the selinux-policy.spec that is included with the source rpm. Remove any reference to the patch. You have just applied it.
repackage the serefpolicy directory (create the same serefpolicy.tgz but this time with patch applied and modification applied)
copy the contents to ~/rpmbuild/SOURCES/ (exclude the patch since it is already applied)
copy the selinux-policy.spec to ~/rpmbuild/SPECS
run: rpmbuild -ba ~/rpmbuild/SPECS/selinux-policy.spec
install the modified/created selinux-policy and selinux-policy-targeted rpms.
type=1400 audit(1277908958.656.4): avc: denied { read } for pid=906 comm="rsyslogd" name="log" dev=dm-0 ino=16386 scontext=system_u:system_r:syslogd_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=lnk_file
There is a similar one with "mingetty" as well, but scontext=system_u:system_r:getty_t:s0
This symlink is mislabeled. What/who created it? if you , yourself created it, then you may be able to make things work by labeling the symlink type bin_t or type var_log_t, provided that the source of the interaction (in this case syslogd_t and getty_t) have access to the target of the symlink.
I did create it - it was done during the image build (it is empty, but it links to a separate/secure partition on the target machine). Relabelling worked though, I had to link the actual partition in order to make it work!
You would need to edit the source, and rebuild modified selinux-policy packages. The port declaration is located in policy/modules/kernel/corenetwork.te.in.
Building the RPMs went OK, though the image build failed miserably!
I am getting the following errors when trying to install my (custom-built) selinux-policy and selinux-policy-targeted rpms:
=============Errors when executing rpm -ivh selinux-policy*.rpm on the image====================== libsemanage.semanage_install_active: setfiles returned error code 1. (Permission denied). libsemanage.semanage_install_active: Could not copy /etc/selinux/targeted/modules/active/policy.kern to /etc/selinux/targeted/policy/policy.24. (No such file or directory). semodule: Failed! libsemanage.semanage_read_policydb: Could not open kernel policy /etc/selinux/targeted/modules/active/policy.kern for reading. (No such file or directory). /usr/sbin/semanage: Could not test MLS enabled status ===============================================================================
Looking at my syslog I am getting the following:
============syslog==================================== Jun 30 20:06:36 xp1 kernel: type=1401 audit(1277924796.734:30578): security_compute_sid: invalid context unconfined_u:system_r:setfiles_mac_t:s0-s0:c0.c1023 for scontext=unconfined_u:system_r:livecd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:setfiles_exec_t:s0 tclass=process Jun 30 20:07:05 xp1 kernel: type=1401 audit(1277924825.706:30579): security_compute_sid: invalid context unconfined_u:system_r:setfiles_mac_t:s0-s0:c0.c1023 for scontext=unconfined_u:system_r:livecd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:setfiles_exec_t:s0 tclass=process Jun 30 20:07:05 xp1 kernel: type=1401 audit(1277924825.740:30580): security_compute_sid: invalid context unconfined_u:system_r:setfiles_mac_t:s0-s0:c0.c1023 for scontext=unconfined_u:system_r:livecd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:setfiles_exec_t:s0 tclass=process =====================================================
I presume my currently running SELinux does not like something when I try to install SELinux on the image. I presume it is something to do with the fact that its own 'selinux-policy' somehow differs from the one I built from source.
When I actually log on the image itself (with qemu) and try running "semanage port -l | grep ssh" I am getting this:
====================================== libsemanage.semanage_read_policydb: Could not open kernel policy /etc/selinux/targeted/modules/active/policy.kern for reading. (No such file or directory). /usr/sbin/semanage: Could not test MLS enabled status ======================================
The interesting thing is that my "semanage fcontext" command to change ipset SELinux attributes have been executed - these attributes are changed.
On 06/30/2010 09:36 PM, Mr Dash Four wrote:
You would need to edit the source, and rebuild modified selinux-policy packages. The port declaration is located in policy/modules/kernel/corenetwork.te.in.
Building the RPMs went OK, though the image build failed miserably!
I am getting the following errors when trying to install my (custom-built) selinux-policy and selinux-policy-targeted rpms:
=============Errors when executing rpm -ivh selinux-policy*.rpm on the image====================== libsemanage.semanage_install_active: setfiles returned error code 1. (Permission denied). libsemanage.semanage_install_active: Could not copy /etc/selinux/targeted/modules/active/policy.kern to /etc/selinux/targeted/policy/policy.24. (No such file or directory). semodule: Failed! libsemanage.semanage_read_policydb: Could not open kernel policy /etc/selinux/targeted/modules/active/policy.kern for reading. (No such file or directory). /usr/sbin/semanage: Could not test MLS enabled status ===============================================================================
Looking at my syslog I am getting the following:
============syslog==================================== Jun 30 20:06:36 xp1 kernel: type=1401 audit(1277924796.734:30578): security_compute_sid: invalid context unconfined_u:system_r:setfiles_mac_t:s0-s0:c0.c1023 for scontext=unconfined_u:system_r:livecd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:setfiles_exec_t:s0 tclass=process Jun 30 20:07:05 xp1 kernel: type=1401 audit(1277924825.706:30579): security_compute_sid: invalid context unconfined_u:system_r:setfiles_mac_t:s0-s0:c0.c1023 for scontext=unconfined_u:system_r:livecd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:setfiles_exec_t:s0 tclass=process Jun 30 20:07:05 xp1 kernel: type=1401 audit(1277924825.740:30580): security_compute_sid: invalid context unconfined_u:system_r:setfiles_mac_t:s0-s0:c0.c1023 for scontext=unconfined_u:system_r:livecd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:setfiles_exec_t:s0 tclass=process =====================================================
I presume my currently running SELinux does not like something when I try to install SELinux on the image. I presume it is something to do with the fact that its own 'selinux-policy' somehow differs from the one I built from source.
When I actually log on the image itself (with qemu) and try running "semanage port -l | grep ssh" I am getting this:
====================================== libsemanage.semanage_read_policydb: Could not open kernel policy /etc/selinux/targeted/modules/active/policy.kern for reading. (No such file or directory). /usr/sbin/semanage: Could not test MLS enabled status ======================================
The interesting thing is that my "semanage fcontext" command to change ipset SELinux attributes have been executed - these attributes are changed.
hmm... i am not sure about this but maybe:
role system_r types setfiles_mac_t;
helps here..
On 06/30/2010 09:48 PM, Mr Dash Four wrote:
hmm... i am not sure about this but maybe:
role system_r types setfiles_mac_t;
helps here..
What do you mean?
Is says "security_compute_sid: invalid context unconfined_u:system_r:setfiles_mac_t:s0-s0:c0.c1023"
I think that may be because system_r cannot be used for setfiles_mac_t. Looking at the policy i could not find anywhere where system_r would be allowed the setfiles_mac_t domain.
So by adding that rule , the system_r role should be allowed the setfiles_mac_t domain, making the context valid.
But its just a guess.
On 06/30/2010 09:48 PM, Mr Dash Four wrote:
hmm... i am not sure about this but maybe:
role system_r types setfiles_mac_t;
helps here..
What do you mean?
Add that rule to the running policy:
policy_module(myseutils, 1.0.0) gen_require(` type setfiles_mac_t; role system_r; ') role system_r types setfiles_mac_t;
... make -f /usr/share/selinux/devel/Makefile myseutils.pp sudo semodule -i myseutils.pp
Again, this is a shot in the dark...
hmm... i am not sure about this but maybe:
role system_r types setfiles_mac_t;
helps here..
What do you mean?
Add that rule to the running policy:
policy_module(myseutils, 1.0.0) gen_require(` type setfiles_mac_t; role system_r; ') role system_r types setfiles_mac_t;
... make -f /usr/share/selinux/devel/Makefile myseutils.pp sudo semodule -i myseutils.pp
Again, this is a shot in the dark...
YES!
This did the trick - no errors and when I log in with qemu and type "semanage port -l | grep ssh" I am getting my own port and nothing else (I did just one modification to see whether it will work). Brilliant!
On 06/30/2010 09:36 PM, Mr Dash Four wrote:
When I actually log on the image itself (with qemu) and try running "semanage port -l | grep ssh" I am getting this:
====================================== libsemanage.semanage_read_policydb: Could not open kernel policy /etc/selinux/targeted/modules/active/policy.kern for reading. (No such file or directory). /usr/sbin/semanage: Could not test MLS enabled status ======================================
I have seen and heard about this a couple of times before but i was never able to produce this myself.
I have no clue about that missing file or directory message (/etc/selinux/targeted/modules/active/policy.kern)
The interesting thing is that my "semanage fcontext" command to change ipset SELinux attributes have been executed - these attributes are changed.
When I actually log on the image itself (with qemu) and try running "semanage port -l | grep ssh" I am getting this:
====================================== libsemanage.semanage_read_policydb: Could not open kernel policy /etc/selinux/targeted/modules/active/policy.kern for reading. (No such file or directory). /usr/sbin/semanage: Could not test MLS enabled status ======================================
I have seen and heard about this a couple of times before but i was never able to produce this myself.
I have no clue about that missing file or directory message (/etc/selinux/targeted/modules/active/policy.kern)
I will have a wild stab at it...This might be able to reproduce the error...
If you have the time you can build a small test image using the livecd tools. You need to have the livecd-tools packages installed though. You also need qemu as well. Create and save this test kickstart file:
===========test-sel.ks======================== auth --useshadow --passalgo=md5 bootloader --location=mbr --timeout=5 firewall --disabled install logging --level=info part / --size 1024 --fstype=ext3 repo --cost=1 --name=fedora --mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-13&arch=$basearch repo --cost=2 --name=updates --mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=updates-released-f13&arc... #repo --cost=3 --name=livna --baseurl=http://rpm.livna.org/repo/13/$basearch/ repo --cost=4 --name=rpmfusion-free --mirrorlist=http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-13&arch=$basear... repo --cost=5 --name=rpmfusion-free-updates --mirrorlist=http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-updates-released-13... repo --cost=6 --name=rpmfusion-nonfree --mirrorlist=http://mirrors.rpmfusion.org/mirrorlist?repo=nonfree-fedora-13&arch=$bas... repo --cost=7 --name=rpmfusion-nonfree-updates --mirrorlist=http://mirrors.rpmfusion.org/mirrorlist?repo=nonfree-fedora-updates-released...
# login: root; pwd: root_test rootpw --plaintext root_test selinux --enforcing skipx text
%packages --nobase --excludedocs
#vital tools kernel bash #selinux-policy #selinux-policy-targeted policycoreutils libsemanage checkpolicy policycoreutils-python
#essential tools rsyslog vim-minimal
%post --nochroot
# selinux-policy-*.rpm = custom-built policies (must exist!) rpm -ivh --root $INSTALL_ROOT ~/selinux-policy-*.rpm %end
%post /sbin/restorecon -rip / %end ==========================================
Then, make sure you have the (customised) selinux-policy files and from the command line execute the following:
livecd-creator -c test-sel.ks -f test-image
It will download the necessary packages and build the image (test-image.iso). Check for the above errors when it comes to install the selinux-policy files (I am assuming that on the machine you are building the image your SELinux is in enforced mode and using the targeted policy). Also check your syslog.
When the image is built, you can log in to the new system with qemu:
qemu -m 512 test-image.iso
Login as root with password "root_test" as specified in the above kicktart file. Once there, try to execute semanage and see what happens...
On 06/30/2010 09:36 PM, Mr Dash Four wrote:
Looking at my syslog I am getting the following:
============syslog==================================== Jun 30 20:06:36 xp1 kernel: type=1401 audit(1277924796.734:30578): security_compute_sid: invalid context unconfined_u:system_r:setfiles_mac_t:s0-s0:c0.c1023 for scontext=unconfined_u:system_r:livecd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:setfiles_exec_t:s0 tclass=process Jun 30 20:07:05 xp1 kernel: type=1401 audit(1277924825.706:30579): security_compute_sid: invalid context unconfined_u:system_r:setfiles_mac_t:s0-s0:c0.c1023 for scontext=unconfined_u:system_r:livecd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:setfiles_exec_t:s0 tclass=process Jun 30 20:07:05 xp1 kernel: type=1401 audit(1277924825.740:30580): security_compute_sid: invalid context unconfined_u:system_r:setfiles_mac_t:s0-s0:c0.c1023 for scontext=unconfined_u:system_r:livecd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:setfiles_exec_t:s0 tclass=process =====================================================
this is what i committed to my branch that might fix that:
------------------------ policy/modules/apps/livecd.te ------------------------ index 4e69cdf..5d1084a 100644 @@ -23,7 +23,7 @@
domain_ptrace_all_domains(livecd_t)
-seutil_domtrans_setfiles_mac(livecd_t) +seutil_run_setfiles_mac(livecd_t, system_r)
manage_dirs_pattern(livecd_t, livecd_tmp_t, livecd_tmp_t) manage_files_pattern(livecd_t, livecd_tmp_t, livecd_tmp_t)
this is what i committed to my branch that might fix that:
------------------------ policy/modules/apps/livecd.te
index 4e69cdf..5d1084a 100644 @@ -23,7 +23,7 @@
domain_ptrace_all_domains(livecd_t)
-seutil_domtrans_setfiles_mac(livecd_t) +seutil_run_setfiles_mac(livecd_t, system_r)
manage_dirs_pattern(livecd_t, livecd_tmp_t, livecd_tmp_t) manage_files_pattern(livecd_t, livecd_tmp_t, livecd_tmp_t)
Do I save this as ~/rpmbuld/SOURCES/DG-SELinux.patch and then apply it to my custom selinux-policy?
On 06/30/2010 11:00 PM, Mr Dash Four wrote:
this is what i committed to my branch that might fix that:
------------------------ policy/modules/apps/livecd.te
index 4e69cdf..5d1084a 100644 @@ -23,7 +23,7 @@
domain_ptrace_all_domains(livecd_t)
-seutil_domtrans_setfiles_mac(livecd_t) +seutil_run_setfiles_mac(livecd_t, system_r)
manage_dirs_pattern(livecd_t, livecd_tmp_t, livecd_tmp_t) manage_files_pattern(livecd_t, livecd_tmp_t, livecd_tmp_t)
Do I save this as ~/rpmbuld/SOURCES/DG-SELinux.patch and then apply it to my custom selinux-policy?
Replace it manually. Because that isnt a proper patch.
open policy/modules/apps/livecd.te. find seutil_domtrans_setfiles_mac(livecd_t) and replace it by seutil_run_setfiles_mac(livecd_t, system_r)
this is what i committed to my branch that might fix that:
------------------------ policy/modules/apps/livecd.te
index 4e69cdf..5d1084a 100644 @@ -23,7 +23,7 @@
domain_ptrace_all_domains(livecd_t)
-seutil_domtrans_setfiles_mac(livecd_t) +seutil_run_setfiles_mac(livecd_t, system_r)
manage_dirs_pattern(livecd_t, livecd_tmp_t, livecd_tmp_t) manage_files_pattern(livecd_t, livecd_tmp_t, livecd_tmp_t)
Do I save this as ~/rpmbuld/SOURCES/DG-SELinux.patch and then apply it to my custom selinux-policy?
Replace it manually. Because that isnt a proper patch.
open policy/modules/apps/livecd.te. find seutil_domtrans_setfiles_mac(livecd_t) and replace it by seutil_run_setfiles_mac(livecd_t, system_r)
I presume this will be for the development machine (the one I am using to create the image) as on the image itself livecd is not used at all and is not needed. Is that correct? If so, I presume I need to compile and install my own custom policy and replace it with the 'stock' version - is that right?
On 06/30/2010 11:09 PM, Mr Dash Four wrote:
this is what i committed to my branch that might fix that:
------------------------ policy/modules/apps/livecd.te
index 4e69cdf..5d1084a 100644 @@ -23,7 +23,7 @@
domain_ptrace_all_domains(livecd_t)
-seutil_domtrans_setfiles_mac(livecd_t) +seutil_run_setfiles_mac(livecd_t, system_r)
manage_dirs_pattern(livecd_t, livecd_tmp_t, livecd_tmp_t) manage_files_pattern(livecd_t, livecd_tmp_t, livecd_tmp_t)
Do I save this as ~/rpmbuld/SOURCES/DG-SELinux.patch and then apply it to my custom selinux-policy?
Replace it manually. Because that isnt a proper patch.
open policy/modules/apps/livecd.te. find seutil_domtrans_setfiles_mac(livecd_t) and replace it by seutil_run_setfiles_mac(livecd_t, system_r)
I presume this will be for the development machine (the one I am using to create the image) as on the image itself livecd is not used at all and is not needed. Is that correct? If so, I presume I need to compile and install my own custom policy and replace it with the 'stock' version
- is that right?
Its a bug in policy, and in that regard it affects all systems. The problem is that if you are going to maintain your own fork of selinux_policy it will be much work to maintain (a fedora update might undo your changes)
Therefore it is best to submit this bug report to fedora bugzilla so that the fix can be applied upstream, then eventually it will get pushed to the repositories and end up on your system.
So in your case, you might want to, in the meantime, fix it with a custom module (myseutils.pp) whilst your bug report is processed.
Its a bug in policy, and in that regard it affects all systems. The problem is that if you are going to maintain your own fork of selinux_policy it will be much work to maintain (a fedora update might undo your changes)
Therefore it is best to submit this bug report to fedora bugzilla so that the fix can be applied upstream, then eventually it will get pushed to the repositories and end up on your system.
So in your case, you might want to, in the meantime, fix it with a custom module (myseutils.pp) whilst your bug report is processed.
I get you know! The way I see it I could maintain the source via a set of patches recording the changes I have made (the source will only be updated, the binary selinux-policy-* rpm won't be touched) and not install (the stock) selinux-policy - from what I've seen apart from selinux-targeted(minimal,mls) nothing else is dependant on this package, so it won't break anything (for now, that is!).
This until the fix is officially released, that is.
I have just finished building the image and tested it again - there were NO errors, none whatsoever! Superb work - thank you!
type=1400 audit(1277908958.656.4): avc: denied { read } for pid=906 comm="rsyslogd" name="log" dev=dm-0 ino=16386 scontext=system_u:system_r:syslogd_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=lnk_file
There is a similar one with "mingetty" as well, but scontext=system_u:system_r:getty_t:s0
This symlink is mislabeled. What/who created it? if you , yourself created it, then you may be able to make things work by labeling the symlink type bin_t or type var_log_t, provided that the source of the interaction (in this case syslogd_t and getty_t) have access to the target of the symlink.
Up until yesterday I used this on the real partition and it worked. Today, after deploying a new version I am getting the same errors again in addition to another (similar) error during console login:
===from dmesg as /var/log/messages does not exist as access is denied=== type=1400 audit(1278020473.778:4): avc: denied { read } for pid=914 comm="rsyslogd" name="log" dev=dm-0 ino=6188 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=lnk_file type=1400 audit(1278020487.171:22): avc: denied { read } for pid=1007 comm="mingetty" name="log" dev=dm-0 ino=6188 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=lnk_file type=1400 audit(1278020566.762:38): avc: denied { read } for pid=1007 comm="login" name="log" dev=dm-0 ino=6188 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=lnk_file ===================================================
here is the layout of the files/directories in question:
ls -lasZ /var ~~~~~~~~ lrwxrwxrwx. root root system_u:object_r:var_log_t:s0 log -> /apps/var/log
ls -lasZ /apps ~~~~~~~~~ drwx--x--x. root root system_u:object_r:var_t:s0 var
ls -lasZ /apps/var ~~~~~~~~~~~~ drwx--x--x. root root system_u:object_r:var_t:s0 . drwxr-xr-x. root root system_u:object_r:default_t:s0 .. drwxr-xr-x. root root system_u:object_r:var_log_t:s0 log
ls -lasZ /apps/var/log ~~~~~~~~~~~~~~ drwxr-xr-x. root root system_u:object_r:var_log_t:s0 . drwx--x--x. root root system_u:object_r:var_t:s0 .. -rw-r--r--. root root system_u:object_r:var_log_t:s0 dmesg drwxr-x---. exim exim system_u:object_r:default_t:s0 exim -rw-rw-r--. root utmp system_u:object_r:wtmp_t:s0 wtmp
What am I doing wrong?!
On Thu, 01 Jul 2010 23:53:42 +0100 Mr Dash Four mr.dash.four@googlemail.com wrote:
type=1400 audit(1277908958.656.4): avc: denied { read } for pid=906 comm="rsyslogd" name="log" dev=dm-0 ino=16386 scontext=system_u:system_r:syslogd_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=lnk_file
There is a similar one with "mingetty" as well, but scontext=system_u:system_r:getty_t:s0
This symlink is mislabeled. What/who created it? if you , yourself created it, then you may be able to make things work by labeling the symlink type bin_t or type var_log_t, provided that the source of the interaction (in this case syslogd_t and getty_t) have access to the target of the symlink.
Up until yesterday I used this on the real partition and it worked. Today, after deploying a new version I am getting the same errors again in addition to another (similar) error during console login:
===from dmesg as /var/log/messages does not exist as access is denied=== type=1400 audit(1278020473.778:4): avc: denied { read } for pid=914 comm="rsyslogd" name="log" dev=dm-0 ino=6188 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=lnk_file type=1400 audit(1278020487.171:22): avc: denied { read } for pid=1007 comm="mingetty" name="log" dev=dm-0 ino=6188 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=lnk_file type=1400 audit(1278020566.762:38): avc: denied { read } for pid=1007 comm="login" name="log" dev=dm-0 ino=6188 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=lnk_file ===================================================
here is the layout of the files/directories in question:
ls -lasZ /var
lrwxrwxrwx. root root system_u:object_r:var_log_t:s0 log -> /apps/var/log ls -lasZ /apps
drwx--x--x. root root system_u:object_r:var_t:s0 var
ls -lasZ /apps/var
drwx--x--x. root root system_u:object_r:var_t:s0 . drwxr-xr-x. root root system_u:object_r:default_t:s0 .. drwxr-xr-x. root root system_u:object_r:var_log_t:s0 log ls -lasZ /apps/var/log
drwxr-xr-x. root root system_u:object_r:var_log_t:s0 . drwx--x--x. root root system_u:object_r:var_t:s0 .. -rw-r--r--. root root system_u:object_r:var_log_t:s0 dmesg drwxr-x---. exim exim system_u:object_r:default_t:s0 exim -rw-rw-r--. root utmp system_u:object_r:wtmp_t:s0 wtmp
What am I doing wrong?!
Using bind mounts instead of symlinks will help.
Fix the context of /apps too: # semanage fcontext -a -t root_t /apps # restorecon -Fv /apps
And fix the context of /apps/var/log/*: # semanage fcontext -a -e /var/log /apps/var/log # restorecon -rvF /apps/var/log
Paul.
What am I doing wrong?!
Using bind mounts instead of symlinks will help.
It did!
I added "/apps/var/log /var/log none bind 0 0" to my fstab file and 2 of the three alerts are now gone. I am still getting this though:
kernel: type=1400 audit(1278074918.050:4): avc: denied { write } for pid=1557 comm="login" name="log" dev=sdc ino=16386 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=dir
This happens when I try to log in to the console. Any ideas?
On 02/07/10 15:58, Mr Dash Four wrote:
What am I doing wrong?!
Using bind mounts instead of symlinks will help.
It did!
I added "/apps/var/log /var/log none bind 0 0" to my fstab file and 2 of the three alerts are now gone. I am still getting this though:
kernel: type=1400 audit(1278074918.050:4): avc: denied { write } for pid=1557 comm="login" name="log" dev=sdc ino=16386 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=dir
This happens when I try to log in to the console. Any ideas?
It's probably trying to create a new file in your log directory. Try logging in with the system in permissive mode so you can see which file it's trying to create, then create an empty file with the right ownership and permissions (regular and SELinux) in your log directory and try again in enforcing mode.
Paul.
This happens when I try to log in to the console. Any ideas?
It's probably trying to create a new file in your log directory. Try logging in with the system in permissive mode so you can see which file it's trying to create, then create an empty file with the right ownership and permissions (regular and SELinux) in your log directory and try again in enforcing mode.
It worked - /var/log/lastlog was the culprit! This has now been fixed.
A common problem I found is that if a particular file does not exist in /var/log (standard log directory), and as this directory has the (standard) var_log_t type, almost any process wishing to write to this directory fails miserably (notable exceptions to this is mysqld and shorewall - they have no problems creating the appropriate files if they do not exist!).
I had the exact same problem with the audit daemon as well (auditd) - unless I create a directory (say, /var/log/audit) with the proper permissions (auditd_log_t in this case) it fails to start if audit.log does not exist. I guess if I want to keep one log directory and limit the number of subdirectories I have to remember to keep a copy of the appropriate log files ("touch /var/log/XXX" and then set the permissions with semanage).
On 07/02/2010 12:53 AM, Mr Dash Four wrote:
type=1400 audit(1277908958.656.4): avc: denied { read } for pid=906 comm="rsyslogd" name="log" dev=dm-0 ino=16386 scontext=system_u:system_r:syslogd_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=lnk_file
There is a similar one with "mingetty" as well, but scontext=system_u:system_r:getty_t:s0
This symlink is mislabeled. What/who created it? if you , yourself created it, then you may be able to make things work by labeling the symlink type bin_t or type var_log_t, provided that the source of the interaction (in this case syslogd_t and getty_t) have access to the target of the symlink.
Up until yesterday I used this on the real partition and it worked. Today, after deploying a new version I am getting the same errors again in addition to another (similar) error during console login:
===from dmesg as /var/log/messages does not exist as access is denied=== type=1400 audit(1278020473.778:4): avc: denied { read } for pid=914 comm="rsyslogd" name="log" dev=dm-0 ino=6188 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=lnk_file type=1400 audit(1278020487.171:22): avc: denied { read } for pid=1007 comm="mingetty" name="log" dev=dm-0 ino=6188 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=lnk_file type=1400 audit(1278020566.762:38): avc: denied { read } for pid=1007 comm="login" name="log" dev=dm-0 ino=6188 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=lnk_file ===================================================
here is the layout of the files/directories in question:
ls -lasZ /var
lrwxrwxrwx. root root system_u:object_r:var_log_t:s0 log -> /apps/var/log ls -lasZ /apps
drwx--x--x. root root system_u:object_r:var_t:s0 var
ls -lasZ /apps/var
drwx--x--x. root root system_u:object_r:var_t:s0 . drwxr-xr-x. root root system_u:object_r:default_t:s0 .. drwxr-xr-x. root root system_u:object_r:var_log_t:s0 log ls -lasZ /apps/var/log
drwxr-xr-x. root root system_u:object_r:var_log_t:s0 . drwx--x--x. root root system_u:object_r:var_t:s0 .. -rw-r--r--. root root system_u:object_r:var_log_t:s0 dmesg drwxr-x---. exim exim system_u:object_r:default_t:s0 exim -rw-rw-r--. root utmp system_u:object_r:wtmp_t:s0 wtmp
What am I doing wrong?!
A few things look wrong to me:
1. syslogd_t cannot interact with lnk_files that are labelled with the generic type for objects in /var/log (var_log_t):
$ sesearch --allow -SC -s syslogd_t -t var_log_t -c lnk_file
2. Unrelated to the above AVC denial but sure to also cause issues is the mislabelling of /apps/var/log/exim. This directory is labelled with an type reserved for unknown locations to SELinux.
It means that SELinux currently has no file context specification for this location:
$ matchpathcon /apps/var/log/exim /apps/var/log/exim system_u:object_r:default_t:s0
In Fedora 13 there is option for the semanage command called equivalence. This option can be used to clone file context specification.
In the "man semanage" there is an example that should apply to you configuration:
For home directories under top level directory, for example /disk6/home, execute the following commands. # semanage fcontext -a -t home_root_t "/disk6" # semanage fcontext -a -e /home /disk6/home # restorecon -R -v /disk6
Translating the above to your scenario would look like this:
sudo semanage fcontext -a -t root_t "/apps" sudo semanage fcontext -a -e /var /apps/var sudo restorecon -R -v /apps
If you make sure to use similar locations in /apps are the usual /var, then stuff should get labelled properly.
This will not fix you "read var_log_t lnk_file" issue though. I would probably try labelling the symlink type bin_t, and see if that works.
What am I doing wrong?!
A few things look wrong to me:
$ sesearch --allow -SC -s syslogd_t -t var_log_t -c lnk_file
This returns no matches.
- Unrelated to the above AVC denial but sure to also cause issues is
the mislabelling of /apps/var/log/exim. This directory is labelled with an type reserved for unknown locations to SELinux.
It means that SELinux currently has no file context specification for this location:
$ matchpathcon /apps/var/log/exim /apps/var/log/exim system_u:object_r:default_t:s0
In Fedora 13 there is option for the semanage command called equivalence. This option can be used to clone file context specification.
In the "man semanage" there is an example that should apply to you configuration:
For home directories under top level directory, for example /disk6/home, execute the following commands. # semanage fcontext -a -t home_root_t "/disk6" # semanage fcontext -a -e /home /disk6/home # restorecon -R -v /disk6
Translating the above to your scenario would look like this:
sudo semanage fcontext -a -t root_t "/apps" sudo semanage fcontext -a -e /var /apps/var sudo restorecon -R -v /apps
If you make sure to use similar locations in /apps are the usual /var, then stuff should get labelled properly.
I did just that - restorecon from /apps (recursive) seemed to restore all permissions in that directory once I used mount (--bind) to bind /apps/var/log to /var/log. 2 of the alerts are now gone, though I am still getting one when I log in to the console.
kernel: type=1400 audit(1278074918.050:4): avc: denied { write } for pid=1557 comm="login" name="log" dev=sdc ino=16386 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=dir
This will not fix you "read var_log_t lnk_file" issue though. I would probably try labelling the symlink type bin_t, and see if that works.
I have just discovered this 'magical' type. I use xtunnels (voip proxy) and was worried that I would need to define a whole new policy for it (it 'binds' to one particular port, but then uses a whole range of random ports 1024-65535 to connect externally) - I was dreading it, but when I started it it did bind to the port (no alerts!) and later on I discovered that it has a "bin_t" type. Interesting!
On Sun, 2010-06-27 at 21:26 +0200, Dominick Grift wrote:
On 06/27/2010 08:37 PM, Mr Dash Four wrote:
Also, does semodule need to have a running SELinux as I need to deploy this module on a Linux system (image) which does NOT have SELinux running (yet)?
Not sure, try it out.
I will, though I have a gut feeling that it won't work as semodule may be looking for a running SELinux database and I presume it picks up policy (and files) from the running system. Will give it a try though!
In other words, if I issue this command in chroot-ed environment would that be enough? The "%post" section of the kickstart file does just that
- it chroots to the image as it has been built and from there I can do
whatever I like on the actual image, though this is not a running system
- i.e. SELinux on that system is not loaded! If that is possible and if
I run on different architectures (say the image is for x86_64 and the machine on which the image is built is i686) would it matter?
The policy is arch-independent but i am not sure if it can be installed on a system that has no selinux enabled. I think it is possible but i am not sure.
I'll give it a go!
You will still have the issue that you would have to relabel the filesystem on each boot though.
Is that a necessary thing to do after installing a new module? My understanding is that relabelling only corrects the SELinux file attributes on every file on the system, so why would I need to do the relabelling when I have just installed a new policy?
Also, if my assumption is correct then why would I need to have a running SELinux to do that? It is a great inconvenience and a real pain for scenarios I described in my previous posts!
Good points. i think you might indeed be able to run restorecon or fixfiles/setfiles in %post, but i am not sure.
I would suggest you try it.
Otherwise wait a day when the professionals can reply to your query.
restorecon exits immediately if SELinux is disabled, so you cannot use it to label a tree on a non-SELinux build host. Dan wanted it that way so that he could unconditionally invoke it from scripts and not have it do anything if SELinux was disabled.
setfiles however does support labeling even on a non-SELinux host. As well as labeling an image that is being built with a "foreign" (i.e. different from host) policy on a SELinux host, although you have to run it in setfiles_mac_t for that purpose, as the livecd-creator does.
Is that a necessary thing to do after installing a new module? My understanding is that relabelling only corrects the SELinux file attributes on every file on the system, so why would I need to do the relabelling when I have just installed a new policy?
Also, if my assumption is correct then why would I need to have a running SELinux to do that? It is a great inconvenience and a real pain for scenarios I described in my previous posts!
Good points. i think you might indeed be able to run restorecon or fixfiles/setfiles in %post, but i am not sure.
I would suggest you try it.
Otherwise wait a day when the professionals can reply to your query.
restorecon exits immediately if SELinux is disabled, so you cannot use it to label a tree on a non-SELinux build host. Dan wanted it that way so that he could unconditionally invoke it from scripts and not have it do anything if SELinux was disabled.
setfiles however does support labeling even on a non-SELinux host. As well as labeling an image that is being built with a "foreign" (i.e. different from host) policy on a SELinux host, although you have to run it in setfiles_mac_t for that purpose, as the livecd-creator does.
Actually, I did execute restorecon on a non-SELinux running image (see previous posts on this very thread) and it worked pretty damn well!
It works without me doing anything in particular - just executing restorecon and semodule in the %post section of the kickstart file - no problem!
On Tue, 2010-06-29 at 00:35 +0100, Mr Dash Four wrote:
Is that a necessary thing to do after installing a new module? My understanding is that relabelling only corrects the SELinux file attributes on every file on the system, so why would I need to do the relabelling when I have just installed a new policy?
Also, if my assumption is correct then why would I need to have a running SELinux to do that? It is a great inconvenience and a real pain for scenarios I described in my previous posts!
Good points. i think you might indeed be able to run restorecon or fixfiles/setfiles in %post, but i am not sure.
I would suggest you try it.
Otherwise wait a day when the professionals can reply to your query.
restorecon exits immediately if SELinux is disabled, so you cannot use it to label a tree on a non-SELinux build host. Dan wanted it that way so that he could unconditionally invoke it from scripts and not have it do anything if SELinux was disabled.
setfiles however does support labeling even on a non-SELinux host. As well as labeling an image that is being built with a "foreign" (i.e. different from host) policy on a SELinux host, although you have to run it in setfiles_mac_t for that purpose, as the livecd-creator does.
Actually, I did execute restorecon on a non-SELinux running image (see previous posts on this very thread) and it worked pretty damn well!
It works without me doing anything in particular - just executing restorecon and semodule in the %post section of the kickstart file - no problem!
rpm -q -f `which restorecon` grep selinuxfs /proc/filesystems
restorecon checks is_selinux_enabled() and bails if it is not successful. Just tested it again on F13, and it has been true for a very long time.
Actually, I did execute restorecon on a non-SELinux running image (see previous posts on this very thread) and it worked pretty damn well!
It works without me doing anything in particular - just executing restorecon and semodule in the %post section of the kickstart file - no problem!
rpm -q -f `which restorecon` grep selinuxfs /proc/filesystems
restorecon checks is_selinux_enabled() and bails if it is not successful. Just tested it again on F13, and it has been true for a very long time
Let me make sure we are on the same page - the SELinux on the system I am running to build the image is enabled (in enforced mode) and running the targeted policy.
The commands I am executing (semodule, semanage, restorecon etc) are ran in the %post section of my kickstart file (the file, which is executed and used to build that image) - these commands are basically executed in chroot-ed environment (on the image file) just after it has been created and all software, including SELinux + targeted policy, is installed (the SELinux there is enabled and ready for using the targeted policy, but it is NOT running as nothing is loaded - it is just an image with about 200+MB worth of files in it).
All of the above SELinux commands run successfully without any problem whatsoever.
I have verified that and I am 100% certain they are doing the job they are supposed to be doing on the image file (with the 'dead' SELinux system). So, if you are thinking that is not possible, you are quite simply wrong, because it is clear to me that is not the case - I saw this with my own eyes!
On Tue, 2010-06-29 at 14:35 +0100, Mr Dash Four wrote:
Actually, I did execute restorecon on a non-SELinux running image (see previous posts on this very thread) and it worked pretty damn well!
It works without me doing anything in particular - just executing restorecon and semodule in the %post section of the kickstart file - no problem!
rpm -q -f `which restorecon` grep selinuxfs /proc/filesystems
restorecon checks is_selinux_enabled() and bails if it is not successful. Just tested it again on F13, and it has been true for a very long time
Let me make sure we are on the same page - the SELinux on the system I am running to build the image is enabled (in enforced mode) and running the targeted policy.
Oh, so SELinux is enabled.
The commands I am executing (semodule, semanage, restorecon etc) are ran in the %post section of my kickstart file (the file, which is executed and used to build that image) - these commands are basically executed in chroot-ed environment (on the image file) just after it has been created and all software, including SELinux + targeted policy, is installed (the SELinux there is enabled and ready for using the targeted policy, but it is NOT running as nothing is loaded - it is just an image with about 200+MB worth of files in it).
Sure, but the question of SELinux enablement is merely one of whether the running kernel has SELinux enabled and a policy loaded. As your build host is running with SELinux enabled, restorecon will run for you, even within the chroot, although it might need proc mounted within the chroot to determine the SELinux status.
All of the above SELinux commands run successfully without any problem whatsoever.
I have verified that and I am 100% certain they are doing the job they are supposed to be doing on the image file (with the 'dead' SELinux system). So, if you are thinking that is not possible, you are quite simply wrong, because it is clear to me that is not the case - I saw this with my own eyes!
restorecon will run as long as it sees that SELinux is enabled, which in this case it is. But if you were in fact building the image on a SELinux-disabled host, you'd have to use setfiles instead.
Another interesting case is when SELinux is enabled on the build host but using a very different policy than the image you are building, including file security contexts that aren't even defined in the build host's policy. They had to solve that issue for livecd-creator.
On Sun, 2010-06-27 at 13:37 +0100, Mr Dash Four wrote:
Problems combining these 2 to run while SELinux is in 'enforced' mode (policy running is the 'stock' targeted one supplied with FC13). I get 2 audit alerts when Shorewall starts (and fails!) - see logs below. I have x86_64 arch machine with FC13 running. Stock Shorewall is installed. IPSet (xtunnels) is compiled in (though with the 'stock' rpm I am getting the same errors).
The problem seems to be caused by the Shorewall init script (see further below). The relevant part of my syslog when SELinux is in enforced mode is:
=========SELinux=Enforcing================================ Jun 26 23:18:38 dev1 shorewall[2456]: Compiling... Jun 26 23:18:38 dev1 kernel: type=1400 audit(1277590718.634:29543): avc: denied { create } for pid=2577 comm="ipset" scontext=unconfined_u:system_r:shorewall_t:s0 tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket Jun 26 23:18:38 dev1 kernel: type=1400 audit(1277590718.637:29544): avc: denied { create } for pid=2579 comm="ipset" scontext=unconfined_u:system_r:shorewall_t:s0 tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket Jun 26 23:18:38 dev1 shorewall[2456]: Compiling /etc/shorewall/zones... Jun 26 23:18:38 dev1 shorewall[2456]: Compiling /etc/shorewall/interfaces... Jun 26 23:18:38 dev1 shorewall[2456]: Determining Hosts in Zones... Jun 26 23:18:38 dev1 shorewall[2456]: Preprocessing Action Files... Jun 26 23:18:38 dev1 shorewall[2456]: Pre-processing /usr/share/shorewall/action.Drop... Jun 26 23:18:38 dev1 shorewall[2456]: Pre-processing /usr/share/shorewall/action.Reject... Jun 26 23:18:38 dev1 shorewall[2456]: Compiling /etc/shorewall/policy... Jun 26 23:18:38 dev1 shorewall[2456]: Compiling /etc/shorewall/blacklist... Jun 26 23:18:38 dev1 shorewall[2456]: ERROR: ipset names in Shorewall configuration files require Ipset Match in your kernel and iptables : /etc/shorewall/blacklist (line 11) Jun 26 23:18:38 dev1 shorewall[2456]: ERROR: Shorewall start failed ==========================================================
When I switch SELinux to Permissive I get two further errors:
=========SELinux=Permissive=============================== Jun 26 23:32:45 dev1 kernel: type=1400 audit(1277591565.629:29551): avc: denied { create } for pid=3799 comm="ipset" scontext=unconfined_u:system_r:shorewall_t:s0 tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket Jun 26 23:32:45 dev1 kernel: type=1400 audit(1277591565.629:29552): avc: denied { getopt } for pid=3799 comm="ipset" lport=255 scontext=unconfined_u:system_r:shorewall_t:s0 tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket Jun 26 23:32:45 dev1 kernel: type=1400 audit(1277591565.629:29553): avc: denied { setopt } for pid=3799 comm="ipset" lport=255 scontext=unconfined_u:system_r:shorewall_t:s0 tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket Jun 26 23:32:45 dev1 shorewall[3678]: Compiling /etc/shorewall/zones... Jun 26 23:32:45 dev1 shorewall[3678]: Compiling /etc/shorewall/interfaces... Jun 26 23:32:45 dev1 shorewall[3678]: Determining Hosts in Zones... Jun 26 23:32:45 dev1 shorewall[3678]: Preprocessing Action Files... Jun 26 23:32:45 dev1 shorewall[3678]: Pre-processing /usr/share/shorewall/action.Drop... Jun 26 23:32:45 dev1 shorewall[3678]: Pre-processing /usr/share/shorewall/action.Reject... Jun 26 23:32:45 dev1 shorewall[3678]: Compiling /etc/shorewall/policy... Jun 26 23:32:45 dev1 shorewall[3678]: Compiling /etc/shorewall/blacklist... Jun 26 23:32:45 dev1 shorewall[3678]: Adding Anti-smurf Rules Jun 26 23:32:45 dev1 shorewall[3678]: Compiling TCP Flags filtering... Jun 26 23:32:45 dev1 shorewall[3678]: Compiling Kernel Route Filtering... Jun 26 23:32:45 dev1 shorewall[3678]: Compiling Martian Logging... Jun 26 23:32:45 dev1 shorewall[3678]: Compiling MAC Filtration -- Phase 1... Jun 26 23:32:45 dev1 shorewall[3678]: Compiling /etc/shorewall/rules... Jun 26 23:32:45 dev1 shorewall[3678]: Generating Transitive Closure of Used-action List... Jun 26 23:32:45 dev1 shorewall[3678]: Processing /usr/share/shorewall/action.Reject for chain Reject... Jun 26 23:32:45 dev1 shorewall[3678]: Processing /usr/share/shorewall/action.Drop for chain Drop... Jun 26 23:32:45 dev1 shorewall[3678]: Compiling MAC Filtration -- Phase 2... Jun 26 23:32:45 dev1 shorewall[3678]: Applying Policies... Jun 26 23:32:45 dev1 shorewall[3678]: Generating Rule Matrix... Jun 26 23:32:45 dev1 shorewall[3678]: Creating iptables-restore input... Jun 26 23:32:45 dev1 shorewall[3678]: Compiling iptables-restore input for chains blacklst mangle:... Jun 26 23:32:45 dev1 shorewall[3678]: Shorewall configuration compiled to /var/lib/shorewall/.start Jun 26 23:32:45 dev1 shorewall[3678]: Starting Shorewall.... Jun 26 23:32:45 dev1 shorewall[3678]: Initializing... Jun 26 23:32:46 dev1 kernel: u32 classifier Jun 26 23:32:46 dev1 kernel: Performance counters on Jun 26 23:32:46 dev1 kernel: input device check on Jun 26 23:32:46 dev1 kernel: Actions configured Jun 26 23:32:46 dev1 shorewall[3678]: Processing /etc/shorewall/init ... Jun 26 23:32:46 dev1 shorewall[3678]: loading /etc/shorewall/ips/blacklist-x1.ips Jun 26 23:32:46 dev1 shorewall[3678]: loading /etc/shorewall/ips/blacklist-x2.ips Jun 26 23:32:46 dev1 shorewall[3678]: loading /etc/shorewall/ips/blacklist-z1.ips Jun 26 23:32:47 dev1 shorewall[3678]: loading /etc/shorewall/ips/blacklist-z2.ips Jun 26 23:32:49 dev1 shorewall[3678]: Processing /etc/shorewall/tcclear ... Jun 26 23:32:49 dev1 shorewall[3678]: Setting up Route Filtering... Jun 26 23:32:49 dev1 shorewall[3678]: Setting up Martian Logging... Jun 26 23:32:49 dev1 shorewall[3678]: Setting up Proxy ARP... Jun 26 23:32:49 dev1 shorewall[3678]: Setting up Traffic Control... Jun 26 23:32:49 dev1 shorewall[3678]: Preparing iptables-restore input... Jun 26 23:32:49 dev1 shorewall[3678]: Running /sbin/iptables-restore... Jun 26 23:32:49 dev1 shorewall[3678]: IPv4 Forwarding Enabled Jun 26 23:32:49 dev1 shorewall[3678]: Processing /etc/shorewall/start ... Jun 26 23:32:49 dev1 shorewall[3678]: Processing /etc/shorewall/started ... Jun 26 23:32:49 dev1 shorewall[3678]: Shorewall started ==========================================================
The problem seems to be caused by the shorewall init script, which is:
===========Shorewall init script========================== modprobe ifb numifbs=1 ip link set dev ifb0 up
# configure the ipsets sw_ips_mask='/etc/shorewall/ips/*.ips' ipset_exec='/usr/sbin/ipset' if [ "$COMMAND" = start ]; then $ipset_exec -F $ipset_exec -X for c in `/bin/ls $sw_ips_mask 2>/dev/null`; do echo loading $c $ipset_exec -R < $c done fi ==========================================================
The above script executes /usr/sbin/ipset to create my IP Sets needed for running Shorewall (all IP set commands are contained in those *.ips files). These IP sets comprise mainly of IP subnets which are part of my blacklists (banned IP subnets), though they also contain some IP Port sets as well.
Don't know why SELinux denies "create" (and then "getopt" and "setopt") on a, what seems to be, raw ip socket (IPSet do not use/need one as far as I know!)? If I remove the IP Set part of the init script above and rearrange Shorewall to run without IPSets all is well, though its functionality is VERY limited and barely useful to me!
Two questions to the SELinux gurus on here: 1) Why am I getting these alerts? and 2) How can I fix the problem so that I could run both Shorewall and IPSets with SELinux in Enforced mode?
This is important for me as this is a production server and a lot of stuff runs on it and needs to be available 24/7.
ipset does appear to create and use a raw IP socket based on a quick look at its source code. You could have also confirmed that by strace'ing it or enabling syscall audit.
ipset isn't part of Fedora, right? You just built and installed it from source?
I think it might be easiest to just label it the same as iptables and then shorewall will transition to iptables_t which already has raw IP socket access as well as other related permissions. That will be better too in that you don't need to directly allow shorewall or anything else it runs in-domain to have those permissions.
semanage fcontext -a -t iptables_exec_t /path/to/ipset restorecon -v /path/to/ipset
ipset isn't part of Fedora, right?
Wrong!
It is distributed as rpm in the Fedora Fusion (Free) repo (3 rpms in fact: kmod-xtables-addons, xtables-addons and one additional package - optional - xtables addons with metadata for kernel).
You just built and installed it from source?
Please read my initial post - installing the above packages (i.e. the 'standard' distribution) makes NO difference whatsoever - I was getting the same alerts regardless of whether I compile and install from source or use the 'standard' distribution packages.
I think it might be easiest to just label it the same as iptables and then shorewall will transition to iptables_t which already has raw IP socket access as well as other related permissions. That will be better too in that you don't need to directly allow shorewall or anything else it runs in-domain to have those permissions.
semanage fcontext -a -t iptables_exec_t /path/to/ipset restorecon -v /path/to/ipset
An elegant solution ... but unfortunately it does NOT work - I am getting the same alerts again.
The problem (as evident from my initial post on this thread) is that the shorewall init file (normally based in /etc/shorewall/init) executes ipset, which in turn, as you pointed out above, tries to open a raw socket. I am in no way SELinux expert, but I would assume that the security context in which this executes is shorewall and not the one set in ipset.
Anyway, the solution presented by Dominic above works very well, so I may stick with it.
On Tue, 2010-06-29 at 00:30 +0100, Mr Dash Four wrote:
I think it might be easiest to just label it the same as iptables and then shorewall will transition to iptables_t which already has raw IP socket access as well as other related permissions. That will be better too in that you don't need to directly allow shorewall or anything else it runs in-domain to have those permissions.
semanage fcontext -a -t iptables_exec_t /path/to/ipset restorecon -v /path/to/ipset
An elegant solution ... but unfortunately it does NOT work - I am getting the same alerts again.
The problem (as evident from my initial post on this thread) is that the shorewall init file (normally based in /etc/shorewall/init) executes ipset, which in turn, as you pointed out above, tries to open a raw socket. I am in no way SELinux expert, but I would assume that the security context in which this executes is shorewall and not the one set in ipset.
# sesearch --type -s shorewall_t -t iptables_exec_t Found 1 semantic te rules: type_transition shorewall_t iptables_exec_t : process iptables_t;
The policy defines a transition from shorewall_t to iptables_t upon executing a binary labeled with iptables_exec_t. So when shorewall invokes iptables, it transitions to the right domain. Labeling ipset in the same manner would yield the same effect for it.
As a simulation, I did this: $ cp /usr/bin/id ./myipset $ chcon -t iptables_exec_t ./myipset $ setenforce 0 $ runcon system_u:system_r:shorewall_t:s0 /bin/bash -c ./myipset
And it correctly reported that myipset was running in iptables_t.
So I'm curious as to why this isn't working for you. Did the restorecon command in fact change the label of the program to iptables_exec_t? Did you get the same AVC message as before?
Anyway, the solution presented by Dominic above works very well, so I may stick with it.
So I'm curious as to why this isn't working for you. Did the restorecon command in fact change the label of the program to iptables_exec_t? Did you get the same AVC message as before?
Exactly the same message - no difference!
I am willing to investigate this further to get to the bottom of it. When I do not have my custom .pp and FC tries to start the shorewall service it fails (sometimes it gives me the alert, some times it doesn't). When I try to execute "service shorewall start" (as root) it always fails and always gives me those alerts (as I mentioned they are exactly the same, but I will have a closer look again). I will post these logs again (+ what I am doing/executing) when I have the chance to get to it - later today may be.
So I'm curious as to why this isn't working for you. Did the restorecon command in fact change the label of the program to iptables_exec_t? Did you get the same AVC message as before?
OK, I did the following after "semanage fcontext -a -t iptables_exec_t /usr/sbin/ipset" and "restorecon -v /usr/sbin/ipset":
[root@dev1 ~]# sesearch --type -s shorewall_t -t iptables_exec_t Found 1 semantic te rules: type_transition shorewall_t iptables_exec_t : process iptables_t;
[root@dev1 ~]# ls -lasZ /usr/sbin/ipset -rwxr-xr-x. root root system_u:object_r:iptables_exec_t:s0 /usr/sbin/ipset
[root@dev1 ~]# service shorewall start Starting Shorewall: [FAILED]
==============syslog======================================================== Jun 29 22:42:01 dev1 shorewall[2667]: Compiling... Jun 29 22:42:02 dev1 kernel: type=1400 audit(1277847722.204:30394): avc: denied { create } for pid=2790 comm="ipset" scontext=unconfined_u:system_r:shorewall_t:s0 tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket Jun 29 22:42:02 dev1 kernel: type=1400 audit(1277847722.207:30395): avc: denied { create } for pid=2792 comm="ipset" scontext=unconfined_u:system_r:shorewall_t:s0 tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket Jun 29 22:42:02 dev1 shorewall[2667]: Compiling /etc/shorewall/zones... Jun 29 22:42:02 dev1 shorewall[2667]: Compiling /etc/shorewall/interfaces... Jun 29 22:42:02 dev1 shorewall[2667]: Determining Hosts in Zones... Jun 29 22:42:02 dev1 shorewall[2667]: Preprocessing Action Files... Jun 29 22:42:02 dev1 shorewall[2667]: Pre-processing /usr/share/shorewall/action.Drop... Jun 29 22:42:02 dev1 shorewall[2667]: Pre-processing /usr/share/shorewall/action.Reject... Jun 29 22:42:02 dev1 shorewall[2667]: Compiling /etc/shorewall/policy... Jun 29 22:42:02 dev1 shorewall[2667]: Compiling /etc/shorewall/blacklist... Jun 29 22:42:02 dev1 shorewall[2667]: ERROR: ipset names in Shorewall configuration files require Ipset Match in your kernel and iptables : /etc/shorewall/blacklist (line 11) Jun 29 22:42:02 dev1 shorewall[2667]: ERROR:Shorewall start failed ================================================================================
So, as you can see it clearly does NOT work for some reason! Applying my own/patched policy module (myshorewall.pp) does the trick. Any suggestions?
So I'm curious as to why this isn't working for you. Did the restorecon command in fact change the label of the program to iptables_exec_t? Did you get the same AVC message as before?
Mystery solved! I've had an inspiration this morning.
At the time I installed ipset at least 2 times (from Fedora Fusion as well as compiling it from source), so I assumed ipset was installed in the same location. 'whereis ipset' revealed that I have TWO copies: one in /sbin and another one (which I have 'used' up until now) in /usr/sbin. So, for some reason, even though I specified the executable in /usr/sbin to be executed in my shorewall init (the one with the 'right' SELinux attributes) the executable in /sbin must have been picked somehow. When I removed the copy in /sbin and then rebooted - all was well and shorewall ran without any problems. Bizarre!
--->Back to the future...--->
I've had this problem in the early days of FC13 (from what I remember this was my first post ever in this mailing list), today upgraded to FC14 and ... voila... here we go again:
type=AVC msg=audit(1294001576.891:33): avc: denied { read } for pid=2753 comm="ipset" path="/etc/shorewall/ips/blacklist-eu1.ips" dev=dm-0 ino=16488 scontext=unconfined _u:system_r:iptables_t:s0 tcontext=system_u:object_r:shorewall_etc_t:s0 tclass=file type=SYSCALL msg=audit(1294001576.891:33): arch=40000003 syscall=11 success=yes exit=0 a0=979f3c0 a1=979f520 a2=9794ba0 a3=979f520 items=0 ppid=2727 pid=2753 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="ipset" exe="/sbin/ipset" subj=unconfined_u:system_r:iptables_t:s0 key=(null)
Quick scan with sesearch on the policy with FC13 (which works!) reveals this:
[zeek@test1 serefpolicy-3.7.19]$ sesearch -A -s iptables_t -t shorewall_etc_t Found 3 semantic av rules: allow iptables_t configfile : file { ioctl read getattr lock open } ; allow iptables_t configfile : dir { ioctl read getattr lock search open } ; allow iptables_t configfile : lnk_file { read getattr } ;
While the same command when executed with the newest version of the targeted policy on FC14 fetches nothing! So, my questions is - what has changed and why?!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/02/2011 11:38 PM, Mr Dash Four wrote:
--->Back to the future...--->
I've had this problem in the early days of FC13 (from what I remember this was my first post ever in this mailing list), today upgraded to FC14 and ... voila... here we go again:
type=AVC msg=audit(1294001576.891:33): avc: denied { read } for pid=2753 comm="ipset" path="/etc/shorewall/ips/blacklist-eu1.ips" dev=dm-0 ino=16488 scontext=unconfined _u:system_r:iptables_t:s0 tcontext=system_u:object_r:shorewall_etc_t:s0 tclass=file type=SYSCALL msg=audit(1294001576.891:33): arch=40000003 syscall=11 success=yes exit=0 a0=979f3c0 a1=979f520 a2=9794ba0 a3=979f520 items=0 ppid=2727 pid=2753 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="ipset" exe="/sbin/ipset" subj=unconfined_u:system_r:iptables_t:s0 key=(null)
Quick scan with sesearch on the policy with FC13 (which works!) reveals this:
[zeek@test1 serefpolicy-3.7.19]$ sesearch -A -s iptables_t -t shorewall_etc_t Found 3 semantic av rules: allow iptables_t configfile : file { ioctl read getattr lock open } ; allow iptables_t configfile : dir { ioctl read getattr lock search open } ; allow iptables_t configfile : lnk_file { read getattr } ;
While the same command when executed with the newest version of the targeted policy on FC14 fetches nothing! So, my questions is - what has changed and why?!
Might have been some merge issue with upstream policy.
I think Fedora and refpolicy implement configfile each in a different way, this may (or may not) cause confusion when Fedora merges upstream refpolicy in its branch.
In my view allowing iptables to read all config files is sub-optimal.
I would probably just allow:
shorewall_read_config(iptables)
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Might have been some merge issue with upstream policy.
I think Fedora and refpolicy implement configfile each in a different way, this may (or may not) cause confusion when Fedora merges upstream refpolicy in its branch.
I am annoyed because I do not want to be dealing with issues which were 'resolved' nearly a year ago just to resurface again when I try to upgrade.
Anyway, I backed out of this upgrade because as it turns out there are also quite a few issues with compiling the kernel as well, so I may as well just wait until FC15 comes around - I do not normally follow even number Fedora upgrades, but do not know what possessed me over the xmas period to go for this upgrade...
In my view allowing iptables to read all config files is sub-optimal.
I would probably just allow:
shorewall_read_config(iptables)
I did that as a temporary measure (added optional_policy statement with shorewall_read_config) to see if it is going to cure the problem - it did, though, as you put it above, it is not ideal.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/03/2011 03:25 PM, Mr Dash Four wrote:
Might have been some merge issue with upstream policy.
I think Fedora and refpolicy implement configfile each in a different way, this may (or may not) cause confusion when Fedora merges upstream refpolicy in its branch.
I am annoyed because I do not want to be dealing with issues which were 'resolved' nearly a year ago just to resurface again when I try to upgrade.
Yes, but this may just be an isolated incident. We are still only human plus some things changed in the way policy is maintained (moved to git/ new maintainer)
Anyway, I backed out of this upgrade because as it turns out there are also quite a few issues with compiling the kernel as well, so I may as well just wait until FC15 comes around - I do not normally follow even number Fedora upgrades, but do not know what possessed me over the xmas period to go for this upgrade...
SeLinux related issues? can you be more specific?
In my view allowing iptables to read all config files is sub-optimal.
I would probably just allow:
shorewall_read_config(iptables)
I did that as a temporary measure (added optional_policy statement with shorewall_read_config) to see if it is going to cure the problem - it did, though, as you put it above, it is not ideal.
shorewall_read_config IS ideal in my view. (unlike what Fedora previously may have implemented)
I think its probably best to just report this issue to bugzilla.redhat.com/f14/selinux-policy so that it can be fixed.
I am annoyed because I do not want to be dealing with issues which were 'resolved' nearly a year ago just to resurface again when I try to upgrade.
Yes, but this may just be an isolated incident. We are still only human plus some things changed in the way policy is maintained (moved to git/ new maintainer)
I still don't understand how is it possible for this to happen provided there are (presumably) at least basic QA procedures in place, but, most importantly, it is not the first time Fedora (in general) pulls this particular 'rabbit' out of the hat - tweaks something without giving it a second thought and then all hell breaks loose.
Anyway, I backed out of this upgrade because as it turns out there are also quite a few issues with compiling the kernel as well, so I may as well just wait until FC15 comes around - I do not normally follow even number Fedora upgrades, but do not know what possessed me over the xmas period to go for this upgrade...
SeLinux related issues? can you be more specific?
No, it is not related to SELinux at all, but it has a lot to do with the non-existence of the QA at Fedora, which should have spotted a lot of issues with the kernel build-up, (kernel) module dependencies in particular!
I started doing the digging, but gave up at the end as it was a bit too much for me to deal with - to say that I am unimpressed with FC14 would be an understatement!
As I already pointed out - I normally go for odd revisions (have been doing that since FC2), but don't know what possessed me this time to do it earlier - I was hoping to get the new version of iptables (which only works with the .35 version or above of the kernel), but soon realised that there are far too many rough edges and leftovers in that revision, so I decided to back out and restore FC13 and I am more content now.
In my view allowing iptables to read all config files is sub-optimal.
I would probably just allow:
shorewall_read_config(iptables)
I did that as a temporary measure (added optional_policy statement with shorewall_read_config) to see if it is going to cure the problem - it did, though, as you put it above, it is not ideal.
shorewall_read_config IS ideal in my view. (unlike what Fedora previously may have implemented)
I do not know what was implemented earlier as this was the first thing I wanted to check out - where are these 3 av statement matches shown in the FC13 revision of the policy. I could not find the source of these statements (much to my disappointment!), but the 'optional_policy' on shorewall should have been present in iptables.te - there is already a different (optional_policy) shorewall statement relating to the var/lib read/write permissions (I think), so, adding another one to cover the shorewall_etc_t domain wouldn't have done any harm at all.
I think its probably best to just report this issue to bugzilla.redhat.com/f14/selinux-policy so that it can be fixed.
I'll do this when I find the time to submit it, but that isn't going to happen tomorrow.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/03/2011 11:43 PM, Mr Dash Four wrote:
I am annoyed because I do not want to be dealing with issues which were 'resolved' nearly a year ago just to resurface again when I try to upgrade.
Yes, but this may just be an isolated incident. We are still only human plus some things changed in the way policy is maintained (moved to git/ new maintainer)
I still don't understand how is it possible for this to happen provided there are (presumably) at least basic QA procedures in place, but, most importantly, it is not the first time Fedora (in general) pulls this particular 'rabbit' out of the hat - tweaks something without giving it a second thought and then all hell breaks loose.
Anyway, I backed out of this upgrade because as it turns out there are also quite a few issues with compiling the kernel as well, so I may as well just wait until FC15 comes around - I do not normally follow even number Fedora upgrades, but do not know what possessed me over the xmas period to go for this upgrade...
SeLinux related issues? can you be more specific?
No, it is not related to SELinux at all, but it has a lot to do with the non-existence of the QA at Fedora, which should have spotted a lot of issues with the kernel build-up, (kernel) module dependencies in particular!
I started doing the digging, but gave up at the end as it was a bit too much for me to deal with - to say that I am unimpressed with FC14 would be an understatement!
As I already pointed out - I normally go for odd revisions (have been doing that since FC2), but don't know what possessed me this time to do it earlier - I was hoping to get the new version of iptables (which only works with the .35 version or above of the kernel), but soon realised that there are far too many rough edges and leftovers in that revision, so I decided to back out and restore FC13 and I am more content now.
Feel free to stick to f13, i also had some issue in f14 most notable with my sound chip/kernel and i worked with the kernel team to resolve this issue so that the community as a whole can benefit. After this issue was resolved i personally am very happy with f14.
For f15 i foresee larger issues. Think about systemd (compare that with the first fedora release that had pulseaudio (the same person too) and ofcourse defaulting to btrfs is also something that may not go all right the first time around.
But this is Fedora the distro where innovation and creativity happens, and stuff breaks sometimes.
But anyways that is off topic.
In my view allowing iptables to read all config files is sub-optimal.
I would probably just allow:
shorewall_read_config(iptables)
I did that as a temporary measure (added optional_policy statement with shorewall_read_config) to see if it is going to cure the problem - it did, though, as you put it above, it is not ideal.
shorewall_read_config IS ideal in my view. (unlike what Fedora previously may have implemented)
I do not know what was implemented earlier as this was the first thing I wanted to check out - where are these 3 av statement matches shown in the FC13 revision of the policy. I could not find the source of these statements (much to my disappointment!), but the 'optional_policy' on shorewall should have been present in iptables.te - there is already a different (optional_policy) shorewall statement relating to the var/lib read/write permissions (I think), so, adding another one to cover the shorewall_etc_t domain wouldn't have done any harm at all.
I think its probably best to just report this issue to bugzilla.redhat.com/f14/selinux-policy so that it can be fixed.
I'll do this when I find the time to submit it, but that isn't going to happen tomorrow.
I think its probably best to just report this issue to bugzilla.redhat.com/f14/selinux-policy so that it can be fixed.
Submitted a bug report: https://bugzilla.redhat.com/show_bug.cgi?id=670180.
On a separate note, I was (finally) able to build the new kernel (after much arguing with some of the kernel devs on that mailing list) and I now have a hybrid: FC13 core system with FC14 kernel.
I plan to add the new version of iptables with the latest (FC15-rawhide) fixes in the coming days. That iptables version would be extremely useful to me as it adds some very important features (incorporating ipset kernel modules within the kernel space, introducing new AUDIT target - just to name a few), so I am hoping to make full use of this until FC15 comes around, hopefully in the summer.
selinux@lists.fedoraproject.org