Changeset 38666 in vbox for trunk/doc

Timestamp:

Sep 6, 2011 4:39:38 PM (13 years ago)

Author:

vboxsync

Message:

doc/manual: language changes

Location:

trunk/doc/manual/en_US

Files:

• user_GuestAdditions.xml (modified) (1 diff)
• user_Security.xml (modified) (4 diffs)

trunk/doc/manual/en_US/user_GuestAdditions.xml

@@ -1185 +1185 @@
             linkend="generalsettings" />).<note>
             <para>
-              Enabling 3D acceleration may expose security holes to malicious
-              software running in the guest. The 3D host graphics drivers
-              are often known to contain bugs and might crash with certain
-              operations. VirtualBox is not hardened enough to prevent every
-              risky 3D operation on the host. But a VirtualBox guest can not induce
-              any more harm to the host than any other malicious host application
-              using the 3D graphics API.
+              Untrusted guest systems should not be allowed to use
+              VirtualBox's 3D acceleration features, just as untrusted host
+              software should not be allowed to use 3D acceleration.  Drivers
+              for 3D hardware are generally too complex to be made properly
+              secure and any software which is allowed to access them may be
+              able able to compromise the operating system running them.  In
+              addition, enabling 3D acceleration gives the guest direct access
+              to a large body of additional program code in the VirtualBox
+              host process which it might conceivably be able to use to crash
+              the virtual machine.
             </para>
             </note></para>

trunk/doc/manual/en_US/user_Security.xml

@@ -100 +100 @@
     </para>
     <para>
-      On Windows hosts, the installer allows to disable USB support, support
+      On Windows hosts, the installer allows for disabling USB support, support
       for bridged networking, support for host-only networking and the Python
       language bindings, see <xref linkend="installation_windows"/>.
@@ -106 +106 @@
       of them could be appropriate if the corresponding functionality is not
       required by any virtual machine. The Python language bindings are only
-      required if the VirtualBox API should be used by external Python
+      required if the VirtualBox API is to be used by external Python
       applications. In particular USB support and support
-      for the two networking modes induce the installation of Windows kernel
-      drivers at the host. Therefore disabling those selected features can
-      not only be used to restrict the user to a certain functionality but
-      also to minimize the surfaces provided to a potential attacker.     </para>
-    <para>
-      The regular case is to install the complete VirtualBox package. The
+      for the two networking modes require the installation of Windows kernel
+      drivers on the host. Therefore disabling those selected features can
+      not only be used to restrict the user to certain functionality but
+      also to minimize the surface provided to a potential attacker.     </para>
+    <para>
+      The general case is to install the complete VirtualBox package. The
       installation must be done with system privileges. All VirtualBox binaries
       should be executed as a regular user and never as a privileged user.
@@ -122 +122 @@
       <xref linkend="intro-installing"/>. As for the base package, the SHA256
       checksum of the extension pack should be verified. As the installation
-      requires system privileges, the VirtualBox GUI will ask for the system
+      requires system privileges, VirtualBox will ask for the system
       password during the installation of the extension pack.
     </para>
@@ -317 +317 @@
           which the data is transferred could therefore intercept that
           data. An SSH tunnel could be used to secure the connection between
-          the two host. But when considering to teleport a VM over an untrusted
+          the two hosts. But when considering teleporting a VM over an untrusted
           network the first question to answer is how both VMs can securely
           access the same virtual disk image(s) with a reasonable performance. </para>