To build a Debian jail for INN2 I must know every single file, device
file, and directory to which INN needs access so that I may whitelist
them and blacklist all others. The end goal is to build a restricted
sandbox that locks out all other directories and binaries so that remote
compromise is rendered nigh impossible--then package it up with easy
options to operate over a Tor hidden service. The end user/operator
would just drop down the jail file and execute it then everything will
be up and running, with a Tor hidden service, systemd profiles and
services included.

I am willing and actually happy to do all the work of creating the jail
and a fool-proof configuration so Debian users can just drop the blob
and run with a single command, with automatic peering and configuration.
But I do not want to spend an eternity examining source code and running
execution traces to narrow down all the requisite resource access.
Locking out just one unnecessary resource could create a real PITA at
some unexpected time.

Running a execution profiling tool will not be very effective since
every possible feature of INN would need to be actually invoked to get a
full trace profile to every binary and directory need by INN. This just
is not feasible. It would be far more work than the source code for the
jail. The 'ldd' command is helpful but cannot be relied upon to reveal a
complete stack of requisite resources. It is only a dependency link
identification and not a complete call or subprocess identification.
Firejail and bubblewrap traces suffer the same shortcomings.

Does anyone have data on the binaries invoked by INN and the folders,
files, and devices, that must be accessible to INN and whatever scripts
and binaries it calls? This is for Debian server, Buster to current.

--

Borg

Borg <resistance@is.futile> writes:

> To build a Debian jail for INN2 I must know every single file, device
> file, and directory to which INN needs access so that I may whitelist
> them and blacklist all others. The end goal is to build a restricted
> sandbox that locks out all other directories and binaries so that remote
> compromise is rendered nigh impossible--then package it up with easy
> options to operate over a Tor hidden service. The end user/operator
> would just drop down the jail file and execute it then everything will
> be up and running, with a Tor hidden service, systemd profiles and
> services included.

This is unfortunately going to be really hard because INN is rather
sprawling, particularly if you include all of the optional configurations
and extra supported features.

Why not just make a container? I think a container based on a Debian
stable image with the inn2 package installed would accomplish roughly the
same thing. You'd have extra binaries in the container that INN
technically doesn't need, but I highly doubt that would introduce any new
security risks over all the stuff INN does need.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.