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. > > It is a problem because a kernel that implements W^X properly > will not allow it. It has no idea what has been done in userland. > It has no idea that the user has checked and verified the buffer > contents after transitioning the page to R--. No, it is not a problem. W^X is designed to protect from attackers doing buffer overflows, not attackers doing arbitrary syscalls. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: PGP signature
