lkml.org 
[lkml]   [2020]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor
Hi!

> Thanks for the lively discussion. I have tried to answer some of the
> comments below.

> > There are options today, e.g.
> >
> > a) If the restriction is only per-alias, you can have distinct aliases
> > where one is writable and another is executable, and you can make it
> > hard to find the relationship between the two.
> >
> > b) If the restriction is only temporal, you can write instructions into
> > an RW- buffer, transition the buffer to R--, verify the buffer
> > contents, then transition it to --X.
> >
> > c) You can have two processes A and B where A generates instrucitons into
> > a buffer that (only) B can execute (where B may be restricted from
> > making syscalls like write, mprotect, etc).
>
> The general principle of the mitigation is W^X. I would argue that
> the above options are violations of the W^X principle. If they are
> allowed today, they must be fixed. And they will be. So, we cannot
> rely on them.

Would you mind describing your threat model?

Because I believe you are using model different from everyone else.

In particular, I don't believe b) is a problem or should be fixed.

I'll add d), application mmaps a file(R--), and uses write syscall to change
trampolines in it.

> b) This is again a violation. The kernel should refuse to give execute
> ???????? permission to a page that was writeable in the past and refuse to
> ???????? give write permission to a page that was executable in the past.

Why?

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

\
 
 \ /
  Last update: 2020-08-09 00:19    [W:0.342 / U:0.468 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site