Re: Bug#751417: linux-image-3.2.0-4-5kc-malta: no SIGKILL after prctl(PR_SET_SECCOMP, 1, ...) on MIPS

Re: Bug#751417: linux-image-3.2.0-4-5kc-malta: no SIGKILL after prctl(PR_SET_SECCOMP, 1, ...) on MIPS

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 2847 bytes --]

On Thu, 2014-06-12 at 20:36 +0100, Ben Hutchings wrote:
> Control: tag -1 security upstream patch moreinfo
> Control: severity -1 grave
> Control: found -1 3.14.5-1

Aurelien Jarno pointed out this appears to be fixed upstream in 3.15:

commit 137f7df8cead00688524c82360930845396b8a21
Author: Markos Chandras <markos.chandras@imgtec.com>
Date:   Wed Jan 22 14:40:00 2014 +0000

    MIPS: asm: thread_info: Add _TIF_SECCOMP flag

It looks like this can be cherry-picked cleanly onto stable branches for
3.13 and 3.14.  For 3.11 and 3.12, it will need trivial adjustment.

For branches older than 3.11, this needs to be cherry-picked first:

commit e7f3b48af7be9f8007a224663a5b91340626fed5
Author: Ralf Baechle <ralf@linux-mips.org>
Date:   Wed May 29 01:02:18 2013 +0200

    MIPS: Cleanup flags in syscall flags handlers.

Ben.

> On Thu, 2014-06-12 at 16:19 +0000, Plamen Alexandrov wrote:
> > Package: src:linux
> > Version: 3.2.51-1
> > Severity: normal
> > 
> > Under MIPS the system call prctl(PR_SET_SECCOMP, 1, ...) does not behave as expected.
> > According to the manual page, after calling it with 1 as a second argument, any consecutive system calls other than read(), write(), _exit() and sigreturn() should result in the delivery of SIGKILL. However, under MIPS any consecutive system call behaves as if prctl(PR_SET_SECCOMP, 1, ...) was never called.
> > 
> > Here is a simple example that can be used to reproduce the bug:
> > 
> > plamen@debian-mips:/tmp$ id
> > uid=1000(plamen) gid=1000(user) groups=1000(user)
> > plamen@debian-mips:/tmp$ cat prctl.c 
> > #include <unistd.h>
> > #include <sys/prctl.h>
> > #include <stdio.h>
> > 
> > int main(void)
> > {
> > 	if (prctl(PR_SET_SECCOMP, 1, 0, 0, 0) != 0)
> > 		return 0;
> > 	uid_t uid = getuid();
> > 	printf("%u\n", (unsigned)uid);
> > 	return 0;
> > }
> > plamen@debian-mips:/tmp$ gcc prctl.c -o prctl
> > plamen@debian-mips:/tmp$ ./prctl 
> > 1000
> > 
> > There is no change if I replace
> > 	if (prctl(PR_SET_SECCOMP, 1, 0, 0, 0) != 0)
> > with
> > 	if (prctl(PR_SET_SECCOMP, SECCOMP_MODE_STRICT, 0, 0, 0) != 0)
> > and I add #include <linux/seccomp.h>
> 
> Indeed, I see no check for seccomp on the MIPS syscall 'fast path'.  The
> seccomp check appears to be done on the 'slow path' which is used only
> if tracing or audit is also enabled for the task.  If I run the above
> program under strace, it is killed as expected.
> 
> Could you test whether the attached patches fix this?  (Instructions for
> rebuilding the Debian kernel package with patches can be found at
> <http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official>.  These patches apply to 'wheezy'.)
> 
> Ben.
> 

-- 
Ben Hutchings
The program is absolutely right; therefore, the computer must be wrong.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: Bug#751417: linux-image-3.2.0-4-5kc-malta: no SIGKILL after prctl(PR_SET_SECCOMP, 1, ...) on MIPS

[Greg KH]

On Thu, Jun 12, 2014 at 09:21:41PM +0100, Ben Hutchings wrote:
> On Thu, 2014-06-12 at 20:36 +0100, Ben Hutchings wrote:
> > Control: tag -1 security upstream patch moreinfo
> > Control: severity -1 grave
> > Control: found -1 3.14.5-1
> 
> Aurelien Jarno pointed out this appears to be fixed upstream in 3.15:
> 
> commit 137f7df8cead00688524c82360930845396b8a21
> Author: Markos Chandras <markos.chandras@imgtec.com>
> Date:   Wed Jan 22 14:40:00 2014 +0000
> 
>     MIPS: asm: thread_info: Add _TIF_SECCOMP flag
> 
> It looks like this can be cherry-picked cleanly onto stable branches for
> 3.13 and 3.14.  For 3.11 and 3.12, it will need trivial adjustment.
> 
> For branches older than 3.11, this needs to be cherry-picked first:
> 
> commit e7f3b48af7be9f8007a224663a5b91340626fed5
> Author: Ralf Baechle <ralf@linux-mips.org>
> Date:   Wed May 29 01:02:18 2013 +0200
> 
>     MIPS: Cleanup flags in syscall flags handlers.

It also needs parts of 1d7bf993e0731b4ac790667c196b2a2d787f95c3 (MIPS:
ftrace: Add support for syscall tracepoints.) to apply properly to stuff
older than 3.11.  But, I'm not so sure that is good to apply as that is
a whole new feature.

So I think I'll just do this "by hand" to get it to work properly...

thanks,

greg k-h

Re: Bug#751417: linux-image-3.2.0-4-5kc-malta: no SIGKILL after prctl(PR_SET_SECCOMP, 1, ...) on MIPS

[Greg KH]

On Thu, Jun 12, 2014 at 02:03:23PM -0700, Greg KH wrote:
> On Thu, Jun 12, 2014 at 09:21:41PM +0100, Ben Hutchings wrote:
> > On Thu, 2014-06-12 at 20:36 +0100, Ben Hutchings wrote:
> > > Control: tag -1 security upstream patch moreinfo
> > > Control: severity -1 grave
> > > Control: found -1 3.14.5-1
> > 
> > Aurelien Jarno pointed out this appears to be fixed upstream in 3.15:
> > 
> > commit 137f7df8cead00688524c82360930845396b8a21
> > Author: Markos Chandras <markos.chandras@imgtec.com>
> > Date:   Wed Jan 22 14:40:00 2014 +0000
> > 
> >     MIPS: asm: thread_info: Add _TIF_SECCOMP flag
> > 
> > It looks like this can be cherry-picked cleanly onto stable branches for
> > 3.13 and 3.14.  For 3.11 and 3.12, it will need trivial adjustment.
> > 
> > For branches older than 3.11, this needs to be cherry-picked first:
> > 
> > commit e7f3b48af7be9f8007a224663a5b91340626fed5
> > Author: Ralf Baechle <ralf@linux-mips.org>
> > Date:   Wed May 29 01:02:18 2013 +0200
> > 
> >     MIPS: Cleanup flags in syscall flags handlers.
> 
> It also needs parts of 1d7bf993e0731b4ac790667c196b2a2d787f95c3 (MIPS:
> ftrace: Add support for syscall tracepoints.) to apply properly to stuff
> older than 3.11.  But, I'm not so sure that is good to apply as that is
> a whole new feature.
> 
> So I think I'll just do this "by hand" to get it to work properly...

Wait, no, SECCOMP for MIPS isn't even in 3.10 or older kernels, so why
is this a 3.2 issue?  Did you add it there to your kernel for some
reason?

thanks,

greg k-h

Re: Bug#751417: linux-image-3.2.0-4-5kc-malta: no SIGKILL after prctl(PR_SET_SECCOMP, 1, ...) on MIPS

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 2028 bytes --]

On Thu, 2014-06-12 at 14:05 -0700, Greg KH wrote:
> On Thu, Jun 12, 2014 at 02:03:23PM -0700, Greg KH wrote:
> > On Thu, Jun 12, 2014 at 09:21:41PM +0100, Ben Hutchings wrote:
> > > On Thu, 2014-06-12 at 20:36 +0100, Ben Hutchings wrote:
> > > > Control: tag -1 security upstream patch moreinfo
> > > > Control: severity -1 grave
> > > > Control: found -1 3.14.5-1
> > > 
> > > Aurelien Jarno pointed out this appears to be fixed upstream in 3.15:
> > > 
> > > commit 137f7df8cead00688524c82360930845396b8a21
> > > Author: Markos Chandras <markos.chandras@imgtec.com>
> > > Date:   Wed Jan 22 14:40:00 2014 +0000
> > > 
> > >     MIPS: asm: thread_info: Add _TIF_SECCOMP flag
> > > 
> > > It looks like this can be cherry-picked cleanly onto stable branches for
> > > 3.13 and 3.14.  For 3.11 and 3.12, it will need trivial adjustment.
> > > 
> > > For branches older than 3.11, this needs to be cherry-picked first:
> > > 
> > > commit e7f3b48af7be9f8007a224663a5b91340626fed5
> > > Author: Ralf Baechle <ralf@linux-mips.org>
> > > Date:   Wed May 29 01:02:18 2013 +0200
> > > 
> > >     MIPS: Cleanup flags in syscall flags handlers.
> > 
> > It also needs parts of 1d7bf993e0731b4ac790667c196b2a2d787f95c3 (MIPS:
> > ftrace: Add support for syscall tracepoints.) to apply properly to stuff
> > older than 3.11.  But, I'm not so sure that is good to apply as that is
> > a whole new feature.
> > 
> > So I think I'll just do this "by hand" to get it to work properly...
> 
> Wait, no, SECCOMP for MIPS isn't even in 3.10 or older kernels, so why
> is this a 3.2 issue?  Did you add it there to your kernel for some
> reason?

Seccomp mode 2 (i.e. filtering with BPF) was only just implenented for
MIPS in 3.15.  Mode 1 (fixed set of syscalls) was implemented long ago.

(If prctl(PR_SET_SECCOMP) could return success when CONFIG_SECCOMP is
not enabled, that would be even worse!)

Ben.

-- 
Ben Hutchings
The program is absolutely right; therefore, the computer must be wrong.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: Bug#751417: linux-image-3.2.0-4-5kc-malta: no SIGKILL after prctl(PR_SET_SECCOMP, 1, ...) on MIPS

[Greg KH]

On Thu, Jun 12, 2014 at 10:10:59PM +0100, Ben Hutchings wrote:
> On Thu, 2014-06-12 at 14:05 -0700, Greg KH wrote:
> > On Thu, Jun 12, 2014 at 02:03:23PM -0700, Greg KH wrote:
> > > On Thu, Jun 12, 2014 at 09:21:41PM +0100, Ben Hutchings wrote:
> > > > On Thu, 2014-06-12 at 20:36 +0100, Ben Hutchings wrote:
> > > > > Control: tag -1 security upstream patch moreinfo
> > > > > Control: severity -1 grave
> > > > > Control: found -1 3.14.5-1
> > > > 
> > > > Aurelien Jarno pointed out this appears to be fixed upstream in 3.15:
> > > > 
> > > > commit 137f7df8cead00688524c82360930845396b8a21
> > > > Author: Markos Chandras <markos.chandras@imgtec.com>
> > > > Date:   Wed Jan 22 14:40:00 2014 +0000
> > > > 
> > > >     MIPS: asm: thread_info: Add _TIF_SECCOMP flag
> > > > 
> > > > It looks like this can be cherry-picked cleanly onto stable branches for
> > > > 3.13 and 3.14.  For 3.11 and 3.12, it will need trivial adjustment.
> > > > 
> > > > For branches older than 3.11, this needs to be cherry-picked first:
> > > > 
> > > > commit e7f3b48af7be9f8007a224663a5b91340626fed5
> > > > Author: Ralf Baechle <ralf@linux-mips.org>
> > > > Date:   Wed May 29 01:02:18 2013 +0200
> > > > 
> > > >     MIPS: Cleanup flags in syscall flags handlers.
> > > 
> > > It also needs parts of 1d7bf993e0731b4ac790667c196b2a2d787f95c3 (MIPS:
> > > ftrace: Add support for syscall tracepoints.) to apply properly to stuff
> > > older than 3.11.  But, I'm not so sure that is good to apply as that is
> > > a whole new feature.
> > > 
> > > So I think I'll just do this "by hand" to get it to work properly...
> > 
> > Wait, no, SECCOMP for MIPS isn't even in 3.10 or older kernels, so why
> > is this a 3.2 issue?  Did you add it there to your kernel for some
> > reason?
> 
> Seccomp mode 2 (i.e. filtering with BPF) was only just implenented for
> MIPS in 3.15.  Mode 1 (fixed set of syscalls) was implemented long ago.

Really?  I don't see _TIF_SECCOMP in the mips asm files in 3.10.  I
don't feel comfortable backporting it to 3.10 or 3.4, are you going to
do that for 3.2?

> (If prctl(PR_SET_SECCOMP) could return success when CONFIG_SECCOMP is
> not enabled, that would be even worse!)

True, but this seems to have always been broken, right?  :)

thanks,

greg k-h

Re: Bug#751417: linux-image-3.2.0-4-5kc-malta: no SIGKILL after prctl(PR_SET_SECCOMP, 1, ...) on MIPS

[Ben Hutchings]

[-- Attachment #1.1: Type: text/plain, Size: 2777 bytes --]

On Thu, 2014-06-12 at 14:59 -0700, Greg KH wrote:
> On Thu, Jun 12, 2014 at 10:10:59PM +0100, Ben Hutchings wrote:
> > On Thu, 2014-06-12 at 14:05 -0700, Greg KH wrote:
> > > On Thu, Jun 12, 2014 at 02:03:23PM -0700, Greg KH wrote:
> > > > On Thu, Jun 12, 2014 at 09:21:41PM +0100, Ben Hutchings wrote:
> > > > > On Thu, 2014-06-12 at 20:36 +0100, Ben Hutchings wrote:
> > > > > > Control: tag -1 security upstream patch moreinfo
> > > > > > Control: severity -1 grave
> > > > > > Control: found -1 3.14.5-1
> > > > > 
> > > > > Aurelien Jarno pointed out this appears to be fixed upstream in 3.15:
> > > > > 
> > > > > commit 137f7df8cead00688524c82360930845396b8a21
> > > > > Author: Markos Chandras <markos.chandras@imgtec.com>
> > > > > Date:   Wed Jan 22 14:40:00 2014 +0000
> > > > > 
> > > > >     MIPS: asm: thread_info: Add _TIF_SECCOMP flag
> > > > > 
> > > > > It looks like this can be cherry-picked cleanly onto stable branches for
> > > > > 3.13 and 3.14.  For 3.11 and 3.12, it will need trivial adjustment.
> > > > > 
> > > > > For branches older than 3.11, this needs to be cherry-picked first:
> > > > > 
> > > > > commit e7f3b48af7be9f8007a224663a5b91340626fed5
> > > > > Author: Ralf Baechle <ralf@linux-mips.org>
> > > > > Date:   Wed May 29 01:02:18 2013 +0200
> > > > > 
> > > > >     MIPS: Cleanup flags in syscall flags handlers.
> > > > 
> > > > It also needs parts of 1d7bf993e0731b4ac790667c196b2a2d787f95c3 (MIPS:
> > > > ftrace: Add support for syscall tracepoints.) to apply properly to stuff
> > > > older than 3.11.  But, I'm not so sure that is good to apply as that is
> > > > a whole new feature.
> > > > 
> > > > So I think I'll just do this "by hand" to get it to work properly...
> > > 
> > > Wait, no, SECCOMP for MIPS isn't even in 3.10 or older kernels, so why
> > > is this a 3.2 issue?  Did you add it there to your kernel for some
> > > reason?
> > 
> > Seccomp mode 2 (i.e. filtering with BPF) was only just implenented for
> > MIPS in 3.15.  Mode 1 (fixed set of syscalls) was implemented long ago.
> 
> Really?  I don't see _TIF_SECCOMP in the mips asm files in 3.10.  I
> don't feel comfortable backporting it to 3.10 or 3.4, are you going to
> do that for 3.2?

I'm attaching the backport to 3.2 which I've now been able to test.  It
appears to apply cleanly to 3.4 and 3.10 as well.  ("MIPS: Cleanup flags
in syscall flags handlers." applies to all branches with some fuzz.)

> > (If prctl(PR_SET_SECCOMP) could return success when CONFIG_SECCOMP is
> > not enabled, that would be even worse!)
> 
> True, but this seems to have always been broken, right?  :)

Yes, so far as I can see.

Ben.

-- 
Ben Hutchings
Tomorrow will be cancelled due to lack of interest.

[-- Attachment #1.2: MIPS-asm-thread_info-Add-_TIF_SECCOMP-flag.patch --]
[-- Type: text/x-patch, Size: 1342 bytes --]

From: Markos Chandras <markos.chandras@imgtec.com>
Date: Wed, 22 Jan 2014 14:40:00 +0000
Subject: MIPS: asm: thread_info: Add _TIF_SECCOMP flag
Origin: https://git.kernel.org/linus/137f7df8cead00688524c82360930845396b8a21

Add _TIF_SECCOMP flag to _TIF_WORK_SYSCALL_ENTRY to indicate
that the system call needs to be checked against a seccomp filter.

Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Reviewed-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/6405/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
[bwh: Backported to 3.2: various other flags are not included in
 _TIF_WORK_SYSCALL_ENTRY]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
--- a/arch/mips/include/asm/thread_info.h
+++ b/arch/mips/include/asm/thread_info.h
@@ -149,7 +149,7 @@ register struct thread_info *__current_t
 #define _TIF_FPUBOUND		(1<<TIF_FPUBOUND)
 #define _TIF_LOAD_WATCH		(1<<TIF_LOAD_WATCH)
 
-#define _TIF_WORK_SYSCALL_ENTRY	(_TIF_SYSCALL_TRACE | _TIF_SYSCALL_AUDIT)
+#define _TIF_WORK_SYSCALL_ENTRY	(_TIF_SYSCALL_TRACE | _TIF_SYSCALL_AUDIT | _TIF_SECCOMP)
 
 /* work to do in syscall_trace_leave() */
 #define _TIF_WORK_SYSCALL_EXIT	(_TIF_SYSCALL_TRACE | _TIF_SYSCALL_AUDIT)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: Bug#751417: linux-image-3.2.0-4-5kc-malta: no SIGKILL after prctl(PR_SET_SECCOMP, 1, ...) on MIPS

[Luis Henriques]

On Thu, Jun 12, 2014 at 09:21:41PM +0100, Ben Hutchings wrote:
> On Thu, 2014-06-12 at 20:36 +0100, Ben Hutchings wrote:
> > Control: tag -1 security upstream patch moreinfo
> > Control: severity -1 grave
> > Control: found -1 3.14.5-1
> 
> Aurelien Jarno pointed out this appears to be fixed upstream in 3.15:
> 
> commit 137f7df8cead00688524c82360930845396b8a21
> Author: Markos Chandras <markos.chandras@imgtec.com>
> Date:   Wed Jan 22 14:40:00 2014 +0000
> 
>     MIPS: asm: thread_info: Add _TIF_SECCOMP flag
> 
> It looks like this can be cherry-picked cleanly onto stable branches for
> 3.13 and 3.14.  For 3.11 and 3.12, it will need trivial adjustment.
> 
> For branches older than 3.11, this needs to be cherry-picked first:
> 
> commit e7f3b48af7be9f8007a224663a5b91340626fed5
> Author: Ralf Baechle <ralf@linux-mips.org>
> Date:   Wed May 29 01:02:18 2013 +0200
> 
>     MIPS: Cleanup flags in syscall flags handlers.
> 
> Ben.
>

Thank you, I'm queuing this for the 3.11 kernel.

Cheers,
--
Luís

> > On Thu, 2014-06-12 at 16:19 +0000, Plamen Alexandrov wrote:
> > > Package: src:linux
> > > Version: 3.2.51-1
> > > Severity: normal
> > > 
> > > Under MIPS the system call prctl(PR_SET_SECCOMP, 1, ...) does not behave as expected.
> > > According to the manual page, after calling it with 1 as a second argument, any consecutive system calls other than read(), write(), _exit() and sigreturn() should result in the delivery of SIGKILL. However, under MIPS any consecutive system call behaves as if prctl(PR_SET_SECCOMP, 1, ...) was never called.
> > > 
> > > Here is a simple example that can be used to reproduce the bug:
> > > 
> > > plamen@debian-mips:/tmp$ id
> > > uid=1000(plamen) gid=1000(user) groups=1000(user)
> > > plamen@debian-mips:/tmp$ cat prctl.c 
> > > #include <unistd.h>
> > > #include <sys/prctl.h>
> > > #include <stdio.h>
> > > 
> > > int main(void)
> > > {
> > > 	if (prctl(PR_SET_SECCOMP, 1, 0, 0, 0) != 0)
> > > 		return 0;
> > > 	uid_t uid = getuid();
> > > 	printf("%u\n", (unsigned)uid);
> > > 	return 0;
> > > }
> > > plamen@debian-mips:/tmp$ gcc prctl.c -o prctl
> > > plamen@debian-mips:/tmp$ ./prctl 
> > > 1000
> > > 
> > > There is no change if I replace
> > > 	if (prctl(PR_SET_SECCOMP, 1, 0, 0, 0) != 0)
> > > with
> > > 	if (prctl(PR_SET_SECCOMP, SECCOMP_MODE_STRICT, 0, 0, 0) != 0)
> > > and I add #include <linux/seccomp.h>
> > 
> > Indeed, I see no check for seccomp on the MIPS syscall 'fast path'.  The
> > seccomp check appears to be done on the 'slow path' which is used only
> > if tracing or audit is also enabled for the task.  If I run the above
> > program under strace, it is killed as expected.
> > 
> > Could you test whether the attached patches fix this?  (Instructions for
> > rebuilding the Debian kernel package with patches can be found at
> > <http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official>.  These patches apply to 'wheezy'.)
> > 
> > Ben.
> > 
> 
> -- 
> Ben Hutchings
> The program is absolutely right; therefore, the computer must be wrong.