| Summary: | SELinux is preventing /sbin/chkconfig from 'getattr' accesses on the file /etc/rc.d/init.d/lvm2-monitor. | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Luya Tshimbalanga <luya> |
| Component: | selinux-policy | Assignee: | Miroslav Grepl <mgrepl> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 15 | CC: | dwalsh, elad, eparis, icj, jmorris, jsmith.fedora, lpoetter, luya, mgrepl, michel, notting, orangesunny, sdsmall, stephent98, vonbrand, watzkej |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | setroubleshoot_trace_hash:b3235fcf04a0cc9619ef9274437409043e2d423be822813b49d990e467c4d0a3 | ||
| Fixed In Version: | selinux-policy-3.9.16-15.fc15 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-04-15 21:33:00 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
Luya can you run this in permissive mode, and see what else gnomeclock does. I have a fealing it is turning on the ntp init script. Which means it is going to need
allow gnomeclock_t etc_t:dir { write remove_name add_name };
allow gnomeclock_t etc_t:lnk_file { create unlink };
Dan, good feeling. #============= gnomeclock_t ============== allow gnomeclock_t etc_t:lnk_file create; from another bug report. *** Bug 675399 has been marked as a duplicate of this bug. *** *** Bug 675640 has been marked as a duplicate of this bug. *** *** Bug 675641 has been marked as a duplicate of this bug. *** *** Bug 675642 has been marked as a duplicate of this bug. *** *** Bug 675644 has been marked as a duplicate of this bug. *** *** Bug 675643 has been marked as a duplicate of this bug. *** *** Bug 675647 has been marked as a duplicate of this bug. *** Miroslav lets add the code for now so people can use gnomeclock but I think we need to look into more secure mechanisms for this. I guess the more secure mechanism would be to label the link ntpd_exec_script_t and then only allow gnome_clock_t to create that link and then only allow apps that start ntpd_exec_script_t to read the link. Although this would allow gnomeclock to setup random links on other init scripts and unconfined domains would start them. Another option would be to some how add an access check on the creation of a link file based on the target of the link. Allow gnomeclock to create a link labeled etc_t but only if it points at ntpd_initrc_exec_t. Can we bring the systemd people into this? Maybe they have a better idea how this can be handled sanely? One of the problems here is how chckonfig works - it does ordering of services as well. So if you change a service with LSB dependencies, it can re-order *other* services relative to the new one that you're enabling. That's why it's reading all the services. The real problem is chkconfig creating and deleting link files. gnomeclock wants to configure ntpd to either start/stop at boot time, so it is doing a chkconfig ntpd on Which is creating a link file in /etc/rc.*/ This link file is labeled etc_t and could point anywhere. With current policy we would have to allow gnomeclock_t to create etc_t:lnk_file. By doing this gnomeclock_t could cause any service on the system to start/stop on the next boot. Eric is asking as we move forward will their be a better way to tell systemd to start and stop a service rather then setting up symbolic links in random directories. Then we could write a policy that would allow systemd decide which domains are allowed to configure which services. gnomeclock_t is allowed to configure ntpd_exec_t but not iptables_exec_t. *** Bug 676496 has been marked as a duplicate of this bug. *** Given that ntpd already ships native systemd unit files I think a simple fix could be to use "systemctl enable ntpd.service" in the applet code. That said Bill commited a fix very recently to chkconfig which forwards "chkconfig on" to "systemctl enable" anyway if there is a native service file around. This means the problem should be fixed too, even if the clock applet does not actually use systemctl enable directly. So I guess this bug can be closed as soon as the new chkconfig version hits F15 and is tested to work as intended for this case. Lennart, Is there any kind of authorization going on between system services and who can start and stop a service through systemd? The goal with the SELinux policy is to make sure that gnome-clock can only start and stop ntpd service but can not touch sshd or httpd, or modify anything else systemd controls. (In reply to comment #18) > Lennart, Is there any kind of authorization going on between system services > and who can start and stop a service through systemd? The goal with the > SELinux policy is to make sure that gnome-clock can only start and stop ntpd > service but can not touch sshd or httpd, or modify anything else systemd > controls. Well, you can start services via "systemctl start" only if you are root, if that's what you are asking. Beyond that there is no authorization. The baseos have asked us to make this more finegrained via PK. So that you can allow unprivileged users to start some service A, but only A. However I am not really happy with adding a PK dependency to systemd. Note that if a service is triggered by something else but invoking "systemctl start" (or something equivalent) it may very likely be that some unprivileged user action causes a service to start: example: an unprivileged user opens nautilus and udisks is started via dbus activation which is forwarded to systemd. My goal would be to put SELinux controls into systemd, so it could ask can gnomeclock_t transition to ntpd_t yes ... Can gnomeclock_t transition to sshd_t no, block. Since systemd already has SELinux awareness, This could be a simple check on starting services, and would just allow on disabled/permissive machines. So adding PK to systemd could get us this, but the enforcement choices then become configuration rather than compiled in checks. Making avc_has_perm() type calls directly in systemd makes it a more traditional userspace object manager with fixed compiled in checks..... I don't know which I like better. I'm still undecided on my feelings for PK. (I do feel like PK has a distint benefit of doing of a lot of the heavy lifting for you) How would this look like in detail? Note that "systemctl enable" actually does all its stuff on the client side, there is no D-Bus calls involved (well, there is a final query sent to systemd to ask for a config reload). So for "systemctl enable foo.service" we'd look for "foo.service", read the label from it, see if the transition is allowed to it and then work accordingly? That should be fairly simple. Maybe we just label the foo.service script and run systemctl under gnomeclock_systemctl_t and allow it to read ntp.service script? The problem I see is you don't know what the final domain will be. With sysvinit scripts we are just labeling the init script and say something like gnomeclock_t can transition to initrc_t through ntpd_initrc_exec_t I am trying to test it using runcon:
I have
---
type gnomeclock_systemctl_t;
domain_type(gnomeclock_systemctl_t)
type ntpd_systemd_exec_t;
files_type(ntpd_systemd_exec_t)
type systemd_systemctl_exec_t;
corecmd_executable_file(systemd_systemctl_exec_t)
domtrans_pattern(gnomeclock_t, systemd_systemctl_exec_t,gnomeclock_systemctl_t)
role system_r types gnomeclock_systemctl_t;
---
# ls -Z /lib/systemd/system/ntpd.service
... ntpd_system_exec_t
# ls -Z /sbin/systemctl
.. systemd_systemctl_exec_t
--
then I run runcon on a test script which contains
exec systemctl enable ntpd.service
---
And I am seeing
allow gnomeclock_systemctl_t ntpd_systemd_exec_t:file { read getattr open };
allow gnomeclock_systemctl_t etc_t:lnk_file { read create };
Also /lib/systemd/system/* files should be labeled as "bin_t" since gnomeclock_systemctl_t domain is not allowed to read "bin_t" label.
> Also /lib/systemd/system/* files should be labeled as "bin_t" since
> gnomeclock_systemctl_t domain is not allowed to read "bin_t" label.
Which is what we want.
I would label them all as systemd_exec_t, and not allow the reading of those files. The problem with this is gnomeclock could direct systemctl to read any other file that gnomeclock_systemctl_t is allowed to read and try to fool it, I guess as long as gnomeclock_systemctl_t can not read anything that gnomeclock_t can write, it is fairly secure. And no code changes. *** Bug 680760 has been marked as a duplicate of this bug. *** I am testing a patch which adds the following transitions gnomeclock_t -> systemd_systemctl_exec_t -> gnomeclock_systemctl_t and adds a new type for unit files located in /lib/systemd/system directory systemd_unit_file_t (instead of systemd_exec_t or bin_t) and add a new type for ntpd unit file ntpd_systemd_unit_file_t which can be read by gnomeclock_systemctl_t domain. Dan, I am also thinking about making systemd module as base module. Sounds good. I think we should bring up a discussion on the name of these things on the refpolicy list. (In reply to comment #30) > > Sounds good. I think we should bring up a discussion on the name of these > things on the refpolicy list. Yes. I also need to send a systemd patch to upstream. *** Bug 681035 has been marked as a duplicate of this bug. *** *** Bug 681034 has been marked as a duplicate of this bug. *** This is still happening as of today -- any chance we could get this fixed? I was testing a patch and will add it to the next F15 release. *** Bug 694315 has been marked as a duplicate of this bug. *** *** Bug 694316 has been marked as a duplicate of this bug. *** *** Bug 674032 has been marked as a duplicate of this bug. *** *** This bug has been marked as a duplicate of bug 684069 *** I did a scratch build which should fix this issue. http://koji.fedoraproject.org/koji/taskinfo?taskID=2981608 Could you test it? *** Bug 684069 has been marked as a duplicate of this bug. *** (In reply to comment #40) > I did a scratch build which should fix this issue. > > http://koji.fedoraproject.org/koji/taskinfo?taskID=2981608 > > Could you test it? After attempting to enable ntpd from gnome clock: Bug 694473 - SELinux is preventing /bin/systemctl from 'search' accesses on the directory /sys. Bug 694474 - SELinux is preventing /bin/systemctl from 'search' accesses on the directory /sys/fs/cgroup. selinux-policy-3.9.16-13.fc15.noarch selinux-policy-targeted-3.9.16-13.fc15.noarch Yes, I am also seeing these msgs. But it should work for you. Probably can dontaudit for now. (In reply to comment #43) > Yes, I am also seeing these msgs. But it should work for you. OK. I thought ntpd would be started immediately. After rebooting, ntpd is running, so it does indeed work. [joeblow@fir ~]$ systemctl status ntpd.service ntpd.service - Network Time Service Loaded: loaded (/lib/systemd/system/ntpd.service) Active: active (running) since Thu, 07 Apr 2011 10:52:21 -0700; 5min ago Main PID: 835 (ntpd) CGroup: name=systemd:/system/ntpd.service └ 835 /usr/sbin/ntpd -n -u ntp:ntp -g Fixed in selinux-policy-3.9.16-14.fc15 selinux-policy-3.9.16-14.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/selinux-policy-3.9.16-14.fc15 Package selinux-policy-3.9.16-14.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.9.16-14.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/selinux-policy-3.9.16-14.fc15 then log in and leave karma (feedback). (In reply to comment #48) > Package selinux-policy-3.9.16-14.fc15: This update fixed the issue. Looking into sealert, lwm2-monitor access alert no longer appears. selinux-policy-3.9.16-15.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/selinux-policy-3.9.16-15.fc15 selinux-policy-3.9.16-15.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report. |
SELinux is preventing /sbin/chkconfig from 'getattr' accesses on the file /etc/rc.d/init.d/lvm2-monitor. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that chkconfig should be allowed getattr access on the lvm2-monitor 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 chkconfig /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:gnomeclock_t:s0-s0:c0.c1023 Target Context system_u:object_r:initrc_exec_t:s0 Target Objects /etc/rc.d/init.d/lvm2-monitor [ file ] Source chkconfig Source Path /sbin/chkconfig Port <Unknown> Host (removed) Source RPM Packages chkconfig-1.3.49-1.fc15 Target RPM Packages lvm2-2.02.82-2.fc15 Policy RPM selinux-policy-3.9.13-8.fc15 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 2.6.37-2.fc15.i686 #1 SMP Fri Jan 7 15:46:20 UTC 2011 i686 i686 Alert Count 44 First Seen Thu 03 Feb 2011 11:24:45 PM PST Last Seen Tue 22 Feb 2011 11:26:26 PM PST Local ID 9e52c430-ec02-4b16-81a8-f54e5009a309 Raw Audit Messages type=AVC msg=audit(1298445986.341:450): avc: denied { getattr } for pid=3213 comm="chkconfig" path="/etc/rc.d/init.d/lvm2-monitor" dev=dm-0 ino=263664 scontext=system_u:system_r:gnomeclock_t:s0-s0:c0.c1023 tcontext=system_u:object_r:initrc_exec_t:s0 tclass=file type=SYSCALL msg=audit(1298445986.341:450): arch=i386 syscall=stat64 success=no exit=EACCES a0=bfb09efc a1=bfb09df0 a2=4fcafff4 a3=3 items=0 ppid=3211 pid=3213 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=chkconfig exe=/sbin/chkconfig subj=system_u:system_r:gnomeclock_t:s0-s0:c0.c1023 key=(null) Hash: chkconfig,gnomeclock_t,initrc_exec_t,file,getattr audit2allow #============= gnomeclock_t ============== allow gnomeclock_t initrc_exec_t:file getattr; audit2allow -R #============= gnomeclock_t ============== allow gnomeclock_t initrc_exec_t:file getattr;