Bug 160414
Summary: | upgrade from fc3 to fc4 with yum breaks selinux targeted | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jarkko <jval> | ||||
Component: | selinux-policy-targeted | Assignee: | Daniel Walsh <dwalsh> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | |||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 4 | CC: | 2 | ||||
Target Milestone: | --- | Keywords: | Security | ||||
Target Release: | --- | ||||||
Hardware: | i386 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2005-06-23 12:56:14 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Jarkko
2005-06-14 22:53:41 UTC
I've just been hit by this too. It doesn't seem to be purely yum-related, either. I have two systems, one of which was upgraded using the DVD, and one of which was upgraded using yum. Although selinux is running on the non-yum machine, something definitely isn't right. Suppose I install dovecot: yum install dovecot ... cd /etc/pki ls -aZ dovecot drwxr-xr-x root root root:object_r:cert_t . drwxr-xr-x root root system_u:object_r:cert_t .. -rw-r--r-- root root system_u:object_r:cert_t dovecot-openssl.cnf -rw------- root root root:object_r:cert_t dovecot.pem drwxr-xr-x root root root:object_r:cert_t private The new files have been labelled as cert_t. However, these files should be matching this rule: /etc/pki/dovecot(/.*)? system_u:object_r:dovecot_cert_t (from /etc/selinux/targeted/src/policy/file_contexts/program/dovecot.fc) If these files end up as cert_t, dovecot will not work, because it only has search rights on cert_t: allow dovecot_t cert_t:dir search; On dovecot_cert_t, it has full read rights, which is what is required: allow dovecot_t dovecot_cert_t:dir { read getattr lock search ioctl }; allow dovecot_t dovecot_cert_t:file { read getattr lock ioctl }; Interestingly, relabelling the filesystem doesn't help: yeltsin # restorecon -R -vv /etc/pki restorecon reset /etc/pki/dovecot context root:object_r:cert_t->system_u:object_r:cert_t restorecon reset /etc/pki/dovecot/dovecot.pem context root:object_r:cert_t->system_u:object_r:cert_t restorecon reset /etc/pki/dovecot/private context root:object_r:cert_t->system_u:object_r:cert_t restorecon reset /etc/pki/dovecot/private/dovecot.pem context root:object_r:cert_t->system_u:object_r:cert_t So the user is now system_u, which is fair enough, but the type is still cert_t. One other interesting fact which may help you: the very first time I installed dovecot, the file contexts were set correctly. When I relabelled, the relabelling process changed the contexts from from dovecot_cert_t to cert_t, so spoiling things. Whenever I uninstalled dovecot and reinstalled it, after that, the contexts were wrong! Reinstalled kernel and selinux-policy-targeted (used --force). Relabeled the filesystem three or more times and suddenly things started to work a bit better. (One weird side effect was that I had to run system-config-display and keyboard as those settings changed?). Now I get deny messages only with a few programs. Bringing up ppp0 is one of them. This is what I get when I run "service network start": Jun 20 02:38:22 localhost kernel: audit(1119224302.260:91): avc: denied { search } for pid=6264 comm="pppd" name=net dev=proc ino=-268435434 scontext=root:system_r:pppd_t tcontext=system_u:object_r:proc_net_t tclass=dir Jun 20 02:38:22 localhost kernel: audit(1119224302.260:92): avc: denied { read } for pid=6264 comm="pppd" name=route dev=proc ino=-268434950 scontext=root:system_r:pppd_t tcontext=system_u:object_r:proc_net_t tclass=file Jun 20 02:38:22 localhost kernel: audit(1119224302.260:93): avc: denied { getattr } for pid=6264 comm="pppd" name=route dev=proc ino=-268434950 scontext=root:system_r:pppd_t tcontext=system_u:object_r:proc_net_t tclass=file Jun 20 02:38:22 localhost kernel: audit(1119224302.296:94): avc: denied { read } for pid=6279 comm="ifconfig" name=net dev=proc ino=-268435434 scontext=root:system_r:pppd_t tcontext=system_u:object_r:proc_net_t tclass=dir Jun 20 02:38:22 localhost kernel: audit(1119224302.297:95): avc: denied { search } for pid=6279 comm="ifconfig" name=net dev=proc ino=-268435350 scontext=root:system_r:pppd_t tcontext=system_u:object_r:sysctl_net_t tclass=dir Perhaps something went wrong when I installed the fc4 kernel at fc3. Possibly fc3's selinux policy denied some scriptlet with the kernel install... Hope this information helps... Created attachment 115671 [details]
patch to pppd.te to allow access to proc_net_t.
Added a patch to pppd.te to grant the requested access to proc_net_t.
1) yum install selinux-policy-targeted-sources 2) applied the patch 3) make load Now (running in permissive mode): -- # service network start Bringing up loopback interface: [ OK ] Bringing up interface eth0: [ OK ] Bringing up interface eth1: [ OK ] Bringing up interface ppp0: audit(1119247506.662:52): avc: denied { read } for pid=18898 comm="sh" name=pppoe dev=sda3 ino=1121910 scontext=root:system_r:pppd_t tcontext=system_u:object_r:sbin_t tclass=lnk_file audit(1119247508.133:53): avc: denied { read } for pid=18922 comm="ifconfig" name=net dev=proc ino=-268435434 scontext=root:system_r:pppd_t tcontext=system_u:object_r:proc_net_t tclass=dir audit(1119247508.133:54): avc: denied { search } for pid=18922 comm="ifconfig" name=net dev=proc ino=-268435350 scontext=root:system_r:pppd_t tcontext=system_u:object_r:sysctl_net_t tclass=dir [ OK ] -- When running "service network stop", these get to /var/log/messages: -- Jun 20 09:08:04 localhost kernel: audit(1119247684.128:55): avc: denied { create } for pid=19576 comm="ip" scontext=root:system_r:pppd_t tcontext=root:system_r:pppd_t tclass=netlink_route_socket Jun 20 09:08:04 localhost kernel: audit(1119247684.128:56): avc: denied { setopt } for pid=19576 comm="ip" scontext=root:system_r:pppd_t tcontext=root:system_r:pppd_t tclass=netlink_route_socket Jun 20 09:08:04 localhost kernel: audit(1119247684.128:57): avc: denied { bind } for pid=19576 comm="ip" scontext=root:system_r:pppd_t tcontext=root:system_r:pppd_t tclass=netlink_route_socket Jun 20 09:08:04 localhost kernel: audit(1119247684.128:58): avc: denied { getattr } for pid=19576 comm="ip" scontext=root:system_r:pppd_t tcontext=root:system_r:pppd_t tclass=netlink_route_socket Jun 20 09:08:04 localhost kernel: audit(1119247684.128:59): avc: denied { write } for pid=19576 comm="ip" scontext=root:system_r:pppd_t tcontext=root:system_r:pppd_t tclass=netlink_route_socket Jun 20 09:08:04 localhost kernel: audit(1119247684.128:60): avc: denied { nlmsg_read } for pid=19576 comm="ip" scontext=root:system_r:pppd_t tcontext=root:system_r:pppd_t tclass=netlink_route_socket Jun 20 09:08:04 localhost kernel: audit(1119247684.128:61): avc: denied { read } for pid=19576 comm="ip" scontext=root:system_r:pppd_t tcontext=root:system_r:pppd_t tclass=netlink_route_socket -- I just upgraded to selinux-policy-targeted 1.23.18-12 and I still have the same trouble. I just noticed a comment in file_contexts/file_contexts saying that the last matching specification is to be used. This means that the file contexts are being applied correctly, but the /etc/pki/dovecot rule needs to be moved so that it comes after the /etc/pki rule. I'm not quite sure what has happened here. Is there a single change since FC3 that has caused all these policy-related problems? Alternatively, are the problems with pppd and dovecot just separate bugs which should be filed in Bugzilla individually? Someone said to me at #fedora that initrd might have been somehow broken. That's why I reinstalled the kernel package which rebuilt the initrd. After that I had to relabel multiple times (rebooting every time between relabels), and then the majority of the denies vanished. (I don't know exactly why this helped. Can someone explain this to me?) So somehow the installation of the FC4 kernel (or something related to it) caused this issue. (What could it be? Note that I was running FC3 with selinux targeted policy when I installed the FC4 kernel.) It's true that the pppd and dovecot problems are separate issues from the kernel/initrd failure. But at least the pppd issue got already one patch which solved it partially (it still does not work, but some of the denies are gone)... More patches are needed to solve these deny issues properly... And if someone could explain what went wrong with the kernel, that would be great (does this mean yum upgrade does not work this way - I mean is that what caused the initial problem which caused almost everything to be denied?). We have added more targets in FC4. And we have a period of time where we fix all the problems, just like we did in FC3. If you grab the policy package in devel, I believe both the pppd and dovecot problems are fixed. I will be updateing the FC4 to match this package today. Dan What are the latest AVC messages you are seeing? Dan, Thanks for looking into this. I get these AVC messages when I try to start dovecot. type=PATH msg=audit(1119362155.753:11381101): item=0 name="/etc/pki/dovecot/dovecot.pem" inode=18366 dev=03:03 mode=0100600 ouid=0 ogid=0 rdev=00:00 type=SYSCALL msg=audit(1119362155.753:11381101): arch=40000003 syscall=33 success=no exit=-13 a0=85b0310 a1=4 a2=0 a3=0 items=1 pid=17332 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="dovecot" exe="/usr/sbin/dovecot" type=AVC msg=audit(1119362155.753:11381101): avc: denied { read } for pid=17332 comm="dovecot" name=dovecot.pem dev=hda3 ino=18366 scontext=root:system_r:dovecot_t tcontext=root:object_r:cert_t tclass=file I hope this is clear, if it comes out formatted wrong I will attach it as a file. When I update with your new policy, I will test my box again and see if all the services now come up as expected. If not I can file individual bug reports if that is helpful. Version of selinux-policy-targeted currently installed: -- $ rpm -q selinux-policy-targeted selinux-policy-targeted-1.23.18-12 -- Audit messages at system startup: -- # cat /var/log/messages | grep audit Jun 22 02:02:09 localhost kernel: audit: initializing netlink socket (disabled) Jun 22 02:02:09 localhost kernel: audit(1119394893.525:1): initialized Jun 22 02:02:10 localhost kernel: audit(1119394923.374:2): avc: denied { read } for pid=3065 comm="sh" name=pppoe dev=sda3 ino=1121910 scontext=system_u:system_r:pppd_t tcontext=system_u:object_r:sbin_t tclass=lnk_file Jun 22 02:02:10 localhost kernel: audit(1119394925.022:3): avc: denied { read } for pid=3079 comm="ifconfig" name=net dev=proc ino=-268435434 scontext=system_u:system_r:pppd_t tcontext=system_u:object_r:proc_net_t tclass=dir Jun 22 02:02:10 localhost kernel: audit(1119394925.022:4): avc: denied { search } for pid=3079 comm="ifconfig" name=net dev=proc ino=-268435350 scontext=system_u:system_r:pppd_t tcontext=system_u:object_r:sysctl_net_t tclass=dir -- Audit messages when running "service network stop": -- Jun 22 02:07:25 localhost kernel: audit(1119395245.504:5): avc: denied { create } for pid=4866 comm="ip" scontext=system_u:system_r:pppd_t tcontext=system_u:system_r:pppd_t tclass=netlink_route_socket Jun 22 02:07:25 localhost kernel: audit(1119395245.504:6): avc: denied { setopt } for pid=4866 comm="ip" scontext=system_u:system_r:pppd_t tcontext=system_u:system_r:pppd_t tclass=netlink_route_socket Jun 22 02:07:25 localhost kernel: audit(1119395245.504:7): avc: denied { bind } for pid=4866 comm="ip" scontext=system_u:system_r:pppd_t tcontext=system_u:system_r:pppd_t tclass=netlink_route_socket Jun 22 02:07:25 localhost kernel: audit(1119395245.504:8): avc: denied { getattr } for pid=4866 comm="ip" scontext=system_u:system_r:pppd_t tcontext=system_u:system_r:pppd_t tclass=netlink_route_socket Jun 22 02:07:25 localhost kernel: audit(1119395245.504:9): avc: denied { write } for pid=4866 comm="ip" scontext=system_u:system_r:pppd_t tcontext=system_u:system_r:pppd_t tclass=netlink_route_socket Jun 22 02:07:25 localhost kernel: audit(1119395245.504:10): avc: denied { nlmsg_read } for pid=4866 comm="ip" scontext=system_u:system_r:pppd_t tcontext=system_u:system_r:pppd_t tclass=netlink_route_socket Jun 22 02:07:25 localhost kernel: audit(1119395245.505:11): avc: denied { read } for pid=4866 comm="ip" scontext=system_u:system_r:pppd_t tcontext=system_u:system_r:pppd_t tclass=netlink_route_socket -- Installing the latest version from development: -- # rpm -Uvh selinux-policy-targeted*-1.23.18-15.noarch.rpm Preparing... ########################################### [100%] 1:selinux-policy-targetedwarning: /etc/selinux/targeted/contexts/files/file_contexts saved as /etc/selinux/targeted/contexts/files/file_contexts.rpmsave warning: /etc/selinux/targeted/contexts/files/file_contexts.homedirs saved as /etc/selinux/targeted/contexts/files/file_contexts.homedirs.rpmsave ########################################### [ 50%] 2:selinux-policy-targetedwarning: /etc/selinux/targeted/src/policy/domains/program/pppd.te saved as /etc/selinux/targeted/src/policy/domains/program/pppd.te.rpmsave ########################################### [100%] -- "service network stop" - no audit messages! "service network start" - no audit messages! Seems like the pppd issue is now fixed. Good work! When starting the machine: -- Jun 22 12:00:16 localhost kernel: audit: initializing netlink socket (disabled) Jun 22 12:00:16 localhost kernel: audit(1119430782.860:1): initialized Jun 22 12:00:17 localhost kernel: audit(1119430797.290:2): avc: denied { read } for pid=1496 comm="hwclock" name=ld.so.cache dev=sda2 ino=47879 scontext=syst em_u:system_r:hwclock_t tcontext=system_u:object_r:etc_t tclass=file -- Seems like hwclock is denied which should not happen I guess. Please open other bug reports. This looks like you have a labeling problem restorecon /etc/ld.so.cache will fix it. FYI, the rawhide package fixes the Dovecot issue. I'll open new reports if I notice anything else giving trouble. Thanks for your help with this. |