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



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