Re: Resurrecting the Securing Debian Manual

Vladislav Kurz <[email protected]>
Newsgroups gmane.linux.debian.devel.documentation,gmane.linux.debian.devel.security
Message-ID <2208055.zkTO2fcNTg@hex>
Hello Noah,

very good idea. Things have changed a lot in the past years, and many guides 
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 consideration.
Generic security guides tell users, that there should be no executables in 
/var and especially in /tmp filesystems. So as a security measure, these should 
be mounted noexec, nosiud, nodev, to prevent an intruder that gained 
unprivileged user access to put a malicious file in /tmp (write for everyone) 
and execute it. Alas Debian by default relies on /var/lib/dpkg/ being 
executable for various pre/post-inst/rm scripts, and recently libc update 
required even /tmp to be executable. What a pity that at least /tmp cannot be 
noexec.

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

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

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

Vladki

Dne pondělí 9. června 2025 18:20:36 CEST, Noah Meyerhans napsal(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.
> 
> 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?
> 
> 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.
> 
> 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
> 
> 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.
> 
> 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.
> 
> If you've got ideas for other topics, I'd love to hear them.
> 
> noah
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.