On Tue, 2013-01-15 at 09:58 -0500, Daniel J Walsh wrote: > On 01/15/2013 09:15 AM, Dominick Grift wrote: > > On Tue, 2013-01-15 at 14:11 +0100, Göran Uddeborg wrote: > >> I'm running a "restorecon -n -R -v /" from cron once a month, just to be > >> careful and know what is happening. Last night when it ran, I got a lot > >> of error messages like these: > >> > >> restorecon: Warning no default label for /dev/pts/3 > >> > >> and > >> > >> restorecon: Warning no default label for /tmp/efs0YYVa79.html > >> > >> There were a couple for things in /dev, and lots of them for things in > >> /tmp. > >> > >> I have lately been upgrading bit by bit to Fedora 18 (the beta, strictly > >> speaking, since the final release isn't officially out at the time of > >> this writing), so I assume the new message is related to these upgrades. > >> But why? When I list file contexts, I see rules like this: > >> > >> /dev/pts(/.*)? all files > >> <<None>> > >> > >> So I guess it is not a simple mistake. But what is the reason? Why > >> don't some /dev entries, and almost the entire /tmp directory, have any > >> default context any more? > > > > It has to do with some optional security models like mcs, mls and ubac and > > the nature of their security attributes i believe > > > > For example if you create a file in /tmp with a compartment of s0:c23 then > > you do not want a relabel to reset it because that would declassify the > > file back to s0 > > > > SELinux cannot determine that the file should be labeled s0:c23 because a > > unprivileged user with access to the compartment decided that > > > > So by ignoring the context altogether you can be sure that the file will > > not get declassified by restorecon/fixfiles > > > > So you will see this in public places like /tmp etc. > > > > There is a similar issue with types. Users may have some discretion over > > select types to relabel to and from. SELinux cannot determine that a user > > decided to label from example file ~/bla type httpd_user_content_t. > > > > So with types there is a different approach: some types are declared > > customizable types. If a file has a customizable type then SELinux will not > > try to relabel it (so that it wont get unintentionally declassified) unless > > you use the -F flag. > > > > The identity field by default does not get reset unless one uses restorecon > > with the -F flag > > > > With MLS security models processes are forced to operate on specified > > security levels for the sake of enforcing confidentiality. Files that may > > be affected and are in public places are not flagged to be reset with the > > <<None>> > > > > Disclaimer: this is my understanding of the issue but i might be wrong > > > > > > > >> -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx > >> https://admin.fedoraproject.org/mailman/listinfo/selinux > > > > > > -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx > > https://admin.fedoraproject.org/mailman/listinfo/selinux > > > Yes the basic idea is in certain directories like mnt_t, tmp_t, tmpfs_t we do > not have a standard definition of content in these directories. So <<none>> > says any content could be here, so don't change the labels. For example a > user does cp -a ~/.ssh /tmp Would move ssh_home_t content to /tmp, if you ran > restorecon on it and we had default label of tmp_t or user_tmp_t, then all > apps could read tmp_t could not read the content. > > Modern restorecon in RHEL7 and Latest Fedoras does not change any components > of the security context other then the type field. unless you specify force. > This is something we want avoid as we move forward with MCS labeling and MLS > Labeling. If you use containers or static labeling for virtual machines, you > do not want restorecon changing the MLS/MCS field. > > The reason you are noticing this is we added an error check to restorecon to > tell the user that restorecon /mnt/foobar did not do anything. > > restorecon -R /mnt > > Will not output the error, since we wanted to quiet the noise, but if you get > verbose, you will get the noise. I guess we could add a -vv for realy > verbose, if the message is aggravating. By the way, we probably want to not relabel content in /var/lib/libvirt/filesystems. I did a relabel and all my container contexts were reset -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
