[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 22 Nov 2019 17:08:30 +0100
From: Solar Designer <solar@...nwall.com>
To: lkrg-users@...ts.openwall.com
Subject: Re: LKRG Security Questions
On Thu, Nov 14, 2019 at 11:50:18PM +0100, Adam Zabrocki wrote:
> > Quote https://www.openwall.com/lkrg/
> >
> > > LKRG's current response to kernel integrity violations is merely
> > reporting those in kernel messages (which obviously doesn't mitigate
> > attacks when those are for real)
> >
> >
> > Would it be possible / sane to kernel panic in such cases? Perhaps with
> > a clearly written message on the user's screen for informational
> > purposes? Or dispatch a configurable hook script that could specify the
> > response?
>
> That's because we didn't update the documentation. We have an optional feature
> to panic() the system in case of CI integrity violation:
>
> "-> Kernel panic on CI failure (lkrg.ci_panic) - only two options are
> available:
> 0 - do NOT crash the kernel on CI failure (default)
> 1 - crash the kernel (call panic()) on CI failure"
I've just updated the quoted text on LKRG homepage to be:
"LKRG's current default response to kernel integrity violations is
merely reporting those in kernel messages (which obviously doesn't
mitigate real attacks), but LKRG may be configured to panic the kernel
instead. LKRG's current response to unauthorized process credentials is
killing the process (which does defeat many exploits, but is a rather
mild response nevertheless). LKRG's default response is changing as
LKRG becomes more mature. In fact, current LKRG will by default panic
the kernel if it finds SMEP (Supervisor Mode Execution Protection, a
security feature of recent CPUs) unexpectedly disabled. We dare to do
this because we reasonably expect no false positives with that specific
LKRG feature."
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.
