docker build & security-relevant parameters

[uchi-mata]

Dear Team,

I have a more general question that does not really fit the provided Issue template, apologies.

I was digging into options of dropping container privileges during build (capabilities, blocking more syscalls than the default, supplying a more restrictive apparmor profile, starting build container as non-root) and it is not possible. This issue was raised a couple of times with a focus on sec-comp (e.g. #37332, #34454), but I wanted to widen the scope for all the great security options that exist for docker run.

I fully understand the argument from the other issues that built images should be portable (which may be impacted by using higher privileges), but in my opinion it would be quite important to be able to drop privileges as container build systems are everywhere now and securing them is quite a challenge. From a quick brainstorming perspective, I also don't see how that would impact portability (especially since the target audience would probably be environments that want to apply the same runtime hardening to build and run systems).

Any ideas whether that could be put on any roadmap?

Thanks for your consideration & best,
Matthias

[AkihiroSuda]

Does rootless mode cover your requirement?

[uchi-mata]

Hi @AkihiroSuda,

sorry for this incredibly delayed answer, as often, the reading on this was not connected to a very high priority project.

I don't think rootless mode covers the idea to restrict build-time containers.

From what I see so far rootless mode seems to result in significantly higher privileges for the executed container besides the actual uid than default containers. I.e. when I follow this description using rootlesskit and slirp4netns, the container executed by the rootless docker environment has the following capabilities:
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

In addition, as documented, the container is executed without apparmor profile.

For my scenario, the ability to start a container as non-root is not the relevant requirement but to restrict the executed build-time container as much as possible.

Thank you & best,
Matthias

[AkihiroSuda]

rootless docker environment has the following capabilities:

These capabilities are fake and limited in the user namespace

[AkihiroSuda]

Maybe you want to try running kaniko

[uchi-mata]

That of course makes sense on proper thought, thank you! Kaniko is definitely an option; but does that recommendation mean that there are no plans to integrate docker run CLI switches like --security-optand -u/-g into docker build?

[AkihiroSuda]

Contribution is wanted