On Thu, 2013-02-28 at 16:15 +0000, Daniel P. Berrange wrote:
On Thu, Feb 28, 2013 at 04:06:30PM +0000, Matthew Booth wrote:
> On Thu, 2013-02-28 at 16:01 +0000, Daniel P. Berrange wrote:
> > On Thu, Feb 28, 2013 at 03:52:32PM +0000, Matthew Booth wrote:
> > > On Thu, 2013-02-28 at 15:49 +0000, Daniel P. Berrange wrote:
> > > > On Thu, Feb 28, 2013 at 03:01:20PM +0000, Matthew Booth wrote:
> > > > > Secondly, by relabelling disk images we're potentially
making them
> > > > > temporarily unavailable to other processes, which is something
we
> > > > > weren't doing before. It's possible there may be no way
round this, but
> > > > > if so we ought to highlight it as a major gotcha. Is there any
way we
> > > > > can give a file 2 different SELinux contexts? If there were, we
could
> > > > > leave the original untouched and only allow our ephemeral
process to
> > > > > access the second one. A hard link doesn't allow this, btw.
A copy is
> > > > > almost certainly infeasible in the general case, but if the FS
allows
> > > > > reflink it might fly. Thoughts?
> > > >
> > > > There will never be any way to give one file multiple SELinux
labels.
> > > > It is explicitly rejected as a concept by security people.
> > > >
> > > > What I describe here though is explicitly about *not* having to make
> > > > libguestfs relabel other disk images. The point is to define a
policy
> > > > such that libguestfs can access the other VMs' disks without any
> > > > relabelling needing doing to them.
> > > >
> > > > Any relabelling would only be needing on any qcow2 snapshot that
> > > > libguestfs has above the original disks.
> > >
> > > I wasn't talking about whether libguestfs or libvirt does the
> > > relabelling, I was talking about the problems of any relabelling
> > > happening at all to the input file.
> >
> > Sorry, what do you mean by "input file" here ? What files in
particular
> > are you worried about
>
> If we open an image file read-only, ideally we wouldn't modify it in any
> way, including its permissions/context.
If that's what you want, then you're basically saying libguestfs KVM security
context needs to be allowed to read any file on the system, which is a
pretty lax requirement from a security POV. It is much more secure to have
libvirt/libguesfs relabel just the files which the libguesfs VM is intended
to access and have a strict policy for QEMU.
Right, hence the talk of copying/multiple labels, because it's still
less than ideal to modify the input file. We might make it temporarily
unreadable by some other process.
Matt