On Tue, 2013-01-15 at 17:36 -0500, Daniel J Walsh wrote:
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@lists.fedoraproject.org >>>> https://admin.fedoraproject.org/mailman/listinfo/selinux >>> >>> >>> -- selinux mailing list selinux@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@lists.fedoraproject.org
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@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";
Yes strange though that even though there is a transition and fc spec that somehow still the file ended up with the wrong context. In the end i just gave up and cheated a bit by disabling quota and then using chcon the db files and then re-enabling quota without running quotacheck after wards ( that would have probably changed the context again )
Whats even stranger is that on an other identical system quotacheck did create it with the proper context (but there it was run by sysadm_t instead of unconfined_t)