Seccomp not working as expected

[Gonçalo R]

Hello, everyone.

I am having some problems with rkt and I believe the cause is seccomp misbehaving or me using it incorrectly.

As an example:

1. Run a container and install `strace` and `capsh`

# rkt --insecure-options=image run docker://debian:stretch-slim --dns 8.8.8.8 --interactive --exec=/bin/bash
# apt update && apt install -y strace libcap2-bin

2. Enter the container

# rkt enter ...

3. Run a simple `strace` command and it works

# strace /bin/ls
(strace output)

So far so good. Since `rkt enter` does not apply seccomp rules we have a whole lot of capabilities, including `cap_sys_ptrace`, which allow us to run `strace`:

# capsh --print
Current: = cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read+ep
...

So I expect that if I run a container with all these capabilities I will be able to run `strace` in there. However what happens is the following:

# rkt --insecure-options=image run registry-1.docker.io/library/debian:stretch-slim --dns 8.8.8.8 --interactive --exec=/bin/bash --caps-retain=cap_chown,cap_dac_override,cap_dac_read_search,...
# apt update && apt install -y strace libcap2-bin
# strace /bin/ls
Bad system call (core dumped)

As you can see `strace` fails with a bad system call. Running `capsh --print` reveals all the filters that were passed with `--caps-retain`, so I don't understand what is wrong.

Am I doing something wrong? Can this be a bug? I am running rkt 1.29.0 on Debian Stretch. Thank you.

[Gonçalo R]

I also noticed that I can run `strace` successfully by using `--seccomp mode=retain,@appc.io/all`. However `capsh` only reports a small set of capabilities:

# rkt --insecure-options=image run docker://debian:stretch-slim --dns 8.8.8.8 --interactive --exec=/bin/bash --seccomp mode=retain,@appc.io/all

# apt update && apt install -y strace libcap2-bin

# capsh --print
Current: = cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap+ep

# strace /bin/ls
(strace output)

Why does this happen?

[Luca BRUNO]

On Sunday, November 12, 2017 2:32:41 AM UTC Gonçalo R wrote:

> As you can see `strace` fails with a bad system call. Running `capsh
> --print` reveals all the filters that were passed with `--caps-retain`, so
> I don't understand what is wrong.

> I also noticed that I can run `strace` successfully by using `--seccomp
> mode=retain,@appc.io/all`. However `capsh` only reports a small set of
> capabilities:

capabilities(7) and seccomp(2) are orthogonal technologies.

The "Bad system call (core dumped)" you experienced is due to default seccomp
list blocking one syscall (ptrace(2) I'd guess), which is _mostly_ unrelated
to which capabilities your process has.

For a syscall which is not in the default whitelist, you need to allow it in
the seccomp filter AND have proper capabilities in order to invoke it.

Ciao, Luca

--
"If you build a wall, think of what you leave outside it" - Italo Calvino

[Gonçalo R]

On Monday, November 13, 2017 at 9:38:37 AM UTC, Luca BRUNO wrote:

capabilities(7) and seccomp(2) are orthogonal technologies.

I am new to both capabilities and seccomp and didn't realise they were not related but instead complement each other. I already looked it up a bit to start to understand the difference. Here's a good starting reference for anyone that comes here in the future with the same confusion am me.

Thank you for clearing that up for me, Luca.