Description of problem: /root has 755 permissions on livecd images. (I've checked Fedora-Live-KDE-x86_64-20-TC3.iso and Fedora-Live-Desktop-x86_64-20-TC4.iso) Filesystem package itself has proper permissions, so it might be bug in livecd-creator: $ rpm -qlv filesystem | grep '/root' dr-xr-x--- 2 root root 0 авг 7 13:10 /root Version-Release number of selected component (if applicable): filesystem-3.2-19.fc20.x86_64 Steps to Reproduce: Run `ls -lad /root`. Actual results: drwxr-xr-x. 8 root root 4096 Dec 3 18:02 /root Expected results: dr-xr-x--- permissions Additional info:
Proposing this as blocker bug according to https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Security_bugs
Seems that rootfiles %posttrans script copying permissions from /etc/skel. Introduced in this commit - http://pkgs.fedoraproject.org/cgit/rootfiles.git/commit/?id=0c5486443deb8848b26869b44282d2a3f6813170 P.S. When fixing this bug it would be good to introduce a fix that fixes wrong permissions for people that installed system from F-20 pre-release images.
alexey: can you explain why you think this is a security issue? root is not in any way locked down on live images, they are not designed that way.
(In reply to Adam Williamson from comment #3) > alexey: can you explain why you think this is a security issue? Because it will be installed with those permissions, and on installed system it is supposed to be locked. As turns out it is issue in rootfiles script, it will also cover any other system - i.e. installed using anaconda, all kind of cloud or other images. I'm not sure, but seems that according to redhat classification (https://access.redhat.com/site/security/updates/classification/) it is "Important" as it allows local users to gain privileges by viewing some files that would be otherwise locked.
OK, confirmed it has 0755 permissions post-install. Still don't know if this is really a big issue, security team, would be good to have an evalution ASAP if possible - thanks.
It's fairly important. Throughout UNIX history, having a root directory that is unreadable is an expectation. I'd imagine a substantial number of admins keep all sorts of dangerous things in /root under the assumption it's not world readable (this is not a debate on the merits of this behavior, it's just the way it is). If it was up to me, I'd block on this. It violates a reasonable security expectation.
Other distros do the same thing, so this isn't something specific to Fedora. I know that FreeBSD installs with root as 0755 and Ubuntu uses 0700. This isn't to say it doesn't need to be fixed - but it's pretty common.
mike: AIUI 5 vs. 7 for user doesn't matter much, nor does group, it's the 5 vs. 0 for other that's the big one.
I've got to go out for lunch briefly. if no-one else has done it by the time i get back i'll slap a rootfiles update together with the change from c#2.
Created attachment 832286 [details] patch Here is patch that should fix it, but I didn't test it yet :-)
Created attachment 832287 [details] patch - chmod should go inside if, probably
Created attachment 832308 [details] also hide ugly error message
wait, let me follow the logic of this. I always forget the values for scriptlets; is the stuff inside "if" being executed only on install, not upgrade? or vice versa? i am not sure we should be trying to 'fix' existing installs, especially if this chmod would get executed on upgrades. we've always placed a low value on fixing up errors like this in pre-release versions, and almost any other goal takes higher priority than that, very much including not doing unexpected things to people upgrading from stable release to stable release. the conservative approach would be to fix this only for subsequent f20 fresh installs, not to try and 'fix' existing systems.
(In reply to Adam Williamson from comment #13) > wait, let me follow the logic of this. I always forget the values for > scriptlets; is the stuff inside "if" being executed only on install, not > upgrade? or vice versa? %posttrans $1 == 0 is run at install and upgrade time - https://fedoraproject.org/wiki/Packaging:ScriptletSnippets > i am not sure we should be trying to 'fix' existing installs, especially if > this chmod would get executed on upgrades. we've always placed a low value > on fixing up errors like this in pre-release versions, and almost any other > goal takes higher priority than that, very much including not doing > unexpected things to people upgrading from stable release to stable release. > the conservative approach would be to fix this only for subsequent f20 fresh > installs, not to try and 'fix' existing systems. Well, chmod part should dropped then.
--no-preserve=mode should be better... Thanks for spotting that...
Note: This needs to get on isos, otherwise the fix will not work (I don't like the chmod in posttrans - but if not on the isos, it will be the only option to fix it)
rootfiles-8.1-15.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/rootfiles-8.1-15.fc20
"Note: This needs to get on isos, otherwise the fix will not work (I don't like the chmod in posttrans - but if not on the isos, it will be the only option to fix it)" yes, we know, that's what the blocker nomination is about :)
(In reply to Ondrej Vasik from comment #15) > --no-preserve=mode should be better... Thanks for spotting that... Actually, it does not seem to work properly with `cp -ndpr --no-preserve=mode ...` or with different order of arguments. Probably because of -p which is --preserve=mode,ownership,timestamps. Bug in cp? Works this way though: cp -ndr --preserve=ownership,timestamp /etc/skel/. /root
According to coreutils' NEWS: cp --no-preserve=mode now no longer preserves the original file's permissions but correctly sets mode specified by 0666 & ~umask This counter-intuitive behaviour should be probably mentioned in man page... Or reversed to 'normal' one...
I'll change it to the --preserve style ... I don't like the chmod after cp, as it is racy and can fail anyway...
Discussed in 2013-12-04 Blocker Review Meeting [1]. Voted as an AcceptedBlocker. Wrong /root permission is considered to violate Final Security criteria: "The release must contain no known security bugs of 'important' or higher impact..." [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-12-04/ [2] http://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Security_bugs
Package rootfiles-8.1-16.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing rootfiles-8.1-16.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-22722/rootfiles-8.1-16.fc20 then log in and leave karma (feedback).
This should be probably added to common bugs list (and announced on test-announce@ ?) with a note that people who tested F-20 Beta and updated to release might need to do the following to keep their systems secure: chmod 0550 /root
rootfiles-8.1-16.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
doesn't need to be commonbugs, we fixed it.
(In reply to Adam Williamson from comment #26) > doesn't need to be commonbugs, we fixed it. CommonBugs was intended for people who installed with broken version as update does not fix it retrospectively.
aha, right - thanks for the reminder.