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