-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Smalley wrote: > On Fri, 2007-12-21 at 09:52 -0500, Daniel J Walsh wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Doing this I believe I found a bug in bug in SELinux, that I am not >> sure how we fix. >> >> Steps to produce bug. >> >> Build and install >> >> http://people.fedoraproject.org/~dwalsh/SELinux/example-1.0-0.fc9.src.rpm >> >> This will install a daemon program >> >> /usr/sbin/example >> /var/spool/example >> /etc/init.d/example >> >> All of these should be labeled correctly >> >> Now start the daemon >> # rpm -Uhv example-1.0-0.fc9.noarch.rpm >> # service example start >> >> This will only create a pid file /var/run/example.pid >> >> Now make sure everything is labeled correctly >> >> # ls -ldZ /usr/sbin/example /etc/init.d/example /var/spool/example/ >> /var/run/example.pid >> - -rwxr-xr-x root root system_u:object_r:example_script_exec_t >> /etc/init.d/example >> - -rwxr-xr-x root root system_u:object_r:example_exec_t /usr/sbin/example >> - -rw-r--r-- root root system_u:object_r:example_var_run_t >> /var/run/example.pid >> drwxr-xr-x root root system_u:object_r:example_spool_t /var/spool/example/ >> >> Touch a file in /var/spool/example to make sure rpm does not remove with >> the package >> >> # touch /var/spool/example/example.tmp >> >> Now I am going to test the uninstall of the package. >> >> >> rpm -e example >> >> ls -ldZ /usr/sbin/example /etc/init.d/example /var/spool/example/ >> /var/run/example.pid >> ls: cannot access /usr/sbin/example: No such file or directory >> ls: cannot access /etc/init.d/example: No such file or directory >> - -rw-r--r-- root root system_u:object_r:unlabeled_t >> /var/run/example.pid >> drwxr-xr-x root root system_u:object_r:var_spool_t /var/spool/example/ >> >> # restorecon -R -v /var/run/example.pid >> # ls -lZ /var/run/example.pid >> - -rw-r--r-- root root system_u:object_r:unlabeled_t >> /var/run/example.pid >> >> It leaves the pid file as unlabeled_t, this is because >> >> /var/run/.*\.*pid <<none>> >> >> Which tells restorecon to not change any context on a pid file. But >> leaving the file as unlabeled_t causes other problems. > > Interestingly though, there are specific entries for specific pid files > in the .fc files. In which case I'm not sure why we retain the above - > the original point of marking /var/run pid files with <<none>> was > because those files are runtime files and thus just labeled based on > type transitions when they are created, and we didn't want > setfiles/restorecon to clobber those labels. But if we have specific > entries for the individual files (because they actually do have > meaningful and predictable names, unlike /tmp files), then we don't > really buy much by having the <<none>> entry. > I am going to remove that mapping. All domains that create a pid file should have a file context that matches. >> Now I reinstall the package >> >> # rpm -Uhv >> /home/devel/dwalsh/sources/RPMS/noarch/example-1.0-0.fc9.noarch.rpm >> Preparing... ########################################### >> [100%] >> 1:example ########################################### >> [100%] >> /sbin/restorecon set context >> /var/run/example.pid->system_u:object_r:example_var_run_t:s0 >> failed:'Permission denied' >> >> AVC is generated >> >> time->Thu Dec 20 19:28:50 2007 >> type=PATH msg=audit(1198196930.130:1540): item=0 >> name="/var/run/example.pid" inode=3178877 dev=fd:00 mode=0100644 ouid=0 >> ogid=0 rdev=00:00 obj=system_u:object_r:example_var_run_t:s0 >> type=CWD msg=audit(1198196930.130:1540): cwd="/" >> type=SYSCALL msg=audit(1198196930.130:1540): arch=40000003 syscall=227 >> success=no exit=-13 a0=bfcbd7e0 a1=1417c1 a2=ba1ed1e0 a3=27 items=1 >> ppid=23898 pid=23928 auid=3267 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 >> sgid=0 fsgid=0 tty=pts2 comm="restorecon" exe="/sbin/setfiles" >> subj=unconfined_u:unconfined_r:setfiles_t:s0-s0:c0.c1023 key=(null) >> type=AVC msg=audit(1198196930.130:1540): avc: denied { relabelto } for >> pid=23928 comm="restorecon" name="example.pid" dev=dm-0 ino=3178877 >> scontext=unconfined_u:unconfined_r:setfiles_t:s0-s0:c0.c1023 >> tcontext=system_u:object_r:example_var_run_t:s0 tclass=file > > That doesn't seem to match the policy, since setfiles_t does have > relabelto for all file types, and it has relabelfrom for unlabeled_t > AFAICS. And it has the attribute needed to relabel files with different > SELinux user identities. > >> If I pipe this to audit2why >> type=AVC msg=audit(1198196930.130:1540): avc: denied { relabelto } for >> pid=23928 comm="restorecon" name="example.pid" dev=dm-0 ino=3178877 >> scontext=unconfined_u:unconfined_r:setfiles_t:s0-s0:c0.c1023 >> tcontext=system_u:object_r:example_var_run_t:s0 tclass=file >> Was caused by: >> Unknown - would be allowed by active policy >> Possible mismatch between this policy and the one under which the >> audit message was generated. >> Possible mismatch between current in-memory boolean settings vs. >> permanent ones. > > So userland's interpretation of the policy doesn't match the kernel's > interpretation, or they aren't actually seeing the same policy. Not > good. > >> If I run restorecon on it now, it is fine. > > That's interesting - does it run in a different context when run > interactively than from rpm? >> If I do the exact same steps above, but change the context on >> /var/run/example.pid to say bin_t. >> Yes I guess it does, rpm transisitions to setfiles_t while unconfined_t stays as unconfined_t. Although the kernel definitely understands the example_var_run_t is a valid file context, when run from unconfined_t. >> The install happens successfully. > > Hmmm..which seems to tie it to the fact that the file was unlabeled (or > more precisely, had an invalidated SID). Yet the denial itself wasn't > on the unlabeled SID but on the new label. > >> It seems that during the rpm update the policy in the kernel is >> different then when it completes. All the postinstall is doing is >> >> # semodule -s targeted -i example.pp >> followed by a fixfiles on the files in example.spec >> >> Why this would work outside the rpm transaction but not inside is the >> bug. Why does it work with the label of bin_t, but not when it is >> labeled unlabeled_t? > > I agree it shouldn't differ, so this suggests a bug in the kernel's > handling of inodes with invalidated SIDs. > > We should try to track that down regardless, but one thing that might > change the situation would be the old patch I had to retain invalidated > contexts in the SID table and then turn them back into valid SIDs upon > policy reload that make them valid once again. That avoided the whole > unlabeled_t state for such files. That patch actually had two logical > changes within it, one to support preservation of such invalidated > contexts and one to let privileged programs (ala rpm) set invalid > contexts in the first place (so that they could set down the context > before loading the policy module). The latter part was the more > controversial piece and could be removed. > Of course the second part has always been requested by Red Hat/RPM maintainers in order to have rpm do a better job of placing the file context on disk in the first place. semodule -r policy causing things like processes to go wild with unlabeled_t and file context becoming invalidated, so other confined domains, loose access is a hinderence to using policy in rpm. Since if I uninstall the apache policy. All apps that rely on the files will suddenly stop working. I have seen processes go to 100 CPU utilization when they become unlabeled_t. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHa+YdrlYvE4MpobMRAptPAJ0avXIkMHKDBnl7VBYrOzVL9xDR9gCfYW7W WLRFWR8JfbXDuWyNQwIv670= =oRLd -----END PGP SIGNATURE----- -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
