Libguestfs - Jan 2014 - Re: Livecd-creator is disabling selinux

[Moving this to the libguestfs mailing list]

On Mon, Jan 13, 2014 at 03:05:14PM -0500, Daniel J Walsh
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 01/13/2014 11:49 AM, Richard W.M. Jones wrote:
> > On Mon, Jan 13, 2014 at 10:20:22AM -0500, Daniel J Walsh wrote:
> >> Secondly we prevent even unconfined_t from putting down labels on
the
> >> file system that the kernel does not understand.  IE If I am
building a
> >> F21 image on a RHEL6 box, it would blow up in enforcing mode if
run as
> >> unconfined_t.  We added a special policy called livecd_t that is
allowed
> >> to put down labels which the kernel does not understand, and
unconfined_t
> >> will transition to this domain.
> > 
> > Slightly off-topic, but this (in-)ability to label files with labels
which
> > the kernel doesn't know about affects libguestfs negatively too.
Is there
> > some reason why it's bad?
>
> Well we could add a label to libguestfs to allow these labels.  From
> the running kernel point of view you end up with unlabeled_t.
I think it's more complex with libguestfs because of the appliance,
and because libguestfs normally runs with SELinux disabled inside the
appliance.

  [Note to peanut gallery: libguestfs uses and endorses SELinux and
  sVirt to implement containment of qemu *in the host*.  The above
  applies only to the appliance.]

I know you wrote a good blog posting and we have a (very very old)
open bug to fix libguestfs's SELinux support:

  https://bugzilla.redhat.com/show_bug.cgi?id=554829

After thinking about this for some years and Pino Toscano implementing
a new & useful copy-attributes API in libguestfs, I think what we
really want is to copy security.selinux xattr from one file to
another.  This gives us almost all we need, doesn't require us to run
loadpolicy, and should work independent of guest policy.

Luckily for us ... it works!

  $ virt-builder fedora-20
  $ guestfish -a fedora-20.img -i
  ><fs> getxattrs /etc/shadow
  [0] = {
    attrname: security.selinux
    attrval: system_u:object_r:shadow_t:s0\x00
  }
  ><fs> cp /etc/shadow /etc/shadow.copy
  ><fs> setxattr security.selinux system_u:object_r:shadow_t:s0 29
/etc/shadow.copy
  ><fs> getxattrs /etc/shadow.copy [0] = {
    attrname: security.selinux
    attrval: system_u:object_r:shadow_t:s0
  }

Is this expected?  Are we bypassing the kernel/SELinux in some way?
Note that the libguestfs appliance kernel doesn't (AFAIK) know about
the system_u:object_r:shadow_t:s0 label.
> We also would like to prevent users from making mistakes like
> assigning httpd_t to a file when it is a process type.
>
> SELinux is going to check before you put the label down unless you have the
> mac_admin capability.
Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/13/2014 04:17 PM, Richard W.M. Jones wrote:
> [Moving this to the libguestfs mailing list]
> 
> On Mon, Jan 13, 2014 at 03:05:14PM -0500, Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> On 01/13/2014 11:49 AM, Richard W.M. Jones wrote:
>>> On Mon, Jan 13, 2014 at 10:20:22AM -0500, Daniel J Walsh wrote:
>>>> Secondly we prevent even unconfined_t from putting down labels
on
>>>> the file system that the kernel does not understand.  IE If I
am
>>>> building a F21 image on a RHEL6 box, it would blow up in
enforcing
>>>> mode if run as unconfined_t.  We added a special policy called
>>>> livecd_t that is allowed to put down labels which the kernel
does not
>>>> understand, and unconfined_t will transition to this domain.
>>> 
>>> Slightly off-topic, but this (in-)ability to label files with
labels
>>> which the kernel doesn't know about affects libguestfs
negatively too.
>>> Is there some reason why it's bad?
>> 
>> Well we could add a label to libguestfs to allow these labels.  From
the
>> running kernel point of view you end up with unlabeled_t.
> 
> I think it's more complex with libguestfs because of the appliance, and
> because libguestfs normally runs with SELinux disabled inside the 
> appliance.
> 
> [Note to peanut gallery: libguestfs uses and endorses SELinux and sVirt to
> implement containment of qemu *in the host*.  The above applies only to the
> appliance.]
> 
> I know you wrote a good blog posting and we have a (very very old) open bug
> to fix libguestfs's SELinux support:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=554829
> 
> After thinking about this for some years and Pino Toscano implementing a
> new & useful copy-attributes API in libguestfs, I think what we really
want
> is to copy security.selinux xattr from one file to another.  This gives us
> almost all we need, doesn't require us to run loadpolicy, and should
work
> independent of guest policy.
> 
> Luckily for us ... it works!
> 
> $ virt-builder fedora-20 $ guestfish -a fedora-20.img -i
>> <fs> getxattrs /etc/shadow
> [0] = { attrname: security.selinux attrval:
> system_u:object_r:shadow_t:s0\x00 }
>> <fs> cp /etc/shadow /etc/shadow.copy <fs> setxattr
security.selinux
>> system_u:object_r:shadow_t:s0 29 /etc/shadow.copy <fs> getxattrs
>> /etc/shadow.copy [0] = {
> attrname: security.selinux attrval: system_u:object_r:shadow_t:s0 }
> 
> Is this expected?  Are we bypassing the kernel/SELinux in some way? Note
> that the libguestfs appliance kernel doesn't (AFAIK) know about the
> system_u:object_r:shadow_t:s0 label.
> 
>> We also would like to prevent users from making mistakes like assigning
>> httpd_t to a file when it is a process type.
>> 
>> SELinux is going to check before you put the label down unless you have
>> the mac_admin capability.
> 
> Rich.
> 
That is correct, and what you are doing is correct.  In libguestfs case there
is no reason to load_policy in the guest.  As long as you don't force the
host
to setenforce 0.  Setting a XAttr to anything, is ok on an SELinux disabled
system, which is why this is working for you.  As long as libguestfs maintains
the SELinux labels inside the guest, it is perfect.

Thanks.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLVTIQACgkQrlYvE4MpobNbjQCeMCd2oNg5VT9n3h0QEuQVKlaf
T1UAni/ZEXcgteDI7qKRLVJKi5ppFZbB
=jQvP
-----END PGP SIGNATURE-----