tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: FWIW: sysrestrict



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.


Home | Main Index | Thread Index | Old Index