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 : :
restorecon -R -v /etc/locale.conf Do you know if this file as created at boot time.
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.
> if i can get a VM working i'll see if i can reproduce this. Ok, reopen if this happens again.
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.
/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.
(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.
Lets add miscfiles_manage_localization(init_t) miscfiles_filetrans_named_content(init_t) For now and then look at breaking out the systemd-local.
Michal does systemd init create the file directly named locale.conf or does it create a tmp file and then rename it?
hm, it uses a temporary file + rename. write_env_file(): http://cgit.freedesktop.org/systemd/systemd/tree/src/util.c?id=v43#n957
The temporary file name is /etc/.locale.confXXXXXX (where X are random chars).
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.
Michal, any chance to use locale.conf.new?
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.]
Ok, I added file name transition for /etc/.locale.conf.new.
No danger, and lots of apps use predictable names in /etc including passwd.
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?
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.
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).
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.
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
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"
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
Actually systemd_timedatd is currently labeled as gnomeclock_t, which should probably be changed to keep the non gnome people happy.
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() ?
Hmm, that could work too. We can label the files explicitly when creating them if need us to.
(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)
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.
It would be nice to have it.
(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
(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.
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
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.4 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).
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.