| Main Archive Page > Month Archives > linux-kernel archives |
Re: [PATCH 2/3] security: introducing security_request_module
From: Serge E. Hallyn <serue_at_nospam>Date: Thu Aug 13 2009 - 17:54:05 GMT
To: Eric Paris <eparis@redhat.com>
Quoting Eric Paris (eparis@redhat.com):
> On Thu, 2009-08-13 at 09:03 -0500, Serge E. Hallyn wrote:
> > Quoting Eric Paris (eparis@redhat.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?
> that the best protection is done by controlling access to modprobe and
> the modules on disk (which we are working to fix vs what happened in the
> xen fb exploit I showed earlier) but stopping it from the other
> direction is, I feel, a useful defense in depth.
>
> If they can't get modprobe called, they can't take over the system
> directly, even if they did change a module or change modprobe. I agree
> it's not strong security as if they can change modprobe or modules they
> might be able to just wait until something else calls modprobe (next
> reboot maybe?) to take over the system. But I'd find it very
> interesting to know that a high threat target tried to do anything which
> attempted to load a module....
>
> -Eric
>
> --
> 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
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.