PR_SET_SECCOMP and PR_GET_SECCOMP doc (and bug?)

PR_SET_SECCOMP and PR_GET_SECCOMP doc (and bug?)

[Michael Kerrisk]

Andrea,

Below is my attempt to document the SECCOMP prctl() operations that you added
in 2.6.23.  Could you please read, and let me know if I have the details
correct.  Especially take a look at the description of PR_GET_SECCOMP, whose
operation tends to suggest a thinko:

    PR_SET_SECCOMP (since Linux 2.6.23)
        Set the secure computing mode for the calling  thread.   In
        the  current  implementation,  arg2  must  be 1.  After the
        secure computing mode has been set to 1,  the  only  system
        calls  that  the  thread  is permitted to make are read(2),
        write(2), _exit(2), and sigreturn(2).  Other  system  calls
        result in the delivery of a SIGKILL signal.  Secure comput-
        ing mode is useful for number-crunching  applications  that
        may  need  to execute untrusted byte code, perhaps obtained
        by reading from a pipe or socket.  This operation  is  only
        available  if  the kernel is configured with CONFIG_SECCOMP
        enabled.

    PR_GET_SECCOMP (since Linux 2.6.23)
        Return the secure computing mode  of  the  calling  thread.
        Not  very  useful: if the caller is not in secure computing
        mode, this operation returns 0; if the caller is in  secure
        computing  mode, then the prctl() call will cause a SIGKILL
        signal to be sent to the process.  This operation  is  only
        available  if  the kernel is configured with CONFIG_SECCOMP
        enabled.

Have I misunderstood something?  Surely it is not really intended that
PR_GET_SECCOMP be this useless?  The alternatives that I can think of would be
that

a) at least the call prctl(PR_GET_SECCOMP) would be among the set of permitted
syscalls in secure computing mode, or

b) there shouldn't be a prctl(PR_GET_SECCOMP) at all.

Cheers,

Michael

Re: PR_SET_SECCOMP and PR_GET_SECCOMP doc (and bug?)

[Andrea Arcangeli]

Hi Michael,

On Mon, Jun 16, 2008 at 02:15:13PM +0200, Michael Kerrisk wrote:
> Andrea,
> 
> Below is my attempt to document the SECCOMP prctl() operations that you added
> in 2.6.23.  Could you please read, and let me know if I have the details
> correct.  Especially take a look at the description of PR_GET_SECCOMP, whose
> operation tends to suggest a thinko:

thanks for this useful doc effort!

> 
>     PR_SET_SECCOMP (since Linux 2.6.23)
>         Set the secure computing mode for the calling  thread.   In
>         the  current  implementation,  arg2  must  be 1.  After the
>         secure computing mode has been set to 1,  the  only  system
>         calls  that  the  thread  is permitted to make are read(2),
>         write(2), _exit(2), and sigreturn(2).  Other  system  calls
>         result in the delivery of a SIGKILL signal.  Secure comput-
>         ing mode is useful for number-crunching  applications  that
>         may  need  to execute untrusted byte code, perhaps obtained
>         by reading from a pipe or socket.  This operation  is  only
>         available  if  the kernel is configured with CONFIG_SECCOMP
>         enabled.
> 
>     PR_GET_SECCOMP (since Linux 2.6.23)
>         Return the secure computing mode  of  the  calling  thread.
>         Not  very  useful: if the caller is not in secure computing
>         mode, this operation returns 0; if the caller is in  secure
>         computing  mode, then the prctl() call will cause a SIGKILL
>         signal to be sent to the process.  This operation  is  only
>         available  if  the kernel is configured with CONFIG_SECCOMP
>         enabled.
> 
> Have I misunderstood something?  Surely it is not really intended that

No, the above is exactly correct.

> PR_GET_SECCOMP be this useless?  The alternatives that I can think of would be
> that

I thought that registering a PR_GET_SECCOMP next to the SET operation
was nicer in case future modes > 1 will allow to enable/disable more
syscalls on demand (so including prctl), if you see the prctl.h file
has get/set and read/drop for all other prctl so retaining that
symmetry looked natural. However I tend to agree that currently
PR_GET_SECCOMP is mostly useless, so perhaps it was better not to
register it at all but it doesn't really make any practical
difference.

> a) at least the call prctl(PR_GET_SECCOMP) would be among the set of permitted
> syscalls in secure computing mode, or

It's very intentional that prctl isn't one of the permitted syscalls
with mode=1. Future modes may vary.

> b) there shouldn't be a prctl(PR_GET_SECCOMP) at all.

I'm not against if somebody wants to nuke GET_SECCOMP, I'm neutral on
this, but it doesn't really waste anything relevant and at least to
me, it looked cleaner to have it even if not useful with current
mode=1.

Re: PR_SET_SECCOMP and PR_GET_SECCOMP doc (and bug?)

[Michael Kerrisk]

Hi Andrea,

On Mon, Jun 16, 2008 at 6:25 PM, Andrea Arcangeli <andrea@qumranet.com> wrote:
> Hi Michael,
>
> On Mon, Jun 16, 2008 at 02:15:13PM +0200, Michael Kerrisk wrote:
>> Andrea,
>>
>> Below is my attempt to document the SECCOMP prctl() operations that you added
>> in 2.6.23.  Could you please read, and let me know if I have the details
>> correct.  Especially take a look at the description of PR_GET_SECCOMP, whose
>> operation tends to suggest a thinko:
>
> thanks for this useful doc effort!
>
>>
>>     PR_SET_SECCOMP (since Linux 2.6.23)
>>         Set the secure computing mode for the calling  thread.   In
>>         the  current  implementation,  arg2  must  be 1.  After the
>>         secure computing mode has been set to 1,  the  only  system
>>         calls  that  the  thread  is permitted to make are read(2),
>>         write(2), _exit(2), and sigreturn(2).  Other  system  calls
>>         result in the delivery of a SIGKILL signal.  Secure comput-
>>         ing mode is useful for number-crunching  applications  that
>>         may  need  to execute untrusted byte code, perhaps obtained
>>         by reading from a pipe or socket.  This operation  is  only
>>         available  if  the kernel is configured with CONFIG_SECCOMP
>>         enabled.
>>
>>     PR_GET_SECCOMP (since Linux 2.6.23)
>>         Return the secure computing mode  of  the  calling  thread.
>>         Not  very  useful: if the caller is not in secure computing
>>         mode, this operation returns 0; if the caller is in  secure
>>         computing  mode, then the prctl() call will cause a SIGKILL
>>         signal to be sent to the process.  This operation  is  only
>>         available  if  the kernel is configured with CONFIG_SECCOMP
>>         enabled.
>>
>> Have I misunderstood something?  Surely it is not really intended that
>
> No, the above is exactly correct.

Okay -- thanks for the confirmation.

>> PR_GET_SECCOMP be this useless?  The alternatives that I can think of would be
>> that
>
> I thought that registering a PR_GET_SECCOMP next to the SET operation
> was nicer in case future modes > 1 will allow to enable/disable more
> syscalls on demand (so including prctl),

Okay.

> if you see the prctl.h file
> has get/set and read/drop for all other prctl so retaining that
> symmetry looked natural.

Okay.

> However I tend to agree that currently
> PR_GET_SECCOMP is mostly useless, so perhaps it was better not to
> register it at all but it doesn't really make any practical
> difference.
>
>> a) at least the call prctl(PR_GET_SECCOMP) would be among the set of permitted
>> syscalls in secure computing mode, or
>
> It's very intentional that prctl isn't one of the permitted syscalls
> with mode=1. Future modes may vary.
>
>> b) there shouldn't be a prctl(PR_GET_SECCOMP) at all.
>
> I'm not against if somebody wants to nuke GET_SECCOMP, I'm neutral on
> this, but it doesn't really waste anything relevant and at least to
> me, it looked cleaner to have it even if not useful with current
> mode=1.

I have no strong opinion either way about what should be done.  IMO,
even the status quo is fine, as long as it's documented.  My only
doubt was that the status quo is a little "strange" so I wondered
whether there might have been some mistake.  Anyway, if you do decide
to change something here, please CC me.

Cheers,

Michael



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html

Re: PR_SET_SECCOMP and PR_GET_SECCOMP doc (and bug?)

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 910 bytes --]

On Tue, 17 Jun 2008 15:32:29 +0200, Michael Kerrisk said:
> On Mon, Jun 16, 2008 at 6:25 PM, Andrea Arcangeli <andrea@qumranet.com> wrote:
> > On Mon, Jun 16, 2008 at 02:15:13PM +0200, Michael Kerrisk wrote:

> >>     PR_GET_SECCOMP (since Linux 2.6.23)
> >>         Return the secure computing mode  of  the  calling  thread.
> >>         Not  very  useful: if the caller is not in secure computing
> >>         mode, this operation returns 0; if the caller is in  secure
> >>         computing  mode, then the prctl() call will cause a SIGKILL
> >>         signal to be sent to the process.  This operation  is  only
> >>         available  if  the kernel is configured with CONFIG_SECCOMP
> >>         enabled.

Would it make sense to change the text to read "Not very useful for the
current implementation of mode=1" and/or add that it may be useful for
future modes that allow prctl() modes other than 1?

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: PR_SET_SECCOMP and PR_GET_SECCOMP doc (and bug?)

[Andrea Arcangeli]

On Tue, Jun 17, 2008 at 12:12:14PM -0400, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 17 Jun 2008 15:32:29 +0200, Michael Kerrisk said:
> > On Mon, Jun 16, 2008 at 6:25 PM, Andrea Arcangeli <andrea@qumranet.com> wrote:
> > > On Mon, Jun 16, 2008 at 02:15:13PM +0200, Michael Kerrisk wrote:
> 
> > >>     PR_GET_SECCOMP (since Linux 2.6.23)
> > >>         Return the secure computing mode  of  the  calling  thread.
> > >>         Not  very  useful: if the caller is not in secure computing
> > >>         mode, this operation returns 0; if the caller is in  secure
> > >>         computing  mode, then the prctl() call will cause a SIGKILL
> > >>         signal to be sent to the process.  This operation  is  only
> > >>         available  if  the kernel is configured with CONFIG_SECCOMP
> > >>         enabled.
> 
> Would it make sense to change the text to read "Not very useful for the
> current implementation of mode=1" and/or add that it may be useful for

Yes, makes sense to me ;).

Re: PR_SET_SECCOMP and PR_GET_SECCOMP doc (and bug?)

[Andrea Arcangeli]

On Tue, Jun 17, 2008 at 03:32:29PM +0200, Michael Kerrisk wrote:
> even the status quo is fine, as long as it's documented.  My only
> doubt was that the status quo is a little "strange" so I wondered

I agree it's a little strange ;).

> whether there might have been some mistake.  Anyway, if you do decide
> to change something here, please CC me.

Sure!

Re: PR_SET_SECCOMP and PR_GET_SECCOMP doc (and bug?)

[Michael Kerrisk]

On Tue, Jun 17, 2008 at 7:34 PM, Andrea Arcangeli <andrea@qumranet.com> wrote:
> On Tue, Jun 17, 2008 at 12:12:14PM -0400, Valdis.Kletnieks@vt.edu wrote:
>> On Tue, 17 Jun 2008 15:32:29 +0200, Michael Kerrisk said:
>> > On Mon, Jun 16, 2008 at 6:25 PM, Andrea Arcangeli <andrea@qumranet.com> wrote:
>> > > On Mon, Jun 16, 2008 at 02:15:13PM +0200, Michael Kerrisk wrote:
>>
>> > >>     PR_GET_SECCOMP (since Linux 2.6.23)
>> > >>         Return the secure computing mode  of  the  calling  thread.
>> > >>         Not  very  useful: if the caller is not in secure computing
>> > >>         mode, this operation returns 0; if the caller is in  secure
>> > >>         computing  mode, then the prctl() call will cause a SIGKILL
>> > >>         signal to be sent to the process.  This operation  is  only
>> > >>         available  if  the kernel is configured with CONFIG_SECCOMP
>> > >>         enabled.
>>
>> Would it make sense to change the text to read "Not very useful for the
>> current implementation of mode=1" and/or add that it may be useful for
>
> Yes, makes sense to me ;).

I've made a change something like you suggest, Valdis.  But I'm still
not really convinced that it will be useful in the future.  The
problem is that as things stand, we would *never* be able to safely
make the prctl(PR_GET_SECCOMP) call, since there is a chance (if mode
is 1) that we would be killed by SIGKILL.



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html