Re: [patch] seccomp.2: Note that memory area is read-only

2015-04-19 Thread Michael Kerrisk (man-pages)
On 19 April 2015 at 01:37, Kees Cook  wrote:
> On Mon, Apr 6, 2015 at 8:29 AM, Michael Kerrisk (man-pages)
>  wrote:
>> Hi Kees,
>>
>> I recently was asked about the point below, and had to go check the code
>> to be sure, since the man page said nothing. It would be good to have
>> a confirmation: the seccomp_data buffer supplied to a seccomp BPF program
>> is read-only, right? (That is, one can't write to the buffer in order to
>> change the arguments that a system call actually receives.)
>
> That's correct. If BPF even allows changing the data, it's not copied
> back to the syscall when it runs. Anything wanting to do things like
> that would need to use ptrace to catch the call an directly modify the
> registers before continuing with the call.
>
>>
>> A small man page patch below.
>
> Looks good, thanks!

Thanks, Kees!

Cheers,

Michael


>> --- a/man2/seccomp.2
>> +++ b/man2/seccomp.2
>> @@ -232,15 +232,15 @@ struct sock_filter {/* Filter block */
>>  };
>>  .fi
>>  .in
>>
>>  When executing the instructions, the BPF program operates on the
>>  system call information made available (i.e., use the
>>  .BR BPF_ABS
>> -addressing mode) as a buffer of the following form:
>> +addressing mode) as a (read-only) buffer of the following form:
>>
>>  .in +4n
>>  .nf
>>  struct seccomp_data {
>>  int   nr;   /* System call number */
>>  __u32 arch; /* AUDIT_ARCH_* value
>> (see ) */
>>
>>
>> --
>> Michael Kerrisk
>> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
>> Linux/UNIX System Programming Training: http://man7.org/training/
>
>
>
> --
> Kees Cook
> Chrome OS Security



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
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/


Re: [patch] seccomp.2: Note that memory area is read-only

2015-04-19 Thread Michael Kerrisk (man-pages)
On 19 April 2015 at 01:37, Kees Cook keesc...@chromium.org wrote:
 On Mon, Apr 6, 2015 at 8:29 AM, Michael Kerrisk (man-pages)
 mtk.manpa...@gmail.com wrote:
 Hi Kees,

 I recently was asked about the point below, and had to go check the code
 to be sure, since the man page said nothing. It would be good to have
 a confirmation: the seccomp_data buffer supplied to a seccomp BPF program
 is read-only, right? (That is, one can't write to the buffer in order to
 change the arguments that a system call actually receives.)

 That's correct. If BPF even allows changing the data, it's not copied
 back to the syscall when it runs. Anything wanting to do things like
 that would need to use ptrace to catch the call an directly modify the
 registers before continuing with the call.


 A small man page patch below.

 Looks good, thanks!

Thanks, Kees!

Cheers,

Michael


 --- a/man2/seccomp.2
 +++ b/man2/seccomp.2
 @@ -232,15 +232,15 @@ struct sock_filter {/* Filter block */
  };
  .fi
  .in

  When executing the instructions, the BPF program operates on the
  system call information made available (i.e., use the
  .BR BPF_ABS
 -addressing mode) as a buffer of the following form:
 +addressing mode) as a (read-only) buffer of the following form:

  .in +4n
  .nf
  struct seccomp_data {
  int   nr;   /* System call number */
  __u32 arch; /* AUDIT_ARCH_* value
 (see linux/audit.h) */


 --
 Michael Kerrisk
 Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
 Linux/UNIX System Programming Training: http://man7.org/training/



 --
 Kees Cook
 Chrome OS Security



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
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/


Re: [patch] seccomp.2: Note that memory area is read-only

2015-04-18 Thread Alexei Starovoitov
On Sat, Apr 18, 2015 at 04:37:35PM -0700, Kees Cook wrote:
> On Mon, Apr 6, 2015 at 8:29 AM, Michael Kerrisk (man-pages)
>  wrote:
> > Hi Kees,
> >
> > I recently was asked about the point below, and had to go check the code
> > to be sure, since the man page said nothing. It would be good to have
> > a confirmation: the seccomp_data buffer supplied to a seccomp BPF program
> > is read-only, right? (That is, one can't write to the buffer in order to
> > change the arguments that a system call actually receives.)
> 
> That's correct. If BPF even allows changing the data, it's not copied
> back to the syscall when it runs. Anything wanting to do things like
> that would need to use ptrace to catch the call an directly modify the
> registers before continuing with the call.

Today BPF programs can only read from seccomp_data buffer.
I think it would be an interesting feature to allow overwrite of
syscall arguments by the program on the fly... sometime in the future.

--
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/


Re: [patch] seccomp.2: Note that memory area is read-only

2015-04-18 Thread Kees Cook
On Mon, Apr 6, 2015 at 8:29 AM, Michael Kerrisk (man-pages)
 wrote:
> Hi Kees,
>
> I recently was asked about the point below, and had to go check the code
> to be sure, since the man page said nothing. It would be good to have
> a confirmation: the seccomp_data buffer supplied to a seccomp BPF program
> is read-only, right? (That is, one can't write to the buffer in order to
> change the arguments that a system call actually receives.)

That's correct. If BPF even allows changing the data, it's not copied
back to the syscall when it runs. Anything wanting to do things like
that would need to use ptrace to catch the call an directly modify the
registers before continuing with the call.

>
> A small man page patch below.

Looks good, thanks!

-Kees

>
> Cheers,
>
> Michael
>
> --- a/man2/seccomp.2
> +++ b/man2/seccomp.2
> @@ -232,15 +232,15 @@ struct sock_filter {/* Filter block */
>  };
>  .fi
>  .in
>
>  When executing the instructions, the BPF program operates on the
>  system call information made available (i.e., use the
>  .BR BPF_ABS
> -addressing mode) as a buffer of the following form:
> +addressing mode) as a (read-only) buffer of the following form:
>
>  .in +4n
>  .nf
>  struct seccomp_data {
>  int   nr;   /* System call number */
>  __u32 arch; /* AUDIT_ARCH_* value
> (see ) */
>
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/



-- 
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/


Re: [patch] seccomp.2: Note that memory area is read-only

2015-04-18 Thread Michael Kerrisk (man-pages)
Hi Kees,

Ping!

Cheers,

Michael



On 6 April 2015 at 17:29, Michael Kerrisk (man-pages)
 wrote:
> Hi Kees,
>
> I recently was asked about the point below, and had to go check the code
> to be sure, since the man page said nothing. It would be good to have
> a confirmation: the seccomp_data buffer supplied to a seccomp BPF program
> is read-only, right? (That is, one can't write to the buffer in order to
> change the arguments that a system call actually receives.)
>
> A small man page patch below.
>
> Cheers,
>
> Michael
>
> --- a/man2/seccomp.2
> +++ b/man2/seccomp.2
> @@ -232,15 +232,15 @@ struct sock_filter {/* Filter block */
>  };
>  .fi
>  .in
>
>  When executing the instructions, the BPF program operates on the
>  system call information made available (i.e., use the
>  .BR BPF_ABS
> -addressing mode) as a buffer of the following form:
> +addressing mode) as a (read-only) buffer of the following form:
>
>  .in +4n
>  .nf
>  struct seccomp_data {
>  int   nr;   /* System call number */
>  __u32 arch; /* AUDIT_ARCH_* value
> (see ) */
>
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
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/


Re: [patch] seccomp.2: Note that memory area is read-only

2015-04-18 Thread Michael Kerrisk (man-pages)
Hi Kees,

Ping!

Cheers,

Michael



On 6 April 2015 at 17:29, Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
 Hi Kees,

 I recently was asked about the point below, and had to go check the code
 to be sure, since the man page said nothing. It would be good to have
 a confirmation: the seccomp_data buffer supplied to a seccomp BPF program
 is read-only, right? (That is, one can't write to the buffer in order to
 change the arguments that a system call actually receives.)

 A small man page patch below.

 Cheers,

 Michael

 --- a/man2/seccomp.2
 +++ b/man2/seccomp.2
 @@ -232,15 +232,15 @@ struct sock_filter {/* Filter block */
  };
  .fi
  .in

  When executing the instructions, the BPF program operates on the
  system call information made available (i.e., use the
  .BR BPF_ABS
 -addressing mode) as a buffer of the following form:
 +addressing mode) as a (read-only) buffer of the following form:

  .in +4n
  .nf
  struct seccomp_data {
  int   nr;   /* System call number */
  __u32 arch; /* AUDIT_ARCH_* value
 (see linux/audit.h) */


 --
 Michael Kerrisk
 Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
 Linux/UNIX System Programming Training: http://man7.org/training/



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
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/


Re: [patch] seccomp.2: Note that memory area is read-only

2015-04-18 Thread Kees Cook
On Mon, Apr 6, 2015 at 8:29 AM, Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
 Hi Kees,

 I recently was asked about the point below, and had to go check the code
 to be sure, since the man page said nothing. It would be good to have
 a confirmation: the seccomp_data buffer supplied to a seccomp BPF program
 is read-only, right? (That is, one can't write to the buffer in order to
 change the arguments that a system call actually receives.)

That's correct. If BPF even allows changing the data, it's not copied
back to the syscall when it runs. Anything wanting to do things like
that would need to use ptrace to catch the call an directly modify the
registers before continuing with the call.


 A small man page patch below.

Looks good, thanks!

-Kees


 Cheers,

 Michael

 --- a/man2/seccomp.2
 +++ b/man2/seccomp.2
 @@ -232,15 +232,15 @@ struct sock_filter {/* Filter block */
  };
  .fi
  .in

  When executing the instructions, the BPF program operates on the
  system call information made available (i.e., use the
  .BR BPF_ABS
 -addressing mode) as a buffer of the following form:
 +addressing mode) as a (read-only) buffer of the following form:

  .in +4n
  .nf
  struct seccomp_data {
  int   nr;   /* System call number */
  __u32 arch; /* AUDIT_ARCH_* value
 (see linux/audit.h) */


 --
 Michael Kerrisk
 Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
 Linux/UNIX System Programming Training: http://man7.org/training/



-- 
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/


Re: [patch] seccomp.2: Note that memory area is read-only

2015-04-18 Thread Alexei Starovoitov
On Sat, Apr 18, 2015 at 04:37:35PM -0700, Kees Cook wrote:
 On Mon, Apr 6, 2015 at 8:29 AM, Michael Kerrisk (man-pages)
 mtk.manpa...@gmail.com wrote:
  Hi Kees,
 
  I recently was asked about the point below, and had to go check the code
  to be sure, since the man page said nothing. It would be good to have
  a confirmation: the seccomp_data buffer supplied to a seccomp BPF program
  is read-only, right? (That is, one can't write to the buffer in order to
  change the arguments that a system call actually receives.)
 
 That's correct. If BPF even allows changing the data, it's not copied
 back to the syscall when it runs. Anything wanting to do things like
 that would need to use ptrace to catch the call an directly modify the
 registers before continuing with the call.

Today BPF programs can only read from seccomp_data buffer.
I think it would be an interesting feature to allow overwrite of
syscall arguments by the program on the fly... sometime in the future.

--
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/