Description of problem: Happens on first boot after install from 2015-02-07 Rawhide Workstation x86_64 live nightly. SELinux is preventing polkitd from 'read' accesses on the lnk_file localtime. ***** Plugin catchall_labels (83.8 confidence) suggests ******************* If you want to allow polkitd to have read access on the localtime lnk_file Then you need to change the label on localtime Do # semanage fcontext -a -t FILE_TYPE 'localtime' where FILE_TYPE is one of the following: admin_home_t, bin_t, boot_t, cache_home_t, cert_t, config_home_t, config_usr_t, data_home_t, dbus_home_t, device_t, devlog_t, etc_runtime_t, etc_t, file_context_t, fonts_cache_t, fonts_t, gconf_home_t, gkeyringd_gnome_home_t, gnome_home_t, gstreamer_home_t, icc_data_home_t, ld_so_t, lib_t, locale_t, man_cache_t, man_t, net_conf_t, postfix_postdrop_t, proc_t, root_t, rpm_script_tmp_t, security_t, shell_exec_t, src_t, sssd_var_lib_t, sysfs_t, system_conf_t, system_db_t, textrel_shlib_t, tmp_t, usr_t, var_run_t, var_t. Then execute: restorecon -v 'localtime' ***** Plugin catchall (17.1 confidence) suggests ************************** If you believe that polkitd should be allowed read access on the localtime lnk_file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep polkitd /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:policykit_t:s0 Target Context system_u:object_r:default_t:s0 Target Objects localtime [ lnk_file ] Source polkitd Source Path polkitd Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-110.fc22.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.19.0-0.rc7.git2.1.fc22.x86_64 #1 SMP Fri Feb 6 08:39:13 UTC 2015 x86_64 x86_64 Alert Count 1 First Seen 2015-02-07 11:34:22 PST Last Seen 2015-02-07 11:34:22 PST Local ID e76454f5-0525-476d-b2b1-8ceedc53e7c4 Raw Audit Messages type=AVC msg=audit(1423337662.636:568): avc: denied { read } for pid=729 comm="polkitd" name="localtime" dev="dm-1" ino=913367 scontext=system_u:system_r:policykit_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=lnk_file permissive=0 Hash: polkitd,policykit_t,default_t,lnk_file,read Version-Release number of selected component: selinux-policy-3.13.1-110.fc22.noarch Additional info: reporter: libreport-2.3.0 hashmarkername: setroubleshoot kernel: 3.19.0-0.rc7.git2.1.fc22.x86_64 type: libreport
There are four similar denials ('read access on the localtime lnk_file') for useradd, gdm-session-wor, spice-vdagentd and cupsd: type=AVC msg=audit(1423337692.633:575): avc: denied { read } for pid=1803 comm="cupsd" name="localtime" dev="dm-1" ino=913367 scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=lnk_file permissive=0 type=AVC msg=audit(1423337660.929:541): avc: denied { read } for pid=716 comm="spice-vdagentd" name="localtime" dev="dm-1" ino=913367 scontext=system_u:system_r:vdagent_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=lnk_file permissive=0 type=AVC msg=audit(1423337657.775:540): avc: denied { read } for pid=1301 comm="gnome-session" name="localtime" dev="dm-1" ino=913367 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=lnk_file permissive=0 type=AVC msg=audit(1423337655.292:528): avc: denied { read } for pid=1583 comm="usermod" name="localtime" dev="dm-1" ino=913367 scontext=system_u:system_r:useradd_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=lnk_file permissive=0 Proposing as a Final blocker, criterion "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop." - https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria#SELinux_and_crash_notifications
Discussed at 02-09-2015 Blocker Review Meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2015-02-09/fedora-blocker-review.2015-02-09-17.00.log.txt AcceptedBlocker for Final - This is a clear violation of the Final criterion: "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop."
I didn't see any denials after installing and booting the 0207 nightly [0] in a vm. selinux-policy-3.13.1-110.fc22.noarch [0] https://kojipkgs.fedoraproject.org/work/tasks/5965/8855965/Fedora-Live-Workstation-x86_64-rawhide-20150207.iso
I also test it, I don't see any denials.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
*** Bug 1211766 has been marked as a duplicate of this bug. ***
*** Bug 1213577 has been marked as a duplicate of this bug. ***
*** Bug 1213574 has been marked as a duplicate of this bug. ***
*** Bug 1213576 has been marked as a duplicate of this bug. ***
Adding Systemd guys, Any help here? Question is, if this issue is also in fresh install of fedora, or just after upgrade.
Oh, I see, it was during live CD
Are we able to get it again?
*** Bug 1210045 has been marked as a duplicate of this bug. ***
Here we get some hint: https://bugzilla.redhat.com/show_bug.cgi?id=1210045#c5
Description of problem: I changed the time settings to use my timezone. Then selinux reported this action. Version-Release number of selected component: selinux-policy-3.13.1-119.fc22.noarch Additional info: reporter: libreport-2.5.0 hashmarkername: setroubleshoot kernel: 4.0.0-0.rc5.git4.1.fc22.x86_64 type: libreport
It seems that the file has context system_u:object_r:default_t:s0, but it should be locale_t. Here I have: $ ls -lZ /etc/localtime lrwxrwxrwx. 1 root root system_u:object_r:locale_t:s0 38 Apr 12 18:04 /etc/localtime -> ../usr/share/zoneinfo/America/New_York restorecon does not complain, so I assume that this is the correct context. The cause of the denial is pretty obvious, and it seems to be correct in the circumstances. The question is where the context was set. timedatectl, i.e. systemd-timedated, seems to set the context correctly to locale_t. I just checked to make sure, and the context of the target file does not matter (/usr/share/zoneinfo/...). So it seems that whoever created the link is guilty. In 1210045#c5 g-i-s was mentioned. I think it calls org.freedesktop.timedate1 method SetTime directly over dbus, so it cannot influence the context of the symlink in any way. anaconda will also create the symlink. Would it be possible for somebody with an affected system to check the timestamp on the file, and say whether it was created by anaconda during installation, or after the start of the first boot?
We need someone to provide the info requested by Zbigniew in #c16, thanks!
I made an installation using Fedora-Workstation-netinst-x86_64-22_TC1.iso, and the context is correct. So I cannot reproduce this.
zbigniew: well, the comment linked in comment #14 says they only saw the bug with i686 and creating a user with g-i-s. though I don't see how the arch could be involved.
Tested F22 TC1 i686 build. Installed from Live Workstation ISO and hit this bug. Steps to reproduce: 1. Install 32 bit version 2. Do not create user in Anaconda 3. Create User in G-I-S 4-a. Change time zone in G-I-S 4-b. Change time zone after G-I-S through system settings 5. Receive the SELinux AVC pop up. The AVC will be attached next.
The specific information Zbigniew needs is in #c16 - he needs to know whether the file was created by anaconda or by g-i-s, which you can tell from the timestamp if you kept notes of the install timings...
It appears the link was created by G-I-S - install was completed at 15:11, the timestamp on the link is 15:21. /etc/localtime is a link to a time zone file in /usr/share/zoneinfo/, which in this specific case for testing is /usr/share/zoneinfo/America/Indiana/Vevay and has a time stamp of April 16. [root@localhost ~]# ls -alZ /etc/localtime lrwxrwxrwx. 1 root root system_u:object_r:default_t:s0 43 May 4 15:21 /etc/localtime -> ../usr/share/zoneinfo/America/Indiana/Vevay [root@localhost ~]# ls -alZ ../usr/share/zoneinfo/America/Indiana/Vevay -rw-r--r--. 1 root root system_u:object_r:locale_t:s0 1423 Apr 16 23:18 ../usr/share/zoneinfo/America/Indiana/Vevay
It seems that this indeed a systemd problem. Patch coming up.
This strange feeling when a binary launched directly behaves differently then when launched through a dbus function call... what is going on ... insert print ... no effect ... insert sleep(5) ... no effect ... check timestamps ... everything OK ... set debug mode in PID1 ... oh, different service.
Ok, I managed to reproduce this with F22 beta3 i686 live install. When stracing timedatex, I can see it is indeed setting the context to system_u:object_r:default_t:s0. I compared the strace output to one created on another system and it seems the problem is missing /etc/selinux/targeted/contexts/files/file_contexts.bin. Reinstalling the selinux-policy{,-targeted} packages created that file and fixed the problem with timedatex setting incorrect context. Why was the file missing? FWIW, the timedatex code just calls matchpathcon() + lsetfilecon().
This could be a live image compose issue. The logs have these lines: mount: mount point /var/tmp/imgcreate-oAAcNS/install_root/sys/fs/selinux/load does not exist /sbin/setfiles: /var/tmp/imgcreate-oAAcNS/install_root is not located in /etc/selinux/targeted/contexts/files/file_contexts /sbin/setfiles: /var/tmp/imgcreate-oAAcNS/install_root/var is not located in /etc/selinux/targeted/contexts/files/file_contexts /sbin/setfiles: /var/tmp/imgcreate-oAAcNS/install_root/var/cache is not located in /etc/selinux/targeted/contexts/files/file_contexts /sbin/setfiles: /var/tmp/imgcreate-oAAcNS/install_root/var/log is not located in /etc/selinux/targeted/contexts/files/file_contexts /sbin/setfiles: /var/tmp/imgcreate-oAAcNS/install_root/boot is not located in /etc/selinux/targeted/contexts/files/file_contexts /sbin/setfiles: /var/tmp/imgcreate-oAAcNS/install_root/etc is not located in /etc/selinux/targeted/contexts/files/file_contexts /sbin/setfiles: /var/tmp/imgcreate-oAAcNS/install_root/etc/sysconfig is not located in /etc/selinux/targeted/contexts/files/file_contexts /sbin/setfiles: /var/tmp/imgcreate-oAAcNS/install_root/etc/sysconfig/mkinitrd is not located in /etc/selinux/targeted/contexts/files/file_contexts /sbin/setfiles: /var/tmp/imgcreate-oAAcNS/install_root/etc/dracut.conf.d is not located in /etc/selinux/targeted/contexts/files/file_contexts /sbin/setfiles: /var/tmp/imgcreate-oAAcNS/install_root/etc/dracut.conf.d/02livecd.conf is not located in /etc/selinux/targeted/contexts/files/file_contexts /sbin/setfiles: /var/tmp/imgcreate-oAAcNS/install_root/lost+found is not located in /etc/selinux/targeted/contexts/files/file_contexts /sbin/setfiles: /var/tmp/imgcreate-oAAcNS/install_root/dev is not located in /etc/selinux/targeted/contexts/files/file_contexts though they appear in both x86_64 and i686 logs, so not sure why the bug would only affect i686. https://koji.fedoraproject.org/koji/taskinfo?taskID=9592150 (x86_64) https://koji.fedoraproject.org/koji/taskinfo?taskID=9592148 (i686) mock_output.log is the most useful. Adding bcl and dennis.
(In reply to Adam Williamson from comment #26) > though they appear in both x86_64 and i686 logs, so not sure why the bug > would only affect i686. I tried it again with x86_64 live install and the .bin files were missing there too. But I'm not sure if I saw the timezone selection dialog, does this depend on network connectivity and successful geo lookup? The context of /etc/localtime was ok until I changed the timezone with timedatectl. Then I upgraded the selinux policy packages, which created the missing .bin files and another change of timezone with timedatectl fixed the context of /etc/localtime.
I think I know what's causing the setfiles errors, at least: https://github.com/SELinuxProject/selinux/commit/219eea83cea9336fc61ee6def5e114067e0c5040 we need that fix in policycoreutils on the live compose host. Whether that's what's causing this bug, I'm not entirely sure - but it should be easy enough to test. I'll see if I can do it.
So, that fix was actually backported to policycoreutils yesterday. Building with the updated policycoreutils does prevent the setfiles errors showing up during image compose, but doesn't seem to fix this problem - /etc/selinux/targeted/contexts/files/file_contexts.bin is still missing, and changing the timezone with g-i-s or gnome-control-center still causes an AVC. I do see one message when the selinux-policy package is installed during image creation: Installing: selinux-policy ################### [ 786/1446] semodule: SELinux policy is not managed or store cannot be accessed. that may be related somehow. Will investigate further.
Another thing that doesn't fix it: selinux-policy-3.13.1-125.fc22 (tried building an image with it in the host and the compose, nope).
So, here's a thing: on F21, file_contexts.bin is also not there after a clean live install - but this doesn't cause the bug. When changing the timezone, /etc/localtime remains correctly labelled. I believe the difference is that timedatex is a new thing in F22 - however timezone changes were handled before, I guess, didn't do it quite the same way as timedatex does. Reinstalling selinux-policy triggers 'semodule -nB', which I believe generates the .bin files. This is because selinux-policy has a %triggerin script: %triggerin -- pcre selinuxenabled && semodule -nB exit 0 a funny thing is that this %triggerin is defined inside the %if %{BUILD_TARGETED} block in the spec, but the script itself is for selinux-policy , not selinux-policy-targeted. Kinda odd. Not sure whether that's intentional or a mistake. (per https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch10s02.html - "The %triggerin script is run when a given target package is installed or upgraded. The %triggerin script is also run when your package is installed or upgraded, should the target package be already installed.")
So here's an interesting thing (this is more or less what timedatex does, so far as I can figure out, translated into Python cos messing around with it interactively like this is easy): BEFORE file_contexts.bin exists ------------------------------- [root@localhost test]# cd /etc [root@localhost etc]# python Python 2.7.9 (default, Apr 15 2015, 12:07:52) [GCC 5.0.0 20150319 (Red Hat 5.0.0-0.21)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import selinux >>> selinux.matchpathcon_init_prefix(None, '../usr/share/zoneinfo') 0 >>> selinux.matchpathcon('/etc/localtime', 0) [0, 'system_u:object_r:default_t:s0'] >>> Now we make file_contexts.bin exist ----------------------------------- [root@localhost etc]# semodule -nB and do it again: ---------------- [root@localhost etc]# python Python 2.7.9 (default, Apr 15 2015, 12:07:52) [GCC 5.0.0 20150319 (Red Hat 5.0.0-0.21)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import selinux >>> selinux.matchpathcon_init_prefix(None, '../usr/share/zoneinfo') 0 >>> selinux.matchpathcon('/etc/localtime', 0) [0, 'system_u:object_r:locale_t:s0'] >>> I wonder if that matchpathcon_init_prefix() is really correct - I'm pretty sure that's what timedatex does, but I think that '../' at the front probably makes it wrong. I suspect maybe instead of just calling `set_default_file_context(tmp, link);` in `finish_set_timezone()`, we should be dropping the LOCALTIME_TO_ZONEINFO_PATH from `link` before using it. I wonder if it only *happens* to work for some reason if the .bin files exist (perhaps in that case libselinux really just loads the whole set because it's just as cheap either way, or something?) I'll play around with this some more in a couple of hours.
OK, so I think I'm more or less right. My timedatex PR: https://github.com/mlichvar/timedatex/pull/1 fixes this, I tested. If anyone else wants to confirm, scratch build is http://koji.fedoraproject.org/koji/taskinfo?taskID=9682170 . There's one bit I still don't *entirely* understand, but hey, it definitely works. See the PR description for more details.
I think there's a libselinux bug thrown into the mix here and somewhat confusing things. Reported as https://bugzilla.redhat.com/show_bug.cgi?id=1219718 .
So far as what timedatex is actually doing here, one of the selinux devs suggested a way it can avoid setting contexts at all. So, here's what timedatex is trying to do: ln -s /usr/share/zoneinfo/new/timezone /etc/localtime59078305 && mv /etc/localtime59078305 /etc/localtime basically it wants to create the new timezone symlink with a temporary name and, if that works, rename it to the final name. The problem it has is that with current SELinux policy, when it creates /etc/localtime(random_integer), the context that file gets is not the correct context for /etc/localtime . SELinux doesn't relabel files on a move operation, so if it just does the above, /etc/localtime winds up with the wrong context. Hence timedatex stuck in the code to get the correct context for /etc/localtime and apply it to the temporary symlink name after it's created but before the rename. 'tfirg' suggests that instead selinux-policy could have a rule that when timedatex creates a link in /etc, it gets the appropriate context. That will work fine so long as this is the only symlink timedatex needs to create in /etc . (I suppose we could also make the default context rule for /etc/localtime into a regex matching /etc/localtime* .) That way timedatex can get out of the context setting business entirely. As a general rule, apps aren't supposed to go around doing this sort of thing, it should usually be handled in SELinux policy somehow or other.
Just call restorecon('/etc/localtime') after rename.
restorecon doesn't appear to be a part of the libselinux API so far as I can see. anyway, that seems racy - if something accesses the symlink after the rename but before the restorecon we'll get an AVC. something *does* seem to access it almost immediately after it's created.
Ok, then type_transition in policy is the right approach.
timedatex-0.3-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/timedatex-0.3-1.fc22
Thanks for looking into this, Adam. The patch is now in timedatex-0.3-1.fc22. BTW, a request for selinux policy for timedatex is in bug #1167289.
for the record, the 0.3-1.fc22 fix is a patch I came up with to improve timedatex's context setting stuff. It does still set the context; we could adopt the 'fix it in the policy' approach and drop the context setting code later.
Package timedatex-0.3-1.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing timedatex-0.3-1.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-7988/timedatex-0.3-1.fc22 then log in and leave karma (feedback).
Built a live image with the update and confirmed the fix.
timedatex-0.3-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.