Re: FWIW: sysrestrict

[Matt Thomas <matt%3am-software.com@localhost>]

> On Jul 23, 2016, at 1:36 AM, Maxime Villard <max%M00nBSD.net@localhost> wrote:
> 
> Eight months ago, I shared with a few developers the code for a kernel
> interface [1] that can disable syscalls in user processes.
> 
> The idea is the following: a syscall bitmap is embedded into the ELF binary
> itself (in a note section, like PaX), and each time the binary performs a
> syscall, the kernel checks whether the syscall in question is allowed in
> the bitmap.
> 
> In details:
> - the ELF section is a bitmap of 64 bytes, which means 512 bits, the
>   number of syscalls. 0 means allowed, 1 means restricted.

Seems you only need the number of bytes needed to encode the hightest
restricted syscall.  However, I think I'd prefer a level of indirection.  Have 
a name of a bitmap embedded which references to a bitmap already loaded.
These would be visible via kern.restriction_sets.<name> which would contain the bitmap.
There would also be a sysctl controlling what happens if you try to run a program
with an unknown bitmap set which only take effect where securelevel is non-zero.

> - in the proc structure, 64 bytes are present, just a copy of the
>   ELF section.
> - when a syscall is performed, the kernel calls sysrestrict_enforce
>   with the proc structure and the syscall number, and gives a look
>   at the bitmap to make sure it is allowed. If it isn't, the process
>   is killed.

What happens when we get more than 512 syscalls?  Is this for NetBSD
binaries only?  

> - a new syscall is added, sysrestrict, so that programs can restrict
>   a syscall at runtime. This might be useful, particularly if a
>   program calls a syscall once and wants to make sure it is not
>   allowed any longer.

I assume it can't unrestrict.  do you pass the size of the array(s)?

> - a userland tool (that I didn't write) can add and update such an ELF
>   section in the binary.
> 
> This interface has the following advantages over most already-existing
> implementations:
> - it is system-independent, it could almost be copied as-is in FreeBSD.
> - it is syscall-independent, we don't need to patch each syscall.
> - it does not require binaries to be recompiled.
> - the performance cost is low, if not non-existent.

If a syscall is restricted, what error is returned?  EPERM?  ENOSYS?

> I've never tested this code. But in case it inspires or motivates someone.
> 
> [1] http://m00nbsd.net/garbage/sysrestrict/