Add a new action, SECCOMP_RET_LOG, that logs a syscall before allowing
the syscall. At the implementation level, this action is identical to
the existing SECCOMP_RET_ALLOW action. However, it can be very useful when
initially developing a seccomp filter for an application. The developer
can set the
On Thu, Feb 2, 2017 at 9:37 PM, Tyler Hicks wrote:
> Add a new action, SECCOMP_RET_LOG, that logs a syscall before allowing
> the syscall. At the implementation level, this action is identical to
> the existing SECCOMP_RET_ALLOW action. However, it can be very useful when
> initially developing a
On Tue, Feb 7, 2017 at 4:33 PM, Kees Cook wrote:
> On Thu, Feb 2, 2017 at 9:37 PM, Tyler Hicks wrote:
>> Add a new action, SECCOMP_RET_LOG, that logs a syscall before allowing
>> the syscall. At the implementation level, this action is identical to
>> the existing SECCOMP_RET_ALLOW action. Howeve
On 02/07/2017 06:33 PM, Kees Cook wrote:
> On Thu, Feb 2, 2017 at 9:37 PM, Tyler Hicks wrote:
>> Add a new action, SECCOMP_RET_LOG, that logs a syscall before allowing
>> the syscall. At the implementation level, this action is identical to
>> the existing SECCOMP_RET_ALLOW action. However, it can
On Fri, Feb 10, 2017 at 4:01 PM, Tyler Hicks wrote:
> On 02/07/2017 06:33 PM, Kees Cook wrote:
>> This adds to UAPI, so it'd be good to think for a moment about how
>> this would work on older kernels: right now, if someone tried to use
>> this RET_LOG on an old kernel, it'll get treated like RET_
On 02/10/2017 06:08 PM, Kees Cook wrote:
> On Fri, Feb 10, 2017 at 4:01 PM, Tyler Hicks wrote:
>> On 02/07/2017 06:33 PM, Kees Cook wrote:
>>> This adds to UAPI, so it'd be good to think for a moment about how
>>> this would work on older kernels: right now, if someone tried to use
>>> this RET_LO
