From: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>
To: John Wood <john.wood@gmx.com>
Cc: kernelnewbies@kernelnewbies.org
Subject: Re: Notify special task kill using wait* functions
Date: Sat, 03 Apr 2021 17:34:01 -0400 [thread overview]
Message-ID: <145687.1617485641@turing-police> (raw)
In-Reply-To: <20210403070226.GA3002@ubuntu>
[-- Attachment #1.1: Type: text/plain, Size: 860 bytes --]
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?
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..)
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...
[-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --]
[-- Attachment #2: Type: text/plain, Size: 170 bytes --]
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
next prev parent reply other threads:[~2021-04-03 21:34 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-30 17:34 Notify special task kill using wait* functions 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 [this message]
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 17:51 ` John Wood
2021-04-07 20:38 ` Valdis Klētnieks
2021-04-07 20:38 ` Valdis Klētnieks
2021-04-08 1:51 ` Andi Kleen
2021-04-08 1:51 ` Andi Kleen
2021-04-09 14:29 ` John Wood
2021-04-09 14:29 ` John Wood
2021-04-09 15:06 ` Andi Kleen
2021-04-09 15:06 ` Andi Kleen
2021-04-09 16:08 ` John Wood
2021-04-09 16:08 ` John Wood
2021-04-09 23:28 ` Valdis Klētnieks
2021-04-09 23:28 ` Valdis Klētnieks
2021-04-11 8:46 ` John Wood
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=145687.1617485641@turing-police \
--to=valdis.kletnieks@vt.edu \
--cc=john.wood@gmx.com \
--cc=kernelnewbies@kernelnewbies.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.