Messages in this thread | | | Date | Sun, 9 Aug 2020 00:17:48 +0200 | From | Pavel Machek <> | Subject | Re: [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
| |