Libguestfs - May 2014 - Re: Labelling /etc/resolv.conf (rh#1089100)

Hi,

I was investigating rh#1089100, which is about /etc/resolv.conf not 
being properly SELinux-labelled.

Basically the problem is due to /etc/resolv.conf in the guest (so 
available as /sysroot/etc/resolv.conf in the appliance) being moved when 
executing shell commands (eg guestfs_sh) by the daemon.
This operation involves:
a) moving away guest's /etc/resolv.conf
b) replacing it with the /etc/resolv.conf in the appliance
c) executing the actual shell command
d) moving the guest's /etc/resolv.conf back
... but only if the network is enabled (which is by default).

So far all the ideas I found (to fix the label of /etc/resolv.conf when 
--selinux-relabel is asked) were:

1) get the security.selinux xattr before (a), and restore it after (d).
   This seems to not have worked at all, at least for me: the read xattr
   is "unlabeled", which SELinux obviously refuses later; hence I
   discarded it

2) closing the guestfs handle, open a new one with the network disabled
   and do the relabel.
   This works for me, but has the drawback to slow the process if the
   relabel is asked and the network is enabled, as closing+opening an
   appliance could not be that fast

3) allow to switch the network on/off also when the appliance is up.
   This would require to actually turn on/off the networking at
   runtime, which surely cannot be done with the direct backend and most
   probably neither with libvirt (but I didn't research hard on this).

Is anything obvious I'm missing? Can I go with solution #2?

-- 
Pino Toscano

On Fri, Apr 25, 2014 at 11:40:35AM +0200, Pino Toscano
wrote:
> Hi,
> 
> I was investigating rh#1089100, which is about /etc/resolv.conf not 
> being properly SELinux-labelled.
> 
> Basically the problem is due to /etc/resolv.conf in the guest (so 
> available as /sysroot/etc/resolv.conf in the appliance) being moved when 
> executing shell commands (eg guestfs_sh) by the daemon.
> This operation involves:
> a) moving away guest's /etc/resolv.conf
> b) replacing it with the /etc/resolv.conf in the appliance
> c) executing the actual shell command
> d) moving the guest's /etc/resolv.conf back
> ... but only if the network is enabled (which is by default).
Does bind-mounting /etc/resolv.conf into /sysroot not work?
> So far all the ideas I found (to fix the label of /etc/resolv.conf when 
> --selinux-relabel is asked) were:
> 
> 1) get the security.selinux xattr before (a), and restore it after (d).
>    This seems to not have worked at all, at least for me: the read xattr
>    is "unlabeled", which SELinux obviously refuses later; hence I
>    discarded it
This was going to be my suggestion.  Surprising there is no label on
the file.
> 2) closing the guestfs handle, open a new one with the network disabled
>    and do the relabel.
>    This works for me, but has the drawback to slow the process if the
>    relabel is asked and the network is enabled, as closing+opening an
>    appliance could not be that fast
Yup, this sounds like a hack ...
> 3) allow to switch the network on/off also when the appliance is up.
>    This would require to actually turn on/off the networking at
>    runtime, which surely cannot be done with the direct backend and most
>    probably neither with libvirt (but I didn't research hard on this).
It probably could be done with the libvirt backend, ie. dropping or
adding the network interface, but it'd be really ugly and hard.
> Is anything obvious I'm missing? Can I go with solution #2?
Another possibility might be to have an optional flag on guestfs_sh
for enabling/disabling resolv.conf munging.  Unfortunately resolv.conf
munging is an implementation detail / hack, and it's not nice to
expose implementation details through the API.  We've regretted doing
this before.

I'm afraid I don't have a good answer here ..

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

On Friday 25 April 2014 21:03:13 Richard W.M. Jones
wrote:
> On Fri, Apr 25, 2014 at 11:40:35AM +0200, Pino Toscano wrote:
> > Hi,
> > 
> > I was investigating rh#1089100, which is about /etc/resolv.conf not
> > being properly SELinux-labelled.
> > 
> > Basically the problem is due to /etc/resolv.conf in the guest (so
> > available as /sysroot/etc/resolv.conf in the appliance) being moved
> > when executing shell commands (eg guestfs_sh) by the daemon.
> > This operation involves:
> > a) moving away guest's /etc/resolv.conf
> > b) replacing it with the /etc/resolv.conf in the appliance
> > c) executing the actual shell command
> > d) moving the guest's /etc/resolv.conf back
> > ... but only if the network is enabled (which is by default).
> 
> Does bind-mounting /etc/resolv.conf into /sysroot not work?
The comments in set_up_etc_resolv_conf (top and inline) talk about 
/etc/resolv.conf potentially being a symlink (and a dangling one), hence 
ruling this possibility out.
> > So far all the ideas I found (to fix the label of /etc/resolv.conf
> > when --selinux-relabel is asked) were:
> > 
> > 1) get the security.selinux xattr before (a), and restore it after
> > (d).> 
> >    This seems to not have worked at all, at least for me: the read
> >    xattr
> >    is "unlabeled", which SELinux obviously refuses later;
hence I
> >    discarded it
> 
> This was going to be my suggestion.  Surprising there is no label on
> the file.
And interestingly, they are "unlabeled" even when reading 
security.selinux xattr before mounting the selinux mount point(s).
> > 2) closing the guestfs handle, open a new one with the network
> > disabled> 
> >    and do the relabel.
> >    This works for me, but has the drawback to slow the process if
> >    the
> >    relabel is asked and the network is enabled, as closing+opening
> >    an
> >    appliance could not be that fast
> 
> Yup, this sounds like a hack ...
> 
> > 3) allow to switch the network on/off also when the appliance is up.
> > 
> >    This would require to actually turn on/off the networking at
> >    runtime, which surely cannot be done with the direct backend and
> >    most
> >    probably neither with libvirt (but I didn't research hard on
> >    this).
> 
> It probably could be done with the libvirt backend, ie. dropping or
> adding the network interface, but it'd be really ugly and hard.
> 
> > Is anything obvious I'm missing? Can I go with solution #2?
> 
> Another possibility might be to have an optional flag on guestfs_sh
> for enabling/disabling resolv.conf munging.  Unfortunately resolv.conf
> munging is an implementation detail / hack, and it's not nice to
> expose implementation details through the API.  We've regretted doing
> this before.
Agree, let's keep it private.

I did another experiment, that is, instead of copy+restore, just 
link+unlink resolv.conf. But of course it doesn't work either, since 
executing "load_policy && fixfiles restore" will change the
label of the
file, whereever it is copied/linked within /sysroot.

The other possible solution it came into my mind is adding a new API, 
say selinux_relabel or so, which would just handle daemon-side all the 
details needed to make sure linux guests with selinux would have proper 
labels on their files. This way, clients would just do an API call, and 
the daemon can do whatever it is needed (even changing the actual 
implementation from version to version).

-- 
Pino Toscano