Source: linux
Severity: wishlist
(Foreword: I have an idea to make Debian more secure. This is for
post-stretch consideration. This is being filed as wishlist and is
only an idea, if parts of it don't make sense or have errors, I
welcome corrections, discussion, etc. Thanks!)
With the recent advent of syscall fuzzing, generic code analysis tools,
and other security related tools, we are seeing more and more security
vulnerabilities found in kernel subsystems. That they are being found
is a good thing! Previously they existed and only well funded (state
level?) attackers knew about them. Now they are coming out and getting
fixed which is great. But a side effect of this new transparency is
that all attackers learn of them and each system is at risk from more
attackers, security upgrades are becoming more urgent.
When a linux DSA is released, I read the advisory to assess if it
applies to the systems I maintain. Often the problems are in
subsystems that I don't use directly, but there exists a way for
a local unprivileged user to cause that subsystem to load and then
exploit it. A recent example is the DCCP bug (CVE-2017-6074,
DSA-3791-1), almost no one uses DCCP but all had to either upgrade
and reboot or mitigate on all systems.
There are many kernel modules where the number of systems that
truly need them installed is far under 0.01% of the installed
Debian base. It would be nice if we could find a way of avoiding
having those installed.
One way of solving this problem is to preload any modules you
may need at boot via /etc/modules and then
sysctl kernel.modules_disabled=1
to disable further changes. Another option is to blacklist specific
modules and require the user to enable them if they need them.
Those both work, but aren't very user friendly.
After thinking about this, I came up with the following idea:
1) split all in-tree kernel modules into separate package groupings
according to a logical scheme. That might be:
* use classes: base, desktop, laptop, server
* era computer was produced: new, recent, legacy
* statistical frequency modules are used: base, common, niche
(determined with something like popcon for modules, #202675)
* arch related: mips-router, x86-tablet, arm-phone
* some combination of the above
2) for each non-default-installed module package provided, build a
corresponding dummy/stubs package that provides all the same modules
but when loaded all they do is log a message indicating the kernel
attempted to load the module but it wasn't present and what package
the user needs to install to get it. The kernel package would then
depend on: modules-foo-version-stub | modules-foo-version, the stub
package gets pulled in by default. (for default-installed module
packages the kernel could just depend directly). (I am hoping this
is technically possible, IANAKernelDeveloper)
3) at install time, d-i could detect if any non-default module packages
were needed and install the non-stub version, future upgrades would
continue to work.
4) users that know they need the additional packages could install
them (setup their configuration management system to install them,
create metapackages that depend on them, etc)
Some things I've thought of:
* I'd probaby resist the urge to create a lot of these package and
initially aim to make the default modules something that works for
99.99% of systems and still manages to split off tons of modules to
a second package.
* I still see the floppy and parallel port module load on many of my
systems because the superio/southbridge/etc happened to have that
device in case the system designer wanted to use it. It's time for
this stuff to go away.
* firewire is a particular risk, it could be argued that even if the
hardware _is_ present, the user should have to opt-in to enabling it
* Debian is cool because it still runs great on old systems, we don't
want to prevent that, but it would be nice to leave the old baggage
in a separate package (ISA, old network standards, old filesystems,
anything that stopped being produced 20+ years ago).
* This would add complication to an already complicated package.
Would the benefit be worth it?
* This might be confusing for the very, very, small percentage of
users where things didn't "just work" with d-i doing the right thing.
Would the benefit be worth it?
If you feel this idea has merit, I think the first step would be to
gather some module usage statistics in order to see if there are clear
patterns. Let me know if I can help.
Thanks,
--
Matt Taggart
tagg...@debian.org
