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.
I guess it is. I had to try fixfiles onboot because quotacheck kept
creating aquota.user with the wrong type and i was denied access to
restore it ( turned out fixfiles onboot wasnt allowed it either ) we
probably want to make sure that quotacheck run by unconfined_t creates
quota db files with the proper context