-----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(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
>>
>
> 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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
Right , is fixfiles onboot doing a force? If it is, that is a bug.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iEYEARECAAYFAlD1weoACgkQrlYvE4MpobMexgCdEH+1T6U39+mX5/yjKPpV4cYB
lagAn22JhANvswewyeXme1fF192MqG8F
=OwBe
-----END PGP SIGNATURE-----