-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/15/2013 10:03 AM, Dominick Grift wrote: > 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 > Really, I don't see that # restorecon -R -v /var/lib/libvirt/filesystems/ # ls -lZ /var/lib/libvirt/filesystems/ drwxr-xr-x. root root system_u:object_r:svirt_lxc_file_t:s0:c1,c2 apache1 drwxr-xr-x. root root system_u:object_r:svirt_lxc_file_t:s0:c1,c2 container1 drwxr-xr-x. root root system_u:object_r:svirt_lxc_file_t:s0:c0.c1023 dan drwxr-xr-x. root root system_u:object_r:svirt_lxc_file_t:s0:c0.c1023 myapache drwxr-xr-x. root root system_u:object_r:svirt_lxc_file_t:s0:c0.c1023 mymysql -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlD1cXUACgkQrlYvE4MpobO39gCfQ8TFEV9WJ+RXw8K+iAhVYvVM 2WEAnisF73lXQzpdWYG/D00JJoXSCHT4 =5Pqg -----END PGP SIGNATURE----- -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
