No default labels, is it intentional?
Daniel J Walsh
dwalsh at redhat.com
Tue Jan 15 22:36:44 UTC 2013
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/15/2013 04:22 PM, Dominick Grift wrote:
> On Tue, 2013-01-15 at 15:54 -0500, Daniel J Walsh wrote:
>> 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 at lists.fedoraproject.org
>>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>>>>>>>>
>>>>>>>>
>>>>>>>> -- selinux mailing list selinux at 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 at 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 at 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 at 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
>
>
> -- selinux mailing list selinux at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux
>
It should although not everywhere.
sesearch -T -s unconfined_t | grep quota_db_t
type_transition unconfined_t var_spool_t : file quota_db_t "aquota.group";
type_transition unconfined_t home_root_t : file quota_db_t "aquota.group";
type_transition unconfined_t usr_t : file quota_db_t "aquota.group";
type_transition unconfined_t mail_spool_t : file quota_db_t "aquota.user";
type_transition unconfined_t root_t : file quota_db_t "aquota.group";
type_transition unconfined_t home_root_t : file quota_db_t "aquota.user";
type_transition unconfined_t tmp_t : file quota_db_t "aquota.group";
type_transition unconfined_t tmp_t : file quota_db_t "aquota.user";
type_transition unconfined_t var_t : file quota_db_t "aquota.user";
type_transition unconfined_t mail_spool_t : file quota_db_t "aquota.group";
type_transition unconfined_t boot_t : file quota_db_t "aquota.group";
type_transition unconfined_t etc_t : file quota_db_t "aquota.user";
type_transition unconfined_t mqueue_spool_t : file quota_db_t "aquota.group";
type_transition unconfined_t var_spool_t : file quota_db_t "aquota.user";
type_transition unconfined_t root_t : file quota_db_t "aquota.user";
type_transition unconfined_t mqueue_spool_t : file quota_db_t "aquota.user";
type_transition unconfined_t var_t : file quota_db_t "aquota.group";
type_transition unconfined_t etc_t : file quota_db_t "aquota.group";
type_transition unconfined_t usr_t : file quota_db_t "aquota.user";
type_transition unconfined_t boot_t : file quota_db_t "aquota.user";
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlD12fsACgkQrlYvE4MpobO9hACg6yZRH/CtLkjD5FQg23JIQbRt
Dy8AoOrR01PrDElo2Pdf4WbgvTzWifQx
=mlye
-----END PGP SIGNATURE-----
More information about the selinux
mailing list