Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 9 Nov 2020 16:09:21 -0800
From: Randy Dunlap <rdunlap@...radead.org>
To: John Wood <john.wood@....com>, Kees Cook <keescook@...omium.org>,
 Jann Horn <jannh@...gle.com>
Cc: Jonathan Corbet <corbet@....net>, James Morris <jmorris@...ei.org>,
 "Serge E. Hallyn" <serge@...lyn.com>, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org,
 kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH v2 7/8] Documentation: Add documentation for the Brute LSM

On 11/9/20 10:23 AM, John Wood wrote:
> Hi,
> Thanks for the typos corrections. Will be corrected in the next patch
> version.
> 
> On Sun, Nov 08, 2020 at 08:31:13PM -0800, Randy Dunlap wrote:
>>
>> So an app could read crash_period_threshold and just do a new fork every
>> threshold + 1 time units, right? and not be caught?
> 
> Yes, you are right. But we must set a crash_period_threshold that does not
> make an attack feasible. For example, with the default value of 30000 ms,
> an attacker can break the app only once every 30 seconds. So, to guess
> canaries or break ASLR, the attack needs a big amount of time. But it is
> possible.
> 
> So, I think that to avoid this scenario we can add a maximum number of
> faults per fork hierarchy. Then, the mitigation will be triggered if the
> application crash period falls under the period threshold or if the number
> of faults exceed the maximum commented.
> 
> This way, if an attack is of long duration, it will also be detected and
> mitigated.
> 
> What do you think?

Hi,
That sounds reasonable to me.

thanks.
-- 
~Randy

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.