seccomp vs ptrace

seccomp vs ptrace

[Serge E. Hallyn]

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?

thanks,
-serge

Re: seccomp vs ptrace

[Kees Cook]

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.

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

Re: seccomp vs ptrace

[Andy Lutomirski]

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?

No, just got stalled because I'm too busy.  The code is here:

https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=x86/seccomp

but it's not really adequately tested.

>
> thanks,
> -serge



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: seccomp vs ptrace

[Andy Lutomirski]

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

Re: seccomp vs ptrace

[Kees Cook]

On Wed, Mar 18, 2015 at 2:42 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> 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.

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

Re: seccomp vs ptrace

[Andy Lutomirski]

On Wed, Mar 18, 2015 at 2:44 PM, Kees Cook <keescook@chromium.org> wrote:
> On Wed, Mar 18, 2015 at 2:42 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> 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.
>
> 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.

Oh, right, I read it backwards.

We could try to handle TRACE immediately instead of after running all
filters.  This could be rather tricky given the way the x86 code
works, though.  Maybe at some point we'll be able to change that
without killing performance.

We could add an ugly flag that says that subsequent filters can use
TRACE, I suppose.  Yuck.

--Andy