Re: [Tails-dev] Removing or blacklist kernel modules

Hi,

Jurre van Bergen wrote (11 Jul 2014 15:20:22 GMT) :
> 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.

Fine with me, as there seems to be energy willing to be put into
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.

My understanding is that to have a blacklisted module loaded, assuming
one isn't root yet (otherwise, we've lost already), one needs to find
a way to exploit a bug in modprobe so that it ignores at least part of
its configured blacklist. And then, one has to have the module loaded
(not so hard, in many cases) and exploit it. So, my take on it is that
blacklisting should be Good Enough™, at least for a first iteration
(see below).

However, removing modules altogether is no more work than blacklisting
them: we can do it either via chroot_local-hooks (and then, regenerate
the initrd's), or with the exclude file passed to mksquashfs (but in
this case, if any of the blacklisted module is in the initrd's, then
we're not really removing it; so likely a hook is better).

The only downside I can see to removing the modules (as opposed to
blacklisting them) is that it entirely prevents users from
force-loading a module they need. Which will probably matter in the
initial stages of preparing, and fine-tuning, the list of modules we
don't want: hardening is great, but regressions are bad.

So, I would suggest to blacklist (and document how to bypass the
blacklist) as an initial step, and once we're happy with the
blacklist, and haven't seen serious complains about it for a few
releases, then we can remove modules for real. Makes sense?

Now, regardless of the method used to disable these modules, the list
will have to be maintained. Jurre, I guess you're volunteering,
right? :)

Cheers,
--
intrigeri