Description of problem: # timedatectl set-local-rtc 1 Additional info: libreport version: 2.0.17 kernel: 3.6.6-3.fc18.i686 description: :SELinux is preventing /usr/lib/systemd/systemd-timedated from 'create' accesses on the file .adjtime72IeZW. : :***** Plugin catchall_labels (83.8 confidence) suggests ******************** : :If you want to allow systemd-timedated to have create access on the .adjtime72IeZW file :Then you need to change the label on .adjtime72IeZW :Do :# semanage fcontext -a -t FILE_TYPE '.adjtime72IeZW' :where FILE_TYPE is one of the following: locale_t, config_usr_t, systemd_passwd_var_run_t. :Then execute: :restorecon -v '.adjtime72IeZW' : : :***** Plugin catchall (17.1 confidence) suggests *************************** : :If you believe that systemd-timedated should be allowed create access on the .adjtime72IeZW 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 systemd-timedat /var/log/audit/audit.log | audit2allow -M mypol :# semodule -i mypol.pp : :Additional Information: :Source Context system_u:system_r:gnomeclock_t:s0 :Target Context system_u:object_r:etc_t:s0 :Target Objects .adjtime72IeZW [ file ] :Source systemd-timedat :Source Path /usr/lib/systemd/systemd-timedated :Port <Unknown> :Host (removed) :Source RPM Packages systemd-195-8.fc18.i686 :Target RPM Packages :Policy RPM selinux-policy-3.11.1-50.fc18.noarch :Selinux Enabled True :Policy Type targeted :Enforcing Mode Enforcing :Host Name (removed) :Platform Linux (removed) 3.6.6-3.fc18.i686 #1 SMP Mon Nov 5 : 16:47:11 UTC 2012 i686 i686 :Alert Count 1 :First Seen 2012-11-28 22:38:15 PST :Last Seen 2012-11-28 22:38:15 PST :Local ID 08de2bbd-a07c-404b-a4db-22e25edf39d9 : :Raw Audit Messages :type=AVC msg=audit(1354171095.502:303): avc: denied { create } for pid=1361 comm="systemd-timedat" name=".adjtime72IeZW" scontext=system_u:system_r:gnomeclock_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file : : :type=SYSCALL msg=audit(1354171095.502:303): arch=i386 syscall=open success=no exit=EACCES a0=b8550a68 a1=880c2 a2=180 a3=1ad7 items=0 ppid=1 pid=1361 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=systemd-timedat exe=/usr/lib/systemd/systemd-timedated subj=system_u:system_r:gnomeclock_t:s0 key=(null) : :Hash: systemd-timedat,gnomeclock_t,etc_t,file,create : :audit2allow : :#============= gnomeclock_t ============== :allow gnomeclock_t etc_t:file create; : :audit2allow -R : :#============= gnomeclock_t ============== :allow gnomeclock_t etc_t:file create; :
Created attachment 654005 [details] File: type
Created attachment 654006 [details] File: hashmarkername
(In reply to comment #0) > Description of problem: > # timedatectl set-local-rtc 1 ... This command modifies /etc/adjtime.
*** Bug 881580 has been marked as a duplicate of this bug. ***
*** Bug 881581 has been marked as a duplicate of this bug. ***
It makes me unhappy. Only way how to fix is using files_etc_filetrans(gnomeclock_t, adjtime_t, file) manage_files_pattern(gnomeclock_t, adjtime_t, adjtime_t) We can not use filename transition because it creates .adjtime* files.
Is there any reason this has to be random? If it just created /etc/adjtime- and then renamed it, then we could do a better job of confining it with SELinux. THis is how passwd and tools like it do this.
(In reply to comment #7) > Is there any reason this has to be random? If it just created /etc/adjtime- > and then renamed it, then we could do a better job of confining it with > SELinux. THis is how passwd and tools like it do this. /etc/adjtime is not really private property of timedated, hence assuming that timedated was the only one changing it and hence using a fixed name such as "/etc/adjtime-" is problematic. Using a random name has the benefit that any combination of writers can write the file race-freely without any further cooperation.
Well the same assumption could be made about /etc/passwd but it uses the -, and in practice you would be really stretching it to fine a case where a conflict would happen, taking a lock on adjtime- in the library would probably fix the case where two processes want to use it at the same time wouldn't it?
strace shows what the passwd command does. AFAICT, shadow- is not changed in this test. $ sudo strace -ttt -f -s 256 -o x1.strace passwd $ less x1.strace 2133 1356666894.635849 execve("/bin/passwd", ["passwd"], [/* 19 vars */]) = 0 ... 2133 1356666905.511953 open("/etc/.pwd.lock", O_WRONLY|O_CREAT|O_CLOEXEC, 0600) = 5 ... 2133 1356666905.745453 rename("/etc/nshadow", "/etc/shadow") = 0 ...
Well it uses well known paths /etc/.pwd.lock and /etc/nshadow.
The issue with taking locks via lock files is that everybody has to agree to take it. If only one writer cares for the lock and the others don't you have not solved anything. Creating a randomized config file, and then renaming it to the target file requires no cooperation from anybody else. THrough the randomness it is guaranteed that nobody can interfere with the logic and at any time either the new or the old file is in place, but there's no point in time where neither or a half-written file is in place. For the sake of security I think it is definitely the best to keep the current logic in place. Also not that we use the same logic to write most config files in /etc, like /etc/vconsole.conf, /etc/locale.conf and so on.
It would be nice to get this fixed before F18 is officially released, because the release notes explicitly mention set-local-rtc: To set the clock to use local time instead of UTC, use the command timedatectl set-local-rtc 1 Release Notes for Fedora 18 http://docs.fedoraproject.org/en-US/Fedora/18/html/Release_Notes/sect-Release_Notes-Changes_for_Sysadmin.html#idm41364656
*** Bug 895374 has been marked as a duplicate of this bug. ***
(In reply to comment #12) ... > Also not that we use the same logic to write most config files in /etc, like > /etc/vconsole.conf, /etc/locale.conf and so on. Thanks for pointing that out: [root@localhost ~]# ls -Z /etc/adjtime /etc/locale.conf /etc/vconsole.conf -rw-r--r--. root root system_u:object_r:adjtime_t:s0 /etc/adjtime -rw-r--r--. root root system_u:object_r:etc_runtime_t:s0 /etc/locale.conf -rw-r--r--. root root system_u:object_r:etc_runtime_t:s0 /etc/vconsole.conf [root@localhost ~]# rpm -qf /etc/adjtime /etc/locale.conf /etc/vconsole.conf initscripts-9.42.1-1.fc18.x86_64 systemd-195-15.fc18.x86_64 systemd-195-15.fc18.x86_64
(In reply to comment #10) > strace shows what the passwd command does. AFAICT, shadow- is not changed in > this test. Different tools for modifying /etc/passwd use different locking strategies, so locking is not very effective, see bug 864880. I'm sure there are further locking strategies floating around. I'm mentioning this just for completeness. I'm not sure if locking is needed for /etc/adjtime. Atomic replacement is probably sufficient, but this might need additional SELinux privileges me might not wish to grant.
Created attachment 690079 [details] This patch tells SELinux to create /etc/adjtime with the proper label I started out writing a patch for util.c to do this on any files that util.c creates, but I would have to call label_init() in all of the programs. I settled for just doing this for timedated for now.
Thanks, Dan. Do we need a bug for all of the programs, then?
I am not sure, I would like to hear what Lennart thinks, Basically if a systemd process is going to create random content into a system directory like /etc, we probably want to make sure the labels. Will attach the proposed future patch in next comment.
Created attachment 690424 [details] Patch to use SELinux labeling when ever systemd apps call: write_one_line_file or fopen_temporary The problem with this patch is it causes major changes to Makefile.am, where lots of apps now need to compile against the _shared.la library. Also we would need to add label_init() to all of these programs to get the labeling to work.
# ls -Z /usr/lib/systemd/systemd-timedated -rwxr-xr-x. root root system_u:object_r:gnomeclock_exec_t:s0 /usr/lib/systemd/systemd-timedated has to be fixed, btw...
upstream fix: http://cgit.freedesktop.org/systemd/systemd/commit/?id=a5c32cff1f56afe6f0c6c70d91a88a7a8238b2d7
Yes, I am going to backport it from Rawhide.
systemd-201-2.fc18.1 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/systemd-201-2.fc18.1
Package systemd-201-2.fc18.2: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.2' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.2 then log in and leave karma (feedback).
Package systemd-201-2.fc18.4: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.4' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.3 then log in and leave karma (feedback).
Package systemd-201-2.fc18.5: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.5' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.5 then log in and leave karma (feedback).
*** Bug 954135 has been marked as a duplicate of this bug. ***
*** Bug 955389 has been marked as a duplicate of this bug. ***
*** Bug 955390 has been marked as a duplicate of this bug. ***
*** Bug 955391 has been marked as a duplicate of this bug. ***
I apologize, the last three bugs are copy/paste issue.
systemd-201-2.fc18.6 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.6
Package systemd-201-2.fc18.6: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.6' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.6 then log in and leave karma (feedback).
systemd-201-2.fc18.6 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
$ cat /etc/adjtime 0.0 0 0.0 0 LOCAL $ timedatectl Local time: Wed 2013-05-29 01:12:10 EDT Universal time: Wed 2013-05-29 05:12:10 UTC Timezone: America/New_York (EDT, -0400) NTP enabled: yes NTP synchronized: yes RTC in local TZ: yes DST active: yes Last DST change: DST began at Sun 2013-03-10 01:59:59 EST Sun 2013-03-10 03:00:00 EDT Next DST change: DST ends (the clock jumps one hour backwards) at Sun 2013-11-03 01:59:59 EDT Sun 2013-11-03 01:00:00 EST Warning: The RTC is configured to maintain time in the local time zone. This mode is not fully supported and will create various problems with time zone changes and daylight saving adjustments. If at all possible use RTC in UTC, by calling 'timedatectl set-local-rtc 0'. $ timedatectl set-local-rtc false ==== AUTHENTICATING FOR org.freedesktop.timedate1.set-local-rtc === Authentication is required to control whether the RTC stores the local or UTC time. Authenticating as: root Password: ==== AUTHENTICATION COMPLETE === $ timedatectl Local time: Wed 2013-05-29 01:12:39 EDT Universal time: Wed 2013-05-29 05:12:39 UTC Timezone: America/New_York (EDT, -0400) NTP enabled: yes NTP synchronized: yes RTC in local TZ: no DST active: yes Last DST change: DST began at Sun 2013-03-10 01:59:59 EST Sun 2013-03-10 03:00:00 EDT Next DST change: DST ends (the clock jumps one hour backwards) at Sun 2013-11-03 01:59:59 EDT Sun 2013-11-03 01:00:00 EST $ cat /etc/adjtime 0.0 0 0.0 0 LOCAL # grep "adjtime\|sealert" /var/log/messages … May 29 01:12:39 localhost setroubleshoot: SELinux is preventing /usr/lib/systemd/systemd-timedated from create access on the file .adjtimeYeBnxw. For complete SELinux messages. run sealert -l f5fc548c-6891-4148-83ea-849f91f2a1c6 # grep adjtime /var/log/audit/audit.log … type=AVC msg=audit(1369804356.004:440): avc: denied { create } for pid=866 comm="systemd-timedat" name=".adjtimeYeBnxw" scontext=system_u:system_r:systemd_timedated_t:s0 tcontext=system_u:object_r:adjtime_t:s0 tclass=file # sealert -l f5fc548c-6891-4148-83ea-849f91f2a1c6 SELinux is preventing /usr/lib/systemd/systemd-timedated from create access on the file .adjtimeYeBnxw. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that systemd-timedated should be allowed create access on the .adjtimeYeBnxw 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 systemd-timedat /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:systemd_timedated_t:s0 Target Context system_u:object_r:adjtime_t:s0 Target Objects .adjtimeYeBnxw [ file ] Source systemd-timedat Source Path /usr/lib/systemd/systemd-timedated Port <Unknown> Host localhost.localdomain Source RPM Packages systemd-204-3.fc20.i686 Target RPM Packages Policy RPM selinux-policy-3.12.1-46.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name localhost.localdomain Platform Linux localhost.localdomain 3.10.0-0.rc1.git7.1.fc20.i686.PAE #1 SMP Mon May 20 14:16:04 UTC 2013 i686 i686 Alert Count 6 First Seen 2013-05-29 00:29:38 EDT Last Seen 2013-05-29 01:12:36 EDT Local ID f5fc548c-6891-4148-83ea-849f91f2a1c6 Raw Audit Messages type=AVC msg=audit(1369804356.4:440): avc: denied { create } for pid=866 comm="systemd-timedat" name=".adjtimeYeBnxw" scontext=system_u:system_r:systemd_timedated_t:s0 tcontext=system_u:object_r:adjtime_t:s0 tclass=file type=SYSCALL msg=audit(1369804356.4:440): arch=i386 syscall=open success=no exit=EACCES a0=b82f4070 a1=880c2 a2=180 a3=b76d2a80 items=0 ppid=1 pid=866 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=systemd-timedat exe=/usr/lib/systemd/systemd-timedated subj=system_u:system_r:systemd_timedated_t:s0 key=(null) Hash: systemd-timedat,systemd_timedated_t,adjtime_t,file,create In addition: https://bugzilla.redhat.com/show_bug.cgi?id=967878
3d2d0459904b5bba7ceea726fcd4c274038772f4 fixes this in git.
$ cat /etc/adjtime 0.0 0 0.0 0 LOCAL $ timedatectl Local time: Wed 2013-05-29 12:03:25 EDT Universal time: Wed 2013-05-29 16:03:25 UTC Timezone: America/New_York (EDT, -0400) NTP enabled: yes NTP synchronized: yes RTC in local TZ: yes DST active: yes Last DST change: DST began at Sun 2013-03-10 01:59:59 EST Sun 2013-03-10 03:00:00 EDT Next DST change: DST ends (the clock jumps one hour backwards) at Sun 2013-11-03 01:59:59 EDT Sun 2013-11-03 01:00:00 EST Warning: The RTC is configured to maintain time in the local time zone. This mode is not fully supported and will create various problems with time zone changes and daylight saving adjustments. If at all possible use RTC in UTC, by calling 'timedatectl set-local-rtc 0'. $ timedatectl set-local-rtc off ==== AUTHENTICATING FOR org.freedesktop.timedate1.set-local-rtc === Authentication is required to control whether the RTC stores the local or UTC time. Authenticating as: root Password: ==== AUTHENTICATION COMPLETE === $ cat /etc/adjtime 0.0 0 0.0 0 UTC $ timedatectl Local time: Wed 2013-05-29 12:03:51 EDT Universal time: Wed 2013-05-29 16:03:51 UTC Timezone: America/New_York (EDT, -0400) NTP enabled: yes NTP synchronized: yes RTC in local TZ: no DST active: yes Last DST change: DST began at Sun 2013-03-10 01:59:59 EST Sun 2013-03-10 03:00:00 EDT Next DST change: DST ends (the clock jumps one hour backwards) at Sun 2013-11-03 01:59:59 EDT Sun 2013-11-03 01:00:00 EST PASSED selinux-policy-3.12.1-47.fc20 http://koji.fedoraproject.org/koji/buildinfo?buildID=422774 PASSED selinux-policy-3.12.1-47.fc19 http://koji.fedoraproject.org/koji/buildinfo?buildID=422770 Thanks Miroslav, Daniel. ;)