Kevin, who owns sslh?

I'd be happy to spend some (limited) time experimenting with the config file and then report here. Could some 5min seccomp crash course somewhere help me do that?

> Did this work before? Yes Probably just before 326413 above got merged (April 12th)

I have been using ssh over IPv6 for months and months.

I don't think the introduction of this policy in April caused a regression, but it is possible that changes in some other dependency did.  Also, sslh was upgraded about a month ago:

https://chromium-review.googlesource.com/643553

So this may be worth bisecting if it is broken in canary.  I haven't noticed a problem, don't remember when I last synced (probably 2+ weeks ago).


The current policy for socket() looks sane, and seems to match the usage in the sslh code:

    socket: arg0 == 10 && arg1 == 1 && arg2 == 0 || arg0 == 2 && arg1 == 1 && arg2 == 0

If changing it to "socket: 1" fixes the issue, maybe there is a bug in converting that expression into a BPF sequence.


I don't know where these are coming from:

[pid  4568] access("/proc/net", R_OK)   = 0
[pid  4568] access("/proc/net/unix", R_OK) = 0
[pid  4568] syscall_18446744073709551615(0x1, 0x80002, 0, 0x7ffff591ff20, 0xfefefefefefefeff, 0xfefefeff77686d74) = 0x29
[pid  4568] --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_call_addr=0x775761df0167, si_syscall=__NR_socket, si_arch=AUDIT_ARCH_X86_64} ---

Syscall 0xffffffffffffffff?  Hmmmm.

there is a known issue with minijail & syslog related to socket() due to sslh using -L that has been fixed via  issue 769047 .  the CL for updating minijail is in review now.

but what i find interesting is this:
[pid  4568] --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_call_addr=0x775761d2c0c0, si_syscall=__NR_rt_sigprocmask, si_arch=AUDIT_ARCH_X86_64} ---

where is that sigprocmask coming from ?  minijail ?

This is enough to make ssh over IPv6 work again:

--- sslh-seccomp.policy.orig	2017-10-06 17:59:14.522996997 -0700
+++ sslh-seccomp.policy	2017-10-06 18:26:42.642002894 -0700
@@ -12,7 +12,8 @@
 clone: 1
 exit_group: 1
 # We only want to allow AF_INET, AF_INET6, and SOCK_STREAM.
-socket: arg0 == 10 && arg1 == 1 && arg2 == 0 || arg0 == 2 && arg1 == 1 && arg2 == 0
+socket: 1
+ioctl: 1
 connect: 1
 open: 1
 stat: 1


> some 5min seccomp crash course

This was useful: https://www.chromium.org/chromium-os/developer-guide/chromium-os-sandboxing


> If changing it to "socket: 1" fixes the issue,

As seen above it helped but wasn't enough. Without the ioctl line I was (surprise...) getting this:

2017-10-06T18:25:53.056173-07:00 ERR sslh-fork[3817]: libminijail[5]: blocked syscall: ioctl


> Syscall 0xffffffffffffffff?  Hmmmm.
> [...]
> but what i find interesting is this [...] where is that sigprocmask coming from ?

Now I'm not so sure strace and seccomp play along well.

> Now I'm not so sure strace and seccomp play along well.

In my experience, they do not.

Here's an strace of a *successful* connection over IPv6 thanks to the above policy change repeated here too.

Reminder this is a link-local address (poor man's IPv6)

-socket: arg0 == 10 && arg1 == 1 && arg2 == 0 || arg0 == 2 && arg1 == 1 && arg2 == 0
+socket: 1
+ioctl: 1

[pid  3335] read(6, "SSH-2.0-OpenSSH_7.4\r\n", 8192) = 21
[pid  3335] getpeername(6, {sa_family=AF_INET6, sin6_port=htons(60217), inet_pton(AF_INET6, "fe80::1423:78e3:7b92:6094", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=if_nametoindex("eth1")}, [128->28]) = 0
[pid  3335] socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 4
[pid  3335] connect(4, {sa_family=AF_INET, sin_port=htons(2222), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
[pid  3335] getpeername(6, {sa_family=AF_INET6, sin6_port=htons(60217), inet_pton(AF_INET6, "fe80::1423:78e3:7b92:6094", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=if_nametoindex("eth1")}, [128->28]) = 0
[pid  3335] access("/proc/net", R_OK)   = 0
[pid  3335] access("/proc/net/unix", R_OK) = 0
[pid  3335] socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 7
[pid  3335] ioctl(7, SIOCGIFNAME, {ifr_index=4, ifr_name="eth1"}) = 0
[pid  3335] close(7)                    = 0
[pid  3335] getsockname(6, {sa_family=AF_INET6, sin6_port=htons(22), inet_pton(AF_INET6, "fe80::20e:c6ff:fe88:ffa7", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=if_nametoindex("eth1")}, [128->28]) = 0
[pid  3335] socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 7
[pid  3335] ioctl(7, SIOCGIFNAME, {ifr_index=4, ifr_name="eth1"}) = 0
[pid  3335] close(7)                    = 0
[pid  3335] getpeername(4, {sa_family=AF_INET, sin_port=htons(2222), sin_addr=inet_addr("127.0.0.1")}, [128->16]) = 0
[pid  3335] getsockname(4, {sa_family=AF_INET, sin_port=htons(43182), sin_addr=inet_addr("127.0.0.1")}, [128->16]) = 0
[pid  3335] write(2, "ssh:connection from fe80::1423:7"..., 142) = 142
[pid  3335] write(4, "SSH-2.0-OpenSSH_7.4\r\n", 21) = 21
[pid  3335] select(7, [4 6], NULL, NULL, NULL) = 1 (in [4])
[pid  3335] read(4, "SSH-2.0-OpenSSH_7.5p1-hpn14v12\r\n", 8192) = 32
[pid  3335] write(6, "SSH-2.0-OpenSSH_7.5p1-hpn14v12\r\n", 32) = 32
[pid  3335] select(7, [4 6], NULL, NULL, NULL) = 1 (in [4])
[pid  3335] read(4, "\0\0\4$\n\24\274\345\342[\305'J\204\212\0\260\202_\201\234\267\0\0\1\2curve2"..., 8192) = 1064

[pid  3335] socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 7
[pid  3335] ioctl(7, SIOCGIFNAME, {ifr_index=4, ifr_name="eth1"}) = 0
[pid  3335] close(7)                    = 0

This is translating the scope_id from an interface index to an interface name.  I don't see anything in the sslh code that is doing this, so it could be from libc, or strace, or something else.

I'm guessing that this step would be skipped if scope_id was 0, so maybe the fact that you're using link-local addresses is relevant here.  That isn't something that would normally be tested at Google, because workstations and test Chromebooks are never on the same LAN.  If you switch to a ULA or public IPv6 address, does that hide the problem?

yeah, sounds like it's due to the zone ids.  we can whitelist those specific ioctl's (we don't want to whitelist all of them).

glibc/sysdeps/unix/sysv/linux/if_index.c:
char *
__if_indextoname (unsigned int ifindex, char *ifname)
{
  /* We may be able to do the conversion directly, rather than searching a
     list.  This ioctl is not present in kernels before version 2.1.50.  */
  struct ifreq ifr;
  int fd;
  int status;

  fd = __opensock ();

  if (fd < 0)
    return NULL;

  ifr.ifr_ifindex = ifindex;
  status = __ioctl (fd, SIOCGIFNAME, &ifr);

  close_not_cancel_no_status (fd);

  if (status  < 0)
    {
      if (errno == ENODEV)
    /* POSIX requires ENXIO.  */
    __set_errno (ENXIO);

      return NULL;
    }
  else
    return strncpy (ifname, ifr.ifr_name, IFNAMSIZ);
}

Away from the system so can't make 100% sure, yet confident I found the other pieces:

https://github.com/yrutschle/sslh/blob/0929d39a34a78e/common.c#L519
sslh/common.c#log_connection()
sslh/common.c#sprintaddr()
glibc/inet/getnameinfo.c#getnameinfo()
  if (IN6_IS_ADDR_LINKLOCAL(...)) {
     if_indextoname(..)

> PS: I'm using link local address; I doubt it matters.

:-(

> we can whitelist those specific ioctl

Thanks! I can help with at least testing.

Makes sense; getnameinfo() can add the scope ID to the string.  This prints "fe80::1%lo":

#include <sys/socket.h>
#include <netdb.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <netinet/ip6.h>

int main(int argc, char **argv)
{
	struct sockaddr_in6 s = {0};
	s.sin6_family = AF_INET6;

	s.sin6_addr.s6_addr[0] = 0xfe;
	s.sin6_addr.s6_addr[1] = 0x80;
	s.sin6_addr.s6_addr[15] = 0x1;
	s.sin6_scope_id = 1;

	char host[256];
	if (getnameinfo((void *)&s, sizeof(s), host, sizeof(host), NULL, 0,
			NI_NUMERICHOST) < 0) {
		printf("error: %d\n", errno);
	} else {
		puts(host);
	}

	return 0;
}

Just +1 Verified https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/706715 uploaded by Mike (thx).

With strace -s 100:

  [pid  3348] write(2, "ssh:connection from fe80::1423:78e3:7b92:6094%eth1:62776 to fe80::20e:c6ff:fe88:ffa7%eth1:22 forward"..., 142) = 142

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/d24031bee8702e14fb53aa6e54141577b702c76b

commit d24031bee8702e14fb53aa6e54141577b702c76b
Author: Mike Frysinger <vapier@chromium.org>
Date: Tue Oct 10 00:39:09 2017

arc-sslh-init: expand seccomp for IPv6 zone id lookups

When using IPv6 with zone ids, glibc will look up interface details via
SIOCGIFNAME on an AF_UNIX socket.  Allow those in the seccomp filters.

Sync/sort the filters too to cut down on diffs between them.

BUG= chromium:772273 
TEST=precq passes

Change-Id: If6939854e63fcdc8ee3fceb849e50c5b412d7a1c
Reviewed-on: https://chromium-review.googlesource.com/706715
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Marc Herbert <marc.herbert@intel.com>
Tested-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Kevin Cernekee <cernekee@chromium.org>

[rename] https://crrev.com/d24031bee8702e14fb53aa6e54141577b702c76b/chromeos-base/arc-sslh-init/arc-sslh-init-0.0.1-r2.ebuild
[modify] https://crrev.com/d24031bee8702e14fb53aa6e54141577b702c76b/chromeos-base/arc-sslh-init/files/sslh-seccomp-arm.policy
[modify] https://crrev.com/d24031bee8702e14fb53aa6e54141577b702c76b/chromeos-base/arc-sslh-init/files/sslh-seccomp-amd64.policy