PR_SET_SECCOMP and PR_GET_SECCOMP doc (and bug?)

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.

Hi Michael,

Quoted 6 lines · 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:

thanks for this useful doc effort!

Quoted 23 lines

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.

Quoted 1 line

Have I misunderstood something? Surely it is not really intended that

No, the above is exactly correct.

Quoted 2 lines

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.

Quoted 2 lines

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.

Quoted 1 line

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.

Quoted 10 lines · Andrea Arcangeli

Quoted 8 lines · Michael Kerrisk

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.

Quoted 11 lines · Michael Kerrisk

Quoted 10 lines · Andrea Arcangeli

Quoted 8 lines · Michael Kerrisk

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

Quoted 13 lines · On Tue, Jun 17, 2008 at 12:12:14PM -0400…

Quoted 11 lines · Michael Kerrisk

Quoted 10 lines · Andrea Arcangeli

Quoted 8 lines · Michael Kerrisk

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.

Quoted 2 lines

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 ;).

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.