[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 9 Jun 2020 05:37:16 +0200
From: Adam Zabrocki <pi3@....com.pl>
To: lkrg-users@...ts.openwall.com
Subject: Re: Outdated sysctl documentation
Hi,
Some of my comments inline:
On Mon, Jun 08, 2020 at 08:19:30PM +0200, Mikhail Morfikov wrote:
> On 08/06/2020 17:18, Adam Zabrocki wrote:
> > Hi,
> >
> > We are on the edge of releasing a new LKRG version (0.8). However, we are still
> > working on some features which are changing some of the functinoality. Updating
> > documentation is the last step of the work which is in our TODO list.
> > Current documentation refelct the last LKRG release (0.7).
> >
> I see, OK no problem.
>
> > Few weeks ago we've completely rewrote communication channel and documentation
> > for it is in the official commit:
> >
> > https://bitbucket.org/Adam_pi3/lkrg-main/commits/2febcf467d6182e9bd180334e2601c79812f2cf5
> >
> I have a couple of questions, which came to my mind while reading the commit:
>
> -----------
> 1) Introduce 'kint_validate' to control kernel/system integrity logic:
> 0 - disabled
> 1 - validation is performed only when manually triggered
> 3 - validation is performed periodically by timer interrupt and on random events
> -----------
> 1. By the "timer interrupt" you mean that if CONFIG_HZ=1000 then the check will
> be performed 1000 times per second, am I right?
The timer is configured to run in seconds. By default it is every 15 seconds
but you can tune it through sysctl interface (lkrg.interval).
However, that's is just one piece of component in the bigger picture.
More information about LKRG you can find in this presentation:
https://www.youtube.com/watch?v=tOiPM692DOM
However, it's outdated.
> 2. What do you mean by random events?
https://openwall.info/wiki/p_lkrg/Main#When-is-the-LKRG-validation-routine-executed
However, this list is not updated as well :)
> 3. Is there a value of "2" or just "1" and "3"?
>
It is, my mistake I've overlooked it. Here is the list:
0 - "DISABLED",
1 - "MANUAL",
2 - "PERIODICALLY", <- timer
3 - "PERIODICALLY + RANDOM EVENTS" <- timer + random events
> -----------
> 2) Introduce 'kint_enforce' to control how LKRG reacts when kernel/system integrity fails:
> 0 - log & accept corruption
> 1 - log only (for SELinux and CR0.WP violation log & restore original values)
> 2 - panic() - kill the kernel
> -----------
> 4. What's actually the difference between "0" and "1"?
>
0 - if corruption is detect, it will be reported only once. After that LKRG
accepts the new state of the system
1 - LKRG will report corruption as long as such corruption is detected. This
can spam your log file.
> -----------
> 6) Introduce 'smep_enforce' to control how LKRG reacts when SMEP validation fails:
> 0 - log & accept
> 1 - log & restore
> 2 - panic() - kill the kernel
> -----------
> 5. Is this similar to the previous one (I mean the value of "0" and "1")?
>
Same here. However, in case of option 1, such corruption will results in
restoring the correct state of SMEP (the same for SMAP).
> -----------
> 8) Introduce 'smep_enforce' to control how LKRG reacts when UMH validation fails:
> 0 - log only
> 1 - prevent execution
> 2 - panic() - kill the kernel
> -----------
> prevent execution... of?
>
this is a mistake. This is a description for 'umh_enforce':
0 - log only
1 - prevent execution
2 - panic() - kill the kernel
for 'smep_enforce' is:
0 - log & accept
1 - log & restore
2 - panic() - kill the kernel
> -----------
> 9) Introduce 'pcfi_validate' to control if pCFI validation will be performed
> 0 - disabled
> 1 - no stackwalk (weak pCFI)
> 2 - fully enabled
> -----------
> What does "1" do here?
Verifyies stack pointer and stack page. It has a chance to detect ROP-only
attacks.
> Does the CFI stand for Control-Flow Integrity?
>
Yes.
> -----------
> -> Hiding (lkrg.hide) - if built with this optional feature included, LKRG can
> (un)hide itself from the module list (but it can be detected regardless):
> -----------
> The doc says that hiding the module can be detected even when lkrg.hide=1 -- any
> example how to detect it in such situation?
>
It can be done through the /sys or /proc interface. E.g:
https://github.com/rapid7/metasploit-framework/pull/11081/commits/80d83720df381ffbb195ca87c3145cc116dd4f93
In the future we might address it. It doesn't matter for the current state of
the project.
Thanks,
Adam
--
pi3 (pi3ki31ny) - pi3 (at) itsec pl
http://pi3.com.pl
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.
