Bug 881577 - SELinux is preventing /usr/lib/systemd/systemd-timedated from 'create' accesses on the file .adjtime72IeZW.
Summary: SELinux is preventing /usr/lib/systemd/systemd-timedated from 'create' access...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 18
Hardware: i686
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:913363c4a8a8acfe909a5ec01f5...
: 881580 881581 895374 954135 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-11-29 06:45 UTC by Steve Tyler
Modified: 2016-03-27 14:33 UTC (History)
18 users (show)

Fixed In Version: systemd-201-2.fc18.6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-05-16 02:57:09 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
File: type (9 bytes, text/plain)
2012-11-29 06:45 UTC, Steve Tyler
no flags Details
File: hashmarkername (14 bytes, text/plain)
2012-11-29 06:45 UTC, Steve Tyler
no flags Details
This patch tells SELinux to create /etc/adjtime with the proper label (2.68 KB, patch)
2013-01-29 23:30 UTC, Daniel Walsh
no flags Details | Diff
Patch to use SELinux labeling when ever systemd apps call: (1.23 KB, patch)
2013-01-30 15:28 UTC, Daniel Walsh
no flags Details | Diff

Description Steve Tyler 2012-11-29 06:45:25 UTC
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;
:

Comment 1 Steve Tyler 2012-11-29 06:45:27 UTC
Created attachment 654005 [details]
File: type

Comment 2 Steve Tyler 2012-11-29 06:45:29 UTC
Created attachment 654006 [details]
File: hashmarkername

Comment 3 Steve Tyler 2012-11-29 06:49:08 UTC
(In reply to comment #0)
> Description of problem:
> # timedatectl set-local-rtc 1
...

This command modifies /etc/adjtime.

Comment 4 Miroslav Grepl 2012-11-29 17:41:03 UTC
*** Bug 881580 has been marked as a duplicate of this bug. ***

Comment 5 Miroslav Grepl 2012-11-29 17:41:15 UTC
*** Bug 881581 has been marked as a duplicate of this bug. ***

Comment 6 Miroslav Grepl 2012-11-29 17:47:01 UTC
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.

Comment 7 Daniel Walsh 2012-11-30 12:16:02 UTC
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.

Comment 8 Lennart Poettering 2012-12-22 09:43:46 UTC
(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.

Comment 9 Daniel Walsh 2012-12-27 16:44:26 UTC
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?

Comment 10 Steve Tyler 2012-12-28 04:08:01 UTC
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
...

Comment 11 Daniel Walsh 2012-12-28 16:47:06 UTC
Well it uses well known paths /etc/.pwd.lock and /etc/nshadow.

Comment 12 Lennart Poettering 2013-01-14 17:20:51 UTC
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.

Comment 13 Steve Tyler 2013-01-14 17:54:39 UTC
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

Comment 14 Miroslav Grepl 2013-01-15 11:16:27 UTC
*** Bug 895374 has been marked as a duplicate of this bug. ***

Comment 15 Steve Tyler 2013-01-15 17:29:38 UTC
(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

Comment 16 Florian Weimer 2013-01-29 08:55:58 UTC
(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.

Comment 17 Daniel Walsh 2013-01-29 23:30:50 UTC
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.

Comment 18 Steve Tyler 2013-01-30 03:55:25 UTC
Thanks, Dan.
Do we need a bug for all of the programs, then?

Comment 19 Daniel Walsh 2013-01-30 15:24:10 UTC
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.

Comment 20 Daniel Walsh 2013-01-30 15:28:38 UTC
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.

Comment 21 Harald Hoyer 2013-02-14 15:17:22 UTC
# 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...

Comment 23 Miroslav Grepl 2013-02-14 16:01:38 UTC
Yes, I am going to backport it from Rawhide.

Comment 24 Fedora Update System 2013-04-10 20:11:01 UTC
systemd-201-2.fc18.1 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/systemd-201-2.fc18.1

Comment 25 Fedora Update System 2013-04-11 23:23:54 UTC
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).

Comment 26 Fedora Update System 2013-04-15 23:58:29 UTC
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).

Comment 27 Fedora Update System 2013-04-18 02:35:48 UTC
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).

Comment 28 Miroslav Grepl 2013-04-23 07:17:06 UTC
*** Bug 954135 has been marked as a duplicate of this bug. ***

Comment 29 Miroslav Grepl 2013-04-23 08:08:39 UTC
*** Bug 955389 has been marked as a duplicate of this bug. ***

Comment 30 Miroslav Grepl 2013-04-23 08:08:42 UTC
*** Bug 955390 has been marked as a duplicate of this bug. ***

Comment 31 Miroslav Grepl 2013-04-23 08:08:44 UTC
*** Bug 955391 has been marked as a duplicate of this bug. ***

Comment 32 Miroslav Grepl 2013-04-23 08:10:48 UTC
I apologize, the last three bugs are copy/paste issue.

Comment 33 Fedora Update System 2013-05-07 13:38:13 UTC
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

Comment 34 Fedora Update System 2013-05-09 10:01:02 UTC
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).

Comment 35 Fedora Update System 2013-05-16 02:57:09 UTC
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.

Comment 36 poma 2013-05-29 05:32:23 UTC

$ 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

Comment 37 Daniel Walsh 2013-05-29 13:08:51 UTC
3d2d0459904b5bba7ceea726fcd4c274038772f4 fixes this in git.

Comment 38 poma 2013-05-29 16:25:43 UTC
$ 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. ;)


Note You need to log in before you can comment on or make changes to this bug.