Re: No default labels, is it intentional?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----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@xxxxxxxxxxxxxxxxxxxxxxx 
>>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx 
>>>>>>>> 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@xxxxxxxxxxxxxxxxxxxxxxx
>>> 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@xxxxxxxxxxxxxxxxxxxxxxx 
> 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-----
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux



[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux