Re: FWIW: sysrestrict

[Alistair Crooks <agc%pkgsrc.org@localhost>]

ISTM that your sysretsrict suffers from one of the same drawbacks as
pledge/tame/name-du-jour - the restrictions are being burned into the
binary at compile/link time. That might be fine for system binaries
(but some people download distributions from the project servers) that
are built locally - what about anything more than the basics, like an
apache with loadable modules? How do you specify the modular
restrictions? How do we make it so that an apache binary can be
successfully have its restriction set "expanded" to allow modules to
do their job, when that is what sysretsrict is trying to prevent?

I'd be much happier with a variant of seccomp-bpf, or even using lua
to do the same job (if it was performant, JIT-enabled and safe to do
such a thing, I expect not :().

My main problem is that simply outlawing system calls is a very
coarse-grained hammer. I may want a binary to be able to open files
for writing in /tmp, but not open any files in /etc for writing. Or
reading files in my home directory, except for anything in ~/.ssh or
~/.gnupg. How does sysrestrict cope with this?

Thanks,
Alistair

On 23 July 2016 at 14:50, Paul Goyette <paul%whooppee.com@localhost> wrote:
> I would assume that the checking of syscall restrictions would be done
> within the kauth(9) framework?
>
>
> On Sat, 23 Jul 2016, Maxime Villard 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.
>> - 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.
>> - 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.
>> - 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.
>>
>> I've never tested this code. But in case it inspires or motivates someone.
>>
>> [1] http://m00nbsd.net/garbage/sysrestrict/
>>
>> !DSPAM:5793b16a111187246213503!
>>
>>
>
> +------------------+--------------------------+------------------------+
> | Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:      |
> | (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
> | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
> +------------------+--------------------------+------------------------+
>