kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: John Wood <john.wood@gmx.com>
To: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>
Cc: John Wood <john.wood@gmx.com>, kernelnewbies@kernelnewbies.org
Subject: Re: Notify special task kill using wait* functions
Date: Sun, 4 Apr 2021 11:48:37 +0200	[thread overview]
Message-ID: <20210404094837.GA3263@ubuntu> (raw)
In-Reply-To: <145687.1617485641@turing-police>

Hi,

On Sat, Apr 03, 2021 at 05:34:01PM -0400, Valdis Klētnieks wrote:
> On Sat, 03 Apr 2021 09:02:26 +0200, John Wood said:
>
> > 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.
>
> So how do you figure out how far up the chain you kill processes?

When a process crashes with a fatal signal their stats are updated. Also,
are updated the "exec" stats (the statistics of the parent process: the
process that called the execve system call).

Then the stats of the process that crashes are checked. If these show a
fast crash rate, this fork hierarchy is killed (all the processes that
have the same stats). Then the exec stats are checked but if the info are
equal to the fork stats nothing is done. Otherwise, if they show an attack,
this fork hierarchy is also killed.

If you follow the discussion with Andi Kleen there is a full example. [1]

[1] https://lore.kernel.org/kernel-hardening/20210309184054.GA3058@ubuntu/

Now, the process that forks and crashes is mitigated. Also, the process
that exec and the child crashes is mitigated. The only drawback here, as
point Andi, is that a supervisor respawns some process killed. To avoid
this situation he suggest to notify to usersapace via wait* that the
task has been killed by "brute". Then, this supervisor has the chance to
do what they need (respawn or not).

> What does a triple or quadruple fork do? How do you ensure that you deliver
> the notification to the correct supervisor? (Hint - walking backwards until you
> hit a process running as root isn't necessarily the right answer, especially
> once you consider containers and systems where gdm runs as non-root
> and other weird stuff..)

The number of forks does not matter. It's not a problem here. And, if you
follow the annotated discussion, you will see that walking backwards not
necessary reach init.

The notification is delivered to the supervisor that wants it (via wait).

> Bonus points if you deal correctly with abuse of LD_PRELOAD to front-end
> a signal handler that catches SIGSEGV, without breaking the semantics
> of legitimate signal handlers...

Hmm, interesting... I need to study it and test. Good point. Thanks.

Thanks,
John Wood

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

  reply	other threads:[~2021-04-04  9:49 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
2021-04-03 21:34         ` Valdis Klētnieks
2021-04-04  9:48           ` John Wood [this message]
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20210404094837.GA3263@ubuntu \
    --to=john.wood@gmx.com \
    --cc=kernelnewbies@kernelnewbies.org \
    --cc=valdis.kletnieks@vt.edu \
    --subject='Re: Notify special task kill using wait* functions' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).