XPost: linux.debian.security

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.security

Hi Noah,

On Mon, Jun 09, 2025 at 12:20:36PM -0400, Noah Meyerhans wrote:

Most basically, I wonder if folks think this is a worthy idea.

I do think so! Thanks for your initiative, I do hope it will fly!

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.

sounds sound! I also liked your mock/draft table of contents!

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.

https://wiki.debian.org/DebianEdu/Documentation/Trixie (or Bookworm or many earlier relases) is an example where this is being done, using translations via .po files (nowadays mostly translated via weblate) and with a src:debian-edu-doc
package building several binary packages mostly for different translations, shipping
txt, html, pdf and epub versions of that manual.


--
cheers,
Holger

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

"A developed country is not a place where the poor have cars. It's where the rich use public transportation." (quote attributed to several people)

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmhHDz4ACgkQCRq4Vgaa qhyEGxAAte/i4a9v32IYnFc9yDC+xq5W/91bVIh4wadn4Qg4eAp+Lvxg/IV03lLo NGbF+PA1fwi1xF5dk3jxhJvwJRuRdjDZ8zrpm8HwntB4oeW2Pe9ofyXqyA9JrwWo AAvL4V3f3VQg2JUao9qvEbI0tLSqabL/vWuf1zhm3gWCrLQRmM1E5UMPwXRsvbcO DtrXvGQuFvF/R/AU/9RcskSuS9v/QgScbhrswRCeoHcXzU2VgjJs0rphSdsdeqJC mBozovOX+/lI2tKTljgtIfKJVBbcbywPKSIhrQl0PluDxXzXJPEe0TV0qLip3jTf ooaIeBrMyrfxhPOSz0nWRB8ZPy6ZOFQy99uDlHw4wpKDSMiOBcm+z1y9T32md9f8 KERf0VPWbhi3Oo19W56WT+eEy3fKfIdHtNeKCkZW3GIzgUwlk5aVau9URBureM6y Ll/zGxPwznK6mrqKIAkVTSArl/eRIxXsVPMQq8yW4F26pnb2d6KaXj6GeMJvssua ok5oFRg4olZJkCfx211EgWbOYEar0fo

XPost: linux.debian.security

Hi Noah,

Most basically, I wonder if folks think this is a worthy idea.

Another long-term Debian user here who normally doesn't post to this
list. I am very much in favour of this idea. There is a lot of
information out there on this topic, but a lot of nonsense and flame
wars which discourage those who cannot orient themselves in the
terrain. Many people who might be inclined to trust Debian - knowing
the philosophy and culture of the project - might not know who to
otherwise trust in this field. It appears esoteric, and since the people
who seem to know seem to be fighting among themselves, many people
settle for apathy / do nothing at all.

My inclination is to primarily focus on general principles

Yes! And the outline suggested seems to me to be ideal. More or less in
that order ie. starting with threat modelling.

If you've got ideas for other topics, I'd love to hear them.

I wonder if Lynis and other auditing tools might warrant mentioning.
Fairly low-down if so.

Thanks,

Rob

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.security

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.security

SSBjZXJ0YWlubHkgdGhpbmsgaGF2aW5nIGFuIHVwIHRvIGRhdGUgIlNlY3VyaW5nIERlYmlhbiIg ZG9jdW1lbnQgaXMgYSB3b3J0aHkgZW5kZWF2b3IsIGVzcGVjaWFsbHkgZm9yIHNlcnZlciBtYW5h Z2VtZW50LiBJJ3ZlIGJlZW4gdXNpbmcgRGViaWFuIHRvIGhvc3QgbXkgZmFtaWx5IGhvbWUgc2Vy dmVyIGZvciB5ZWFycyBub3cgYW5kIGhhdmUgbGVhcm5lZCBhIGxvdCBpbiB0aGF0IHRpbWUsIHNv IEkgYWN0dWFsbHkgc3RhcnRlZCBteSBvd24gdGFrZSBvbiBhIHJlLXdyaXRlIGEgd2hpbGUgYmFj ayB0aGF0IEkgd2FzIGNvbnNpZGVyaW5nIHByb3Bvc2luZywgYnV0IGZvdW5kIGl0IHdhcyBhIG11 Y2ggYmlnZ2VyIHRhc2sgdGhhbiBJIHdhcyBwcmVwYXJlZCB0byB1bmRlcnRha2UgYWxvbmUuIEJl dHdlZW4gbXkgaW5leHBlcmllbmNlIGluIHByb2R1Y2luZyBxdWFsaXR5IGRvY3VtZW50YXRpb24g KEkgdGVuZCB0byBnZXQgcXVpdGUgd29yZHkpIHRvIG15IGxhY2sgb2YgZXhwZXJ0IGtub3dsZWRn ZSBpbiBhbGwgdGhlIHZhcmlvdXMgdG9waWNzIHRoYXQgbWlnaHQgbmVlZCB0byBiZSBjb3ZlcmVk IEkga2luZGEgZ2F2ZSB1cCBvbiBpdC4gSSdsbCBrZWVwIGl0IGFzIG15IG93biBzb3J0IG9mIHJl ZmVyZW5jZSBwb2ludCwgYnV0IEknbSBub3Qgc3VyZSBpdCdzIHNvbWV0aGluZyBJIHdvdWxkIHdh bnQgdG8gZGlzdHJpYnV0ZSB0byB0aGUgd2lkZXIgY29tbXVuaXR5LgoKSWYgeW91LCBvciBhbnli b2R5IGVsc2UgZm9yIHRoYXQgbWF0dGVyLCB3b3VsZCBsaWtlIHRvIGxvb2sgYXQgd2hhdCBJIGdv dCB3cml0dGVuIGJlZm9yZSBJIHF1aXQgb24gaXQsIEkndmUgc2hhcmVkIGl0IGZyb20gbXkgcGVy c29uYWwgTmV4dGNsb3VkIGhlcmU6CgpMaW5rOiBodHRwczovL2Nsb3VkLm1hcmN1c2FuZGFzaC5u ZXQvaW5kZXgucGhwL3MvYVk5VHcyZ0hEYWd3c2JvCgotLQoKfn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fgpNYXJjdXMgRGVhbiBBZGFtcwoKU2ln bmFsOiBbZ2Vyb3dlbi44MV0oaHR0cHM6Ly9zaWduYWwubWUvI2V1L3c2eG9NWnA2WVRKVURLNVRZ T21lVjUwd1B0bDZUZ1hEMkY0aFRlZEFMOUlPXzBDVWVYOUZwcXBiRU5Sc0g5SlEpCgpNYXN0b2Rv bjogW2dlcm93ZW5AbWFzdG9kb24uc29jaWFsXShodHRwczovL21hc3RvZG9uLnNvY2lhbC9AZ2Vy b3dlbikKCldlYnNpdGU6IGh0dHBzOi8vbWFyY3VzYWRhbXMubWUKCiJDaXZpbGl6YXRpb24gaXMg dGhlIGxpbWl0bGVzcyBtdWx0aXBsaWNhdGlvbgpvZiB1bm5lY2Vzc2FyeSBuZWNlc3NpdGllcy4i Ci0tIE1hcmsgVHdhaW4KCk9uIE1vbiwgMjAyNS0wNi0wOSBhdCAxMjoyMCAtMDQwMCwgTm9haCBN ZXllcmhhbnMgLSBub2FobSBhdCBkZWJpYW4ub3JnIHdyb3RlOgoKPiBIaSBhbGwuIFRoZSBTZWN1 cmluZyBEZWJpYW4gTWFudWFsICh0aGUgaGFyZGVuLWRvYyBwYWNrYWdlKSBpcwo+IHdvZWZ1bGx5 IG91dCBvZiBkYXRlIGFuZCBkb2Vzbid0IHByb3ZpZGUgYWNjdXJhdGUgZ3VpZGFuY2UgZm9yCj4g b3BlcmF0aW5nIG1vZGVybiBzb2Z0d2FyZSBpbiB0aGUgY3VycmVudCB0aHJlYXQgbGFuZHNjYXBl LiBJJ2QgbGlrZQo+IHRvIGJlZ2luIHRoZSB0YXNrIG9mIHVwZGF0aW5nIGl0IHRvIHJlZmxlY3Qg Y3VycmVudCBiZXN0IHByYWN0aWNlIGFuZAo+IHRvIGRvY3VtZW50IGN1cnJlbnQgdG9vbHMgYW5k IHRlY2hub2xvZ2llcy4KPgo+IE1vc3QgYmFzaWNhbGx5LCBJIHdvbmRlciBpZiBmb2xrcyB0aGlu ayB0aGlzIGlzIGEgd29ydGh5IGlkZWEuIFRoZQo+IGxhbmRzY2FwZSBoYXMgY2hhbmdlZCBzaWdu aWZpY2FudGx5IHNpbmNlIGhhcmRlbi1kb2Mgd2FzIGZpcnN0Cj4gd3JpdHRlbi4gRGVmYXVsdCBj b25maWd1cmF0aW9ucyBkb24ndCByZXF1aXJlIGFzIG11Y2ggaGFyZGVuaW5nLCBhbmQKPiB0aGVy ZSBhcmUgbG90cyBtb3JlIGF2YWlsYWJsZSByZXNvdXJjZXMuIE1heWJlIGhhcmRlbi1kb2MgaGFz Cj4gc3RhZ25hdGVkIGJlY2F1c2UgdGhlcmUncyBubyByZWFsIG5lZWQgZm9yIGl0Pwo+Cj4gQXNz dW1pbmcgd2UgZG8gcmV2aXZlIHRoZSBkb2MsIGhlcmUgYXJlIHNvbWUgaWRlYXMgb2Ygd2hhdCBJ J2QgbGlrZSB0bwo+IGRvIHdpdGggdGhlIGRvY3VtZW50LiBJJ2QgbGlrZSB0byBhbHNvIGdldCBm ZWVkYmFjaywgaWRlYXMsIGFuZAo+IGNvbnRyaWJ1dGlvbnMgZnJvbSBvdGhlcnMgaW50ZXJlc3Rl ZCBpbiB0aGUgdG9waWMuCj4KPiAxLiBNb3JlIGJhY2tncm91bmQgaW5mb3JtYXRpb24gb24gcHJp bmNpcGxlcyBzdWNoIGFzOgo+IGEuIFRocmVhdCBtb2RlbGluZwo+IGIuIERlZmVuc2UgaW4gZGVw dGgKPiBjLiBMZWFzdCBwcml2aWxlZ2UKPiAyLiBNb2Rlcm4gc2VydmVyIGRlcGxveW1lbnQgcHJh Y3RpY2VzLCBzdWNoIGFzOgo+IGEuIFNhbmRib3hpbmcgKHdpdGggc3lzdGVtZCwgY29udGFpbmVy cywgZXRjKQo+IGIuIEltYWdlLWJhc2VkIGRlcGxveW1lbnRzLCBpbmNsdWRpbmcgY2xvdWQKPiBj LiBVcGRhdGUgZGVwbG95bWVudCBzdHJhdGVnaWVzIGZvciBsYXJnZSBmbGVldHMKPiAzLiBEYXRh IHByaXZhY3k6Cj4gYS4gVlBOcywgd2lyZWd1YXJkLCBldGMKPiBiLiBEaXNrIGVuY3J5cHRpb24K PiA0LiBXb3Jrc3RhdGlvbiBiZXN0IHByYWN0aWNlcywgaW5jbHVkaW5nOgo+IGEuIFNzaCBrZXkg Z2VuZXJhdGlvbiBhbmQgaGFuZGxpbmcKPiBiLiBCYXNpYyBicm93c2VyIGh5Z2luZQo+IGMuIFBh c3N3b3JkIG1hbmFnZXJzIGFuZCBvdGhlciBwYXNzd29yZCBoeWdpbmUKPgo+IE15IGluY2xpbmF0 aW9uIGlzIHRvIHByaW1hcmlseSBmb2N1cyBvbiBnZW5lcmFsIHByaW5jaXBsZXMgcmF0aGVyIHRo YW4KPiB0cnkgdG8gZG9jdW1lbnQgc3BlY2lmaWMgc2V0dGluZ3MgaW4gc3BlY2lmaWMgcGFja2Fn ZXMsIGFzIGluIHRoZQo+IGN1cnJlbnQgZG9jdW1lbnQncyBDaGFwdGVyIDUgKCJTZWN1cmluZyBz ZXJ2aWNlcyBydW5uaW5nIG9uIHlvdXIKPiBzeXN0ZW0iKS4gSXQnbGwgbWFrZSBzZW5zZSB0byBk b2N1bWVudCBzb21lIGFwcHJvYWNoZXMgdG8gc2FmZSB1c2FnZSBvZgo+IHRoZSBtb3N0IGNvbW1v biBzb2Z0d2FyZSAoZmlyZWZveCwgb3BlbnNzaCwgZXRjKSwgYnV0IEkgZG9uJ3QgYmVsaWV2ZQo+ IHRoYXQgaXQncyBmZWFzaWJsZSB0byBwcm92aWRlIHVzZWZ1bCBhZHZpY2UgZm9yIGEgbWVhbmlu Z2Z1bCBzdWJzZXQgb2YKPiBEZWJpYW4gcGFja2FnZXMuCj4KPiBTaG91bGQgd2UgbWF5YmUgY29u c2lkZXIgbWFpbnRhaW5pbmcgdGhpcyBkb2N1bWVudCBvbiB3aWtpLmRlYmlhbi5vcmcsCj4gcmF0 aGVyIHRoYW4gYmVpbmcgYSBjZW50cmFsbHkgbWFpbnRhaW5lZCBkb2N1bWVudD8gVGhlIHdpa2kg bWF5IHNjYWxlCj4gYmV0dGVyIHRvIG11bHRpcGxlIGNvbnRyaWJ1dG9ycywgbGVhZGluZyB0byBi ZXR0ZXIgY29udGVudCBhbmQgbW9yZQo+IGFjdGl2ZSBtYWludGVuYW5jZS4KPgo+IElmIHlvdSd2 ZSBnb3QgaWRlYXMgZm9yIG90aGVyIHRvcGljcywgSSdkIGxvdmUgdG8gaGVhciB0aGVtLgo+Cj4g bm9haA== PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5PjxkaXY+SSBjZXJ0YWlubHkgdGhpbmsgaGF2aW5nIGFu IHVwIHRvIGRhdGUgIlNlY3VyaW5nIERlYmlhbiIgZG9jdW1lbnQgaXMgYSB3b3J0aHkgZW5kZWF2 b3IsIGVzcGVjaWFsbHkgZm9yIHNlcnZlciBtYW5hZ2VtZW50LiAmbmJzcDtJJ3ZlIGJlZW4gdXNp bmcgRGViaWFuIHRvIGhvc3QgbXkgZmFtaWx5IGhvbWUgc2VydmVyIGZvciB5ZWFycyBub3cgYW5k IGhhdmUgbGVhcm5lZCBhIGxvdCBpbiB0aGF0IHRpbWUsIHNvIEkgYWN0dWFsbHkgc3RhcnRlZCBt eSBvd24gdGFrZSBvbiBhIHJlLXdyaXRlIGEgd2hpbGUgYmFjayB0aGF0IEkgd2FzIGNvbnNpZGVy aW5nIHByb3Bvc2luZywgYnV0IGZvdW5kIGl0IHdhcyBhIG11Y2ggYmlnZ2VyIHRhc2sgdGhhbiBJ IHdhcyBwcmVwYXJlZCB0byB1bmRlcnRha2UgYWxvbmUuICZuYnNwO0JldHdlZW4gbXkgaW5leHBl cmllbmNlIGluIHByb2R1Y2luZyBxdWFsaXR5IGRvY3VtZW50YXRpb24gKEkgdGVuZCB0byBnZXQg cXVpdGUgd29yZHkpIHRvIG15IGxhY2sgb2YgZXhwZXJ0IGtub3dsZWRnZSBpbiBhbGwgdGhlIHZh cmlvdXMgdG9waWNzIHRoYXQgbWlnaHQgbmVlZCB0byBiZSBjb3ZlcmVkIEkga2luZGEgZ2F2ZSB1 cCBvbiBpdC4gJm5ic3A7SSdsbCBrZWVwIGl0IGFzIG15IG93biBzb3J0IG9mIHJlZmVyZW5jZSBw b2ludCwgYnV0IEknbSBub3Qgc3VyZSBpdCdzIHNvbWV0aGluZyBJIHdvdWxkIHdhbnQgdG8gZGlz dHJpYnV0ZSB0byB0aGUgd2lkZXIgY29tbXVuaXR5LjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+ SWYgeW91LCBvciBhbnlib2R5IGVsc2UgZm9yIHRoYXQgbWF0dGVyLCB3b3VsZCBsaWtlIHRvIGxv b2sgYXQgd2hhdCBJIGdvdCB3cml0dGVuIGJlZm9yZSBJIHF1aXQgb24gaXQsIEkndmUgc2hhcmVk IGl0IGZyb20gbXkgcGVyc29uYWwgTmV4dGNsb3VkIGhlcmU6PC9kaXY+PGRpdj48YnI+PC9kaXY+ PGRpdj5MaW5rOiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vY2xvdWQubWFyY3VzYW5kYXNoLm5ldC9p bmRleC5waHAvcy9hWTlUdzJnSERhZ3dzYm8iPmh0dHBzOi8vY2xvdWQubWFyY3VzYW5kYXNoLm5l dC9pbmRleC5waHAvcy9hWTlUdzJnSERhZ3dzYm88L2E+PC9kaXY+PGRpdj48c3Bhbj48cHJlPi0t IDxicj48L3ByZT48ZGl2Pn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn48L2Rpdj48ZGl2Pk1hcmN1cyBEZWFuIEFkYW1zPC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdj5TaWduYWw6Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9zaWduYWwubWUvI2V1L3c2 eG9NWnA2WVRKVURLNVRZT21lVjUwd1B0bDZUZ1hEMkY0aFRlZEFMOUlPXzBDVWVYOUZwcXBiRU5S c0g5SlEiPmdlcm93ZW4uODE8L2E+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5NYXN0b2Rvbjom bmJzcDs8YSBocmVmPSJodHRwczovL21hc3RvZG9uLnNvY2lhbC9AZ2Vyb3dlbiI+Z2Vyb3dlbkBt YXN0b2Rvbi5zb2NpYWw8L2E+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5XZWJzaXRlOiZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vbWFyY3VzYWRhbXMubWUiPmh0dHBzOi8vbWFyY3VzYWRhbXMubWU8 L2E+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48aT4iQ2l2aWxpemF0aW9uIGlzIHRoZSBsaW1p dGxlc3MgbXVsdGlwbGljYXRpb248L2k+PC9kaXY+PGRpdj48aT5vZiB1bm5lY2Vzc2FyeSBuZWNl c3NpdGllcy4iPC9pPjwvZGl2PjxkaXY+PGk+LS0gTWFyayBUd2FpbjwvaT48L2Rpdj48L3NwYW4+ PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5PbiBNb24sIDIwMjUtMDYtMDkgYXQgMTI6MjAgLTA0 MDAsIE5vYWggTWV5ZXJoYW5zIC0gbm9haG0gYXQgZGViaWFuLm9yZyB3cm90ZTo8L2Rpdj48Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7IGJvcmRlci1sZWZ0 OjJweCAjNzI5ZmNmIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPjxkaXY+SGkgYWxsLiZuYnNwOyBU aGUgU2VjdXJpbmcgRGViaWFuIE1hbnVhbCAodGhlIGhhcmRlbi1kb2MgcGFja2FnZSkgaXM8YnI+ PC9kaXY+PGRpdj53b2VmdWxseSBvdXQgb2YgZGF0ZSBhbmQgZG9lc24ndCBwcm92aWRlIGFjY3Vy YXRlIGd1aWRhbmNlIGZvcjxicj48L2Rpdj48ZGl2Pm9wZXJhdGluZyBtb2Rlcm4gc29mdHdhcmUg aW4gdGhlIGN1cnJlbnQgdGhyZWF0IGxhbmRzY2FwZS4mbmJzcDsgSSdkIGxpa2U8YnI+PC9kaXY+ PGRpdj50byBiZWdpbiB0aGUgdGFzayBvZiB1cGRhdGluZyBpdCB0byByZWZsZWN0IGN1cnJlbnQg YmVzdCBwcmFjdGljZSBhbmQ8YnI+PC9kaXY+PGRpdj50byBkb2N1bWVudCBjdXJyZW50IHRvb2xz IGFuZCB0ZWNobm9sb2dpZXMuPGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+TW9zdCBiYXNp Y2FsbHksIEkgd29uZGVyIGlmIGZvbGtzIHRoaW5rIHRoaXMgaXMgYSB3b3J0aHkgaWRlYS4mbmJz cDsgVGhlPGJyPjwvZGl2PjxkaXY+bGFuZHNjYXBlIGhhcyBjaGFuZ2VkIHNpZ25pZmljYW50bHkg c2luY2UgaGFyZGVuLWRvYyB3YXMgZmlyc3Q8YnI+PC9kaXY+PGRpdj53cml0dGVuLiZuYnNwOyBE ZWZhdWx0IGNvbmZpZ3VyYXRpb25zIGRvbid0IHJlcXVpcmUgYXMgbXVjaCBoYXJkZW5pbmcsIGFu ZDxicj48L2Rpdj48ZGl2PnRoZXJlIGFyZSBsb3RzIG1vcmUgYXZhaWxhYmxlIHJlc291cmNlcy4m bmJzcDsgTWF5YmUgaGFyZGVuLWRvYyBoYXM8YnI+PC9kaXY+PGRpdj5zdGFnbmF0ZWQgYmVjYXVz ZSB0aGVyZSdzIG5vIHJlYWwgbmVlZCBmb3IgaXQ/PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2Pjxk aXY+QXNzdW1pbmcgd2UgZG8gcmV2aXZlIHRoZSBkb2MsIGhlcmUgYXJlIHNvbWUgaWRlYXMgb2Yg d2hhdCBJJ2QgbGlrZSB0bzxicj48L2Rpdj48ZGl2PmRvIHdpdGggdGhlIGRvY3VtZW50LiZuYnNw OyBJJ2QgbGlrZSB0byBhbHNvIGdldCBmZWVkYmFjaywgaWRlYXMsIGFuZDxicj48L2Rpdj48ZGl2 PmNvbnRyaWJ1dGlvbnMgZnJvbSBvdGhlcnMgaW50ZXJlc3RlZCBpbiB0aGUgdG9waWMuPGJyPjwv ZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+MS4gTW9yZSBiYWNrZ3JvdW5kIGluZm9ybWF0aW9uIG9u IHByaW5jaXBsZXMgc3VjaCBhczo8YnI+PC9kaXY+PGRpdj4mbmJzcDsmbmJzcDsgYS4gVGhyZWF0 IG1vZGVsaW5nPGJyPjwvZGl2PjxkaXY+Jm5ic3A7Jm5ic3A7IGIuIERlZmVuc2UgaW4gZGVwdGg8 YnI+PC9kaXY+PGRpdj4mbmJzcDsmbmJzcDsgYy4gTGVhc3QgcHJpdmlsZWdlPGJyPjwvZGl2Pjxk aXY+Mi4gTW9kZXJuIHNlcnZlciBkZXBsb3ltZW50IHByYWN0aWNlcywgc3VjaCBhczo8YnI+PC9k aXY+PGRpdj4mbmJzcDsmbmJzcDsgYS4gU2FuZGJveGluZyAod2l0aCBzeXN0ZW1kLCBjb250YWlu ZXJzLCBldGMpPGJyPjwvZGl2PjxkaXY+Jm5ic3A7Jm5ic3A7IGIuIEltYWdlLWJhc2VkIGRlcGxv eW1lbnRzLCBpbmNsdWRpbmcgY2xvdWQ8YnI+PC9kaXY+PGRpdj4mbmJzcDsmbmJzcDsgYy4gVXBk YXRlIGRlcGxveW1lbnQgc3RyYXRlZ2llcyBmb3IgbGFyZ2UgZmxlZXRzPGJyPjwvZGl2PjxkaXY+ My4gRGF0YSBwcml2YWN5Ojxicj48L2Rpdj48ZGl2PiZuYnNwOyZuYnNwOyBhLiBWUE5zLCB3aXJl Z3VhcmQsIGV0Yzxicj48L2Rpdj48ZGl2PiZuYnNwOyZuYnNwOyBiLiBEaXNrIGVuY3J5cHRpb248 YnI+PC9kaXY+PGRpdj40LiBXb3Jrc3RhdGlvbiBiZXN0IHByYWN0aWNlcywgaW5jbHVkaW5nOjxi cj48L2Rpdj48ZGl2PiZuYnNwOyZuYnNwOyBhLiBTc2gga2V5IGdlbmVyYXRpb24gYW5kIGhhbmRs aW5nPGJyPjwvZGl2PjxkaXY+Jm5ic3A7Jm5ic3A7IGIuIEJhc2ljIGJyb3dzZXIgaHlnaW5lPGJy PjwvZGl2PjxkaXY+Jm5ic3A7Jm5ic3A7IGMuIFBhc3N3b3JkIG1hbmFnZXJzIGFuZCBvdGhlciBw YXNzd29yZCBoeWdpbmU8YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5NeSBpbmNsaW5hdGlv biBpcyB0byBwcmltYXJpbHkgZm9jdXMgb24gZ2VuZXJhbCBwcmluY2lwbGVzIHJhdGhlciB0aGFu PGJyPjwvZGl2PjxkaXY+dHJ5IHRvIGRvY3VtZW50IHNwZWNpZmljIHNldHRpbmdzIGluIHNwZWNp ZmljIHBhY2thZ2VzLCBhcyBpbiB0aGU8YnI+PC9kaXY+PGRpdj5jdXJyZW50IGRvY3VtZW50J3Mg Q2hhcHRlciA1ICgiU2VjdXJpbmcgc2VydmljZXMgcnVubmluZyBvbiB5b3VyPGJyPjwvZGl2Pjxk aXY+c3lzdGVtIikuJm5ic3A7IEl0J2xsIG1ha2Ugc2Vuc2UgdG8gZG9jdW1lbnQgc29tZSBhcHBy b2FjaGVzIHRvIHNhZmUgdXNhZ2Ugb2Y8YnI+PC9kaXY+PGRpdj50aGUgbW9zdCBjb21tb24gc29m dHdhcmUgKGZpcmVmb3gsIG9wZW5zc2gsIGV0YyksIGJ1dCBJIGRvbid0IGJlbGlldmU8YnI+PC9k aXY+PGRpdj50aGF0IGl0J3MgZmVhc2libGUgdG8gcHJvdmlkZSB1c2VmdWwgYWR2aWNlIGZvciBh IG1lYW5pbmdmdWwgc3Vic2V0IG9mPGJyPjwvZGl2PjxkaXY+RGViaWFuIHBhY2thZ2VzLjxicj48 L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlNob3VsZCB3ZSBtYXliZSBjb25zaWRlciBtYWludGFp bmluZyB0aGlzIGRvY3VtZW50IG9uIHdpa2kuZGViaWFuLm9yZyw8YnI+PC9kaXY+PGRpdj5yYXRo ZXIgdGhhbiBiZWluZyBhIGNlbnRyYWxseSBtYWludGFpbmVkIGRvY3VtZW50PyBUaGUgd2lraSBt YXkgc2NhbGU8YnI+PC9kaXY+PGRpdj5iZXR0ZXIgdG8gbXVsdGlwbGUgY29udHJpYnV0b3JzLCBs ZWFkaW5nIHRvIGJldHRlciBjb250ZW50IGFuZCBtb3JlPGJyPjwvZGl2PjxkaXY+YWN0aXZlIG1h aW50ZW5hbmNlLjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PklmIHlvdSd2ZSBnb3QgaWRl YXMgZm9yIG90aGVyIHRvcGljcywgSSdkIGxvdmUgdG8gaGVhciB0aGVtLjxicj48L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2Pm5vYWg8YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9k aXY+PC9ibG9ja3F1b3RlPjwvYm9keT48L2h0bWw+DQo=

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.security

[ Apologies on advance for top posting but I'm writing this on my phone in
an airplane ]

Dear Noah,

As the main developer of the manual I find tour comments very interesting.
I agree that the manual needs an overhaul and I'm sure more hands in it
would help improve it tremendously.

Moving the manual to a Wiki could be an option but I would rather first
have an updated version/content using the current package/toolset and then consider moving it to a wiki.

The manual is not "centrally maintained" as it is available in Salsa for
anyone to contribute bits and pieces as they see fit.

Alternatively, somebody could start writing in the wiki different sections related to hardening specific services and, once mature/finished, move it
to the manual.

Personally I think that the manual :

- Should not cover in details the principles you mention. There is enough literature out there that it does not make sense to describe what other
sources (books / sites) provide better info on (it is manual, not a book!)

- Should maybe focus only on specific use cases (eg setting up a server)
rather than trying to cover all potential use cases (eg desktop) unless
there are enough "hands" working on it

Those thoughts aside I would be glad to help in pushing patches / new
versions of the manual to the archive if people start actively contributing
to it.

Best regards,

Javier

El mar, 10 jun 2025, 15:11, Dave P. <[email protected]> escribió:

Excellent idea Noah, especially Debian *server* security. I'm willing to help. The Wiki option sounds like the best way to me.
Some points:
- SSH server security
- Firewalls: I think someone mentioned nftables, and that is optimal. But
for people choosing between UFW and firewalld front-end tools, why
firewalld will usually be preferable.
- Monitoring/auditing: top/htop/etc, process termination, AIDE/Lynis/etc
- Minimizing the attack surface
- Modern backup strategies
- Looking at the current manual, user security needs to be updated as well.

Thanks for taking this on. As you say, the current manual has
been out-of-date for a long time and is not easily reviseable.
If you would like additional help, please email or contact me at my
Discord <https://discord.com/invite/mggw8VGzUp> server. I support Debian servers for several customers and use Debian 12 and sid on the client side. Also, I wrote an SSH server security manual for a customer; it can be
reused for this purpose.

Dave

On Mon, Jun 9, 2025 at 12:21 PM Noah Meyerhans <[email protected]> wrote:

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

<div dir="auto"><p dir="ltr">[ Apologies on advance for top posting but I&#39;m writing this on my phone in an airplane ]</p>
<p dir="ltr">Dear Noah,</p>
<p dir="ltr">As the main developer of the manual I find tour comments very interesting.  I agree that the manual needs an overhaul and I&#39;m sure more hands in it would help improve it tremendously.</p>
<p dir="ltr">Moving the manual to a Wiki could be an option but I would rather first have an updated version/content using the current package/toolset and then consider moving it to a wiki.</p>
<p dir="ltr">The manual is not &quot;centrally maintained&quot; as it is available in Salsa for anyone to contribute bits and pieces as they see fit. </p>
<p dir="ltr">Alternatively, somebody could start writing in the wiki different sections related to hardening specific services and, once mature/finished, move it to the manual.</p>
<p dir="ltr">Personally I think that the manual : </p>
<p dir="ltr">- Should not cover in details the principles you mention. There is enough literature out there that it does not make sense to describe what other sources (books / sites) provide better info on (it is manual, not a book!)</p>
<p dir="ltr">- Should maybe focus only on specific use cases (eg setting up a server) rather than trying to cover all potential use cases (eg desktop) unless there are enough &quot;hands&quot; working on it </p>
<p dir="ltr">Those thoughts aside I would be glad to help in pushing patches / new versions of the manual to the archive if people start actively contributing to it. </p>
<p dir="ltr">Best regards,</p><div data-smartmail="gmail_signature"><br>Javier</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">El mar, 10 jun 2025, 15:11, Dave P. &lt;<a href="mailto:[email protected]">
[email protected]</a>&gt; escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,
sans-serif;font-size:small">Excellent idea Noah, especially Debian <i>server</i> security. I&#39;m willing to help. The Wiki option sounds like the best way to me.  <br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:
small">Some points:</div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">- SSH server security <br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">- Firewalls: I think someone
mentioned nftables, and that is optimal. But for people choosing between UFW and firewalld front-end tools, why firewalld will usually be preferable.</div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">- Monitoring/
auditing: top/htop/etc, process termination, AIDE/Lynis/etc</div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">- Minimizing the attack surface</div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-
size:small">- Modern backup strategies</div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">- Looking at the current manual, user security needs to be updated as well.</div><div class="gmail_default" style="font-family:
tahoma,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">Thanks for taking this on. As you say, the current manual has been out-of-date for a long time and is not easily reviseable.<br>
</div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small"></div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">If you would like additional help, please email or contact me at my <a href="
https://discord.com/invite/mggw8VGzUp" target="_blank" rel="noreferrer">Discord</a> server. I support Debian servers for several customers and use Debian 12 and sid on the client side. Also, I wrote an SSH server security manual for a customer; it can be
reused for this purpose.</div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">Dave<br></div></div><br><div class="gmail_quote"><
div dir="ltr" class="gmail_attr">On Mon, Jun 9, 2025 at 12:21 PM Noah Meyerhans &lt;<a href="mailto:[email protected]" target="_blank" rel="noreferrer">[email protected]</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all.  The Securing Debian Manual (the harden-doc package) is<br>
woefully out of date and doesn&#39;t provide accurate guidance for<br> operating modern software in the current threat landscape.  I&#39;d like<br> to begin the task of updating it to reflect current best practice and<br>
to document current tools and technologies.<br>

Most basically, I wonder if folks think this is a worthy idea.  The<br> landscape has changed significantly since harden-doc was first<br>
written.  Default configurations don&#39;t require as much hardening, and<br> there are lots more available resources.  Maybe harden-doc has<br>
stagnated because there&#39;s no real need for it?<br>

Assuming we do revive the doc, here are some ideas of what I&#39;d like to<br> do with the document.  I&#39;d like to also get feedback, ideas, and<br> contributions from others interested in the topic.<br>

1. More background information on principles such as:<br>
   a. Threat modeling<br>
   b. Defense in depth<br>
   c. Least privilege<br>
2. Modern server deployment practices, such as:<br>
   a. Sandboxing (with systemd, containers, etc)<br>
   b. Image-based deployments, including cloud<br>
   c. Update deployment strategies for large fleets<br>
3. Data privacy:<br>
   a. VPNs, wireguard, etc<br>
   b. Disk encryption<br>
4. Workstation best practices, including:<br>
   a. Ssh key generation and handling<br>
   b. Basic browser hygine<br>
   c. Password managers and other password hygine<br>

My inclination is to primarily focus on general principles rather than<br>
try to document specific settings in specific packages, as in the<br>
current document&#39;s Chapter 5 (&quot;Securing services running on your<br> system&quot;).  It&#39;ll make sense to document some approaches to safe usage of<br>
the most common software (firefox, openssh, etc), but I don&#39;t believe<br> that it&#39;s feasible to provide useful advice for a meaningful subset of<br> Debian packages.<br>

Should we maybe consider maintaining this document on <a href="http://wiki.debian.org" rel="noreferrer noreferrer" target="_blank">wiki.debian.org</a>,<br>
rather than being a centrally maintained document? The wiki may scale<br> better to multiple contributors, leading to better content and more<br>
active maintenance.<br>

If you&#39;ve got ideas for other topics, I&#39;d love to hear them.  <br>

noah<br>

</blockquote></div>
</div>
</blockquote></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.security

On Tue, Jun 10, 2025 at 09:57:43PM +0200, Javier Fernandez-Sanguino wrote:

Moving the manual to a Wiki could be an option but I would rather first
have an updated version/content using the current package/toolset and then
consider moving it to a wiki.

The current format is arcane and presents a barrier to contributors.
I'm not sure that working within the existing structure (either markup
or content) is worthwhile at this point.

The manual is not "centrally maintained" as it is available in Salsa for
anyone to contribute bits and pieces as they see fit.

Well..

Alternatively, somebody could start writing in the wiki different sections
related to hardening specific services and, once mature/finished, move it
to the manual.

Yeah, this may be reasonable. Holger's example of the DebianEdu docs
might be a good one to follow.

Personally I think that the manual :

- Should not cover in details the principles you mention. There is enough
literature out there that it does not make sense to describe what other
sources (books / sites) provide better info on (it is manual, not a book!)

I understand your point. However, as Schneier and others have observed, security is a process, not a product (and not a checklist). In order to
adapt to changes with security implications, an admin will need to
understant topics like threat modeling in order to react react
appropriately. We don't want to provide a set of receipes/checklists
and leave the reader with a sense that they're done when they've
completed them. I would expect to provide basic content on these
topics, but to link to external resources for further reading. So I
think we probably agree; the question will be how to figure out how much
detail to include, and when to refer out to some other document.

- Should maybe focus only on specific use cases (eg setting up a server)
rather than trying to cover all potential use cases (eg desktop) unless
there are enough "hands" working on it

Broadly speaking, I'd say that the two most common use cases can be
classified as either "a system that's always online and offers network services" and "a system that runs a web browser and other interactive applications", and we should be able to cover those. We can get more
granular or broaden the scope later, as needed.

Those thoughts aside I would be glad to help in pushing patches / new
versions of the manual to the archive if people start actively
contributing to it.

...this is exactly what I mean by centrally maintained. :) The wiki
eliminates the need for merge requests, approvers, etc.

noah

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.security

On Tue, 10 Jun 2025 at 22:57, Noah Meyerhans <[email protected]> wrote:

On Tue, Jun 10, 2025 at 09:57:43PM +0200, Javier Fernandez-Sanguino wrote:

Moving the manual to a Wiki could be an option but I would rather

first

have an updated version/content using the current package/toolset and

then

consider moving it to a wiki.

The current format is arcane and presents a barrier to contributors.
I'm not sure that working within the existing structure (either markup
or content) is worthwhile at this point.

I'm not fully convinced that the current format is a barrier to
contributors as the Debian website uses WML and this has not hindered contributions. When I've received snippets of text (even if unformatted
form) I have gladly included them in the manual. The XML files available in Sala ( https://salsa.debian.org/ddp-team/securing-debian-manual/-/tree/master/en-US?ref_type=heads)
can be forked/edited quickly by anybody who has just a basic notion of
HTML. However, the BTS and merge requests in the last 10 years shows that
the number of people willing to put the work and actually write /
contribute is low.

I personally also see some advantages to the current format (including nice printable versions as well as easy translations via PO files) which would
be lost if the content is moved to a Wiki format.

In any case, I would suggest that the best approach to improve the manual
would be to first update the existing content in its current format, get it
to a good enough shape that it can be shipped back into Debian proper and *then* consider moving it to Debian's Wiki.

Alternatively, somebody could start writing in the wiki different

sections

related to hardening specific services and, once mature/finished,

move it

to the manual.

Yeah, this may be reasonable. Holger's example of the DebianEdu docs
might be a good one to follow.

I'm not aware of what was done in DebianEdu (any ponter's), but I'm open to trying alternative approaches.

Personally I think that the manual :

- Should not cover in details the principles you mention. There is

enough

literature out there that it does not make sense to describe what

other

sources (books / sites) provide better info on (it is manual, not a

book!)

I understand your point. However, as Schneier and others have observed, security is a process, not a product (and not a checklist). In order to adapt to changes with security implications, an admin will need to
understant topics like threat modeling in order to react react
appropriately. We don't want to provide a set of receipes/checklists
and leave the reader with a sense that they're done when they've
completed them. I would expect to provide basic content on these
topics, but to link to external resources for further reading. So I
think we probably agree; the question will be how to figure out how much detail to include, and when to refer out to some other document.

I'm not opposed to having a section in chapter 2 (Before you begin) giving guidance to administrators on how to approach the problem. As you said, providing basic guidance and pointing to proper resources.

Actually, I think that this discussion on the potential approaches /
rewrite and potential distribution of sections / workload could be well
suited to be documented in a Wiki :)

- Should maybe focus only on specific use cases (eg setting up a

server)

rather than trying to cover all potential use cases (eg desktop)

unless

there are enough "hands" working on it

Broadly speaking, I'd say that the two most common use cases can be classified as either "a system that's always online and offers network services" and "a system that runs a web browser and other interactive applications", and we should be able to cover those. We can get more granular or broaden the scope later, as needed.

Agreed. Although the current manual is more focused on the first use case
in my opinion. It would require a mejor rewrite to fit multiple use cases.

Those thoughts aside I would be glad to help in pushing patches / new
versions of the manual to the archive if people start actively
contributing to it.

...this is exactly what I mean by centrally maintained. :) The wiki eliminates the need for merge requests, approvers, etc.

I was referring to the current status quo in which there is one package and
a common repository (in salsa). If somebody wants to improve it *now* and
help fix the issues raised in the BTS or add new content this would be the
way to go about it.

Best regards

Javier

<div dir="ltr"><div dir="ltr"><div><br></div></div><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, 10 Jun 2025 at 22:57, Noah Meyerhans &lt;<a href="mailto:[email protected]">[email protected]</a>&gt; wrote:<br></

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Jun 10, 2025 at 09:57:43PM +0200, Javier Fernandez-Sanguino wrote:<br>

&gt;    Moving the manual to a Wiki could be an option but I would rather first<br>
&gt;    have an updated version/content using the current package/toolset and then<br>
&gt;    consider moving it to a wiki.<br>

The current format is arcane and presents a barrier to contributors.<br> I&#39;m not sure that working within the existing structure (either markup<br> or content) is worthwhile at this point.<br></blockquote><div><br></div><div>I&#39;m not fully convinced that the current format is a barrier to contributors as the Debian website uses WML and this has not hindered contributions. When I&#39;ve received
snippets of text (even if unformatted form) I have gladly included them in the manual. The XML files available in Sala (<a href="https://salsa.debian.org/ddp-team/securing-debian-manual/-/tree/master/en-US?ref_type=heads">https://salsa.debian.org/ddp-
team/securing-debian-manual/-/tree/master/en-US?ref_type=heads</a>) can be forked/edited quickly by anybody who has just a basic notion of HTML.  However, the BTS and merge requests in the last 10 years shows that the number of people willing to put
the work and actually write / contribute is low.</div><div><br></div><div>I personally also see some advantages to the current format (including nice printable versions as well as easy translations via PO files) which would be lost if the content is
moved to a Wiki format.</div><div><br></div><div>In any case, I would suggest that the best approach to improve the manual would be to first update the existing content in its current format, get it to a good enough shape that it can be shipped back into
Debian proper and *then* consider moving it to Debian&#39;s Wiki.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">&gt;    Alternatively, somebody could start
writing in the wiki different sections<br>
&gt;    related to hardening specific services and, once mature/finished, move it<br>
&gt;    to the manual.<br>

Yeah, this may be reasonable.  Holger&#39;s example of the DebianEdu docs<br> might be a good one to follow.<br></blockquote><div><br></div><div>I&#39;m not aware of what was done in DebianEdu (any ponter&#39;s), but I&#39;m open to trying alternative approaches.</div><div><br></div><div><br></div><blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">&gt;    Personally I think that the manual :<br>
&gt; <br>
&gt;    - Should not cover in details the principles you mention. There is enough<br>
&gt;    literature out there that it does not make sense to describe what other<br>
&gt;    sources (books / sites) provide better info on (it is manual, not a book!)<br>

I understand your point.  However, as Schneier and others have observed,<br> security is a process, not a product (and not a checklist).  In order to<br> adapt to changes with security implications, an admin will need to<br> understant topics like threat modeling in order to react react<br> appropriately.  We don&#39;t want to provide a set of receipes/checklists<br> and leave the reader with a sense that they&#39;re done when they&#39;ve<br> completed them.  I would expect to provide basic content on these<br>
topics, but to link to external resources for further reading.  So I<br>
think we probably agree; the question will be how to figure out how much<br> detail to include, and when to refer out to some other document.<br></blockquote><div><br></div><div>I&#39;m not opposed to having a section in chapter 2 (Before you begin) giving guidance to administrators on how to approach the problem. As you said,
providing basic guidance and pointing to proper resources.</div><div><br></div><div>Actually, I think that this discussion on the potential approaches / rewrite and potential distribution of sections / workload could be well suited to be documented in a
Wiki :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

&gt;    - Should maybe focus only on specific use cases (eg setting up a server)<br>
&gt;    rather than trying to cover all potential use cases (eg desktop) unless<br>
&gt;    there are enough &quot;hands&quot; working on it<br>

Broadly speaking, I&#39;d say that the two most common use cases can be<br> classified as either &quot;a system that&#39;s always online and offers network<br>
services&quot; and &quot;a system that runs a web browser and other interactive<br>
applications&quot;, and we should be able to cover those.  We can get more<br> granular or broaden the scope later, as needed.<br></blockquote><div><br></div><div>Agreed. Although the current manual is more focused on the first use case in my opinion. It would require a mejor rewrite to fit multiple use cases.</div><div> </div><
blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt;    Those thoughts aside I would be glad to help in pushing patches / new<br>
&gt;    versions of the manual to the archive if people start actively<br> &gt;    contributing to it.<br>

...this is exactly what I mean by centrally maintained. :)  The wiki<br> eliminates the need for merge requests, approvers, etc.<br></blockquote><div><br></div><div>I was referring to the current status quo in which there is one package and a common repository (in salsa). If somebody wants to improve it *now* and help fix the
issues raised in the BTS or add new content this would be the way to go about it.</div><div><br></div><div>Best regards</div><div><br></div><div>Javier</div><div><br></div><div><br></div></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.security

On Mon, Jun 09, 2025 at 04:43:47PM +0000, Holger Levsen wrote:

https://wiki.debian.org/DebianEdu/Documentation/Trixie (or Bookworm or many earlier relases) is an example where this is being done, using translations via
.po files (nowadays mostly translated via weblate) and with a src:debian-edu-doc
package building several binary packages mostly for different translations, shipping
txt, html, pdf and epub versions of that manual.

one aspect I forgot to mention: being subscribed to the the wiki pages in question,
so one gets notifications about changes via mail, and reviewing those.

(the tooling also allows to review the git diffs once/each time the wiki is transferred to git, but in practive I have always done the review once there was a wiki edit, also because that is closer in time to the actual edit.)


--
cheers,
Holger

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

You can cut all the flowers, but you can’t keep spring from coming. #transdayofremembrance #berlin (2024)

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmhJVQAACgkQCRq4Vgaa qhxrYg/+L4DHEQr0A1fugqwcWJRH4XmitqHGvXNWt08naY+MDWO/nZW8rn7InIKa o3JUuT76AL9yTrsAUHxA7FXhNzf4SuMQhkn+ob4xiG3mCYm2fZfHviIy3LsbEfAr iK69m1RE5h8DTwf3Iw6c3d7K1UIhe8W7+XRYMKZWA/9LT8Yv646gDlSbWwNdacgA 7/eXnMxRVeYLoS/1C5xds/HSBkMZO4u43O9xhuy1CA5gtEKcAtdezcCDOAK9oq4Q Y9IoU8yFe4TdF4hL+e3TDf37P/+VqWhzS7R8Elc8DgkmKW6tZD+aWZjcUWc9geL4 +mqSKAyiQfKVD/4D9Xx0TOOK2//a33yB+sgiipu58TA+X8D1dj81Fr7GGJBLTiMv Y45bnu6YxrRFvzBDuZ6+2+w7Acqs0G8h5/8qKMukAkChstkMJV8YG6f/4NScGVGQ LOqtNSLff6gxY/beEMd/Om7S71ih+dmpqTtPf2TOOB25MiP7Z/YZybawUYMgFhAo 8tYNuQo7a9wHam7ER0cHZ4q3FibAjYqYzKXzaAHb/I6+Y113d3Tbvi8+9oFr8zVW
uUaJ

XPost: linux.debian.security

hi,

I also should have thrown in some more URLs, namely: https://jenkins.debian.net/userContent/debian-edu-doc/debian-edu-doc-en/debian-edu-bookworm-manual.html
https://jenkins.debian.net/userContent/debian-edu-doc/debian-edu-doc-en/debian-edu-bookworm-manual.pdf
https://jenkins.debian.net/userContent/debian-edu-doc/debian-edu-doc-en/debian-edu-bookworm-manual.epub
which all have
https://wiki.debian.org/DebianEdu/Documentation/Bookworm/
as their source.


--
cheers,
Holger

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

Some of my friends and I overcommit to things, so we made "Saying No to Things" punch cards. If you say no to 10 things, your friends have to buy you an ice cream. In a pilot study, we found participants both said no to more things and got more free ice cream. (@leah_pierson)

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmhJszkACgkQCRq4Vgaa qhxltRAAk89jCEPW5a88sHJTRn+qCu7CX/XzePkUSbjNfa4vXQcI6CwrhGNdO5P6 FWutoeLnlyJRokhtn/qbM8YBanLaBEBgHFxclWdWrCxeY87/HH1U6tu8B3HQ+ET5 D56k1CswzdvxRV6H6/ANo3PcMgdn9hjNo9oP0BnBZ01U1t3ijHDoOHJtg1v7YySs JR6S0RmmGkBPMiXz2it6q6HrALq+rEOVREsgy+Peb88IhoLhnEHAVCZ7PkrFJT7K 1S8L9ZxE1U8LrL/pC6Rhog5Z+wHYb6goXuSrCvndlyMg+wF8/BWVReqKb6utrNIA YUlZrsYoMSBksrV/VcoUaVvVivoSIYhVcHdSI3eiKiIbmFqOlePaHfGtaVRRru/e 1lZc4OBR1B5DnashtQF5KrcXgmkhf1i