archive mirror
 help / color / mirror / Atom feed
From: John Wood <>
To: "Valdis Klētnieks" <>
Cc: John Wood <>,
Subject: Re: Notify special task kill using wait* functions
Date: Sat, 3 Apr 2021 09:02:26 +0200	[thread overview]
Message-ID: <20210403070226.GA3002@ubuntu> (raw)
In-Reply-To: <106842.1617421818@turing-police>


On Fri, Apr 02, 2021 at 11:50:18PM -0400, Valdis Klētnieks wrote:
> On Fri, 02 Apr 2021 14:49:32 +0200, John Wood said:
> > the attack can be started again. So, he suggested that notifying to userspace
> > (via wait*() functions) that a child task has been killed by the "Brute" LSM,
> > the supervisor can adopt the correct policy and avoid respawn the killed
> > processes.
> > [1]
> That patch contains the biggest problem with your idea:
> +Moreover, this method is based on the idea that the protection doesn't act if
> +the parent crashes. So, it would still be possible for an attacker to fork a
> +process and probe itself. Then, fork the child process and probe itself again.
> +This way, these steps can be repeated infinite times without any mitigation.

Sorry, but this paragraph is extracted from the "Other implementations" section
(grsecurity to be more clear). Concreatly from the "Scenarios not detected
(false negatives)". So, it is a problem that has been addressed with the current
implementation. In other words, the "Brute LSM" acts on the parent (brute force
attack through the execve system call).

> In general, "security" that has an obvious and easy way to bypass it isn't
> providing any real security at all. If all it takes to bypass it is a double fork,
> everybody who didn't just fall out of the tree will do a double fork.  In other
> words, anybody who's clued enough to write malware that actually works
> and does the sort of attack you're trying to prevent should be able to fix
> the malware to bypass your "security" with just a few added lines of code.

Currently, the scenario you propose is fully mitigated :). And notifying to
userspace that all the tasks has been killed by "Brute" not decrease the
security. It adds the possibility that the supervisor adopts the correct policy.

If you can bypass it send a proof of concept and I will try to improve the
implementation :)

John Wood

Kernelnewbies mailing list

  reply	other threads:[~2021-04-03  7:03 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-30 17:34 John Wood
2021-03-30 18:40 ` Valdis Klētnieks
2021-04-02 12:49   ` John Wood
2021-04-03  3:50     ` Valdis Klētnieks
2021-04-03  7:02       ` John Wood [this message]
2021-04-03 21:34         ` Valdis Klētnieks
2021-04-04  9:48           ` John Wood
2021-04-04 21:10             ` Valdis Klētnieks
2021-04-05  7:31               ` John Wood
2021-04-06 23:55                 ` Valdis Klētnieks
2021-04-07 17:51                   ` John Wood
2021-04-07 20:38                     ` Valdis Klētnieks
2021-04-08  1:51                       ` Andi Kleen
2021-04-09 14:29                         ` John Wood
2021-04-09 15:06                           ` Andi Kleen
2021-04-09 16:08                             ` John Wood
2021-04-09 23:28                             ` Valdis Klētnieks
2021-04-11  8:46                               ` John Wood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210403070226.GA3002@ubuntu \ \ \ \
    --subject='Re: Notify special task kill using wait* functions' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).