Autor: Jacob Appelbaum Data: A: The Tails public development discussion list Assumpte: Re: [Tails-dev] Removing or blacklist kernel modules
On 7/21/14, intrigeri <intrigeri@???> wrote: > 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).
I'm not clear that this is correct but I think we should find a way to
test this theory.
>
> 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).
>
Is that true? Isn't blacklisting them as simple as adding a few lines
to /etc/modprobe.d/blacklist.conf?
> 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.
>
I think there are some modules we will never want (eg: appletalk) and
some people may oneday force load (ax25) for their HAM radio
emergencies.
> 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?
>
That sounds reasonable.
> Now, regardless of the method used to disable these modules, the list
> will have to be maintained. Jurre, I guess you're volunteering,
> right? :)
Is the right place to put things in /etc/modprobe.d/blacklist.conf as I think?
