Messages in this thread | | | From | Andy Lutomirski <> | Date | Wed, 18 Mar 2015 14:42:02 -0700 | Subject | Re: seccomp vs ptrace |
| |
On Wed, Mar 18, 2015 at 2:38 PM, Kees Cook <keescook@chromium.org> wrote: > On Wed, Mar 18, 2015 at 2:30 PM, Serge E. Hallyn <serge@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.
--Andy
| |