On Thu, Jul 23, 2015 at 4:58 PM, Willy Tarreau <w...@1wt.eu> wrote: > On Thu, Jul 23, 2015 at 04:40:14PM -0700, Andy Lutomirski wrote: >> On Thu, Jul 23, 2015 at 4:36 PM, Kees Cook <keesc...@chromium.org> wrote: >> > I've been pondering something like this that is even MORE generic, for >> > any syscall. Something like a "syscalls" directory under >> > /proc/sys/kernel, with 1 entry per syscall. "0" is "available", "1" is >> > disabled, and "-1" disabled until next boot. >> > >> >> It might want to be /proc/sys/kernel/syscalls/[abi]/[name], possibly >> with more than just those options. We might want "disabled, returns >> ENOSYS", "disabled, returns EPERM", and a lock bit. >> >> On x86 at least, the implementation's easy -- we can just poke the >> syscall table. > > I wouldn't do it these days. Around 2000-2001, with a friend we designed > a module with its userland counterpart which was called "overloader". The > principle was to intercept syscalls in order to enforce some form of > policies, log values, or remap paths, etc. The first use was to log all > file creations during a "make install" to more easily build packages. It > was at the era where it was easy to modify the syscall table from a module, > in kernel 2.2. > > We quickly found that beyond logging/rewriting syscall arguments, it had > limited use cases when used as a "syscall firewall" because many syscalls > are still too coarse to decide whether you want to enable/disable them. > I remember that socketcall() and ioctl() were among the annoying ones. > Either you totally enable or totally disable. In the end, the only valid > use cases we found for enabling/disabling a syscall were limited to a very > small set for debugging purposes, in order to force some application code > to detect a missing implementation and switch to an alternative (eg: these > days if you suspect a bug in epoll you could disable it and force the app > to use poll instead). It was still useful to disable module loading and > FS mounting but that was about all by then. > > All this to say that probably only a handful of tricky syscalls would > need an on/off switch but clearly not all of them at all, so I'd rather > add a few entries just for the relevant ones, mainly to fix compatibility > issues and nothing more. Eg: what's the point of disabling exit(), wait(), > kill(), fork() or getpid()... It would only increase the difficulty to > sort out bug reports. > > Just my opinion,
Well, I would really like to have something like this around so that I can trivially globally disable syscalls when they have security risks. My hack[1] to disable kexec_load, for example, was terrible while I waited for a kernel that supported the disable_kexec_load sysctl. -Kees [1] https://outflux.net/blog/archives/2013/12/10/live-patching-the-kernel/ -- Kees Cook Chrome OS Security _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
