Re: [kernel-hardening] Re: [RFC v2 PATCH 1/2] security: introduce CONFIG_SECURITY_WRITABLE_HOOKS

From: Daniel Micay <danielmicay@gmail.com>
To: Casey Schaufler <casey@schaufler-ca.com>,
	Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	jmorris@namei.org
Cc: linux-security-module@vger.kernel.org, selinux@tycho.nsa.gov,
	kernel-hardening@lists.openwall.com
Subject: Re: [kernel-hardening] Re: [RFC v2 PATCH 1/2] security: introduce CONFIG_SECURITY_WRITABLE_HOOKS
Date: Thu, 16 Feb 2017 15:02:51 -0500	[thread overview]
Message-ID: <1487275371.9667.1.camel@gmail.com> (raw)
In-Reply-To: <63b8eab1-4384-688a-33cd-b648c99497a8@schaufler-ca.com>

[-- Attachment #1: Type: text/plain, Size: 1489 bytes --]

> >  At least one antivirus software (which allows
> > anonymous download of LKM source code) is using LSM hooks since
> > Linux 2.6.32
> > instead of rewriting syscall tables. We are already allowing
> > multiple concurrent
> > LSM modules (up to one fully armored module which uses "struct
> > cred"->security
> > field or exclusive hooks like security_xfrm_state_pol_flow_match(),
> > plus
> > unlimited number of lightweight modules which do not use "struct
> > cred"->security
> > nor exclusive hooks) as long as they are built into the kernel.
> > There is no
> > reason to keep LKM based LSM modules from antivirus software or
> > alike away.
> 
> We're not to the point where in-kernel modules are stacking fully.
> Not everyone is on board for that, but hope springs eternal. Part
> of the design criteria I'm working under is that it shouldn't
> preclude loadable modules, and I still think that's doable. The
> patch James proposed is completely compatible with this philosophy.
> You can argue that it requires a loadable module configuration be
> less "hardened", but the opponents of loadable modules say that is
> inherent to loadable modules.

FWIW, the full infrastructure for read-only data from PaX includes a way
to make data temporary writable for a kernel thread. In PaX,
__ro_after_init was/is called __read_only and pax_open_kernel /
pax_close_kernel make it usable for rarely written data. That could
easily land before loadable LSMs.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 866 bytes --]