On Wed, Mar 18, 2015 at 2:30 PM, Serge E. Hallyn <se...@hallyn.com> 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. Basically, the note is correct: ptrace really cannot be allowed in a filter or it could be used to bypass the filter. I am, of course, open to ideas on fixing this without introducing loops. The use-case of having a ptrace monitor of a sandboxed process intentionally changing syscalls isn't a use-case I think we need to support. Monitors like that should just perform such calls themselves from the unsandboxed half. -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/