Re: Resurrecting the Securing Debian Manual

Michael Lazin <[email protected]> Mon, 9 Jun 2025 12:35:27 -0400
Newsgroups gmane.linux.debian.devel.security,gmane.linux.debian.devel.documentation
Message-ID <CALdcr8ezGtL0ZRRfhT1BHHgr83o6GmZ3dmiLOsE-2JxuABzisw@mail.gmail.com>
--000000000000800a050637262b36
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I am usually radio silent on this list but this project is interesting to
me because I have 11 years of experience doing forensics in a purely Debian
environment.  I am not a full stack developer, I can script in bash and
python but this is not enough to contribute to code.  Contributing to this
manual is in my set of skills and I would like to help with this project.

Thank you,

Michael Lazin

.. =CF=84=E1=BD=B8 =CE=B3=E1=BD=B0=CF=81 =CE=B1=E1=BD=90=CF=84=E1=BD=B8 =CE=
=BD=CE=BF=CE=B5=E1=BF=96=CE=BD =E1=BC=90=CF=83=CF=84=CE=AF=CE=BD =CF=84=CE=
=B5 =CE=BA=CE=B1=E1=BD=B6 =CE=B5=E1=BC=B6=CE=BD=CE=B1=CE=B9.


On Mon, Jun 9, 2025 at 12:21=E2=80=AFPM Noah Meyerhans <[email protected]> w=
rote:

> 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
>
>

--000000000000800a050637262b36
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I am usually radio silent on this list but this proje=
ct is interesting to me because I have 11 years of experience doing forensi=
cs in a purely Debian environment.=C2=A0 I am not a full stack developer, I=
 can script=C2=A0in bash and python but this is not enough=C2=A0to contribu=
te to code.=C2=A0 Contributing to this manual is in my set of skills and I =
would like to help with this project.=C2=A0</div><div><br>Thank you,</div><=
div><br></div><div><div dir=3D"ltr" class=3D"gmail_signature" data-smartmai=
l=3D"gmail_signature"><div dir=3D"ltr">Michael Lazin<br><span style=3D"font=
-size:16.6px;font-family:serif"></span><div><br></div><div><span style=3D"f=
ont-size:16.6px;font-family:serif"></span><span style=3D"font-size:16.6px;f=
ont-family:serif">..              </span><span style=3D"font-size:16.6px;fo=
nt-family:serif">=CF=84=E1=BD=B8 </span><span style=3D"font-size:16.6px;fon=
t-family:serif">=CE=B3=E1=BD=B0=CF=81</span><span style=3D"font-size:16.6px=
;font-family:serif"> =CE=B1=E1=BD=90=CF=84=E1=BD=B8 </span><span style=3D"f=
ont-size:16.6px;font-family:serif">=CE=BD=CE=BF=CE=B5=E1=BF=96=CE=BD </span=
><span style=3D"font-size:16.6px;font-family:serif">=E1=BC=90=CF=83=CF=84=
=CE=AF=CE=BD </span><span style=3D"font-size:16.6px;font-family:serif">=CF=
=84=CE=B5 </span><span style=3D"font-size:16.6px;font-family:serif">=CE=BA=
=CE=B1=E1=BD=B6 </span><span style=3D"font-size:16.6px;font-family:serif">=
=CE=B5=E1=BC=B6=CE=BD=CE=B1=CE=B9</span><span style=3D"font-size:16.6px;fon=
t-family:serif">.</span></div><span style=3D"font-size:16.6px;font-family:s=
erif"></span><span style=3D"font-size:16.6px;font-family:serif"></span><spa=
n style=3D"font-size:16.6px;font-family:serif"></span><span style=3D"font-s=
ize:16.6px;font-family:serif"></span><span style=3D"font-size:16.6px;font-f=
amily:serif"></span><span style=3D"font-size:16.6px;font-family:serif"></sp=
an><span style=3D"font-size:16.6px;font-family:serif"></span><span style=3D=
"font-size:16.6px;font-family:serif"></span><span style=3D"font-size:16.6px=
;font-family:serif"></span></div></div></div><br></div><br><div class=3D"gm=
ail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On M=
on, Jun 9, 2025 at 12:21=E2=80=AFPM Noah Meyerhans &lt;<a href=3D"mailto:no=
[email protected]">[email protected]</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">Hi all.=C2=A0 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.=C2=A0 I&#39;d li=
ke<br>
to begin the task of updating it to reflect current best practice and<br>
to document current tools and technologies.<br>
<br>
Most basically, I wonder if folks think this is a worthy idea.=C2=A0 The<br=
>
landscape has changed significantly since harden-doc was first<br>
written.=C2=A0 Default configurations don&#39;t require as much hardening, =
and<br>
there are lots more available resources.=C2=A0 Maybe harden-doc has<br>
stagnated because there&#39;s no real need for it?<br>
<br>
Assuming we do revive the doc, here are some ideas of what I&#39;d like to<=
br>
do with the document.=C2=A0 I&#39;d like to also get feedback, ideas, and<b=
r>
contributions from others interested in the topic.<br>
<br>
1. More background information on principles such as:<br>
=C2=A0 =C2=A0a. Threat modeling<br>
=C2=A0 =C2=A0b. Defense in depth<br>
=C2=A0 =C2=A0c. Least privilege<br>
2. Modern server deployment practices, such as:<br>
=C2=A0 =C2=A0a. Sandboxing (with systemd, containers, etc)<br>
=C2=A0 =C2=A0b. Image-based deployments, including cloud<br>
=C2=A0 =C2=A0c. Update deployment strategies for large fleets<br>
3. Data privacy:<br>
=C2=A0 =C2=A0a. VPNs, wireguard, etc<br>
=C2=A0 =C2=A0b. Disk encryption<br>
4. Workstation best practices, including:<br>
=C2=A0 =C2=A0a. Ssh key generation and handling<br>
=C2=A0 =C2=A0b. Basic browser hygine<br>
=C2=A0 =C2=A0c. Password managers and other password hygine<br>
<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<b=
r>
system&quot;).=C2=A0 It&#39;ll make sense to document some approaches to sa=
fe usage of<br>
the most common software (firefox, openssh, etc), but I don&#39;t believe<b=
r>
that it&#39;s feasible to provide useful advice for a meaningful subset of<=
br>
Debian packages.<br>
<br>
Should we maybe consider maintaining this document on <a href=3D"http://wik=
i.debian.org" rel=3D"noreferrer" target=3D"_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>
<br>
If you&#39;ve got ideas for other topics, I&#39;d love to hear them.=C2=A0 =
<br>
<br>
noah<br>
<br>
</blockquote></div>

--000000000000800a050637262b36--