From: John Wood <john.wood@gmx.com> To: Andi Kleen <ak@linux.intel.com> Cc: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>, kernel-hardening@lists.openwall.com, "John Wood" <john.wood@gmx.com>, "Kees Cook" <keescook@chromium.org>, kernelnewbies@kernelnewbies.org Subject: Re: Notify special task kill using wait* functions Date: Fri, 9 Apr 2021 18:08:14 +0200 [thread overview] Message-ID: <20210409160814.GA4937@ubuntu> (raw) In-Reply-To: <20210409150621.GJ3762101@tassilo.jf.intel.com> Hi, On Fri, Apr 09, 2021 at 08:06:21AM -0700, Andi Kleen wrote: > > > Any caching of state is inherently insecure because any caches of limited > > > size can be always thrashed by a purposeful attacker. I suppose the > > > only thing that would work is to actually write something to the > > > executable itself on disk, but of course that doesn't always work either. > > > > I'm also working on this. In the next version I will try to find a way to > > prevent brute force attacks through the execve system call with more than > > one level of forking. > > Thanks. > > Thinking more about it what I wrote above wasn't quite right. The cache > would only need to be as big as the number of attackable services/suid > binaries. Presumably on many production systems that's rather small, > so a cache (which wouldn't actually be a cache, but a complete database) > might actually work. Thanks. I will keep it in mind. > > -Andi Regards, John Wood _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
WARNING: multiple messages have this Message-ID (diff)
From: John Wood <john.wood@gmx.com> To: Andi Kleen <ak@linux.intel.com> Cc: "John Wood" <john.wood@gmx.com>, "Valdis Klētnieks" <valdis.kletnieks@vt.edu>, kernelnewbies@kernelnewbies.org, "Kees Cook" <keescook@chromium.org>, kernel-hardening@lists.openwall.com Subject: Re: Notify special task kill using wait* functions Date: Fri, 9 Apr 2021 18:08:14 +0200 [thread overview] Message-ID: <20210409160814.GA4937@ubuntu> (raw) In-Reply-To: <20210409150621.GJ3762101@tassilo.jf.intel.com> Hi, On Fri, Apr 09, 2021 at 08:06:21AM -0700, Andi Kleen wrote: > > > Any caching of state is inherently insecure because any caches of limited > > > size can be always thrashed by a purposeful attacker. I suppose the > > > only thing that would work is to actually write something to the > > > executable itself on disk, but of course that doesn't always work either. > > > > I'm also working on this. In the next version I will try to find a way to > > prevent brute force attacks through the execve system call with more than > > one level of forking. > > Thanks. > > Thinking more about it what I wrote above wasn't quite right. The cache > would only need to be as big as the number of attackable services/suid > binaries. Presumably on many production systems that's rather small, > so a cache (which wouldn't actually be a cache, but a complete database) > might actually work. Thanks. I will keep it in mind. > > -Andi Regards, John Wood
next prev parent reply other threads:[~2021-04-09 16:09 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 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 [this message] 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=20210409160814.GA4937@ubuntu \ --to=john.wood@gmx.com \ --cc=ak@linux.intel.com \ --cc=keescook@chromium.org \ --cc=kernel-hardening@lists.openwall.com \ --cc=kernelnewbies@kernelnewbies.org \ --cc=valdis.kletnieks@vt.edu \ /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: linkBe 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.