>> 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. -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
