No default labels, is it intentional?

[Dominick Grift]

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 at lists.fedoraproject.org 
> >> https://admin.fedoraproject.org/mailman/listinfo/selinux
> > 
> > 
> > -- selinux mailing list selinux at lists.fedoraproject.org 
> > 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