Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753244AbbGXAJY (ORCPT ); Thu, 23 Jul 2015 20:09:24 -0400 Received: from mail-ig0-f175.google.com ([209.85.213.175]:33854 "EHLO mail-ig0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752656AbbGXAJW (ORCPT ); Thu, 23 Jul 2015 20:09:22 -0400 MIME-Version: 1.0 In-Reply-To: <20150723235805.GA3191@1wt.eu> References: <7bfde005b84a90a83bf668a320c7d4ad1b940065.1437592883.git.luto@kernel.org> <20150723102434.GA2929@1wt.eu> <20150723235805.GA3191@1wt.eu> Date: Thu, 23 Jul 2015 17:09:21 -0700 X-Google-Sender-Auth: iiR9e8A206rl46KlGlpubDFBGLQ Message-ID: Subject: Re: [PATCH v3 2/3] x86/ldt: Make modify_ldt optional From: Kees Cook To: Willy Tarreau Cc: Andy Lutomirski , Andy Lutomirski , Peter Zijlstra , Steven Rostedt , "security@kernel.org" , X86 ML , Borislav Petkov , Sasha Levin , LKML , Konrad Rzeszutek Wilk , Boris Ostrovsky , Andrew Cooper , Jan Beulich , xen-devel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3098 Lines: 62 On Thu, Jul 23, 2015 at 4:58 PM, Willy Tarreau 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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/