No default labels, is it intentional?

[Dominick Grift]

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