openssh bugs - Jun 2016 - [Bug 2590] New: Seccomp filter for missing architectures

https://bugzilla.mindrot.org/show_bug.cgi?id=2590

            Bug ID: 2590
           Summary: Seccomp filter for missing architectures
           Product: Portable OpenSSH
           Version: 7.2p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Keywords: patch
          Severity: enhancement
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: jjelen at redhat.com

Created attachment 2840
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2840&action=edit
whitelist PPC64*, S390* and MIPS architectures for seccomp filter

I am posting follow up the the bug #2361 about aarch64 problems with
seccomp filter. Since then we managed to test the seccomp filter on
PPC64, PPC64LE, S390, S390X and MIPS* architectures (still tracked in
Red Hat bugzilla [1]).

The testing went smooth and there were no more problems or missing
syscalls detected. The only thing needed is to whitelist these
architectures in configure since it is perfectly reasonable to use
seccomp when it is supported.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1195065

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2590

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
             Blocks|                            |2543
         Resolution|---                         |FIXED
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
Patch applied - thank-you very much for doing the testing for these.
This will be in the openssh-7.3 release.


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=2543
[Bug 2543] Tracking bug for OpenSSH 7.3 release
-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2590

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #2 from Damien Miller <djm at mindrot.org> ---
Close all resolved bugs after 7.3p1 release

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2590

Joshua Kinard <kumba at gentoo.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CLOSED                      |REOPENED
         Resolution|FIXED                       |---
                 CC|                            |kumba at gentoo.org

--- Comment #3 from Joshua Kinard <kumba at gentoo.org> ---
(In reply to Damien Miller from comment #1)
> Patch applied - thank-you very much for doing the testing for these.
> This will be in the openssh-7.3 release.
I hate to reopen, but I found a corner case for MIPS broken by the MIPS
whitelist.  Specifically, the proposed whitelist does not account for
MIPS N32 ABI (under mips64).

Specifically:
+       mips64-*)
+               seccomp_audit_arch=AUDIT_ARCH_MIPS64

There needs to be another hook to somehow detect N32 and then set
either AUDIT_ARCH_MIPS64 (big-endian) or AUDIT_ARCH_MIPSEL64N32
(little-endian).

I believe there's a known/defined CHOST tuple to specify an N32
userland, but it's not common, so CHOST seems to be unreliable to
detect this.  I am not sure of another reasonable way to do so right
now.

Without this fix, on mips64/N32 platforms, "UsePrivilegeSeparation
sandbox" will fail and not allow a client to connect.  Per strace:

[pid  1883] prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) = 0
[pid  1883] prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, {len=57,
filter=0x565f3920}) = 0
[pid  1883] write(3,
"\0\0\3|\10\24\270\256hb<\257-\30\216\214L\301\35\230\10\233\0\0\0\324curve2"...,
896 <unfinished ...>
[pid  1883] --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP,
si_call_addr=NULL, si_syscall=__NR_write, si_arch=AUDIT_ARCH_MIPS64N32}
---
[pid  1883] <... write resumed> )       = -1 ERRNO_6001 (Unknown error
6001)
[pid  1883] --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP,
si_call_addr=NULL, si_syscall=__NR_write, si_arch=AUDIT_ARCH_MIPS64N32}
---
[pid  1882] <... poll resumed> )        = 2 ([{fd=6,
revents=POLLIN|POLLHUP}, {fd=7, revents=POLLHUP}])
[pid  1883] +++ killed by SIGSYS +++
[pid  1882] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED,
si_pid=1883, si_uid=22, si_status=SIGSYS, si_utime=0, si_stime=0} ---
[pid  1882] read(7, "", 4)              = 0
[pid  1882] close(7)                    = 0
[pid  1882] poll([{fd=6, events=POLLIN}], 1, -1) = 1 ([{fd=6,
revents=POLLIN|POLLHUP}])
[pid  1882] read(6, "", 4)              = 0
[pid  1882] kill(1883, SIGKILL)         = 0
[pid  1882] exit_group(255)             = ?
[pid  1882] +++ exited with 255 +++

Switching to "UsePrivilegeSeparation yes" is a workaround, but seems
suboptimal.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2590

--- Comment #4 from Joshua Kinard <kumba at gentoo.org> ---
(In reply to Joshua Kinard from comment #3)
> There needs to be another hook to somehow detect N32 and then set
> either AUDIT_ARCH_MIPS64 (big-endian) or AUDIT_ARCH_MIPSEL64N32
> (little-endian).
> 
copy-pasted too fast,  The mips64/big-endian case needs to use
AUDIT_ARCH_MIPS64N32.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2590

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at zip.com.au

--- Comment #5 from Darren Tucker <dtucker at zip.com.au> ---
(In reply to Joshua Kinard from comment #3)
> 
> I hate to reopen, but I found a corner case for MIPS broken by the
> MIPS whitelist.  Specifically, the proposed whitelist does not
> account for MIPS N32 ABI (under mips64).
> 
> Specifically:
> +	mips64-*)
> +		seccomp_audit_arch=AUDIT_ARCH_MIPS64
> 
> There needs to be another hook to somehow detect N32 and then set
> either AUDIT_ARCH_MIPS64 (big-endian) or AUDIT_ARCH_MIPSEL64N32
> (little-endian).
what does configure.guess report on such systems?  If that's not a
reliable indicator, what is?  mips64-* && AC_CHECK_SIZEOF([int], [4]) ?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2590

--- Comment #6 from Joshua Kinard <kumba at gentoo.org> ---
(In reply to Darren Tucker from comment #5)
> (In reply to Joshua Kinard from comment #3)
> > 
> > I hate to reopen, but I found a corner case for MIPS broken by the
> > MIPS whitelist.  Specifically, the proposed whitelist does not
> > account for MIPS N32 ABI (under mips64).
> > 
> > Specifically:
> > +	mips64-*)
> > +		seccomp_audit_arch=AUDIT_ARCH_MIPS64
> > 
> > There needs to be another hook to somehow detect N32 and then set
> > either AUDIT_ARCH_MIPS64 (big-endian) or AUDIT_ARCH_MIPSEL64N32
> > (little-endian).
> 
> what does configure.guess report on such systems?  If that's not a
> reliable indicator, what is?  mips64-* && AC_CHECK_SIZEOF([int],
> [4]) ?
config.guess reports back "mips64-unknown-linux-gnu", which is my
system CHOST value (Gentoo, SGI Octane).  It does the same in an O32
chroot, so this might be unreliable.  O32 Linux userlands require a
CHOST of "mips-unknown-linux-gnu", even when run under a mips64
kernel.

Per the MIPS N32 handbook, you can tell O32/N32 apart from N64 (full
64-bit) by checking the size of a pointer, which should be 8 bytes on
N64.  But it'll be 4 bytes under both O32/N32, so this approach won't
work either.

Is it possible to have configure compile a test binary using the
provided C compiler and flags, then check the file magic of the output
binary?  That's a definitive way to differ between all three ABI's (and
may even be applicable for multilib setups).  I scanned briefly through
the autoconf manual, but I don't see a built-in check for this.

O32 /bin/cat:
/bin/cat: ELF 32-bit MSB executable, MIPS, MIPS-IV version 1 (SYSV),
dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 2.6.32,
stripped

N32 /bin/cat:
/bin/cat: ELF 32-bit MSB executable, MIPS, N32 MIPS-IV version 1
(SYSV), dynamically linked, interpreter /lib32/ld.so.1, for GNU/Linux
2.6.32, stripped

So a check for the presence of "N32" in file's output would be
enough
to detect between O32 and N32.

Should you ever get around to supporting X32 on the Intel/AMD
platforms, this same situation is bound to come up again.  X32 either
copies, or was inspired by, N32 and so they aim to achieve similar
goals.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2590

--- Comment #7 from Darren Tucker <dtucker at zip.com.au> ---
(In reply to Joshua Kinard from comment #3)
> I believe there's a known/defined CHOST tuple to specify an N32
Debian seems to document "mips64-linux-gnuabin32":
https://wiki.debian.org/Multiarch/Tuples

(In reply to Joshua Kinard from comment #6)
[...]
> Per the MIPS N32 handbook, you can tell O32/N32 apart from N64 (full
> 64-bit) by checking the size of a pointer, which should be 8 bytes
> on N64.  But it'll be 4 bytes under both O32/N32, so this approach
> won't work either.
I know nothing about this other than what I've read in the last few
minutes, but isn't O32 for purely 32 bit machines?  ie isn't
config.guess is going to say "mips-"?  or can you run O32 userspace
even on a 64 bit kernel?
> Is it possible to have configure compile a test binary using the
> provided C compiler and flags, then check the file magic of the
> output binary?
It's possible but seems pretty icky.

I think the first thing to do is fix the case statement which will
allow you to at least specify the right thing via configure --target.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2590

--- Comment #8 from Darren Tucker <dtucker at zip.com.au> ---
Created attachment 2861
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2861&action=edit
add mips gnuabin32 targets.

how about this?  it should make ./configure
--host=mips64-linux-gnuabin32 do what you want.

I guess the next thing to do is get config.guess to guess this
configuration when appropriate.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2590

--- Comment #9 from Joshua Kinard <kumba at gentoo.org> ---
(In reply to Darren Tucker from comment #8)
> Created attachment 2861 [details]
> add mips gnuabin32 targets.
> 
> how about this?  it should make ./configure
> --host=mips64-linux-gnuabin32 do what you want.
> 
> I guess the next thing to do is get config.guess to guess this
> configuration when appropriate.
I think the problem with overriding --host like that is it might work
for binary distros, but not Gentoo or other source-based distros.  My
system's CHOST is "mips64-unknown-linux-gnu", and I believe that
will
be passed to --host instead, as well as --build.  If --build and --host
differ, I believe GNU autoconf treats it as a cross-compile instead of
a normal compile.

Equally, that CHOST tuple is only valid for glibc-based systems.  I
don't think there is an equivalent like
"mips64-unknown-linux-uclibcn32" for uClibc-based systems or other
libc's that might happen to support ABIs other than O32.  So I don't
think relying on the CHOST will work 100% here (especially for multilib
instances where multiple ABIs coexist on the same root).

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2590

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|2543                        |


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=2543
[Bug 2543] Tracking bug for OpenSSH 7.3 release
-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2590

--- Comment #10 from Darren Tucker <dtucker at dtucker.net> ---
There's a github pull request
(https://github.com/openssh/openssh-portable/pull/71) that looks like
it might fix this.  Can you confirm?

Thanks.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2590

--- Comment #11 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to Darren Tucker from comment #10)
> There's a github pull request
> (https://github.com/openssh/openssh-portable/pull/71) that looks
> like it might fix this.  Can you confirm?
Merged that pull request, if that doesn't fix it please reopen.

Thanks.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2590

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Blocks|                            |2782
             Status|REOPENED                    |RESOLVED


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=2782
[Bug 2782] Tracking bug for OpenSSH 7.7 release
-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2590

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #12 from Damien Miller <djm at mindrot.org> ---
closing resolved bugs as of 8.6p1 release

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.