Inferencium/website
1
0
Fork 0
Code Issues Activity

Update Blog #1 from version 4.0.0.14 to 4.0.1.15.

Browse Source
This commit is contained in:
inference 2023-06-05 00:12:24 +01:00
parent 283fb29b58
commit fe7e4baf99
Signed by: inference
SSH Key Fingerprint: SHA256:9Pl0nZ2UJacgm+IeEtLSZ4FOESgP1eKCtRflfPfdX9M
1 changed files with 13 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
blog/systemd_insecurity.html
View File

@ -5,7 +5,7 @@
<!-- Copyright 2022 Jake Winters -->
<!-- SPDX-License-Identifier: BSD-3-Clause -->
<!-- Version: 4.0.0.14 -->
<!-- Version: 4.0.1.15 -->
<html>
@ -69,8 +69,8 @@
<h2 id="issue0"><a href="#issue0" class="h2"
>Issue #0 - Against CVE Assignment</a></h2>
<br>
<p>Poettering:<br>
"You don't assign CVEs to every single random bugfix we do, do you?"</p>
<blockquote>You don't assign CVEs to every single random bugfix we do, do you?</blockquote>
<p>- Lennart Poettering, systemd lead developer</p>
<br>
<p>My thoughts:<br>
Yes, if they're security-related.</p>
@ -85,11 +85,11 @@
<h2 id="issue1"><a href="#issue1" class="h2"
>Issue #1 - CVEs Are Not Useful</a></h2>
<br>
<p>Poettering:<br>
"Humpf, I am not convinced this is the right way to announce this. We never did that, and half the
<blockquote>Humpf, I am not convinced this is the right way to announce this. We never did that, and half the
CVEs aren't useful anyway, hence I am not sure we should start with that now, because it is either
inherently incomplete or blesses the nonsensical part of the CVE circus which we really shouldn't
bless..."</p>
bless...</blockquote>
<p>- Lennart Poettering, systemd lead developer</p>
<br>
<p>My thoughts:<br>
CVEs are supposed to be for security, and a log of when they were found and their severity, so yes,
@ -106,8 +106,9 @@
<h2 id="issue2"><a href="#issue2" class="h2">
Issue #2 - Security is a Circus</a></h2>
<br>
<p>Poettering:<br>
"I am not sure I buy enough into the security circus to do that though for any minor issue..."</p>
<blockquote>I am not sure I buy enough into the security circus to do that though for any minor
issue...</blockquote>
<p>- Lennart Poettering, systemd lead developer</p>
<br>
<p>Source:<br>
<a class="body-link" href="https://github.com/systemd/systemd/issues/5144#issuecomment-276740654"
@ -119,17 +120,17 @@
<h2 id="issue3"><a href="#issue3" class="h2"
>Issue #3 - Blaming the User</a></h2>
<br>
<p>Poettering:<br>
"Yes, as you found out "0day" is not a valid username. I wonder which tool permitted you to create
<blockquote>Yes, as you found out "0day" is not a valid username. I wonder which tool permitted you to create
it in the first place. Note that not permitting numeric first characters is done on purpose: to
avoid ambiguities between numeric UID and textual user names.<br>
avoid ambiguities between numeric UID and textual user names.
<br>
systemd will validate all configuration data you drop at it, making it hard to generate invalid
configuration. Hence, yes, it's a feature that we don't permit invalid user names, and I'd consider
it a limitation of xinetd that it doesn't refuse an invalid username.<br>
<br>
So, yeah, I don't think there's anything to fix in systemd here. I understand this is annoying, but
still: the username is clearly not valid."</p>
still: the username is clearly not valid.</blockquote>
<p>- Lennart Poettering, systemd lead developer</p>
<br>
<p>My thoughts:<br>
systemd was the thing that allowed root access just because a username started with a number, then