[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e6e04af7-5445-bda9-6665-b52c72735b63@infradead.org>
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.
