[gentoo-hardened] GRKERNSEC_PROC_USERGROUP and docker exec

[gentoo-hardened] GRKERNSEC_PROC_USERGROUP and docker exec

[Alex Efros]

Hi!

It looks like when connecting to existing docker container with `docker
exec` CONFIG_GRKERNSEC_PROC_USERGROUP (and probably
CONFIG_GRKERNSEC_PROC_USER too) hide processes started by `docker run`
from processes started by `docker exec` (all processes are running as
docker "root", docker daemon is started with default options, i.e. without
--userns-remap).

Why is this happens and is there any workaround?


$ sudo zgrep GRKERNSEC_PROC_USER /proc/config.gz
# CONFIG_GRKERNSEC_PROC_USER is not set
CONFIG_GRKERNSEC_PROC_USERGROUP=y

$ docker run -d -it --rm --init alpine sh -c 'ps ax; exec sleep 42'
49bec4451495563d702ad0edb9a7c80a9a7f5918fab4eb67e5a44b803f3ac656

$ docker logs 49bec4451495
PID   USER     TIME   COMMAND
    1 root       0:00 /dev/init -- sh -c ps ax; exec sleep 42
    7 root       0:00 sh -c ps ax; exec sleep 42
    8 root       0:00 ps ax

$ docker exec -it 49bec4451495 ps ax
PID   USER     TIME   COMMAND
    9 root       0:00 ps ax

-- 
			WBR, Alex.

Re: [gentoo-hardened] GRKERNSEC_PROC_USERGROUP and docker exec

["Tóth Attila"]

I don't use docker myself, but if we are speaking about
CONFIG_GRKERNSEC_PROC_USER and CONFIG_GRKERNSEC_PROC_USERGROUP, it would
be important to know what GID is specified in CONFIG_GRKERNSEC_PROC_GID?
That GID is an exception and can provide a way to let that group bypass
CONFIG_GRKERNSEC_PROC_USER restrictions. I could successfully find the
proper settings when I converted to systemd - although I had enough, so
I'm using openrc for some time now. So if you can figure out the important
process's GID, you can officially circumwent the restrictions. Too bad if
the incriminated process runs as root... If you can influence with what
GID the important process starts, you have a key for a solution.
-- 
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

2017.Szeptember 8.(P) 21:20 időpontban Alex Efros ezt írta:
> Hi!
>
> It looks like when connecting to existing docker container with `docker
> exec` CONFIG_GRKERNSEC_PROC_USERGROUP (and probably
> CONFIG_GRKERNSEC_PROC_USER too) hide processes started by `docker run`
> from processes started by `docker exec` (all processes are running as
> docker "root", docker daemon is started with default options, i.e. without
> --userns-remap).
>
> Why is this happens and is there any workaround?
>
>
> $ sudo zgrep GRKERNSEC_PROC_USER /proc/config.gz
> # CONFIG_GRKERNSEC_PROC_USER is not set
> CONFIG_GRKERNSEC_PROC_USERGROUP=y
>
> $ docker run -d -it --rm --init alpine sh -c 'ps ax; exec sleep 42'
> 49bec4451495563d702ad0edb9a7c80a9a7f5918fab4eb67e5a44b803f3ac656
>
> $ docker logs 49bec4451495
> PID   USER     TIME   COMMAND
>     1 root       0:00 /dev/init -- sh -c ps ax; exec sleep 42
>     7 root       0:00 sh -c ps ax; exec sleep 42
>     8 root       0:00 ps ax
>
> $ docker exec -it 49bec4451495 ps ax
> PID   USER     TIME   COMMAND
>     9 root       0:00 ps ax
>
> --
> 			WBR, Alex.
>

Re: [gentoo-hardened] GRKERNSEC_PROC_USERGROUP and docker exec

[Alex Efros]

Hi!

On Sat, Sep 09, 2017 at 11:23:46AM +0200, "Tóth Attila" wrote:
> I don't use docker myself, but if we are speaking about
> CONFIG_GRKERNSEC_PROC_USER and CONFIG_GRKERNSEC_PROC_USERGROUP, it would
> be important to know what GID is specified in CONFIG_GRKERNSEC_PROC_GID?

It's 3 (group "sys"). :)

# zgrep GRKERNSEC_PROC_GID /proc/config.gz
CONFIG_GRKERNSEC_PROC_GID=3

> So if you can figure out the important
> process's GID, you can officially circumwent the restrictions. Too bad if
> the incriminated process runs as root... If you can influence with what
> GID the important process starts, you have a key for a solution.

It's a docker's "root", it has fewer capabilities than real root.
But, anyway, docker's "root" has mostly same groups (including "sys") as
host root:

$ docker run -it --rm alpine id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)
$ sudo id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),26(tape),27(video)

Looks like being in group 3(sys) within container just doesn't have same
effect as on host. Maybe it's because of some capabilities dropped from
container's root account by docker?

-- 
			WBR, Alex.