Re: [Xen-devel] [PATCH for-4.9] livepatch: Declare live patching as a supported feature

[Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>]

On 06/26/2017 05:39 PM, Andrew Cooper wrote:
> On 26/06/17 16:36, Ross Lagerwall wrote:
snip
> > * Unprivileged access to live patching operations:
> >      Live patching operations should only be accessible to privileged
> >      guests and it shall be treated as a security issue if this is not
> >      the case.
> >
> > * Bugs in the patch-application code such that vulnerabilities exist
> >    after application:
> >      If a correct live patch is loaded but it is not applied correctly
> >      such that it might result in an insecure system (e.g. not all
> >      functions are patched), it shall be treated as a security issue.
> >
> > * Bugs in livepatch-build-tools creating incorrect live patch that
> >    results in an insecure host:
> >      If livepatch-build-tools creates an incorrect live patch that
> >      results in an insecure host, this shall not be considered a security
> >      issue. There are too many OSes and toolchains to consider supporting
> >      this. A live patch should be checked to verify that it is valid
> >      before loading.
> >
> > * Loading an incorrect live patch that results in an insecure host or
> >    host crash:
> >      If a live patch (whether created using livepatch-build-tools or some
> >      alternative) is loaded and it results in an insecure host or host
> >      crash due to the content of the live patch being incorrect or the
> >      issue being inappropriate to live patch, this is not considered as a
> >      security issue.
> >
> > * Bugs in the live patch parsing code (the ELF loader):
> >      Bugs in the live patch parsing code such as out-of-bounds reads
> >      caused by invalid ELF files are not considered to be security issues
> >      because the it can only be triggered by a privileged domain.
> For these last points, I think it is worth stating that people using
> livepatching are expected to test their patches in a test environment first.
OK.

> > * Bugs which allow a guest to prevent the application of a livepatch:
> >      A guest should not be able to prevent the application of a live
> >      patch. If an unprivileged guest can prevent the application of a
> >      live patch, it shall be treated as a security issue.
> This one is harder to say.  We know that enough concurrent live
> migrations can, which extends to "lots of activity in the guest".  Its
> perhaps worth noting the potential workaround of `xl pause $DOM;
> xen-livepatch ...; xl unpause`.
>
> I'd prefer that we excluded situations like this from being within
> security support.  "guest having heavy workloads" is normal for end
> users, so shouldn't constitute a security vulnerability, as there is
> nothing we can do about it.
But surely live migrations cannot be triggered by the guest, only the 
host administrator? I don't know of any way of triggering the timeout 
from within an unprivileged guest.
> > There are also some generic security questions which it is worth asking:
> >
> > 1) Is guest->host privilege escalation possible?
> >
> > The new live patching sysctl subops are only accessible to privileged
> > domains and this is tested by OSSTest with an XTF test.
> > There is a caveat -- an incorrect live patch can introduce a guest->host
> > privilege escalation.
> >
> > 2) Is guest user->guest kernel escalation possible?
> >
> > No, although an incorrect live patch can introduce a guest user->guest
> > kernel privilege escalation.
> >
> > 3) Is there any information leakage?
> >
> > The new live patching sysctl subops are only accessible to privileged
> > domains so it is not possible for an unprivileged guest to access the
> > list of loaded live patches. This is tested by OSSTest with an XTF test.
> > There is a caveat -- an incorrect live patch can introduce an
> > information leakage.
> >
> > 4) Can a Denial-of-Service be triggered?
> >
> > There are no known ways that an unprivileged guest can prevent a live
> > patch from being loaded.
> > Once again, there is a caveat that an incorrect live patch can introduce
> > an arbitrary denial of service.
> >
> > Signed-off-by: Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>
> This is all good, but this information needs to be in a file in
> docs/features/, most probably livepatching.pandoc
OK.

> > ---
> >   xen/common/Kconfig | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> > index dc8e876..876086c 100644
> > --- a/xen/common/Kconfig
> > +++ b/xen/common/Kconfig
> > @@ -226,7 +226,7 @@ config CRYPTO
> >         bool
> >   
> >   config LIVEPATCH
> > -       bool "Live patching support (TECH PREVIEW)"
> > +       bool "Live patching support"
> >         default n
> This default should flip as well.
OK.

--
Ross Lagerwall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel