Re: FWIW: sysrestrict

[Maxime Villard <max%m00nbsd.net@localhost>]

Le 26/07/2016 à 11:56, Joerg Sonnenberger a écrit :
> > It's just obvious: we don't want ftpd to call modctl, or execve (even if it
> > currently does), or mount, or reboot, or swapctl, etc. And it gets solved
> > by restricting those syscalls.
>
> You haven't answered my question. "I don't want to allow calls to foo"
> is not a problem. Let's ignore for a moment that the majority of your list
> is restricted to root and you have lost already in the UNIX security
> model if your code is running as root. What's the purpose of not
> allowing execve? In a sensible capability system (which pledge is not
> for exactly this reason), switching to a different binary is just
> another form of running arbitrary code. If you can do the latter
> already, the former doesn't gain you anything. But this is still a
> detail of the mechanism. It doesn't answer the fundamental question of
> what problem you are trying to solve. What attack is this mechanism
> supposed to prevent?

It is not trying to "prevent" an attack, it is supposed to restrict what
the attacker can do. Veriexec too is useful only if there is already an
intruder. And mapping .rodata as R reduces the possibility of ROP attacks
only if there is already a vulnerability that could allow an attacker to
jump to a chosen address.

If a vulnerability exists in a software (root or not) that allows control
of the execution flow, the attacker will often have a small payload of
shellcode, and this shellcode will try to load a bigger shellcode. Doing
this involves using special syscalls. If these syscalls are not available
the attack fails. Of course, there are many other things the attacker can
do with the small shellcode, but at least it restricts the attack surface.

For example, if a vulnerability in ftpd could allow a RCE, it is highly
likely that the shellcode will only consist in execve'ing a downloaded
executable. There are also many other examples in which restricting
syscalls would actually entirely prevent the exploitation of
vulnerabilities.

And beyond the security aspect, a feature like sysrestrict could be useful
for general consistency; by restricting syscalls in the base binaries, we
could make sure no change (in libc, for example) would make them execute an
unusual syscall.