[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAH8yC8kf1rCP7SGYpbRjSsLQ6qSYmZyPFF1QNzum8+o4_P2N9A@mail.gmail.com>
Date: Sat, 16 May 2026 13:29:54 -0400
From: Jeffrey Walton <noloader@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Recent Kernel exploits, attack surface reduction,
example IPSEC
On Sat, May 16, 2026 at 9:07 AM Hanno Böck <hanno@...eck.de> wrote:
>
> Multiple of the recent kernel exploits have affected the "esp" Linux
> Kernel module. ESP is, as far as I understand, part of IPSEC, and I
> think it's fair to say that IPSEC is not widely used these days. I
> think this raises some questions about attack surface. I want to note
> that I use IPSEC as an example here, but it likely applies in very
> similar ways to many features that are part of the Linux Kernel and are
> not used in most common setups.
>
> For everyone who builds custom kernels and doesn't use IPSEC, it's
> probably a good idea to disable all IPSEC-related config options, e.g.:
> CONFIG_INET_ESP
> CONFIG_INET6_ESP
> CONFIG_INET_AH
> CONFIG_INET6_AH
>
> I believe IPCOM is also rarely used separately from IPSEC, so consider
> also disabling these:
> CONFIG_INET_IPCOMP
> CONFIG_INET6_IPCOMP
>
> However, there's a broader point here: I think it's common these
> days that Linux distributions install most or all kernel modules by
> default, and loading them happens automatically. Which, in many cases,
> means people are potentially affected by security flaws in features
> they never use.
> "Attack surface reduction" is widely considered to be a good security
> principle, and I wonder if we can do better here.
>
> To pick the example of IPSEC, i wonder if it wouldn't be better to
> have, e.g., a separate "linux-modules-ipsec" package that isn't
> installed by default. People who use and need IPSEC will likely know
> that they need it, and can install it separately.
>
> I'm aware this doesn't come for free, and will add increased
> complexity to kernel packaging. But think about it like this: If we had
> that separation, three of the recent kernel local root exploits would've
> been much less impactful, and wouldn't have affected most systems.
Another option on x86 is to isolate drivers from the kernel, and make
drivers Ring 1 or RIng 2. Leave the kernel to Ring 0, and userland to
Ring 3. A compromised driver cannot get root, and remains isolated in
the system.
It works on x86 because there are two supervisor bits on x86, not one
like on the old DEC Alphas.
Jeff
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
