On Wed, Mar 18, 2015 at 2:44 PM, Kees Cook wrote:
> On Wed, Mar 18, 2015 at 2:42 PM, Andy Lutomirski wrote:
>> On Wed, Mar 18, 2015 at 2:38 PM, Kees Cook wrote:
>>> On Wed, Mar 18, 2015 at 2:30 PM, Serge E. Hallyn wrote:
Hi,
I'm writing to ask about
The seccomp
On Wed, Mar 18, 2015 at 2:42 PM, Andy Lutomirski wrote:
> On Wed, Mar 18, 2015 at 2:38 PM, Kees Cook wrote:
>> On Wed, Mar 18, 2015 at 2:30 PM, Serge E. Hallyn wrote:
>>> Hi,
>>>
>>> I'm writing to ask about
>>>
>>> The seccomp check will not be run again after the tracer is
>>>
On Wed, Mar 18, 2015 at 2:38 PM, Kees Cook wrote:
> On Wed, Mar 18, 2015 at 2:30 PM, Serge E. Hallyn 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
>>
On Wed, Mar 18, 2015 at 2:30 PM, Serge E. Hallyn 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
On Wed, Mar 18, 2015 at 2:30 PM, Serge E. Hallyn 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
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 es
6 matches
Mail list logo