The Linux kernel never sets the Inheritable capability flag to
anything other than empty. Non-empty values are always exclusively
set by userspace code.
[The kernel stopped defaulting this set of capability values to the
full set in 2000 after a privilege escalation with Capabilities
affecting Sendmail and others.]
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
With the change in #3542 it breaks $PATH handling for images becuase our
default spec always sets a PATH on the process's .Env.
This removes the default and adds an Opt to add this back.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Signed-off-by: John Howard <jhoward@microsoft.com>
Needed for the containerd work on Windows and integrating the
oci package from containerd into moby.
No longer sets defaults for
- .Process.ConsoleSize
- .Windows.IgnoreFlushesDuringBoot
- .Windows.Network.AllowUnqualifiedDNSQuery
Adds helper functions and tests for
- WithWindowsIgnoreFlushesDuringBoot
- WithWindowNetworksAllowUnqualifiedDNSQuery
Updates `ctr run` on Windows to use the new helper functions,
ConsoleSize is already handled.
While looking through the Moby source code was found /proc/asound to be shared
with containers as read-only.
This can lead to two information leaks.
---
**Leak of media playback status of the host**
Steps to reproduce the issue:
- Listen to music/Play a YouTube video/Do anything else that involves sound
output
- Execute docker run --rm ubuntu:latest bash -c "sleep 7; cat
/proc/asound/card*/pcm*p/sub*/status | grep state | cut -d ' ' -f2 | grep
RUNNING || echo 'not running'"
- See that the containerized process is able to check whether someone on the
host is playing music as it prints RUNNING
- Stop the music output
- Execute the command again (The sleep is delaying the output because
information regarding playback status isn't propagated instantly)
- See that it outputs not running
**Describe the results you received:**
A containerized process is able to gather information on the playback
status of an audio device governed by the host. Therefore a process of a
container is able to check whether and what kind of user activity is
present on the host system. Also, this may indicate whether a container
runs on a desktop system or a server as media playback rarely happens on
server systems.
The description above is in regard to media playback - when examining
`/proc/asound/card*/pcm*c/sub*/status` (`pcm*c` instead of `pcm*p`) this
can also leak information regarding capturing sound, as in recording
audio or making calls on the host system.
Reported-by: Philipp Schmied <pschmied@mailbox.org>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
When creating a default OCI spec on Windows that is targeting the LCOW
platform it needs to contain a Windows section as well. This adds the
Windows section by default. It also protects against this case for all
OCI creation that doesnt use the OCI package in the runhcs-shim.
Signed-off-by: Justin Terry (VM) <juterry@microsoft.com>
On Windows we need to be able to create both Linux and Windows OCI spec
files by default to support WCOW and LCOW scenarios. This merges the
compile time differences into runtime differences between the two based
on the spec and platform the user sets.
It maintains the old behavior with Default specs resulting in the
platform default the binary is compiled for.
Signed-off-by: Justin Terry (VM) <juterry@microsoft.com>
We introduce a WithSpecFromFile option combinator to allow creation
simpler creation of OCI specs from a file name. Often used as the first
option in a `SpecOpts` slice, it simplifies choosing between a local
file and the built-in default.
The code in `ctr run` has been updated to use the new option, with out
changing the order of operations or functionality present there.
Signed-off-by: Stephen Day <stephen.day@getcruise.com>
This allows Go to build third party packages correctly without vendoring
issues what want to create their own SpecOpts.
Fixes#2289
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
