Re: Resurrecting the Securing Debian Manual

Hello Noah,

very good idea. Things have changed a lot in the past years, and many guide=
s=20
are obsolete. Tips what to include / check / rewrite:

iptables -> nftables
sysV-init -> systemd
completely new: apparmor, SELinux

Also I have recently hit this thing, which might be for general considerati=
on.
Generic security guides tell users, that there should be no executables in=
=20
/var and especially in /tmp filesystems. So as a security measure, these sh=
ould=20
be mounted noexec, nosiud, nodev, to prevent an intruder that gained=20
unprivileged user access to put a malicious file in /tmp (write for everyon=
e)=20
and execute it. Alas Debian by default relies on /var/lib/dpkg/ being=20
executable for various pre/post-inst/rm scripts, and recently libc update=20
required even /tmp to be executable. What a pity that at least /tmp cannot =
be=20
noexec.

Also a section about web hosting privilegies might be nice. Old suggestions=
=20
were typically that the owner of the files should be the FTP user, while th=
e=20
web is running as www-data. So the web (php) itself could not modify itself=
=2E=20
This is no longer practical, due to various CMS like wordpress that do need=
 to=20
overwrite itself on many many places. So a suexec is much better option, wi=
th=20
each web running as different user.=20

Also there should be a big warning against developer, who suggest that if=20
there are any problems with their program, the first thing you should disab=
le=20
SELinux / apparmor / firewall or setting some file chmod 777, instead of te=
lling=20
exactly where the program needs access, so it can be allowed.

Yeah and a wiki sounds good.=20
I wish you good luck.

Vladki

Dne pond=C4=9Bl=C3=AD 9. =C4=8Dervna 2025 18:20:36 CEST, Noah Meyerhans nap=
sal(a):
> Hi all.  The Securing Debian Manual (the harden-doc package) is
> woefully out of date and doesn't provide accurate guidance for
> operating modern software in the current threat landscape.  I'd like
> to begin the task of updating it to reflect current best practice and
> to document current tools and technologies.
>=20
> Most basically, I wonder if folks think this is a worthy idea.  The
> landscape has changed significantly since harden-doc was first
> written.  Default configurations don't require as much hardening, and
> there are lots more available resources.  Maybe harden-doc has
> stagnated because there's no real need for it?
>=20
> Assuming we do revive the doc, here are some ideas of what I'd like to
> do with the document.  I'd like to also get feedback, ideas, and
> contributions from others interested in the topic.
>=20
> 1. More background information on principles such as:
>    a. Threat modeling
>    b. Defense in depth
>    c. Least privilege
> 2. Modern server deployment practices, such as:
>    a. Sandboxing (with systemd, containers, etc)
>    b. Image-based deployments, including cloud
>    c. Update deployment strategies for large fleets
> 3. Data privacy:
>    a. VPNs, wireguard, etc
>    b. Disk encryption
> 4. Workstation best practices, including:
>    a. Ssh key generation and handling
>    b. Basic browser hygine
>    c. Password managers and other password hygine
>=20
> My inclination is to primarily focus on general principles rather than
> try to document specific settings in specific packages, as in the
> current document's Chapter 5 ("Securing services running on your
> system").  It'll make sense to document some approaches to safe usage of
> the most common software (firefox, openssh, etc), but I don't believe
> that it's feasible to provide useful advice for a meaningful subset of
> Debian packages.
>=20
> Should we maybe consider maintaining this document on wiki.debian.org,
> rather than being a centrally maintained document? The wiki may scale
> better to multiple contributors, leading to better content and more
> active maintenance.
>=20
> If you've got ideas for other topics, I'd love to hear them.
>=20
> noah