| Main Archive Page > Month Archives > linux-security-module archives |
Re: [PATCH v2] modules: sysctl to block module loading
From: Kees Cook <kees_at_nospam>Date: Sun Apr 05 2009 - 14:00:16 GMT
To: "Serge E. Hallyn" <serge@hallyn.com>
Hi,
On Sat, Apr 04, 2009 at 10:47:41PM -0500, Serge E. Hallyn wrote:
> Quoting Andrew G. Morgan (morgan@kernel.org):
> > What privilege do you intend be required to raise this global bit?
> >
> > Just so I can clearly understand the need. How many processes are
> > running at the time this bit would be set? Its not clear to me that
> > modifying the user-space boot script launching code couldn't effectively
> > do the same thing via the inherited bounding set.
>
> We'd talked about that, but the problem is that the system likely needs
> to load some modules long after init has spawned off some long-running
> daemons. It's possible we can play games with keeping CAP_SYS_MODULE
> in pI along some paths, but that seems overly complicated and hence
> fragile.
Right. Additionally, it there are the cases of triggering a module-request from within the kernel (i.e. looking for a binfmt module[1]). While it might be possible to create an interface to init to remove CAP_SYS_MODULE (which I suspect does not belong in init), it still wouldn't be possible to revoke it later on for already running processes. The patch seemed like the simplest approach to restoring the prior behavior.
-Kees
[1] http://invisiblethingslab.com/pub/xenfb-adventures-10.pdf
e.g. page 6, section 3.4 -- Kees Cook Ubuntu Security Team -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html