[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191208115834.GB21382@openwall.com>
Date: Sun, 8 Dec 2019 12:58:34 +0100
From: Solar Designer <solar@...nwall.com>
To: lkrg-users@...ts.openwall.com
Subject: Re: bug: LKRG kills VirtualBox host VMs
On Sun, Dec 08, 2019 at 06:36:40AM +0000, Patrick Schleizer wrote:
> Solar Designer:
> > As to your concerns on having an extra security-sensitive flag, we
> > already have some other sysctl's that also affect LKRG in
> > security-relevant ways. I think we need to come up with a common
> > approach and framework for protecting all of those flags from easy
> > one-shot overwrites or/and making such overwrites ineffective (read-only
> > pages or/and checking against a keyed hash or redundant copies), and
> > use it for all of LKRG's security-sensitive rarely-changing variables.
> >
> > Right now, LKRG's approach to these issues is inconsistent: some
> > settings are security-sensitive yet runtime configurable, and some
> > others are compile-time only. We need to make LKRG consistent.
>
> Maybe a single call "sudo sysctl -w lkrg.fuse=1" could make all LKRG
> settings ready-only until reboot? Before that, all settings are read/write?
>
> I am also looking for a sysctl command to fuse all (not only LKRG)
> sysctl settings, but I don't know if that would be overreaching LKRG's
> scope. (Similar to linux "lockdown" feature.)
Both of these suggestions seem reasonable on the surface, but I think
are unreasonable once you dig deeper. Protecting the kernel from
legitimate(*) root for real requires not only a lock-down of the kernel,
but also of the userland, and a system like this becomes difficult to
use and requires greater skill to use reasonably. Adam planned some
lock-down features in the "experimental" branch of LKRG, but I oppose
that direction because I expect only a negligible percentage of users
will make reasonable use of those.
(*) "Legitimate" as in "indistinguishable from legitimate by LKRG".
What LKRG can reasonably do is protect its settings from attacks that
are still in progress and haven't yet reached the point of having
legitimate-looking root access. I suggested some ways to achieve that
above. In that context, your suggestion for permanently locking down
the settings makes sense for code simplification if it'd be the only
mode we'd implement. It would also very slightly improve security
through LKRG lacking gadgets (code snippets potentially reusable by an
exploit's execution chain) that would unlock the settings, and which
we'd have in there if one of my suggested approaches is implemented.
However, we already have in LKRG some potential gadgets updating its
existing databases. Randomization of kernel module load addresses (by
the Linux kernel that LKRG is loaded into) should help prevent easy use
of LKRG gadgets by exploits. We could also validate stack frames from
within such gadgets.
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
