Dear all, I had trouble persuading 'fedup --network 20' to run on my f19 laptop. It install all the files and gets ready. Then it boots and gets as far as:
[ OK ] Started trigger flushing of journal to persistent storage [ OK ] Started Forward Password Requests to Plymouth [ OK ] Started Forward Password Requests to Plymouth [ OK] Started Recreate Volatile files and Directories There are then 3 lines of selinux permission denied. But no problem, selinux is set permissive anyway.
Earlier on I see 'dracut-initqueue[400] failed to issue method call: Access denied'
However, when I add selinux=0 to the command line..installation proceeds. This is very odd - selinux was in permissive mode.
This is a bug I think? Bill
On Dec 24, 2013, at 2:42 AM, Bill Murray bill.murray@cern.ch wrote:
Dear all, I had trouble persuading 'fedup --network 20' to run on my f19 laptop. It install all the files and gets ready. Then it boots and gets as far as:
[ OK ] Started trigger flushing of journal to persistent storage [ OK ] Started Forward Password Requests to Plymouth [ OK ] Started Forward Password Requests to Plymouth [ OK] Started Recreate Volatile files and Directories There are then 3 lines of selinux permission denied. But no problem, selinux is set permissive anyway.
Earlier on I see 'dracut-initqueue[400] failed to issue method call: Access denied'
However, when I add selinux=0 to the command line..installation proceeds. This is very odd - selinux was in permissive mode.
This is a bug I think?
On a test VM with dracut and systemd debugging enabled (so it's slow):
[ 5.094179] type=1404 audit(1387844762.554:2): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295
The upgrade environment comes up in enforcing mode.
[ 37.388496] upgrade[665]: /bin/upgra[ 37.427863] type=1404 audit(1387844794.861:9): enforcing=0 old_enforcing=1 auid=4294967295 ses=4294967295 de@18(setstate): UPGRADE_STATE=running
Then goes to permissive mode. For fully 32 seconds it is in enforcing mode. And I see quite a few dracut-initqueue process entries at 15 seconds through 21 seconds. So all the preliminary setup logic before the upgrade runs, happens with enforcing enabled.
It's not so good to use selinux=0 because it totally disables selinux and all the labels on files will be unset. You should instead use enforcing=0 which allows selinux to correctly label the system, while not enforcing policy. So I suggest that now that your system is upgraded to Fedora 20, assuming you leave selinux running in enforcing mode on this system, that you relabel it with: restorecon -R -v /
As for whose bug this is, it could be mislabeling from the F19 system. But now that the system is upgraded it's difficult to reproduce to file a bug. I first would have tried a relabel from within Fedora 19: restorecon -R -v /
and then tried the update without changing the selinux behavior. If it still failed, then I'd do: ausearch -m AVC
to see exactly what's being denied and file a bug against it, or maybe against selinux-policy if the request is reasonable and the denial isn't. And then I'd rerun the upgrade with enforcing=0 as a work around.
Chris Murphy
On 12/24/2013 01:42 AM, Bill Murray issued this missive:
Dear all, I had trouble persuading 'fedup --network 20' to run on my f19 laptop. It install all the files and gets ready. Then it boots and gets as far as:
[ OK ] Started trigger flushing of journal to persistent storage [ OK ] Started Forward Password Requests to Plymouth [ OK ] Started Forward Password Requests to Plymouth [ OK] Started Recreate Volatile files and Directories There are then 3 lines of selinux permission denied. But no problem, selinux is set permissive anyway.
Earlier on I see 'dracut-initqueue[400] failed to issue method call: Access denied'
However, when I add selinux=0 to the command line..installation proceeds. This is very odd - selinux was in permissive mode.
I've said this before and I'll say it again...permissive mode does NOT allow ALL access (permissive != disabled, despite what others may say). If you see selinux deny messages, it's still being denied. I've seen this bite people a number of times. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - This message printed using recycled bandwidth - ----------------------------------------------------------------------
On Tue, 24 Dec 2013 09:48:38 -0800 Rick Stevens ricks@alldigital.com wrote:
I've said this before and I'll say it again...permissive mode does NOT allow ALL access (permissive != disabled, despite what others may say). If you see selinux deny messages, it's still being denied. I've seen this bite people a number of times.
Care to give a F18/19/20-working example of this?
IOW, provide a sequence of steps on a clean Fedora install that works with selinux disabled, while it fails with selinux in permissive mode?
Best, :-) Marko
On 12/24/2013 10:27 AM, Marko Vojinovic issued this missive:
On Tue, 24 Dec 2013 09:48:38 -0800 Rick Stevens ricks@alldigital.com wrote:
I've said this before and I'll say it again...permissive mode does NOT allow ALL access (permissive != disabled, despite what others may say). If you see selinux deny messages, it's still being denied. I've seen this bite people a number of times.
Care to give a F18/19/20-working example of this?
IOW, provide a sequence of steps on a clean Fedora install that works with selinux disabled, while it fails with selinux in permissive mode?
I don't have examples at hand, but I have seen FTP-related stuff, some upgrades and some other network-related things fail when SELinux is in permissive mode and work just fine when it's disabled. I never bothered tracking specifically what they are--it's just when they poop out, I've disabled SELinux, redone it and it's worked fine. I have then put it back in permissive mode, looked at the denial messages and put in local rules to cover them and gone to "targeted" mode.
Permissive does allow most actions, but there are some things it still denies. I guess "permissive" should be taken literally, like "we're relaxing most of the rules, but there are some we are going to enforce as long as we're in charge."
As I said, I don't have examples but the OP on this thread ran into the same thing I've hit in the past. He went from permissive to disabled and it worked. I'm just saying that permissive is not the same thing as disabled. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Microsoft Windows: Proof that P.T. Barnum was right - ----------------------------------------------------------------------
On Dec 24, 2013, at 10:48 AM, Rick Stevens ricks@alldigital.com wrote:
On 12/24/2013 01:42 AM, Bill Murray issued this missive:
Dear all, I had trouble persuading 'fedup --network 20' to run on my f19 laptop. It install all the files and gets ready. Then it boots and gets as far as:
[ OK ] Started trigger flushing of journal to persistent storage [ OK ] Started Forward Password Requests to Plymouth [ OK ] Started Forward Password Requests to Plymouth [ OK] Started Recreate Volatile files and Directories There are then 3 lines of selinux permission denied. But no problem, selinux is set permissive anyway.
Earlier on I see 'dracut-initqueue[400] failed to issue method call: Access denied'
However, when I add selinux=0 to the command line..installation proceeds. This is very odd - selinux was in permissive mode.
I've said this before and I'll say it again...permissive mode does NOT allow ALL access (permissive != disabled, despite what others may say). If you see selinux deny messages, it's still being denied. I've seen this bite people a number of times.
When enforcing=0 it reports denial messages, it does not enforce the denials.
http://danwalsh.livejournal.com/24537.html http://danwalsh.livejournal.com/10972.html
You might be thinking of the application of permissive domains, which largely still causes enforcement of denials to occur.
Chris Murphy
On Dec 24, 2013, at 11:52 AM, Rick Stevens ricks@alldigital.com wrote:
As I said, I don't have examples but the OP on this thread ran into the same thing I've hit in the past. He went from permissive to disabled and it worked. I'm just saying that permissive is not the same thing as disabled.
Ok no, that's not what happened to the OP at all as I explained earlier. His system booted in enforcing, and it was while it was enforcing that he got the denial prior to the fedup upgrade process changing to enforcing=0. He solved this problem by selinux=0 rather than enforcing=0.
Prior versions of fedup placed enforcing=0 as a boot parameter so it would have been permissive from the get go and would have avoided this problem, as most likely would a relabel prior to rebooting in the upgrade environment. Rebooting with selinux actually disabled for an upgrade is really not a good idea because as the new rpms are written, none of those installed bits will have the proper labeling.
Chris Murphy
Hi
On Tue, Dec 24, 2013 at 1:52 PM, Rick Stevens wrote:
I don't have examples at hand, but I have seen FTP-related stuff, some upgrades and some other network-related things fail when SELinux is in permissive mode and work just fine when it's disabled.
The default SELinux policy in Fedora is fairly relaxed anyway since it has to work out of the box for most users but once it it goes into permissive mode, any enforcement must be treated as a bug and reported. The goal of permissive model is to purely log policy issues. Permissive domains in SELinux mean an entirely different thing however and shouldn''t be confused with permissive mode.
Rahul
I have learned MORE about SELinux just being on this mailing list than from ANY other source out there!....thanks to all for your responses to this....(this will only help me in my pursuit of RHCE certification!..)
EGO II
On 12/24/2013 04:24 PM, Rahul Sundaram wrote:
Hi
On Tue, Dec 24, 2013 at 1:52 PM, Rick Stevens wrote:
I don't have examples at hand, but I have seen FTP-related stuff, some upgrades and some other network-related things fail when SELinux is in permissive mode and work just fine when it's disabled.The default SELinux policy in Fedora is fairly relaxed anyway since it has to work out of the box for most users but once it it goes into permissive mode, any enforcement must be treated as a bug and reported. The goal of permissive model is to purely log policy issues. Permissive domains in SELinux mean an entirely different thing however and shouldn''t be confused with permissive mode.
Rahul
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I blogged on SELinux blocking stuff in permissive mode.
http://danwalsh.livejournal.com/67855.html
I think fedup putting the machine into permissive mode during the update is the sane thing to do, and since it should be doing this without services running, it should be relatively safe.