On Wed, Mar 18, 2015 at 2:38 PM, Kees Cook <[email protected]> wrote: > On Wed, Mar 18, 2015 at 2:30 PM, Serge E. Hallyn <[email protected]> wrote: >> Hi, >> >> I'm writing to ask about >> >> The seccomp check will not be run again after the tracer is >> notified. (This means that seccomp-based sandboxes MUST NOT >> allow use of ptrace, even of other sandboxed processes, without >> extreme care; ptracers can use this mechanism to escape.) >> >> This basically means that seccomp cannot be safely used with for instance >> an upstart based container. I've been told that Andy was working on >> changing the order so that ptrace checks would be done before seccomp. >> Is there any update on that? Is it likely to happen? Scrapped? > > There are two problems, as I see it: > > 1) seccomp filtering happens first, so any following ptrace actions > could change the syscall that actually happens (e.g. a filter allows > clone and ptrace, meaning it could start a child, ptrace it, issue an > allowed syscall, catch it, and change it to a disallowed syscall: > escape from sandbox). > > 2) even if ptrace was moved ahead of seccomp, a sandboxed process as > above and also access to add more filters (via seccomp or prctl > syscalls) could use SECCOMP_RET_TRACE, to catch the syscall at the end > of the seccomp checks, which would allow the same as above.
Ouch! Arguably we messed up by making SECCOMP_RET_TRACE have higher precedence than ERRNO and TRAP. We could add new ERRNO and TRAP actions that have high precedence or a new flag that promotes them in the filter being applied. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
