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(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux

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(a)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?

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(a)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?

-- selinux mailing list selinux(a)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!

-- selinux mailing list selinux(a)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 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)

> 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.

>> 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. >

> 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.

> 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.

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.

hmm... i am not sure about this but maybe: role system_r types setfiles_mac_t; helps here..

> hmm... i am not sure about this but maybe: > > role system_r types setfiles_mac_t; > > helps here.. > What do you mean?

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.

> 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.

> What am I doing wrong?! > Using bind mounts instead of symlinks will help.

> > 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.

> 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

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.

>> 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

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.

> 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.

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?

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)

> 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 think its probably best to just report this issue to bugzilla.redhat.com/f14/selinux-policy so that it can be fixed.