The quotactl syscall is being whitelisted in default seccomp profile,
gated by CAP_SYS_ADMIN.
Signed-off-by: Panagiotis Moustafellos <pmoust@elastic.co>
Upstream-commit: cf6e1c5dfd07f5048606bb7b21464c658e252322
Component: engine
This reverts commit 7e3a596a63fd8d0ab958132901b6ded81f8b44c0.
Unfortunately, it was pointed out in https://github.com/moby/moby/pull/29076#commitcomment-21831387
that the `socketcall` syscall takes a pointer to a struct so it is not possible to
use seccomp profiles to filter it. This means these cannot be blocked as you can
use `socketcall` to call them regardless, as we currently allow 32 bit syscalls.
Users who wish to block these should use a seccomp profile that blocks all
32 bit syscalls and then just block the non socketcall versions.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Upstream-commit: dcf2632945b87acedeea989a5aa36c084a20ae88
Component: engine
From personality(2):
Have uname(2) report a 2.6.40+ version number rather than a 3.x version
number. Added as a stopgap measure to support broken applications that
could not handle the kernel version-numbering switch from 2.6.x to 3.x.
This allows both "UNAME26|PER_LINUX" and "UNAME26|PER_LINUX32".
Fixes: #32839
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Upstream-commit: cd456433ea2a02ed0016314fc4959b5f1a9c40a3
Component: engine
These are arm variants with different argument ordering because of
register alignment requirements.
fix#30516
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Upstream-commit: d6adcd6a82ba0997fcc123090711b5502da5cbfd
Component: engine
Linux supports many obsolete address families, which are usually available in
common distro kernels, but they are less likely to be properly audited and
may have security issues
This blocks all socket families in the socket (and socketcall where applicable) syscall
except
- AF_UNIX - Unix domain sockets
- AF_INET - IPv4
- AF_INET6 - IPv6
- AF_NETLINK - Netlink sockets for communicating with the ekrnel
- AF_PACKET - raw sockets, which are only allowed with CAP_NET_RAW
All other socket families are blocked, including Appletalk (native, not
over IP), IPX (remember that!), VSOCK and HVSOCK, which should not generally
be used in containers, etc.
Note that users can of course provide a profile per container or in the daemon
config if they have unusual use cases that require these.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Upstream-commit: 7e3a596a63fd8d0ab958132901b6ded81f8b44c0
Component: engine
Do not gate with CAP_IPC_LOCK as unprivileged use is now
allowed in Linux. This returns it to how it was in 1.11.
Fixes#23587
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Upstream-commit: bdf01cf5deee11deb426eb33e1c8433c410084b6
Component: engine
In #22554 I aligned seccomp and capabilities, however the case of
the chown calls and CAP_CHOWN was less clearcut, as these are
simple calls that the capabilities will block if they are not
allowed. They are needed when no new privileges is not set in
order to allow docker to call chown before the container is
started, so there was a workaround but this did not include
all the chown syscalls, and Arm was failing on some seccomp
tests because it was using a different syscall from just the
fchown that was allowed in this case. It is simpler to just
allow all the chown calls in the default seccomp profile and
let the capabilities subsystem block them.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Upstream-commit: 9ed6e39cdd7acf488d5ff2a6876793837687e4cf
Component: engine
In order to do this, allow the socketcall syscall in the default
seccomp profile. This is a multiplexing syscall for the socket
operations, which is becoming obsolete gradually, but it is used
in some architectures. libseccomp has special handling for it for
x86 where it is common, so we did not need it in the profile,
but does not have any handling for ppc64le. It turns out that the
Debian images we use for tests do use the socketcall, while the
newer images such as Ubuntu 16.04 do not. Enabling this does no
harm as we allow all the socket operations anyway, and we allow
the similar ipc call for similar reasons already.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Upstream-commit: a83cedddc6d3e0fe1df352ec54245090df641ab8
Component: engine
Currently the default seccomp profile is fixed. This changes it
so that it varies depending on the Linux capabilities selected with
the --cap-add and --cap-drop options. Without this, if a user adds
privileges, eg to allow ptrace with --cap-add sys_ptrace then still
cannot actually use ptrace as it is still blocked by seccomp, so
they will probably disable seccomp or use --privileged. With this
change the syscalls that are needed for the capability are also
allowed by the seccomp profile based on the selected capabilities.
While this patch makes it easier to do things with for example
cap_sys_admin enabled, as it will now allow creating new namespaces
and use of mount, it still allows less than --cap-add cap_sys_admin
--security-opt seccomp:unconfined would have previously. It is not
recommended that users run containers with cap_sys_admin as this does
give full access to the host machine.
It also cleans up some architecture specific system calls to be
only selected when needed.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Upstream-commit: a01c4dc8f85827f32d88522e5153dddc02f11806
Component: engine
These syscalls are already blocked by the default capabilities:
mlock mlock2 mlockall require CAP_IPC_LOCK
vhangup requires CAP_SYS_TTY_CONFIG
There is therefore no reason to allow them in the default profile
as they cannot be used anyway.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Upstream-commit: e7a99ae5e16f8688a0735c91856d13633f48185c
Component: engine
This adds the following new syscalls that are supported in libseccomp 2.3.0,
including calls added up to kernel 4.5-rc4:
mlock2 - same as mlock but with a flag
copy_file_range - copy file contents, like splice but with reflink support.
The following are not added, and mentioned in docs:
userfaultfd - userspace page fault handling, mainly designed for process migration
The following are not added, only apply to less common architectures:
switch_endian
membarrier
breakpoint
set_tls
I plan to review the other architectures, some of which can now have seccomp
enabled in the build as they are now supported.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Upstream-commit: 96896f2d0bc16269778dd4f60a4920b49953ffed
Component: engine
Fixes#20818
This syscall was blocked as there was some concern that it could be
used to bypass filtering of other syscall arguments. However none of the
potential syscalls where this could be an issue (poll, nanosleep,
clock_nanosleep, futex) are blocked in the default profile anyway.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Upstream-commit: 5abd881883883a132f96f8adb1b07b5545af452b
Component: engine
On 32 bit x86 this is a multiplexing syscall for the system V
ipc syscalls such as shmget, and so needs to be allowed for
shared memory access for 32 bit binaries.
Fixes#20733
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Upstream-commit: 31410a6d79fc4ea6fa496636015bf9f53c1c8b14
Component: engine
We generally want to filter the personality(2) syscall, as it
allows disabling ASLR, and turning on some poorly supported
emulations that have been the target of CVEs. However the use
cases for reading the current value, setting the default
PER_LINUX personality, and setting PER_LINUX32 for 32 bit
emulation are fine.
See issue #20634
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Upstream-commit: 39b799ac53e2ba397edc3063432d01478416dbc8
Component: engine
profile is created by go generate
Signed-off-by: Jessica Frazelle <acidburn@docker.com>
Upstream-commit: d57816de0293e18ecfa68ac6e8c288a888912e33
Component: engine
