[lkml]   [2008]   [Jun]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: PR_SET_SECCOMP and PR_GET_SECCOMP doc (and bug?)
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

> 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

 \ /
  Last update: 2008-06-16 18:29    [W:0.080 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site