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