I agree with his points that SystemD should absolutely stop adding other services and focus on it's "one job" to do that well.
The whole value of having so many services that are NOT PID 1 is that they're less vulnerable and any vulnerabilities are more contained (particularly with namespaces in the kernel, when used correctly)
I strongly disagree with his comment about "memory-unsafe language", however. There's no such thing as a memory-safe language (I've used most of the candidates for that title, and I can show bad code that runs off edges in all of them, it's almost trivial in all but a couple unicorn languages)
The problem is not the language, it's the design and development ethic in the community that allows this type of sloppy design to persist past the first code review.
Now for the obligatory rant.
: Begin Rant
That said, I have to agree with a general sentiment I've seen growing lately that's reflected in this post.
Linux kernel and system-service development has to change. Security at the design level has to be a first-class concern and top-level constraint, not something worked in via QE (there's no such thing as quality assurance in software, only quality engineering) which is done after release by support vendors.
The kernel has constant code review, but I have very rarely seen real security-by-design comments on LKML (when I've had time to wade through that minefield).
SystemD should be restricted to it's INIT functions, dump the horrible non-standard logging, drop all of the service replacements (or spin them into separate services), and get laser-focused on getting that INIT service bullet-proof, because an INIT compromise is a nightmare for everyone.
It's fine to have a DBUS-based DNS resolver (if the system really needs more DBUS dependency, but that's completely different issue), it's very much not fine to include that in PID 1 or the Kernel.
If I recall correctly, SysV INIT had a similar growing-up moment back in the early '80s.
AT&T tried to expand it into more of a service-monitor role and make all process launch run through INIT (via a weird message protocol, borrowed from PLAN9). It failed miserably because it's actually a bad idea.
SystemD is repeating some of those same mistakes because, quite simply, nobody on that team is old enough to remember the history, and computing history is not considered "historical" enough for proper historians to write it all down (and CS courses don't teach the history at all).
Every day I see repetitions of computing history in new projects and it drives me bonkers to see the wasted effort repeating past (well documented) mistakes, or "new and innovative" solutions that recreate work done 20 or 30 years ago (or more, like CGroups and Namespaces from the 1960's).
I think the entire RedHat organization (and the professional open-source community in general) might need a refresher course on operating system design, particularly focusing on microkernel architectures and the how/why those are inherently more secure (also why the tradeoffs involved don't work as well in Ring-0 kernel space as they do in Ring-3 user space).
Linux is not (and should not be) a microkernel of course, for a lot of reasons, but the design lesson still applies, particularly to privileged user-space processes, large device drivers (e.g. video drivers), and system services.
: End Rant
==Joseph++
On 09/28/2016 11:45 PM, der.hans wrote:
> Am 28. Sep, 2016 schwätzte Stephen M so:
>
> moin moin Stephen,
>
> yeah, I'm not pissed that there's a bug. In fact, the fix was committed
> rather quickly.
>
> I do think there's merit to thinking about some of the guy's points as
> they apply to a particular environment.
>
> Granted, the kernel is run in the same "memory-unsafe language" he's
> complaining about and has more than root access :).
>
> ciao,
>
> der.hans
>
>> Well that would definitely be a problem but it does give people chances to
>> fix things and grow. So if we didn't have problems like systemd pausing,
>> though never tried this before on my Fedora system with systemd. It does
>> give developer and other computer enthusiast a challenge to solve. What
>> would the world be like if everything was perfect and nothing ever fail out
>> of sync. This will just be something that someone new coming into the work
>> of Linux learns and adapts to.
>>
>> I'm sure there are stories of before with the introduction of init, SysV,
>> Berkeley standard, so it's bond to happen again.
>>
>> Thanks Hans for the great articles.
>>
>> On Wed, Sep 28, 2016 at 10:59 PM, Steve Litt <slitt@troubleshooters.com>
>> wrote:
>>
>>> On Thu, 29 Sep 2016 04:19:37 +0000 (UTC)
>>> "der.hans" <PLUGd@LuftHans.com> wrote:
>>>
>>>> moin moin,
>>>>
>>>> an important systemd fix is on it's way into distributions.
>>>>
>>>> https://marc.ttias.be/oss-security/2016-09/msg00243.php
>>>>
>>>> The following article has a click-bait title :(, but some salient
>>>> things to consider for systemd.
>>>>
>>>> https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet
>>>
>>> I fixed systemd by switching to Void Linux, which uses the runit init
>>> system.
>>>
>>> SteveT
>>>
>>> Steve Litt
>>> September 2016 featured book: Twenty Eight Tales of Troubleshooting
>>> http://www.troubleshooters.com/28
>>>
>>>
>>> ---------------------------------------------------
>>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
>>> To subscribe, unsubscribe, or to change your mail settings:
>>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>>
>>
>>
>>
>>
>
>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss
(text/plain)
