SELinux and Shorewall with IPSets
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! -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux |
SELinux and Shorewall with IPSets
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 -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux |
SELinux and Shorewall with IPSets
>> 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: > 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! -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux |
SELinux and Shorewall with IPSets
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 -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux |
SELinux and Shorewall with IPSets
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 -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux |
SELinux and Shorewall with IPSets
> 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? -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux |
SELinux and Shorewall with IPSets
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 -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux |
SELinux and Shorewall with IPSets
>> 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? -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux |
SELinux and Shorewall with IPSets
>> 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! -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux |
SELinux and Shorewall with IPSets
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 -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux |
| All times are GMT. The time now is 07:20 AM. |
VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.