Date:	Thu, 23 Jul 2015 17:09:21 -0700
From:	Kees Cook <keescook@...omium.org>
To:	Willy Tarreau <w@....eu>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Andy Lutomirski <luto@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	"security@...nel.org" <security@...nel.org>,
	X86 ML <x86@...nel.org>, Borislav Petkov <bp@...en8.de>,
	Sasha Levin <sasha.levin@...cle.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Andrew Cooper <andrew.cooper3@...rix.com>,
	Jan Beulich <jbeulich@...e.com>,
	xen-devel <xen-devel@...ts.xen.org>
Subject: Re: [PATCH v3 2/3] x86/ldt: Make modify_ldt optional

On Thu, Jul 23, 2015 at 4:58 PM, Willy Tarreau <w@....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 <keescook@...omium.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists