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
