Re: New crash in SUID sandbox with ASAN

[Denis Glotov]

Hi devs!

I faced a crash constantly happening in gpu-process of Chrome that is built with Address Sanitizer.

#0  0x00007fc9796295c0 in __asan::ASAN_OnSIGSEGV(int, siginfo*, void*) ()
#1  <signal handler called>
#2  0x00007fc973f829a5 in (anonymous namespace)::SIGSYS_Handler(int, siginfo*, void*) ()
#3  <signal handler called>
#4  

-- 

Thank you, 

Denis

__pthread_getaffinity_new (th=<value optimized out>, cpusetsize=<value optimized out>, cpuset=0x7fc96de5ff80)
    at ../nptl/sysdeps/unix/sysv/linux/pthread_getaffinity.c:38
#5  0x00007fc96f8d6770 in pthread_getattr_np (thread_id=140503050024704, attr=0x7fc96a62ec58) at pthread_getattr_np.c:153
#6  0x00007fc979622216 in __asan::AsanThread::SetThreadStackTopAndBottom() ()
#7  0x00007fc9796258ad in __asan::AsanThread::Init() ()
#8  0x00007fc9796259ac in __asan::AsanThread::ThreadStart() ()
#9  0x00007fc96f8d4b28 in start_thread (arg=0x7fc96a62f700) at pthread_create.c:297
#10 0x00007fc96e94bbfd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115

This stops happening if --no-sandbox is using. So I suppose there is a conflict of ASAN's thread initialization (frames 6-4) and a SUID sandbox (frame 2).

This has not happen (on my x86-alex) a week ago or so. So the breaking change might be recent.

Any ideas?

-- 

Thank you, 

Denis

[Alexander Potapenko]

Justin,

do you know if sched_getaffinity is allowed under the sandbox? If not,
is it a necessary measure?

> --
> Chromium OS Developers mailing list: chromiu...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en



--
Alexander Potapenko
Software Engineer
Google Moscow

[Justin Schuh]

On Fri, May 4, 2012 at 6:02 AM, Alexander Potapenko <gli...@chromium.org> wrote:

Justin,

do you know if sched_getaffinity is allowed under the sandbox? If not,
is it a necessary measure?

You probably want to direct questions like this at Julien, since the setuid sandbox is his design.

 

[Alexander Potapenko]

> This is a temporary mode to catch reports early on problems that will
> arise with the current policy. We'll soon turn it to a different mode
> to let it degrade gracefully on syscall denies via errno. In the
> meantime (and perhaps even in the future), I don't think it's an issue
> to allow this syscall.
>
> Is there anything else you foresee ASAN might need?
>
We're also doing open("/proc/self/maps"), but looks like ASan can live
without it.
I've ran a small instrumented program under strace and the rest of the
syscalls seem to be allowed (although it actually didn't show me
sched_getaffinity).
So we probably don't need anything else, at least for now.

[Alexander Potapenko]

Oops. I was thinking about /proc/self/environ, which we read too, but
really do not need that much.
ASan has to open /proc/self/maps in order to print the crash reports.
Is it possible to allow a syscall with restricted arguments?

[Denis Glotov]

Julien, the address being de-referenced was 0x0000020250cc. So the call causing the signal was 0xCC: __NR_sched_getaffinity. This agrees to the stack dump I posted in the initial mail.

I locally added EmitAllowSyscall(__NR_sched_getaffinity, program) to the ApplyGPUPolicy(), but things remained the same. Anything else should be done?

BTW, we use --disable-seccomp-sandbox, that's why I thought seccomp sandbox is off. Is the flag ignored?

On Fri, May 4, 2012 at 9:39 PM, Julien Tinnes <j...@google.com> wrote:

Thanks for the report. That's not the setuid sandbox, that's the
seccomp sandbox with BPF filters. If you have the crashdump, you can
see that the syscall number should have gotten dereferenced as an
address. [1]

This is a temporary mode to catch reports early on problems that will
arise with the current policy. We'll soon turn it to a different mode
to let it degrade gracefully on syscall denies via errno. In the
meantime (and perhaps even in the future), I don't think it's an issue
to allow this syscall.

Is there anything else you foresee ASAN might need?

Julien

[1] https://src.chromium.org/viewvc/chrome/trunk/src/content/common/sandbox_init_linux.cc?view=markup&pathrev=132266
(SIGSYS_Handler)

--
Thank you,
Denis

[Denis Glotov]

Sorry, I must have forgotten to save the changes. The crash has gone. But Chrome (with ASAN) does not work still, although it does not visibly crash anymore.

Still, if I use --no-sandbox, things work fine.

If I use --disable-seccomp-filter-sandbox, things does not work.

What lies between --no-sandbox and --disable-seccomp-filter-sandbox?

On Sat, May 5, 2012 at 7:30 PM, Chris Evans <cev...@google.com> wrote:

On Sat, May 5, 2012 at 9:23 AM, Denis Glotov <glo...@chromium.org> wrote:

Julien, the address being de-referenced was 0x0000020250cc. So the call causing the signal was 0xCC: __NR_sched_getaffinity. This agrees to the stack dump I posted in the initial mail.

I locally added EmitAllowSyscall(__NR_sched_getaffinity, program) to the ApplyGPUPolicy(), but things remained the same. Anything else should be done?

BTW, we use --disable-seccomp-sandbox, that's why I thought seccomp sandbox is off. Is the flag ignored?

The seccomp sandbox is in transition so for now use

--disable-seccomp-filter-sandbox

--
Thank you,
Denis

[Alexander Potapenko]

On Sat, May 5, 2012 at 7:56 PM, Denis Glotov <glo...@chromium.org> wrote:
> Sorry, I must have forgotten to save the changes. The crash has gone. But
> Chrome (with ASAN) does not work still, although it does not visibly crash
> anymore.
>
> Still, if I use --no-sandbox, things work fine.
> If I use --disable-seccomp-filter-sandbox, things does not work.
> What lies between --no-sandbox and --disable-seccomp-filter-sandbox?
>

I've committed Clang r156538, which may make the problem more
discoverable (a check will fail if the process can't read
/proc/self/maps).
Regardless of whether that helps, please disable the sandbox so that
you can move further.