linux-kernel - [PATCH] seccomp.2: Add note about alarm(2) not being sufficient to limit runtime

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 12 Mar 2015 14:07:01 +0100
From:	Jann Horn <jann@...jh.net>
To:	Michael Kerrisk <mtk.manpages@...il.com>,
	Mikael Pettersson <mikpelinux@...il.com>
Cc:	linux-man@...r.kernel.org, linux-api@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Michael Kerrisk <mtk.manpages@...il.com>,
	Russell King <linux@....linux.org.uk>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	Jeff Dike <jdike@...toit.com>,
	Richard Weinberger <richard@....at>,
	Kees Cook <keescook@...omium.org>,
	Andy Lutomirski <luto@...capital.net>,
	Will Drewry <wad@...omium.org>
Subject: [PATCH] seccomp.2: Add note about alarm(2) not being sufficient to
 limit runtime

On Wed, Mar 11, 2015 at 10:43:50PM +0100, Mikael Pettersson wrote:
> Jann Horn writes:
>  > Or should I throw this patch away and write a patch
>  > for the prctl() manpage instead that documents that
>  > being able to call sigreturn() implies being able to
>  > effectively call sigprocmask(), at least on some
>  > architectures like X86?
> 
> Well, that is the semantics of sigreturn().  It is essentially
> setcontext() [which includes the actions of sigprocmask()], but
> with restrictions on parameter placement (at least on x86).
> 
> You could introduce some setting to restrict that aspect for
> seccomp processes, but you can't change this for normal processes
> without breaking things.

Then I think it's probably better and easier to just document the existing
behavior? If a new setting would have to be introduced and developers would
need to be aware of that, it's probably easier to just tell everyone to use
SIGKILL.

Does this manpage patch look good?

---
 man2/seccomp.2 | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/man2/seccomp.2 b/man2/seccomp.2
index 702ceb8..f762d07 100644
--- a/man2/seccomp.2
+++ b/man2/seccomp.2
@@ -64,6 +64,31 @@ Strict secure computing mode is useful for number-crunching
 applications that may need to execute untrusted byte code, perhaps
 obtained by reading from a pipe or socket.
 
+Note that although the calling thread can no longer call
+.BR sigprocmask (2),
+it can use
+.BR sigreturn (2)
+to block all signals apart from
+.BR SIGKILL
+and
+.BR SIGSTOP .
+Therefore, to reliably terminate it,
+.BR SIGKILL
+has to be used, meaning that e.g.
+.BR alarm (2)
+is not sufficient for restricting its runtime. Instead, use
+.BR timer_create (2)
+with
+.BR SIGEV_SIGNAL
+and
+.BR sigev_signo
+set to
+.BR SIGKILL
+or use
+.BR setrlimit (2)
+to set the hard limit for
+.BR RLIMIT_CPU .
+
 This operation is available only if the kernel is configured with
 .BR CONFIG_SECCOMP
 enabled.
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/