[lkml]   [2020]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor

> >> 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,
(cesky, pictures)
[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2020-08-11 15:09    [W:0.149 / U:0.524 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site