linux-kernel - Re: [3.1 REGRESSION] Commit 5cec93c216db77c45f7ce970d46283bcb1933884 breaks the Chromium seccomp sandbox

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:	Mon, 14 Nov 2011 11:41:51 +0000
From:	Nix <nix@...eri.org.uk>
To:	Andrew Lutomirski <luto@....edu>
Cc:	Mark Seaborn <mseaborn@...omium.org>, linux-kernel@...r.kernel.org,
	Markus Gutschke <markus@...omium.org>
Subject: Re: [3.1 REGRESSION] Commit 5cec93c216db77c45f7ce970d46283bcb1933884 breaks the Chromium seccomp sandbox

On 14 Nov 2011, Andrew Lutomirski stated:

> On Sun, Nov 13, 2011 at 10:50 PM, Mark Seaborn <mseaborn@...omium.org> wrote:
>> I think the problem is that seccomp-sandbox attempts to patch the
>> vsyscall page.

I grepped for vsyscall to try to avoid making an idiot of myself like
this. A shame I misspelt it. :/

> The vsyscall code is now:
>
>         mov $__NR_whatever %rax
>         syscall
>         ret
> 
> It used to be weirder, but we changed to to avoid breaking things like
> this.  The secret is that, if vsyscall=emulate, the vsyscall page is
> not executable and we use the page fault to invoke
> do_emulate_vsyscall.  But userspace can't tell it's not executable
> without actually jumping there, and with vsyscall=native, it's just a
> normal syscall.
>
> I'll try to build a sandboxing copy of chromium tomorrow to see if I
> can reproduce it.

If you look at line 909 of seccompsandbox/library.cc (in
http://git.chromium.org/external/seccompsandbox.git) the problem does
indeed jump out at you. That nice manual disassembly using == isn't
going to work anymore. It even helpfully dies with a message saying that
it can't patch the vsyscall page, but the message gets thrown away by
some higher layer.

I suspect we want two functions and something to recognize what the
vsyscall page looks like and choose between them, rather than making
this already tricky function even uglier.

(To build Chromium with sandboxing, the recipe is little more than
making sure you haven't passed in -Dselinux, and starting Chromium with
--enable-seccomp-sandbox. It's turned off by default because it slows
Chromium down, not because it doesn't work. :) )

-- 
NULL && (void)
--
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/