A KILL execve seccomp filter is affecting the NsJail parent process

[MarkKoz]

I want a execve to be blocked only on the subproccess NsJail creates. However, the seccomp filter seems to affect the NsJail process itself too. A seccomp violation is triggered before the subprocess even starts. I believe this is because NsJail's execve in subprocNewProc is violating the seccomp filter. Is it possible to only apply the filters to the subprocess?

Example:

nsjail -Mo --chroot / --seccomp_string 'KILL { execve } DEFAULT ALLOW' -- /bin/echo "ABC"

[I][2020-02-21T16:22:18+0000] Mode: STANDALONE_ONCE
[I][2020-02-21T16:22:18+0000] Jail parameters: hostname:'NSJAIL', chroot:'/', process:'/bin/echo', bind:[::]:0, max_conns_per_ip:0, time_limit:0, personality:0, daemonize:false, clone_newnet:true, clone_newuser:true, clone_newns:true, clone_newpid:true, clone_newipc:true, clone_newuts:true, clone_newcgroup:true, keep_caps:false, disable_no_new_privs:false, max_cpus:0
[I][2020-02-21T16:22:18+0000] Mount: '/' -> '/' flags:MS_RDONLY|MS_BIND|MS_REC|MS_PRIVATE type:'' options:'' dir:true
[I][2020-02-21T16:22:18+0000] Mount: '/proc' flags:MS_RDONLY type:'proc' options:'' dir:true
[I][2020-02-21T16:22:18+0000] Uid map: inside_uid:0 outside_uid:0 count:1 newuidmap:false
[W][2020-02-21T16:22:18+0000][21] void cmdline::logParams(nsjconf_t*)():254 Process will be UID/EUID=0 in the global user namespace, and will have user root-level access to files
[I][2020-02-21T16:22:18+0000] Gid map: inside_gid:0 outside_gid:0 count:1 newgidmap:false
[W][2020-02-21T16:22:18+0000][21] void cmdline::logParams(nsjconf_t*)():264 Process will be GID/EGID=0 in the global user namespace, and will have group root-level access to files
[I][2020-02-21T16:22:18+0000] Executing '/bin/echo' for '[STANDALONE MODE]'
[W][2020-02-21T16:22:18+0000][21] void subproc::seccompViolation(nsjconf_t*, siginfo_t*)():259 pid=22 commited a syscall/seccomp violation and exited with SIGSYS
[W][2020-02-21T16:22:18+0000][21] void subproc::seccompViolation(nsjconf_t*, siginfo_t*)():293 pid=22, SiSyscall: 31, SiCode: 2, SiErrno: 0, SiSigno: 17, SP: 0, PC: 0
[I][2020-02-21T16:22:18+0000] pid=22 ([STANDALONE MODE]) terminated with signal: SIGSYS (31), (PIDs left: 0)

[gabrielemarra]

I have the same need, and it seems to be a limitation on how nsjail works and what Kafel allows to do.

[robertswiecki]

It's possible to block execve, and then allow execveat, forcing the flags arg to be AT_EMPTY_PATH (or AT_EMPTY_PATH|AT_SYMLINK_NOFOLLOW). It'll also require forcing use of execveat in nsjail.

  --execute_fd 
        Use execveat() to execute a file-descriptor instead of executing the
        binary path. In such case argv[0]/exec_file denotes a file path before
        mount namespacing

FWIW, execve/execveat is not that special - I'm simplifying here, but it's a superset of open/read/mmap/close, it doesn't allow for any magic per se.

Blocking execve and allowing execveat will disable ability to execute files from the fs, and only leave possibility to execute filedescriptors, which are already opened.