Michael/Andrea,

Would you also like to review the corresponding test cases for the same in
LTP (http://ltp.cvs.sourceforge.net/ltp/ltp/testcases/kernel/syscalls/prctl/),
against the changes in 2.6.23. The testcases are pretty old and may require
review now.

Regards--
Subrata

On Mon, Jun 16, 2008 at 5:45 PM, Michael Kerrisk <
[EMAIL PROTECTED]> 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:
>
>    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
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>



-- 
Regards & Thanks--
Subrata
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Reply via email to