Security Enhanced Linux
What's New
Frequently Asked Questions
Background
Documents
License
Download
Participating
Mail List
Archives
Remaining Work
Contributors
Related Work
Press Releases
Information Assurance Research
NIARL In-house Research Areas
Mathematical Sciences Program
Sabbaticals
Computer & Information Sciences Research
Technology Transfer
Advanced Computing
Advanced Mathematics
Communications & Networking
Information Processing
Microelectronics
Other Technologies
Technology Fact Sheets
Publications
Related Links
|
SELinux Mailing ListRe: I have been working on a example policy/rpm package to demontrate how to ship SELinux policy in an RPM
From: Daniel J Walsh <dwalsh_at_redhat.com>
Date: Fri, 21 Dec 2007 11:13:18 -0500
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 > > 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-----
iD8DBQFHa+YdrlYvE4MpobMRAptPAJ0avXIkMHKDBnl7VBYrOzVL9xDR9gCfYW7W
WLRFWR8JfbXDuWyNQwIv670=
-- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.Received on Fri 21 Dec 2007 - 11:14:06 EST |
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |