[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <31255.1480523138@warthog.procyon.org.uk>
Date: Wed, 30 Nov 2016 16:25:38 +0000
From: David Howells <dhowells@...hat.com>
To: One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc: dhowells@...hat.com, minyard@....org, jforbes@...hat.com,
keyrings@...r.kernel.org, matthew.garrett@...ula.com,
linux-security-module@...r.kernel.org, linux-efi@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed
One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk> wrote:
> > I thought that if I'm changing the module_param annotations anyway then it's
> > probably worth bunging in an extra parameter that notes what the parameter
> > modifies (ioport, iomem, etc.) for future reference, even if we don't store
> > it.
>
> With a security hat on the security best practice and long standing
> accepted rule is that you whitelist rather than blacklist, so there ought
> to be a
>
> module_param_safe_array()
> etc
>
> to mark parameters that are safe, not the reverse.
Whilst that may be true, it's a lot more work. Mind you, that said, you can
take the annotations I've made and script the inverse.
> That debate aside I think the patch is exactly what is needed for this,
> and is probably useful for more general hardening as well.
Okay, I've done a preliminary patchset, labelling all the parameters that
appear to be associated with hardware details and pushed them here:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=efi-lock-down
The patch that modifies the module parameter header is labelled:
Lock down module params that specify hardware parameters (eg. ioport)
and all the driver dir lockdown patches follow that.
I still need to do a bit of commenting in that patch and add various
maintainer cc's in the other patches.
David
Powered by blists - more mailing lists