personality (PER_LINUX|ADDR_NO_RANDOMIZE) not allowed in seccomp.json profile

[dirkmueller]

I'm not sure if it is adequate to allow it by default, but I've run across a case where setarch -R failed to execute within the seccomp profile. it might be an intentional omission, I couldn't find a related ticket or policy documentation however.

[rhatdan]

@giuseppe thoughts?

[giuseppe]

The general idea is to enable as few syscalls as possible to reduce the attack surface.

The personality syscall seems relatively safe. However, enabling it by default will still increase the attack surface of a container, and given it is not widely used (this is the first time I have seen such an issue), I am not sure we should enable it by default.

[rhatdan]

Should we make it easier to add a syscall to the seccomp json file with something like

--syscall-add --syscall-drop (Matching --cap-add and --cap-drop) Making it easier for user rather then forcing them to disable seccomp all together.

[flouthoc]

Not sure but in this case instead of setting default in seccomp.json can --personality directly be used https://docs.podman.io/en/latest/markdown/podman-run.1.html#personality-persona for your use-case ?

I maybe confusing thing but shouldn't we have a different configurable field for personality in containers.conf instead of user's needing to modify seccomp.json ?

Please correct me if i am misunderstanding the issue here.