|
Message-ID: <20191122160829.GA4119@openwall.com> 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.