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