netdev - Re: [PATCH 2/3] security: introducing security_request

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:	Thu, 13 Aug 2009 14:19:10 -0400
From:	Eric Paris <eparis@...hat.com>
To:	"Serge E. Hallyn" <serue@...ibm.com>
Cc:	linux-kernel@...r.kernel.org, selinux@...ho.nsa.gov,
	netdev@...r.kernel.org, linux-security-module@...r.kernel.org,
	sds@...ho.nsa.gov, davem@...emloft.net,
	shemminger@...ux-foundation.org, kees@...ntu.com,
	morgan@...nel.org, casey@...aufler-ca.com, dwalsh@...hat.com
Subject: Re: [PATCH 2/3] security: introducing security_request_module

On Thu, 2009-08-13 at 12:54 -0500, Serge E. Hallyn wrote:
> Quoting Eric Paris (eparis@...hat.com):
> > On Thu, 2009-08-13 at 09:03 -0500, Serge E. Hallyn wrote:
> > > Quoting Eric Paris (eparis@...hat.com):
> > > > Calling request_module() will trigger a userspace upcall which will load a
> > > > new module into the kernel.  This can be a dangerous event if the process
> > > > able to trigger request_module() is able to control either the modprobe
> > > > binary or the module binary.  This patch adds a new security hook to
> > > > request_module() which can be used by an LSM to control a processes ability
> > > > to call request_module().
> > > 
> > > Is there a specific case in which you'd want to deny this ability
> > > from a real task?
> > 
> > qemu and any network facing daemon are all programs I don't want to be
> > able to even ask the kernel to load a module.  Clearly you are right,
> 
> ...  What if the network facing daemon might want to use a kernel crypto
> module?  What if qemu needs the tun module loaded?

Loading code into the kernel is a dangerous operation.  We should find
the places where high risk processes are doing this and either choose to
accept the security risk or make sure they are loaded before the
dangerous code is run, aka libvirt knows if the guest needs the tun
device and it should be allowed to trigger it's loading.  It's shouldn't
be the guest doing the triggering.

It was also pointed out to me that stopping processes from being able to
trigger module loads could be useful to keep a subverted process from
loading an uncommon or unloaded module with a vulnerability which they
could then use to exploit the kernel.  It's all about hardening.

It won't be a simple task for SELinux policy to do something useful with
this hook as they need to identify all of the legitimate callers of
request_module(), but then again, that should be a lot easier than 90%
of what SELinux already has to do, and until SELinux policy decides to
make use of the new permission things will 'just work'

-Eric

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html