[Xen-changelog] [xen master] docs: Fix dm_restrict documentation

[patchbot@xxxxxxx]

commit 3ec62664bdd67dc0c41ff22198c406729b3c87a4
Author:     George Dunlap <george.dunlap@xxxxxxxxxx>
AuthorDate: Thu Jan 24 17:48:27 2019 +0000
Commit:     Wei Liu <wei.liu2@xxxxxxxxxx>
CommitDate: Fri Jan 25 17:09:04 2019 +0000

    docs: Fix dm_restrict documentation
    
    Remove "chatty" and redundant information from the xl man page;
    restrict it to functional descriptions only, and point instead to
    qemu-depriv.pandoc and SUPPORT.md as locations for "canonical"
    information.
    
    Add a man page entry for device_model_user.
    
    Update qemu-deprivilege.pandoc:
    
    Changes in missing feature list:
    - Migration is functional
    - But qdisk backends are not
    
    Add a missing restriction list.
    
    The following statements from the man page are dropped:
    - Mentioning PV; PV guests never have a device model.
    - Drop the confusing statement about stdvga and cirrus vga options.
    - Re-used domain IDs are now handled.
    - Device models should no longer be able to create world-readable
      files on dom0's filesystem.
    
    Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxx>
    Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Release-acked-by: Juergen Gross <jgross@xxxxxxxx>
---
 docs/features/qemu-deprivilege.pandoc |  12 ++--
 docs/man/xl.cfg.5.pod.in              | 100 +++-------------------------------
 2 files changed, 16 insertions(+), 96 deletions(-)

diff --git a/docs/features/qemu-deprivilege.pandoc 
b/docs/features/qemu-deprivilege.pandoc
index 20d6ac2189..cfe528b1d3 100644
--- a/docs/features/qemu-deprivilege.pandoc
+++ b/docs/features/qemu-deprivilege.pandoc
@@ -110,10 +110,14 @@ See docs/design/qemu-deprivilege.md for technical details.
 
 The following features still need to be implemented:
  * Inserting a new cdrom while the guest is running (xl cdrom-insert)
- * Migration / save / restore
-
-dm_restrict is totally unsupported and may have unexpected security
-problems if used with a dom0 Linux kernel earlier than 2.6.18.
+ * Support for qdisk backends
+
+A number of restrictions still need to be implemented.  A compromised
+device model may be able to do the following:
+ * Delay or exploit weaknesses in the toolstack
+ * Launch "fork bombs" or other resource exhaustion attacks
+ * Make network connections on the management network
+ * Break out of the restrictions after migration
 
 Additionally, getting PCI passthrough to work securely would require a
 significant rework of how passthrough works at the moment.  It may be
diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index 3b92f39d8d..ad81af1ed8 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -1316,104 +1316,20 @@ connectors=id0:1920x1080;id1:800x600;id2:640x480
 Restrict the device model after startup,
 to limit the consequencese of security vulnerabilities in qemu.
 
-With this feature enabled,
-a compromise of the device model,
-via such a vulnerability,
-will not provide a privilege escalation attack on the whole system.
+See docs/features/qemu-depriv.pandoc for more information
+on Linux and QEMU version requirements, device model user setup,
+and current limitations.
 
 This feature is a B<technology preview>.
-There are some significant limitations:
+See SUPPORT.md for a security support statement.
 
-=over 4
-
-=item
-
-This is not likely to work at all for PV guests
-nor guests using qdisk backends for their block devices.
-
-=item
-
-You must have a new enough qemu.
-In particular,
-if your qemu does not have the commit
-B<xen: restrict: use xentoolcore_restrict_all>
-the restriction request will be silently ineffective!
-
-=item
-
-The mechanisms used are not effective against
-denial of service problems.
-A compromised qemu can probably still impair
-or perhaps even prevent
-the proper functioning of the whole system,
-(at the very least, but not limited to,
-through resource exhaustion).
-
-=item
-
-It is not known whether the protection is
-effective when a domain is migrated.
-
-=item
-
-Some domain management functions do not work.
-For example, cdrom insert will fail.
-
-=item
+=item B<device_model_user=USERNAME>
 
-You should say C<vga="none">.
-Domains with stdvga graphics cards to not work.
-Domains with cirrus vga may seem to work.
+When running dm_restrict, run the device model as this user.
 
-=item
+NOTE: Each domain MUST have a SEPARATE username.
 
-You must create user(s) for qemu to run as.
-
-Ideally, set aside a range of 32752 uids
-(from N to N+32751)
-and create a user
-whose name is B<xen-qemuuser-range-base>
-and whose uid is N
-and whose gid is a plain unprivileged gid.
-libxl will use one such user for each domid.
-
-Alternatively, either create
-B<xen-qemuuser-domid$domid>
-for every $domid from 1 to 32751 inclusive,
-or
-B<xen-qemuuser-shared>
-(in which case different guests will not
-be protected against each other).
-
-=item
-
-There are no countermeasures taken against reuse
-of the same unix user (uid)
-for subsequent domains,
-even if the B<xen-qemuuser-domid$domid> users are created.
-So a past domain with the same domid may be able to
-interferer with future domains.
-Possibly, even after a reboot.
-
-=item
-
-A compromised qemu will be able to read world-readable
-files in the dom0 operating system.
-
-=item
-
-Because of these limitations, this functionality,
-while it may enhance your security,
-should not be relied on.
-Any further limitations discovered in the current version
-will B<not> be handled via the Xen Project Security Process.
-
-=item
-
-In the future as we enhance this feature to improve the security,
-we may break backward compatibility.
-
-=back
+See docs/features/qemu-depriv.pandoc for more information.
 
 =item B<vsnd=[ VCARD_SPEC, VCARD_SPEC, ... ]>
 
--
generated by git-patchbot for /home/xen/git/xen.git#master

_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/xen-changelog