Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 8 Jan 2017 15:19:33 +0000
From: Simon McVittie <smcv@...ian.org>
To: oss-security@...ts.openwall.com
Subject: Re: Re: Firejail local root exploit

On Sun, 08 Jan 2017 at 12:51:58 +0100, Martin Carpenter wrote:
> Here's
> disable_coredumps() from sudo 1.8.9p5 (as shipped with Ubuntu 14.04,
> which does not disable suid coredumps on desktop by default):
[... the active ingredient is ...]
>  800     (void) getrlimit(RLIMIT_CORE, &corelimit);
>  801     memcpy(&rl, &corelimit, sizeof(struct rlimit));
>  802     rl.rlim_cur = 0;
>  803     (void) setrlimit(RLIMIT_CORE, &rl);

This is not actually enough. dbus has one regression test involving a
binary that deliberately segfaults (so we can assert that the resulting
error is reported correctly) and we found that with tools like corekeeper
that set core_pattern="|some-helper", code similar to sudo's still resulted
in a core dump being written into the pipe to some-helper. In dbus this
was only a performance issue and not a security issue (dumping core
repeatedly made our unit tests really slow).

To address that, we added this:

#if defined(HAVE_PRCTL) && defined(PR_SET_DUMPABLE)
  /* Really, no core dumps please. On Linux, if core_pattern is
   * set to a pipe (for abrt/apport/corekeeper/etc.), RLIMIT_CORE of 0
   * is ignored (deliberately, so people can debug init(8) and other
   * early stuff); but Linux has PR_SET_DUMPABLE, so we can avoid core
   * dumps anyway. */
  prctl (PR_SET_DUMPABLE, 0, 0, 0, 0);
#endif

Reference: https://bugs.freedesktop.org/show_bug.cgi?id=83772
Rationale for RLIMIT_CORE=0 being ignored in this case:
https://lkml.org/lkml/2011/8/24/136

> there just has to be more stuff out there like this. sudo was literally
> the first thing I looked at... Disabling filter inheritance across the
> privilege boundary doesn't seem like an obviously good solution(?).

bubblewrap opts-out of setuid and similar mechanisms by unconditionally
setting PR_SET_NO_NEW_PRIVS (and bailing out if that fails), which seems
a good idea for anything that claims to be a sandbox. If feasible, I would
recommend that firejail should do the same.

    S

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ