On Wed, Mar 18, 2015 at 2:42 PM, Andy Lutomirski <l...@amacapital.net> wrote: > On Wed, Mar 18, 2015 at 2:38 PM, Kees Cook <keesc...@chromium.org> wrote: >> 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. > > 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.
Nope, RET_TRACE is lower. KILL, TRAP, ERRNO, TRACE, ALLOW. Still doesn't help the above cases, but we can't override a blocked syscall just with a new filter. You'd still have to do the ptrace dance with an allowed syscall. -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/