lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 8 Nov 2010 10:20:13 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Dan Rosenberg <drosenberg@...curity.com>
Cc:	linux-kernel@...r.kernel.org, security@...nel.org
Subject: Re: [PATCH RFC] Restrictions on module loading

> loading of kernel modules, for example by creating a socket using a
> packet family that is compiled as a module and not already loaded.  On
> most distributions, this creates a significant attack surface, and
> requires maintenance of blacklists and other inelegant solutions to a
> general problem.

Those inelegant solutions work rather better in a lot of situations
because most distributions will fall flat on their face if auto loading
isn't active and they are more flexible.

> The below patch replaces the existing "modules_disable" sysctl with a

NAK - Its a long standing ABI.

> When set to 2, modules may not be loaded or unloaded by anyone, and the
> sysctl may not be changed from that point forward.  This is designed to
> provide protection against kernel module rootkits.

I've no objection to modules_restrict although I doubt it'll ever get
used in the real world, but better to extend the meaning of the existing
interface, not remove stuff.

If you have "security" in your address the please think like a security
person - users with security relying upon writing to modules_disable are
*not* going to notice a one line log entry somewhere about unable to open
{filename that doesn't look important}.

So your change is actually *bad* for security in its current form, you
remove the facilities they rely upon.

Alan

--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ