Hi Theo
On Tue, Oct 8, 2024 at 12:01 PM Theo de Raadt <deraadt@xxxxxxxxxxxxxxx> wrote:
>
> >-Additional notes:
> >-=================
> > As Jann Horn pointed out in [3], there are still a few ways to write
> >-to RO memory, which is, in a way, by design. Those cases are not covered
> >-by mseal(). If applications want to block such cases, sandbox tools (such as
> >-seccomp, LSM, etc) might be considered.
> >+to RO memory, which is, in a way, by design. And those could be blocked
> >+by different security measures.
> >
> > Those cases are:
> >
> >-- Write to read-only memory through /proc/self/mem interface.
> >-- Write to read-only memory through ptrace (such as PTRACE_POKETEXT).
> >-- userfaultfd.
> >+ - Write to read-only memory through /proc/self/mem interface (FOLL_FORCE).
> >+ - Write to read-only memory through ptrace (such as PTRACE_POKETEXT).
> >+ - userfaultfd.
>
> This block of notes keeps bothering me, because I've encountered a bunch
> of people who walk away with "oh but what's the purpose of this thing then
> it is useless".
Maybe if it will help if I add "Can be blocked by" as below:
- Write to read-only memory through /proc/self/mem interface (FOLL_FORCE).
Can be blocked by CONFIG_PROC_MEM_RESTRICT_WRITE_ALL, Landlock, etc.
- Write to read-only memory through ptrace (such as PTRACE_POKETEXT).
Can be blocked by LSM such as Yama, Landlock, etc.
- userfaultfd
Can be blocked by seccomp.
Anyway, mseal is a syscall that I don't expect to be widely used by
applications, only a few places will actually need it, and I'm
expecting those devs will do necessary work in understanding what
mseal is and if it fits their threat-model.
To this extent, I welcome dev to extend the syscall (there is a
"flags" reserved for such purpose), if they deem it is necessary to
enhance mseal for their user-cases.
-Jeff
