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(a)lists.fedoraproject.org
> >>>>
https://admin.fedoraproject.org/mailman/listinfo/selinux
> >>>
> >>>
> >>> -- selinux mailing list selinux(a)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