Bug#860570: linux: compartmentalize modules into separate packages

[Ben Hutchings]

Matt Taggart  wrote:
[...]
> * 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.

Sounds like a BIOS bug or misconfiguration.  In any case I don't think
those devices will be accessible by unprivileged users.

> * 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

I haven't seen a computer shipped with Firewire ports for a good few
years.  If they're present than they're probably on an add-on card that
the user wants to use.

> * 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).

I agree that filesystems are a problem, but not just old ones - they're
all vulnerable to malicious storage devices.  Ideally I want removable
storage to be mounted using FUSE by default, not kernel filesystems. 
Also util-linux ought not to probe any of those obscure filesystems by
default.  Both of these require userland, not kernel, changes.

Network protocols are a big problem, but again this isn't limited to
old ones.  I want to disable auto-loading for them by default, so you
have to opt in to get anything but AF_{INET,INET6,NETLINK,PACKET,UNIX}.

In general, the modules I'm concerned about are those that can be
loaded on-demand for unprivileged users.  The ModAutoRestrict LSM might
provide a way to deal with those: https://lwn.net/Articles/719385/

The old drivers, however, just aren't going to get loaded so I don't
think they're a problem.

> * This would add complication to an already complicated package.
> Would the benefit be worth it?

No, it's bad enough having to categorise things for udebs.

> * 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.

It would be a very large percentage because, you know, hotplug is a
thing.

> Would the benefit be worth it?

No.

Ben.

-- 
Ben Hutchings
The world is coming to an end.  Please log off.


signature.asc
Description: This is a digitally signed message part

Bug#860570: linux: compartmentalize modules into separate packages

[Matt Taggart]

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