Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.security > #6430
| From | Vladislav Kurz <vladislav.kurz@webstep.net> |
|---|---|
| Newsgroups | linux.debian.security, linux.debian.doc |
| Subject | Re: Resurrecting the Securing Debian Manual |
| Date | 2025-06-09 22:10 +0200 |
| Message-ID | <KVQYF-9qke-3@gated-at.bofh.it> (permalink) |
| References | <KVNxM-9o43-7@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Cross-posted to 2 groups.
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
Back to linux.debian.security | Previous | Next — Previous in thread | Next in thread | Find similar
Resurrecting the Securing Debian Manual Noah Meyerhans <noahm@debian.org> - 2025-06-09 18:30 +0200
Re: Resurrecting the Securing Debian Manual Michael Lazin <microlaser@gmail.com> - 2025-06-09 18:40 +0200
Re: Resurrecting the Securing Debian Manual Holger Levsen <holger@layer-acht.org> - 2025-06-09 18:50 +0200
Re: Resurrecting the Securing Debian Manual Holger Levsen <holger@layer-acht.org> - 2025-06-11 12:10 +0200
Re: Resurrecting the Securing Debian Manual Holger Levsen <holger@layer-acht.org> - 2025-06-11 18:50 +0200
Re: Resurrecting the Securing Debian Manual Jeffrey Chimene <jeff@systasis.co> - 2025-06-09 19:10 +0200
Re: Resurrecting the Securing Debian Manual Rob Ward <pocketapocketa@protonmail.com> - 2025-06-09 19:20 +0200
Re: Resurrecting the Securing Debian Manual Vladislav Kurz <vladislav.kurz@webstep.net> - 2025-06-09 22:10 +0200
Re: Resurrecting the Securing Debian Manual "Dave P." <dprowseus@gmail.com> - 2025-06-10 15:20 +0200
Re: Resurrecting the Securing Debian Manual Javier Fernandez-Sanguino <jfs@debian.org> - 2025-06-10 22:10 +0200
Re: Resurrecting the Securing Debian Manual Noah Meyerhans <noahm@debian.org> - 2025-06-10 23:00 +0200
Re: Resurrecting the Securing Debian Manual Javier Fernandez-Sanguino <jfs@debian.org> - 2025-06-11 00:00 +0200
Re: Resurrecting the Securing Debian Manual debianmailinglists.hz5zm@simplelogin.com - 2025-06-11 08:30 +0200
Re: Resurrecting the Securing Debian Manual "Dave P." <dprowseus@gmail.com> - 2025-06-11 16:50 +0200
Re: Resurrecting the Securing Debian Manual debianmailinglists.hz5zm@simplelogin.com - 2025-06-10 19:50 +0200
csiph-web