On Sat, Jul 12, 2014 at 12:50:22AM +0930, Jurre van Bergen wrote:
>
> Hi,
>
> By default Debian ships a beautiful kernel with a ton of features to
> work outside of the box. With features I mean modules, whether that's
> support for some really obscure network protocol or bluetooth(random
> example) drivers. While that comes in handy for a lot of things, I feel
> that it's important to reconsider what we would like to ship in Tails as
> the more kernel modules we load and/or ship we also increase the attack
> vector.
>
> So I would like to discuss whether it's a good idea to either remove
> and/or blacklist certain modules for the kernel. What the reasoning
> might be to remove those specific modules from the kernel and whether we
> can come to a consensus of some sorts so we can research on how to
> achieve this.
>
> I feel that actually _removing_ modules is a better way to achieve a
> slightly safer kernel as the code could not be reached anymore. Less
> attack vector!
>
> Blacklisting kernel modules allows you to compile them in, but not use
> them, however, *perhaps* code could still be reached which might be
> exploitable with some crazy exploit.
Yeah, I think removing the modules is much better than blacklisting
them. I'd rather use blacklists to deal with module conflicts then for
security. But if you're using the beautiful buxom Debian kernel then
there is no choice. ;)
> I wonder if SubgraphOS has removed modules as well and what their
> reasoning is for removing them, if any.
Currently we're using the vanilla kernel (3.14.x) from upstream w/ grsec and
aiming towards a minimal set of modules. We're happy to work with
everybody towards getting a minimal grsecularized kernel into Debian.
If/when that happens, we'll make the switch. But I suspect this will
take some time. There seems to be momentum towards grsec kernels but
minimal kernels may be a completely different story.
