-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/15/2013 02:28 PM, Dominick Grift wrote:
On Tue, 2013-01-15 at 20:23 +0100, Dominick Grift wrote:
On Tue, 2013-01-15 at 10:10 -0500, Daniel J Walsh wrote:
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@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/selinux
-- selinux mailing list selinux@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
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
I did see it but i did a fixfiles onboot
# pwd /var/lib/libvirt/filesystems/container1/etc/httpd/conf [root@virt conf]# ls -alZ drwxr-xr-x. root root system_u:object_r:svirt_lxc_file_t:s0:c1,c2 . drwxr-xr-x. root root system_u:object_r:svirt_lxc_file_t:s0:c1,c2 .. -rw-r--r--. root root system_u:object_r:svirt_lxc_file_t:s0:c1,c2 httpd.conf -rw-r--r--. root root system_u:object_r:svirt_lxc_file_t:s0:c1,c2 magic [root@virt conf]# restorecon -R -v -F httpd.conf restorecon reset /var/lib/libvirt/filesystems/container1/etc/httpd/conf/httpd.conf context system_u:object_r:svirt_lxc_file_t:s0:c1,c2->system_u:object_r:virt_var_lib_t:s0
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Right , is fixfiles onboot doing a force? If it is, that is a bug.