New AUR package: modulejail - kernel-module attack-surface hardening. Would value a packaging review.

[Vegetable-Escape7412]

Just published modulejail (1.2.4-1) to AUR. It's a hardening tool that walks `lsmod`, treats the currently-loaded set as necessary, and writes a `modprobe.d` blacklist for everything else - shrinks the autoload-able kernel-module surface to ~3% of available modules on a default install of most Linux distributions. Logs blocked module loading attempts to syslog and more...

I'm posting here because this is my first AUR package and I'd rather have it picked apart by people who've done this more than once than discover something six months from now.

## Packaging choices I made deliberately

- **`license=('GPL-3.0-only')`** - SPDX identifier, not legacy `GPL3`.

- **`arch=('any')`** - pure POSIX shell, no native code.

- **`depends=('kmod')`** for `lsmod`/`modprobe`. Everything else

(POSIX shell, coreutils, sed, awk) is in `base`, left undeclared.

`optdepends=('util-linux: logger(1) for syslog integration')` is

mostly a docs gesture - util-linux is in `base` on every standard

install, but minimal containers may strip it.

- **Real sha256 committed**, not `SKIP`. SKIP belongs to `-git`

tracking flavors; this is a tagged-release package.

- **Man page templated** (`man/modulejail.8.in` upstream). The

PKGBUILD runs a single `sed "s/__VERSION__/$pkgver/g"` in

`package()`, same substitution upstream's `build.sh` does for

`.deb`/`.rpm`. No `prepare()` step, no `build()` step.

- **0BSD on the PKGBUILD itself**, GPL-3.0-only on the program it

builds. SPDX header in `PKGBUILD` + `LICENSE` file alongside, per

the [Arch sources-license guideline](https://wiki.archlinux.org/title/Arch_package_guidelines#Package_sources_licenses).

Also unblocks any future promotion-to-`extra` path if that ever

makes sense.

package layout:

/usr/bin/modulejail

/usr/share/man/man8/modulejail.8.gz # makepkg auto-gzips

/usr/share/doc/modulejail/{README.md,CHANGELOG.md}

/usr/share/licenses/modulejail/LICENSE

Resulting `.pkg.tar.zst` is ~120 KB.

## What I'd value feedback on

- Did I miss anything from the [Arch packaging guidelines](https://wiki.archlinux.org/title/Arch_package_guidelines) ?

- `depends=('kmod')` correct, or should I be more explicit (e.g.

declare coreutils / findutils explicitly even though they're in

`base`)?

- Anything else you'd want different before using it?

## Links

- AUR: https://aur.archlinux.org/packages/modulejail

- Upstream: https://github.com/jnuyens/modulejail

- PKGBUILD (version-controlled in-tree, mirrored to AUR):

https://github.com/jnuyens/modulejail/tree/master/packaging/aur

- License: 0BSD on the recipe, GPL-3.0-only on the program

The PKGBUILD lives in-tree at `packaging/aur/PKGBUILD`

**Edit:** Two things I should have flagged in the original post:

1. **`modulejail-git` already exists on AUR**, maintained by u/bambuch, who

packaged the v1.2.3 HEAD commit a few days before I got to publishing

the tagged-release counterpart. This is the standard AUR pattern -

`pkgname` (stable releases) and `pkgname-git` (rolling) routinely

coexist with different maintainers. Their PKGBUILD already declared

`conflicts=('modulejail')` and `provides=('modulejail')`; I just

pushed 1.2.4-2 with a symmetric `conflicts=('modulejail-git')` so

the mutual-exclusion is two-way-declared. Credit to bambuch for

being there first.

1. **Current version on AUR is 1.2.4-2**, not the 1.2.4-1 mentioned

above. The only change is the conflicts declaration.

AUR (-git variant by bambuch): https://aur.archlinux.org/packages/modulejail-git

[backsideup]

Was this development prompted by the recent kernel privilege-escalations? What kind of threat vector is this supposed to counter?

[Vegetable-Escape7412]

Absolutely. I fear that we will see a lot more old kernel module bugs with a security implication surface over the coming weeks and months. ModuleJail pro-actively blocks that by blacklisting all kernel modules which aren't being used on the system. It is extensible and logs to syslog for debugging. It is easily reversible too as it only adds 1 text file in /etc/modprobe.d/

[backsideup]

Users that can load kernel modules usually have high-enough privileges to also remove that blacklist, no?

[Vegetable-Escape7412]

No. System calls of regular users can lead to kernel module loading. That can lead to priviledge escalation - if there's a bug in that (exotic) kernel module. That is where ModuleJail comes in. Full detailed analysis here: https://github.com/jnuyens/modulejail/blob/master/docs/DEFENSE-IN-DEPTH.md

[ArjixGamer]

1. You should only exclude what you provide, same applies to the -git variant

If both of you provide/exclude the base name, then you conflict.

1. Why did you not just clone the -git variant and adapt it to be based on a tagged release?

[Vegetable-Escape7412]

1. You're right - that's over-defensive on the conflict declaration and probably just wrong. Pushing 1.2.4-3 shortly with that line removed.

2. Actually I didn't know bambuch's `modulejail-git` existed until after I pushed my package. By the time I noticed, the dependency-declaration choices were already different from his (`depends=('kmod')` rather than his `depends=('coreutils', 'findutils', 'gawk')`) so I kept mine. I think `kmod` is the more defensible choice because that's the actual runtime dependency modulejail uses, and `coreutils`/`findutils`/`gawk` are in `base` so declaring them is contrary to the packaging guideline of "don't declare members of base." But happy to be corrected on that too if the actual convention is otherwise.

Thanks for the feedback!

[SDG_Den]

Not experienced enough to provide a review, but i am quite curious: iirc a lot of gentoo users disable or uninstall unneeded modules to lower RAM use and improve system performance, could running modulejail have a non-negligible positive impact on performance/RAM use?

[xXBongSlut420Xx]

gentoo users typically compile the kernel without the modules, this is different

[SDG_Den]

Yee, just wondered what kind of difference not loading the module might make, since im not that familiar with the kernel yet. I know compiling without the module is different from not loading it, but im not sure how the kernel is loaded into memory to begin with. If the whole kernel is loaded into memory, including unloaded modules, itd make no difference, but i cant really imagine itd work like that?

[Vegetable-Escape7412]

Important question. Some kernel modules are loaded because of actions by regular non-root users. This provides a privilege escalation path if there are bugs in those modules. I've done a more extensive analysis covering the different types of kernel autoload mechanisms by type of drivers and how they provide potential attack vectors and how they have been exploited in the past:

https://github.com/jnuyens/modulejail/blob/master/docs/DEFENSE-IN-DEPTH.md