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.lagerw...@citrix.com>
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@lists.xen.org
https://lists.xen.org/xen-devel
