Merge pull request #22711 from thaJeztah/docs-cherry-picks

Docs cherry picks

docs/deprecated.md

@@ -92,7 +92,7 @@ The lxc-conf flag and API fields will also be removed.
 ### Old Command Line Options
 **Deprecated In Release: [v1.8.0](https://github.com/docker/docker/releases/tag/v1.8.0)**
 
-**Target For Removal In Release: v1.10**
+**Removed In Release: [v1.10.0](https://github.com/docker/docker/releases/tag/v1.10.0)**
 
 The flags `-d` and `--daemon` are deprecated in favor of the `daemon` subcommand:
 

docs/extend/plugins_authorization.md

@@ -151,8 +151,7 @@ should implement the following two methods:
     "RequestMethod":     "The HTTP method",
     "RequestURI":        "The HTTP request URI",
     "RequestBody":       "Byte array containing the raw HTTP request body",
-    "RequestHeader":     "Byte array containing the raw HTTP request header as a map[string][]string ",
-    "RequestStatusCode": "Request status code"
+    "RequestHeader":     "Byte array containing the raw HTTP request header as a map[string][]string "
 }
 ```
 
@@ -177,7 +176,6 @@ should implement the following two methods:
     "RequestURI":        "The HTTP request URI",
     "RequestBody":       "Byte array containing the raw HTTP request body",
     "RequestHeader":     "Byte array containing the raw HTTP request header as a map[string][]string",
-    "RequestStatusCode": "Request status code",
     "ResponseBody":      "Byte array containing the raw HTTP response body",
     "ResponseHeader":    "Byte array containing the raw HTTP response header as a map[string][]string",
     "ResponseStatusCode":"Response status code"

docs/migration.md

@@ -29,7 +29,7 @@ instructions that didn’t modify the filesystem.
 
 Content addressability is the foundation for the new distribution features. The
 image pull and push code has been reworked to use a download/upload manager
-concept that makes pushing and pulling images much more stable and mitigate any
+concept that makes pushing and pulling images much more stable and mitigates any
 parallel request issues. The download manager also brings retries on failed
 downloads and better prioritization for concurrent downloads.
 

docs/reference/builder.md

@@ -834,7 +834,7 @@ does some more work:
 
 # USE the trap if you need to also do manual cleanup after the service is stopped,
 #     or need to start multiple services in the one container
-trap "echo TRAPed signal" HUP INT QUIT KILL TERM
+trap "echo TRAPed signal" HUP INT QUIT TERM
 
 # start service in background here
 /usr/sbin/apachectl start

docs/security/apparmor.md

@@ -232,7 +232,7 @@ Congrats! You just deployed a container secured with a custom apparmor profile!
 
 ## Debug AppArmor
 
-You can use `demsg` to debug problems and `aa-status` check the loaded profiles.
+You can use `dmesg` to debug problems and `aa-status` check the loaded profiles.
 
 ### Use dmesg
 

docs/security/non-events.md

@@ -0,0 +1,83 @@
+<!--[metadata]>
++++
+title = "Docker Security Non-events"
+description = "Review of security vulnerabilities Docker mitigated"
+keywords = ["Docker, Docker documentation,  security, security non-events"]
+[menu.main]
+parent = "smn_secure_docker"
++++
+<![end-metadata]-->
+
+# Docker Security Non-events
+
+This page lists security vulnerabilities which Docker mitigated, such that
+processes run in Docker containers were never vulnerable to the bug—even before
+it was fixed. This assumes containers are run without adding extra capabilities
+or not run as `--privileged`.
+
+The list below is not even remotely complete. Rather, it is a sample of the few
+bugs we've actually noticed to have attracted security review and publicly
+disclosed vulnerabilities. In all likelihood, the bugs that haven't been
+reported far outnumber those that have. Luckily, since Docker's approach to
+secure by default through apparmor, seccomp, and dropping capabilities, it
+likely mitigates unknown bugs just as well as it does known ones.
+
+Bugs mitigated:
+
+* [CVE-2013-1956](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1956),
+[1957](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1957),
+[1958](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1958),
+[1959](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1959),
+[1979](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1979),
+[CVE-2014-4014](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4014),
+[5206](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-5206),
+[5207](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-5207),
+[7970](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7970),
+[7975](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7975),
+[CVE-2015-2925](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-2925),
+[8543](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-8543),
+[CVE-2016-3134](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3134),
+[3135](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3135), etc.:
+The introduction of unprivileged user namespaces lead to a huge increase in the
+attack surface available to unprivileged users by giving such users legitimate
+access to previously root-only system calls like `mount()`. All of these CVEs
+are examples of security vulnerabilities due to introduction of user namespaces.
+Docker can use user namespaces to set up containers, but then disallows the
+process inside the container from creating its own nested namespaces through the
+default seccomp profile, rendering these vulnerabilities unexploitable.
+* [CVE-2014-0181](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0181),
+[CVE-2015-3339](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3339):
+These are bugs that require the presence of a setuid binary. Docker disables
+setuid binaries inside containers via the `NO_NEW_PRIVS` process flag and
+other mechanisms.
+* [CVE-2014-4699](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4699):
+A bug in `ptrace()` could allow privilege escalation. Docker disables `ptrace()`
+inside the container using apparmor, seccomp and by dropping `CAP_PTRACE`.
+Three times the layers of protection there!
+* [CVE-2014-9529](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-9529):
+A series of crafted `keyctl()` calls could cause kernel DoS / memory corruption.
+Docker disables `keyctl()` inside containers using seccomp.
+* [CVE-2015-3214](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3214),
+[4036](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4036): These are
+bugs in common virtualization drivers which could allow a guest OS user to
+execute code on the host OS. Exploiting them requires access to virtualization
+devices in the guest. Docker hides direct access to these devices when run
+without `--privileged`. Interestingly, these seem to be cases where containers
+are "more secure" than a VM, going against common wisdom that VMs are
+"more secure" than containers.
+* [CVE-2016-0728](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0728):
+Use-after-free caused by crafted `keyctl()` calls could lead to privilege
+escalation. Docker disables `keyctl()` inside containers using the default
+seccomp profile.
+* [CVE-2016-2383](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2383):
+A bug in eBPF -- the special in-kernel DSL used to express things like seccomp
+filters -- allowed arbitrary reads of kernel memory. The `bpf()` system call
+is blocked inside Docker containers using (ironically) seccomp.
+
+Bugs *not* mitigated:
+
+* [CVE-2015-3290](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3290),
+[5157](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5157): Bugs in
+the kernel's non-maskable interrupt handling allowed privilege escalation.
+Can be exploited in Docker containers because the `modify_ldt()` system call is
+not currently blocked using seccomp.

docs/security/seccomp.md

@@ -99,7 +99,6 @@ the reason each syscall is blocked rather than white-listed.
 | `keyctl`            | Prevent containers from using the kernel keyring, which is not namespaced.                                   |
 | `lookup_dcookie`    | Tracing/profiling syscall, which could leak a lot of information on the host.                                |
 | `mbind`             | Syscall that modifies kernel memory and NUMA settings. Already gated by `CAP_SYS_NICE`.                      |
-| `modify_ldt`        | Old syscall only used in 16-bit code and a potential information leak.                                       |
 | `mount`             | Deny mounting, already gated by `CAP_SYS_ADMIN`.                                                             |
 | `move_pages`        | Syscall that modifies kernel memory and NUMA settings.                                                       |
 | `name_to_handle_at` | Sister syscall to `open_by_handle_at`. Already gated by `CAP_SYS_NICE`.                                      |

docs/security/security.md

@@ -52,8 +52,8 @@ How mature is the code providing kernel namespaces and private
 networking? Kernel namespaces were introduced [between kernel version
 2.6.15 and
 2.6.26](http://lxc.sourceforge.net/index.php/about/kernel-namespaces/).
-This means that since July 2008 (date of the 2.6.26 release, now 7 years
-ago), namespace code has been exercised and scrutinized on a large
+This means that since July 2008 (date of the 2.6.26 release
+), namespace code has been exercised and scrutinized on a large
 number of production systems. And there is more: the design and
 inspiration for the namespaces code are even older. Namespaces are
 actually an effort to reimplement the features of [OpenVZ](

docs/userguide/networking/work-with-networks.md

@@ -228,7 +228,8 @@ $ docker run --net=isolated_nw --ip=172.25.3.3 -itd --name=container3 busybox
 As you can see you were able to specify the ip address for your container.
 As long as the network to which the container is connecting was created with
 a user specified subnet, you will be able to select the IPv4 and/or IPv6 address(es)
-for your container when executing `docker run` and `docker network connect` commands.
+for your container when executing `docker run` and `docker network connect` commands
+by respectively passing the `--ip` and `--ip6` flags for IPv4 and IPv6.
 The selected IP address is part of the container networking configuration and will be
 preserved across container reload. The feature is only available on user defined networks,
 because they guarantee their subnets configuration does not change across daemon reload.