pipelines: relax seccomp policy to allow unshare?

Issue #13655 resolved
Serge Hallyn created an issue

I'd like to test some basic containers functionality of a toolsuite. This would require unsharing the user namespace (unshare -U). This requires no capability, your kernel sysctl and apparmor policy allow it, but the default docker seccomp policy denies it.

Would it be possible to allow it?

Without this, I basically can't use pipelines for these tests, so will have to hook in my external jenkins.

Thanks for considering!

Comments (11)

  1. Matt Ryall

    Thanks for the request, Serge. I'm checking with our dev team on the technical feasibility of this.

    What do you require access to unshare for? I didn't really follow what you're doing with "testing containers functionality of a toolsuite". Can you give a bit more detail?

  2. Serge Hallyn reporter

    Actually, it looks like either the pipeline environment has changed, or you have more than one environment. When I filed this bug, tests seemed to run with apparmor and a seccomp policy which denied 'unshare -U'. Today, I see a selinux environment with no seccomp, and I'm able to do 'unshare -U -- id'. This brings me closer to what I need - if in fact all pipelines will run in that environment (and depending on the selinux restrictions imposed by the svirt_lxc_net_t domain).

    Will all tests run in this environment?

    In this new environment, however, "unshare -rU -- unshare --mount-proc -mu -- cat /proc/self/status" is not allowed due to the 'mount-proc".

  3. Serge Hallyn reporter

    If it would help I could come up with a script which, if it runs in the pipelines, should suffice for my tests.

  4. Matt Ryall

    Yes, we have changed environments since December, moving to hosting our containers in Kubernetes instead of ECS, which resulted in some customer-facing changes.

    What does the software do that you're trying to test in Pipelines?

    Testing low-level OS functionality like 'unshare' is not really a design goal of Pipelines. We're primarily about testing application software that works at a higher level and can run in Docker containers in an appropriate sandbox. If you're continually pushing the limits of the sandboxing, you might be better to set up your own EC2 instances for testing.

  5. Serge Hallyn reporter

    I'm not looking to test unshare itself, but rather use unshare to test container management. These run fine, for instance, inside fully sandboxed lxc and lxd containers.

    Indeed, currently I am using a GCE instance on which to run the tests (in lxd containers on the instance).

  6. Serge Hallyn reporter

    So it appears that the current blocker for me is --mount-proc, which is probably due to a selinux policy. I won't ask for that to be changed as that's likely an intricate part of a specific defense.


  7. Log in to comment