> On May 12, 2019, at 6:35 AM, Aleksa Sarai wrote:
>
>> On 2019-05-12, Linus Torvalds wrote:
>>> On Sat, May 11, 2019 at 7:37 PM Andy Lutomirski wrote:
>>> I bet this will break something that already exists. An execveat()
>>> flag to turn off /proc/self/exe would do the trick, though.
>>
>>
On 2019-05-12, Aleksa Sarai wrote:
> On 2019-05-12, Linus Torvalds wrote:
> > On Sat, May 11, 2019 at 7:37 PM Andy Lutomirski wrote:
> > > I bet this will break something that already exists. An execveat()
> > > flag to turn off /proc/self/exe would do the trick, though.
> >
> > Thinking more a
On 2019-05-12, Linus Torvalds wrote:
> On Sat, May 11, 2019 at 7:37 PM Andy Lutomirski wrote:
> > I bet this will break something that already exists. An execveat()
> > flag to turn off /proc/self/exe would do the trick, though.
>
> Thinking more about it, I suspect it is (once again) wrong to l
On Sat, May 11, 2019 at 7:37 PM Andy Lutomirski wrote:
>
> I bet this will break something that already exists. An execveat() flag to
> turn off /proc/self/exe would do the trick, though.
Thinking more about it, I suspect it is (once again) wrong to let the
thing that does the execve() control t
On Sat, May 11, 2019 at 07:08:49PM -0400, Linus Torvalds wrote:
> [ on mobile again, power is off and the wifi doesn't work, so I'm reading
> email on my phone and apologizing once more for horrible html email.. ]
>
> On Sat, May 11, 2019, 18:40 Andy Lutomirski wrote:
>
> >
> > a) Change all my
> On May 11, 2019, at 10:21 AM, Linus Torvalds
> wrote:
>
>> On Sat, May 11, 2019 at 1:00 PM Andy Lutomirski wrote:
>>
>> A better “spawn” API should fix this.
>
> Andy, stop with the "spawn would be better".
It doesn’t have to be spawn per se. But the current situation sucks.
>
> Notice? Non
On 2019-05-11, Linus Torvalds wrote:
> On Sat, May 11, 2019 at 1:31 PM Aleksa Sarai wrote:
> > Yup, I've dropped the patch for the next version. (To be honest, I'm not
> > sure why I included any of the other flags -- the only one that would've
> > been necessary to deal with CVE-2019-5736 was AT
On Sat, May 11, 2019 at 1:31 PM Aleksa Sarai wrote:
>
> Yup, I've dropped the patch for the next version. (To be honest, I'm not
> sure why I included any of the other flags -- the only one that would've
> been necessary to deal with CVE-2019-5736 was AT_NO_MAGICLINKS.)
I do wonder if we could tr
On May 11, 2019 7:43:44 PM GMT+02:00, Linus Torvalds
wrote:
>On Sat, May 11, 2019 at 1:31 PM Aleksa Sarai wrote:
>>
>> Yup, I've dropped the patch for the next version. (To be honest, I'm
>not
>> sure why I included any of the other flags -- the only one that
>would've
>> been necessary to deal
On 2019-05-11, Linus Torvalds wrote:
> On Sat, May 11, 2019 at 1:21 PM Linus Torvalds
> wrote:
> >
> > Notice? None of the real problems are about execve or would be solved
> > by any spawn API. You just think that because you've apparently been
> > talking to too many MS people that think fork (
On Sat, May 11, 2019 at 1:21 PM Linus Torvalds
wrote:
>
> Notice? None of the real problems are about execve or would be solved
> by any spawn API. You just think that because you've apparently been
> talking to too many MS people that think fork (and thus indirectly
> execve()) is bad process man
On Sat, May 11, 2019 at 1:00 PM Andy Lutomirski wrote:
>
> A better “spawn” API should fix this.
Andy, stop with the "spawn would be better".
Spawn is garbage. It's garbage because it's fundamentally too
inflexible, and it's garbage because it is quite complex to try to
work around the inflexibi
On 2019-05-11, Andy Lutomirski wrote:
> >> I've lost track of the context here, but it seems to me that
> >> mitigating attacks involving accidental following of /proc links
> >> shouldn't depend on dumpability. What's the actual problem this is
> >> trying to solve again?
> >
> > The one actual
> On May 10, 2019, at 3:55 PM, Jann Horn wrote:
>
>> On Fri, May 10, 2019 at 02:20:23PM -0700, Andy Lutomirski wrote:
>>> On Fri, May 10, 2019 at 1:41 PM Jann Horn wrote:
>>>
On Tue, May 07, 2019 at 05:17:35AM +1000, Aleksa Sarai wrote:
> On 2019-05-06, Jann Horn wrote:
> In my
On 2019-05-11, Christian Brauner wrote:
> > In my opinion, the problems here are:
> >
> > - Apparently some people run untrusted containers without user
> >namespaces. It would be really nice if people could not do that.
> >(Probably the biggest problem here.)
>
> I know I sound like a br
On Sat, May 11, 2019 at 12:55 AM Jann Horn wrote:
>
> On Fri, May 10, 2019 at 02:20:23PM -0700, Andy Lutomirski wrote:
> > On Fri, May 10, 2019 at 1:41 PM Jann Horn wrote:
> > >
> > > On Tue, May 07, 2019 at 05:17:35AM +1000, Aleksa Sarai wrote:
> > > > On 2019-05-06, Jann Horn wrote:
> > > > >
On Fri, May 10, 2019 at 02:20:23PM -0700, Andy Lutomirski wrote:
> On Fri, May 10, 2019 at 1:41 PM Jann Horn wrote:
> >
> > On Tue, May 07, 2019 at 05:17:35AM +1000, Aleksa Sarai wrote:
> > > On 2019-05-06, Jann Horn wrote:
> > > > In my opinion, CVE-2019-5736 points out two different problems:
>
On Fri, May 10, 2019 at 1:41 PM Jann Horn wrote:
>
> On Tue, May 07, 2019 at 05:17:35AM +1000, Aleksa Sarai wrote:
> > On 2019-05-06, Jann Horn wrote:
> > > In my opinion, CVE-2019-5736 points out two different problems:
> > >
> > > The big problem: The __ptrace_may_access() logic has a special-c
On Tue, May 07, 2019 at 05:17:35AM +1000, Aleksa Sarai wrote:
> On 2019-05-06, Jann Horn wrote:
> > In my opinion, CVE-2019-5736 points out two different problems:
> >
> > The big problem: The __ptrace_may_access() logic has a special-case
> > short-circuit for "introspection" that you can't opt o
On Tue, May 07, 2019 at 07:38:58PM -0500, Eric W. Biederman wrote:
> Jann Horn writes:
> > In my opinion, CVE-2019-5736 points out two different problems:
> >
> > The big problem: The __ptrace_may_access() logic has a special-case
> > short-circuit for "introspection" that you can't opt out of;
>
On 2019-05-07, Aleksa Sarai wrote:
> On 2019-05-06, Jann Horn wrote:
> > On Mon, May 6, 2019 at 6:56 PM Aleksa Sarai wrote:
> > > The need to be able to scope path resolution of interpreters became
> > > clear with one of the possible vectors used in CVE-2019-5736 (which
> > > most major contain
Jann Horn writes:
>
> In my opinion, CVE-2019-5736 points out two different problems:
>
> The big problem: The __ptrace_may_access() logic has a special-case
> short-circuit for "introspection" that you can't opt out of;
Once upon a time in a galaxy far far away I fixed a bug where we missing
ptr
> On May 6, 2019, at 12:17 PM, Aleksa Sarai wrote:
>
>> On 2019-05-06, Jann Horn wrote:
>>> On Mon, May 6, 2019 at 6:56 PM Aleksa Sarai wrote:
>>> The need to be able to scope path resolution of interpreters became
>>> clear with one of the possible vectors used in CVE-2019-5736 (which
>>> m
On 2019-05-06, Jann Horn wrote:
> On Mon, May 6, 2019 at 6:56 PM Aleksa Sarai wrote:
> > The need to be able to scope path resolution of interpreters became
> > clear with one of the possible vectors used in CVE-2019-5736 (which
> > most major container runtimes were vulnerable to).
> >
> > Naive
On Mon, May 6, 2019 at 6:56 PM Aleksa Sarai wrote:
> The need to be able to scope path resolution of interpreters became
> clear with one of the possible vectors used in CVE-2019-5736 (which
> most major container runtimes were vulnerable to).
>
> Naively, it might seem that openat(2) -- which sup
The need to be able to scope path resolution of interpreters became
clear with one of the possible vectors used in CVE-2019-5736 (which
most major container runtimes were vulnerable to).
Naively, it might seem that openat(2) -- which supports path scoping --
can be combined with execveat(AT_EMPTY_
26 matches
Mail list logo
