Add table of contents. Indent code to match coding style.
This commit is contained in:
parent
5e83403040
commit
bcb0c74733
SSH Key Fingerprint:
SHA256:9Pl0nZ2UJacgm+IeEtLSZ4FOESgP1eKCtRflfPfdX9M
@ -5,7 +5,7 @@
|
||||
<!-- Copyright 2022-2023 Jake Winters -->
|
||||
<!-- SPDX-License-Identifier: BSD-3-Clause-Clear -->
|
||||
|
||||
<!-- Version: 3.0.0.12 -->
|
||||
<!-- Version: 3.1.0.13 -->
|
||||
|
||||
|
||||
<html>
|
||||
@ -36,84 +36,110 @@
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<h2>systemd Insecurity</h2>
|
||||
<br>
|
||||
<p class="update_date">Posted: 2022-01-29 (UTC+00:00)</p>
|
||||
<p class="update_date">Updated: 2022-11-14 (UTC+00:00)</p>
|
||||
<br>
|
||||
<br>
|
||||
<h2>systemd Insecurity</h2>
|
||||
<br>
|
||||
<p class="update_date">Posted: 2022-01-29 (UTC+00:00)</p>
|
||||
<p class="update_date">Updated: 2022-11-14 (UTC+00:00)</p>
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<p>Anyone who cares about security may want to switch from systemd as soon as possible; its lead
|
||||
developer doesn't care about your security at all.</p>
|
||||
<br>
|
||||
<br>
|
||||
<h3>Issue #0 - Against CVE Assignment</h3>
|
||||
<br>
|
||||
<p>Poettering:<br>
|
||||
"You don't assign CVEs to every single random bugfix we do, do you?"</p>
|
||||
<br>
|
||||
<p>My thoughts:<br>
|
||||
Yes, if they're security-related.</p>
|
||||
<br>
|
||||
<p>Source:<br>
|
||||
<a class="body-link" href="https://github.com/systemd/systemd/pull/5998#issuecomment-303782334"
|
||||
>systemd GitHub Issue 5998</a></p>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<h3>Issue #1 - CVEs Are Not Useful</h3>
|
||||
<br>
|
||||
<p>Poettering:<br>
|
||||
"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>
|
||||
<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,
|
||||
it *is* the correct way to announce it. It seems as if over 95 security-concious people think the
|
||||
same.</p>
|
||||
<br>
|
||||
<p>Source:<br>
|
||||
<a class="body-link" href="https://github.com/systemd/systemd/pull/6225#issuecomment-311739869"
|
||||
>systemd GitHub Issue 6225</a></p>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<h3>Issue #2 - Security is a Circus</h3>
|
||||
<br>
|
||||
<p>Poettering:<br>
|
||||
"I am not sure I buy enough into the security circus to do that though for any minor issue..."</p>
|
||||
<br>
|
||||
<p>Source:<br>
|
||||
<a class="body-link" href="https://github.com/systemd/systemd/issues/5144#issuecomment-276740654"
|
||||
>systemd GitHub Issue 5144</a></p>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<h3>Issue #3 - Blaming the User</h3>
|
||||
<br>
|
||||
<p>Poettering:<br>
|
||||
"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>
|
||||
<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>
|
||||
<br>
|
||||
<p>My thoughts:<br>
|
||||
systemd was the thing that allowed root access just because a username started with a number, then
|
||||
Poettering blamed the user.</p>
|
||||
<br>
|
||||
<p>Source:<br>
|
||||
<a class="body-link" href="https://github.com/systemd/systemd/issues/6237#issuecomment-311900864"
|
||||
>systemd GitHub Issue 6237</a></p>
|
||||
<br>
|
||||
<br>
|
||||
<!-- Table of contents. -->
|
||||
<h2 id="toc"><a href="#toc" class="h2"
|
||||
>Table of Contents<a/></h2>
|
||||
<ul>
|
||||
<li><a href="#issue0" class="body-link"
|
||||
>Issue #0 - Against CVE Assignment</a></li>
|
||||
<li><a href="#issue1" class="body-link"
|
||||
>Issue #1 - CVEs Are Not Useful</a></li>
|
||||
<li><a href="#issue2" class="body-link"
|
||||
>Issue #2 - Security is a Circus</a></li>
|
||||
<li><a href="#issue3" class="body-link"
|
||||
>Issue #3 - Blaming the User</a></li>
|
||||
</ul>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<p>Anyone who cares about security may want to switch from systemd as soon as possible; its lead
|
||||
developer doesn't care about your security at all.</p>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<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>
|
||||
<br>
|
||||
<p>My thoughts:<br>
|
||||
Yes, if they're security-related.</p>
|
||||
<br>
|
||||
<p>Source:<br>
|
||||
<a class="body-link" href="https://github.com/systemd/systemd/pull/5998#issuecomment-303782334"
|
||||
>systemd GitHub Issue 5998</a></p>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<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
|
||||
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>
|
||||
<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,
|
||||
it *is* the correct way to announce it. It seems as if over 95 security-concious people think the
|
||||
same.</p>
|
||||
<br>
|
||||
<p>Source:<br>
|
||||
<a class="body-link" href="https://github.com/systemd/systemd/pull/6225#issuecomment-311739869"
|
||||
>systemd GitHub Issue 6225</a></p>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<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>
|
||||
<br>
|
||||
<p>Source:<br>
|
||||
<a class="body-link" href="https://github.com/systemd/systemd/issues/5144#issuecomment-276740654"
|
||||
>systemd GitHub Issue 5144</a></p>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<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
|
||||
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>
|
||||
<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>
|
||||
<br>
|
||||
<p>My thoughts:<br>
|
||||
systemd was the thing that allowed root access just because a username started with a number, then
|
||||
Poettering blamed the user.</p>
|
||||
<br>
|
||||
<p>Source:<br>
|
||||
<a class="body-link" href="https://github.com/systemd/systemd/issues/6237#issuecomment-311900864"
|
||||
>systemd GitHub Issue 6237</a></p>
|
||||
<br>
|
||||
<br>
|
||||
</body>
|
||||
|
||||
</html>
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user