Bug 790878 - SELinux is preventing /bin/bash from 'getattr' accesses on the None /etc/locale.conf.
Summary: SELinux is preventing /bin/bash from 'getattr' accesses on the None /etc/loca...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 19
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:76ecb86b67f45b2ca9c3555422b...
Depends On:
Blocks: systemd-RFE
TreeView+ depends on / blocked
 
Reported: 2012-02-15 15:57 UTC by cje
Modified: 2013-05-16 02:59 UTC (History)
13 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:59:28 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description cje 2012-02-15 15:57:52 UTC
libreport version: 2.0.8
executable:     /usr/bin/python
hashmarkername: setroubleshoot
kernel:         3.2.5-3.fc16.x86_64
reason:         SELinux is preventing /bin/bash from 'getattr' accesses on the None /etc/locale.conf.
time:           Wed 15 Feb 2012 15:57:18 GMT

description:
:i think this happened when i tried to apply firewall changes.
:
:SELinux is preventing /bin/bash from 'getattr' accesses on the None /etc/locale.conf.
:
:*****  Plugin catchall (100. confidence) suggests  ***************************
:
:If you believe that bash should be allowed getattr access on the locale.conf <Unknown> 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 service /var/log/audit/audit.log | audit2allow -M mypol
:# semodule -i mypol.pp
:
:Additional Information:
:Source Context                system_u:system_r:firewallgui_t:s0-s0:c0.c1023
:Target Context                system_u:object_r:etc_runtime_t:s0
:Target Objects                /etc/locale.conf [ None ]
:Source                        service
:Source Path                   /bin/bash
:Port                          <Unknown>
:Host                          (removed)
:Source RPM Packages           bash-4.2.20-1.fc16.x86_64
:Target RPM Packages           systemd-37-11.fc16.x86_64
:Policy RPM                    selinux-policy-3.10.0-75.fc16.noarch
:Selinux Enabled               True
:Policy Type                   targeted
:Enforcing Mode                Enforcing
:Host Name                     (removed)
:Platform                      Linux (removed) 3.2.5-3.fc16.x86_64 #1 SMP Thu Feb 9
:                              01:24:38 UTC 2012 x86_64 x86_64
:Alert Count                   6
:First Seen                    Wed 15 Feb 2012 15:55:41 GMT
:Last Seen                     Wed 15 Feb 2012 15:55:42 GMT
:Local ID                      3a8c4ef5-a594-4124-80f6-d03840351dd3
:
:Raw Audit Messages
:type=AVC msg=audit(1329321342.589:4291): avc:  denied  { getattr } for  pid=30339 comm="service" path="/etc/locale.conf" dev=dm-1 ino=136465 scontext=system_u:system_r:firewallgui_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_runtime_t:s0 tclass=filenode=(removed) type=SYSCALL msg=audit(1329321342.589:4291): arch=c000003e syscall=4 success=no exit=-13 a0=21e9560 a1=7fff6a05d8b0 a2=7fff6a05d8b0 a3=8 items=0 ppid=30338 pid=30339 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="service" exe="/bin/bash" subj=system_u:system_r:firewallgui_t:s0-s0:c0.c1023 key=(null)
:
:
:Hash: service,firewallgui_t,etc_runtime_t,None,getattr
:
:audit2allow
:
:
:audit2allow -R
:
:

Comment 1 Daniel Walsh 2012-02-15 19:40:39 UTC
restorecon -R -v /etc/locale.conf

Do you know if this file as created at boot time.

Comment 2 cje 2012-02-16 11:02:16 UTC
hmm.  well, /etc/locale.conf is part of systemd and "rpm -V systemd" doesn't report any modified files.

but the contents of the file are:
LANG=en_GB.utf8

which surely isn't the original contents?

the context certainly isn't correct:

restorecon reset /etc/locale.conf context system_u:object_r:etc_runtime_t:s0->system_u:object_r:locale_t:s0

so maybe this was wrong in the original install (from the live CD) or got messed up when i changed the system/session locale (via gnome settings) or in a subsequent systemd update?  i certainly haven't modified that file manually.

if i can get a VM working i'll see if i can reproduce this.

Comment 3 Miroslav Grepl 2012-02-16 11:30:19 UTC
> if i can get a VM working i'll see if i can reproduce this.

Ok, reopen if this happens again.

Comment 4 cje 2012-02-16 12:45:29 UTC
okay, reproduced.  the file is created when you select a non-default locale in gnome settings -> 'Region and Language' and then click 'Copy Settings' on the 'System' tab to apply those settings to the system.

the file is created with the wrong context.  i think it's created by systemd, so i'm changing the component .. hope that's right.

Comment 5 Michal Schmidt 2012-02-16 13:36:19 UTC
/etc/locale.conf is written by the daemon 'systemd-localed'. The daemon currently runs as init_t.
Ideally it would get its own type - systemd_localed_t.
Then there could be a file transition rule: When systemd_localed_t creates a file in etc_t, it gets labeled locale_t.

Comment 6 Michal Schmidt 2012-02-16 13:44:07 UTC
(In reply to comment #5)
> Then there could be a file transition rule: When systemd_localed_t creates a
> file in etc_t, it gets labeled locale_t.

... but the daemon also writes other files (/etc/vconsole.conf). I don't know if locale_t would be the correct type for them. So the rule may have to be based on the file name. I believe SELinux can do that since F16.

Comment 7 Daniel Walsh 2012-02-16 16:27:32 UTC
Lets add

miscfiles_manage_localization(init_t)
miscfiles_filetrans_named_content(init_t)

For now and then look at breaking out the systemd-local.

Comment 8 Daniel Walsh 2012-02-16 16:28:35 UTC
Michal does systemd init create the file directly named locale.conf or does it create a tmp file and then rename it?

Comment 9 Michal Schmidt 2012-02-16 16:37:17 UTC
hm, it uses a temporary file + rename.

write_env_file():
http://cgit.freedesktop.org/systemd/systemd/tree/src/util.c?id=v43#n957

Comment 10 Michal Schmidt 2012-02-16 17:02:38 UTC
The temporary file name is /etc/.locale.confXXXXXX (where X are random chars).

Comment 11 Daniel Walsh 2012-02-16 17:52:10 UTC
Ok that is a problem, since we can only use constant file names.  If we changed the code to use /etc/.locale.conf.new  Then we could get it labeled correctly.

Comment 12 Miroslav Grepl 2012-02-20 12:59:06 UTC
Michal,
any chance to use locale.conf.new?

Comment 13 Michal Schmidt 2012-02-20 14:01:12 UTC
Yeah, we can change that. There's no danger whatsoever in using the fully predictable name for the temp file under /etc, is there?

[Reassigning to systemd. Should be moved back to selinux-policy once the temp file name is changed as requested.]

Comment 14 Miroslav Grepl 2012-02-20 15:19:37 UTC
Ok, I added file name transition for /etc/.locale.conf.new.

Comment 15 Daniel Walsh 2012-02-20 19:26:01 UTC
No danger, and lots of apps use predictable names in /etc including passwd.

Comment 16 Lennart Poettering 2012-03-12 13:42:14 UTC
Hmm, I am not sure I like this too much. I mean, sure, localed most likely will be the only one writing locale.conf, but that's not really guaranteed, and if everything writes that file with the same temporary name we do have atomicity problems here.

I'd really like to leave the current algorithm (with randomized names) in place. Is there any other way we can find to make things compatible with SELinux here?

Comment 17 Daniel Walsh 2012-03-12 15:27:44 UTC
The following are our options.  

One adopt it from the parent directory.  We could create an /etc/locale directory and then rename the tmp file from there to /etc/locale.conf.

We can write rules to policy that says if a Process A_t creates a file in a directory etc_t then it will create the file labeled locale_t, but this means any file created in etc_t will be labeled locale_t.

We can write rules to policy that says if a Process A_t creates a file in a directory etc_t that is named locale.conf or locale.conf.new but not a random name then it will create the file labeled locale_t.

Or we can write an SELinux aware program that will tell SELinux what to label a file.

Comment 18 Lennart Poettering 2012-03-12 19:23:35 UTC
Hmm, so localed stores exactly two files directly beneath /etc: /etc/locale.conf and /etc/vconsole.conf, and that's it. I think it wouldn't be the worst idea to just label them the same way, since they are frequently changed together anyway (i.e. one selects "german" as keyboard mapping, the other "german" is UI language).

If this is acceptable then the SELinux policy could just say that everything written by localed in /etc gets the same label?

(and i think it is unlikely that it will change anytime soon what the daemon will write).

Comment 19 Dominick Grift 2012-09-14 16:04:06 UTC
I spent a few weeks writing a selinux policy for systemd. It was just to study systemd and to see where we could take advantage of selinux.

I basically created private types for each systemd daemon, helper and systemd owned file. That way i could see exactly what each program is doing to which files.

I see some real advantages of running some helpers and probably all daemons with a private type.

One example is that for example one would need to connect to a systemd-shutdownd unix stream socket to schedule a shutdown.

One needs to connect to systemd via systemds' private sock_file with unix stream socket to restart a service.

Since currently much of systemd is piled into the init_t domain ( which is a unconfined domain type ) we currently cannot make much distinction. If you can connect to init_t via a unix stream socket than from that POV you can reboot as well a restart a service.

Unfortunately i had to put my study on ice since i could not get systemd to shutdown or boot up in enforcing mode because there were no AVC denials for me to work with very early on in the boot process or very late in the shutdown process.

(i tried both with debug shell as well as serial console and came pretty far. Just not far enough)

I would need to read systemd source code and understand the process to be able to make a guess as to what each systemd program might needs to successfuly boot up or shutdown. Unfortunately i am not a programmer and so i kind of hit a dead end there.

Nonetheless, i have learned enough to be able to determine that there could be some real benefits to running at least a select group of systemd daemons and helpers with their own private type.

Comment 20 Daniel Walsh 2013-01-15 01:46:06 UTC
Lennart sure but allowing a domain to create any file in etc_t is also dangerous.

But currently we run most of init processes as init_t and this change would force any file that init_t process ever created in an etc_t directory (/etc) to be created as locale_t.

I just added systemd-localed policy to git, it will show up on Rawhide on the next build

Comment 21 Lennart Poettering 2013-01-15 23:11:05 UTC
Running localed, hostnamed, logind, timedated under their own labels definitely sounds like a good idea.

Hmm, SELinux policy can match wildcards these days, can't it? If so, the prefix of the file names is always stable: "/etc/.locale.conf"

Comment 22 Daniel Walsh 2013-01-15 23:20:20 UTC
This is a kernel issue, it does not support globs or regex.  I guess we could ask the kernel to support something like

".locale.conf*" and then only compare up to the *.  

Fedora 19 currently has

# seinfo -adomain -x | grep systemd_
      systemd_localed_t
      systemd_logger_t
      systemd_logind_t
      systemd_notify_t
      systemd_passwd_agent_t
      systemd_tmpfiles_t

As well as init_t.  :^)

SO I guess we need

hostnamed
and 
timedated

Comment 23 Daniel Walsh 2013-01-15 23:28:36 UTC
Actually systemd_timedatd is currently labeled as gnomeclock_t, which should probably be changed to keep the non gnome people happy.

Comment 24 Eric Paris 2013-01-15 23:30:15 UTC
systemd already has support for this.

Use the same mechanism systemd uses to set the label on all files it creates.  What is it?  label_context_set() ?

Comment 25 Lennart Poettering 2013-01-16 01:10:58 UTC
Hmm, that could work too. We can label the files explicitly when creating them if need us to.

Comment 26 Michal Schmidt 2013-01-16 13:02:20 UTC
(In reply to comment #22)
> This is a kernel issue, it does not support globs or regex.  I guess we
> could ask the kernel to support something like
> 
> ".locale.conf*" and then only compare up to the *.  

I can imagine this feature being useful in policies for other software too. Even if it were not a full-featured glob match and supported only a subset of glob expressions (similar to the limited use of wildcards in ftrace filters, see Documentation/trace/ftrace.txt)

Comment 27 Daniel Walsh 2013-01-16 15:18:18 UTC
My suggestion would be to support just "*" at the end of the name.

If selinux says transition on files /etc/locale.conf*  Then the kernel would 
if matchname[-1]=="*"
    strncmp(newfile,matchname,len(matchname)-1)
else
    strcmp(newfile,matchname);

Only problem with this is matching on files that contain a "*" that you would not want to match, but I think that is a huge corner case.

Comment 28 Miroslav Grepl 2013-01-17 12:04:17 UTC
It would be nice to have it.

Comment 29 Harald Hoyer 2013-02-28 13:12:22 UTC
(In reply to comment #17)
> The following are our options.  
> 
> One adopt it from the parent directory.  We could create an /etc/locale
> directory and then rename the tmp file from there to /etc/locale.conf.
> 
> We can write rules to policy that says if a Process A_t creates a file in a
> directory etc_t then it will create the file labeled locale_t, but this
> means any file created in etc_t will be labeled locale_t.
> 
> We can write rules to policy that says if a Process A_t creates a file in a
> directory etc_t that is named locale.conf or locale.conf.new but not a
> random name then it will create the file labeled locale_t.
> 
> Or we can write an SELinux aware program that will tell SELinux what to
> label a file.

http://cgit.freedesktop.org/systemd/systemd/commit/?id=a5c32cff1f56afe6f0c6c70d91a88a7a8238b2d7
http://cgit.freedesktop.org/systemd/systemd/commit/?id=a860325e7ed7ea2bd688b2f002021123a05af084

Comment 30 Harald Hoyer 2013-02-28 13:15:31 UTC
(In reply to comment #19)
> Unfortunately i had to put my study on ice since i could not get systemd to
> shutdown or boot up in enforcing mode because there were no AVC denials for
> me to work with very early on in the boot process or very late in the
> shutdown process.
> 

Break on shutdown after the pivot_root for Fedora 18:
# mkdir -p /run/initramfs/etc/cmdline.d
# echo "rd.break=pre-shutdown" > /run/initramfs/etc/cmdline.d/debug.conf
# touch /run/initramfs/.need_shutdown

You will get a shell.

Comment 31 Fedora End Of Life 2013-04-03 20:20:51 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Comment 32 Fedora Update System 2013-04-10 20:14:48 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 33 Fedora Update System 2013-04-11 23:27:53 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 34 Fedora Update System 2013-04-16 00:02:25 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.4
then log in and leave karma (feedback).

Comment 35 Fedora Update System 2013-04-18 02:40:08 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 36 Fedora Update System 2013-05-07 13:42:02 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 37 Fedora Update System 2013-05-09 10:03:59 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 38 Fedora Update System 2013-05-16 02:59:28 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.


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