On Mon, Sep 14, 2020 at 09:42:37PM +0200, Jann Horn wrote: > On Sun, Sep 13, 2020 at 7:55 PM John Wood <john.wood@xxxxxxx> wrote: > > On Thu, Sep 10, 2020 at 11:10:38PM +0200, Jann Horn wrote: > > > > + delta_jiffies = get_jiffies_64() - stats->jiffies; > > > > + delta_time = jiffies64_to_msecs(delta_jiffies); > > > > + crashing_rate = delta_time / (u64)stats->faults; > > > > > > Do I see this correctly, is this computing the total runtime of this > > > process hierarchy divided by the total number of faults seen in this > > > process hierarchy? If so, you may want to reconsider whether that's > > > really the behavior you want. For example, if I configure the minimum > > > period between crashes to be 30s (as is the default in the sysctl > > > patch), and I try to attack a server that has been running without any > > > crashes for a month, I'd instantly be able to crash around > > > 30*24*60*60/30 = 86400 times before the detection kicks in. That seems > > > suboptimal. > > > > You are right. This is not the behaviour we want. So, for the next > > version it would be better to compute the crashing period as the time > > between two faults, or the time between the execve call and the first > > fault (first fault case). > > > > However, I am afraid of a premature detection if a child process fails > > twice in a short period. > > > > So, I think it would be a good idea add a new sysctl to setup a > > minimum number of faults before the time between faults starts to be > > computed. And so, the attack detection only will be triggered if the > > application crashes quickly but after a number of crashes. > > > > What do you think? > > You could keep a list of the timestamps of the last five crashes or > so, and then take action if the last five crashes happened within > (5-1)*crash_period_limit time. Ok, your proposed solution seems a more clever one. Anyway I think that a new sysctl for fine tuning the number of timestamps would be needed. Thanks, John Wood
