> On Jul 23, 2016, at 1:36 AM, Maxime Villard <[email protected]> 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/
