Debian May Need To Re-Evaluate Its Interest In "Init System Diversity"

[oiaohm]

You are correct, I did. There is statistical correlation between LoC and software bugs. More LoC, more bugs. Of course, there are other aspects too, like how often the code gets rewritten/re-factored, it's age, who's the developer(s), coding style and so forth.

There is a statistical correlation between lines of code and number of bugs in the big picture. Items like sel4 buck that trend as in having a lot higher line count due to having a full mathematical proof of functionality right down did the compiler spit out correct machine code. So a lot large code base can equal a lot lower bug count.

The statistical correlation between LoC and bug count are based on older coding methods. More modern with correct test casing and auditing code the large code base can equal lower bugs. You have to have lines of code to put that stuff in.

And same idea has also been discarded lots of times. Why? Requirement for glibc. Then systemd would be mainly beneficial only if embedded device in question has lots of services with complex dependencies.

Even allowing for glibc overhead putting systemd cutdown head to head with busybox/bash built on musl you still have a higher memory foot print.

There is a reason for glibc and its horrible. Linux kernel header files are not always libc netural. They are meant to be but they are not always. They are tested always with glibc.

https://wiki.musl-libc.org/functional-differences-from-glibc.html

Next is the quriks between the different libc.

So supporting more than glibc equals a lot more workload..

How many such are around, besides smartphones/tablets (which running generally Android, don't use glibc).

And normally running out of date Linux kernels. Yes the fact Android is not using glibc does not help here. So soc vendor attempt to move Android core to a new kernel and crud the headers to userspace don't work with bionic libc. Yes this is a factor for delayed kernel updates on Android

Choosing not to use glibc on the Linux kernel does bring some serous problems that need serous resources to address.

In case of problems, debugging systemd in embedded device would be copper-plated bitch.

In fact no. There is very little difference debugging device with embedded systemd or sysvinit you go into both devices by jtag. With sysvinit you can look up a process table. With systemd you can look up a process table and cgroup tree. Its a lot simpler with the device using systemd to see what is what because you have more detailed information on what started what process that is now eating all the devices resources and causing it to stall out.

How often have you seen it actually done in most used Linux distributions?

I work with embedded stuff so seeing cut down systemd is a daily thing for me.

Systemd in these tends to come like a kitchen sink. Which still retains the problems I claim.

Really no. Most distributions default installs of sysvinit were also kitchen sink messes as well. Like installing sysvinit do you really need bash, dash and awk? There are a lot of tools that installing sysvinit on most distributions would result in being installed as well just because you may need it to run a sysvinit script.

So there has been a very big problem for a long time of distributions kitchen sinking the init system. Yes systemd as a single package when it does not need to be is just another example of this on going problem.

cgroups as they are in Linux are IMHO completely braindead approach. Yeah, glorious idea.. add more and more layers of security, until it's impossible to understand what privileges particular process might have, you are going to finally end up with mystery black box.

There is a big difference between what version of cgroups. Cgroup v1 was a braindead mess that really was a mystery blackbox. cgroup v2 there is only a single tree in the cgroup system. This single tree makes it very clear what has what permissions. There is way less of a black box than using Linux security modules particularly now that they multi stack.

Well, now they are. And currently they have still much better track record in security than Linux (or other BSD's for that matter). Because paradigms differ. Linux sacrifices security knowingly for better performance and more features.

Please note you said paradigms differ this is not a lines of code difference.

"Newer" and "modern" does not automatically equal "better". It should first actually be proven to be better. "KISS Principle" on the other hand, is time-proven.

https://despair.com/products/tradition

You reminded me of this poster. Tradition "Just because you've always done it that way doesn't mean it's not incredibly stupid."

KISS Principle has come a Tradition. Sel4 code audit process broke that tradition and proved that by going more complex you could audit the code base faster and more exactly than a human could.

What about using some other shell.

The shell restrictions are forced by sysvinit compatibility. That you need to support legacy applications. Systemd decided to deal with this problem where you had to use insecure crap by sand-boxing the insecure crap.

What about using some other init.

Again are you going to break legacy application support. What ever init you choose needs sysvinit compatibility.

What about NOT using shell at all in the init process.

A pure systemd system in fact does that where the service are in fact all started without using shell scripts or shell at all. This was one of the objectives of systemd to get rid of shell out of the init system.

You keep presenting your arguments with the assumption that "only sysvinit and bash are possible alternatives". I could technically run any other shell I like, finding more secure one or do away with the shell and use some interpreter instead, let's say Lua.

No you are not getting it. Being legacy compatible you have to have a plan to deal with the insecurity problems of sysvinit.

eek, and horrible complex pile of slop of incomprehensible code within systemd? With a lot of features crammed into systemd over the years, which could potentially be as well highly dangerous.

Notice you talked against cgroups. You have not noticed that systemd puts cgroups around its own provided parts with more and more security things set to decrease the security problems. So systemd is less dangerous than a sysvinit solution before the parts were taken up by systemd.

Big change that systemd does is making sandboxing around services the normal.

Insecure mess that sysvinit is with more parties running with high privilege than systemd was not good. Yes systemd is more complex but the complexity is what is required to address a KISS caused disaster of being too simple.

Agree. And systemd is already sabotaging potential future competitor by trying to entice other devs use it's offered API's. So that ditching it would be increasingly hard as the time would progress. So, competition would also have to be better designed AND emulate systemd for external software too.

Sysvinit changes also were sabotaging potential future competitors before systemd. The reality replacing the default init is always going to be a uphill battle. Its not like systemd changes this.

[aht0]

1 I was not the one who based argument on lines of code.

You are correct, I did. There is statistical correlation between LoC and software bugs. More LoC, more bugs. Of course, there are other aspects too, like how often the code gets rewritten/re-factored, it's age, who's the developer(s), coding style and so forth.

Like or not embedded developers have sized up systemd multi times. Systemd many build options that distributions don't get.

And same idea has also been discarded lots of times. Why? Requirement for glibc. Then systemd would be mainly beneficial only if embedded device in question has lots of services with complex dependencies. How many such are around, besides smartphones/tablets (which running generally Android, don't use glibc). In case of problems, debugging systemd in embedded device would be copper-plated bitch.

This is the scary thing systemd can at build time have features removed. The smallest functional systemd is smaller than dash/bash. Yes that has fun cgroups around services timers and other things.
systemd removing functionality to improve security is in fact a option.

How often have you seen it actually done in most used Linux distributions? Systemd in these tends to come like a kitchen sink. Which still retains the problems I claim.
cgroups as they are in Linux are IMHO completely braindead approach. Yeah, glorious idea.. add more and more layers of security, until it's impossible to understand what privileges particular process might have, you are going to finally end up with mystery black box.

So on lines of code in a solution if you cut systemd to size with build options systemd wins over sysvinit every single time. Lines of code for security is a really bad metric.

It's good-enough metric for me.

OpenBSD claim is also bogus thinking they were backing openssl and other over-bloated items that had not been properly code audited.

Well, now they are. And currently they have still much better track record in security than Linux (or other BSD's for that matter). Because paradigms differ. Linux sacrifices security knowingly for better performance and more features.

Sel4 method of code auditing/developing is modern newer than OpenBSD development rules.

"Newer" and "modern" does not automatically equal "better". It should first actually be proven to be better. "KISS Principle" on the other hand, is time-proven.

Those results are interesting. IOT devices that have been fuzzed if the item is sysvinit exploits are more likely than systemd ones. The danger of a shell is overlooked.
Lets say something makes the choice of using bash as there shell in a iot device because that is what the sysvinit scripts they have to work with.

https://www.tldp.org/LDP/abs/html/devref1.html

Yep bash has direct means to use TCP. So can download stuff straight from initnet
Lets say we go busybox including command wget so infection can still download more.
What about the alternative toybox it has wget as well.
So how are you going to run your sysvinit without making it a security disaster.

What about using some other shell.
What about using some other init.
What about NOT using shell at all in the init process.

You keep presenting your arguments with the assumption that "only sysvinit and bash are possible alternatives". I could technically run any other shell I like, finding more secure one or do away with the shell and use some interpreter instead, let's say Lua.

The shells sysvinit solutions depend on are a horrible complex pile of slop of incomprehensible code. With a lot of features added to shells over the years that come highly dangerous.

eek, and horrible complex pile of slop of incomprehensible code within systemd? With a lot of features crammed into systemd over the years, which could potentially be as well highly dangerous.

It a surprise to a lot people that in lines of code you need to use to start a system with systemd is quite light. Systemd in a lot of ways does not have too many lines of code for what it does. Systemd in most cases does not have enough lines of code its too small. One thing about poorly coded code is that is can be ultra compact.

And again, since most are users and just use what's provided, they don't get the "light" version. Like ever.

We are in real need of a properly designed from the ground up secure init and service management.

Agree. And systemd is already sabotaging potential future competitor by trying to entice other devs use it's offered API's. So that ditching it would be increasingly hard as the time would progress. So, competition would also have to be better designed AND emulate systemd for external software too.

[oiaohm]

You base your argument first on a purely hypothetical guess (a), then proceed claiming that systemd has less code than this 'hypothetically equally functional' sysvinit would have (b).. And because of this, systemd is certainly more secure? That's one solid argument there.
Question tho: do most people need most features by systemd? Or not? Because they do get all it's potential risks regardless.

1 I was not the one who based argument on lines of code.

Like or not embedded developers have sized up systemd multi times. Systemd many build options that distributions don't get.

Of course I would like to see init system with better security design from the get go right down to using sel4 mathematically secured in code off the start line.

This line of min is because I am not happy by systemd construction.

For some reason 'sel4' is not the path chosen by OpenBSD folks, who are chasing namely security. They are doing it by keeping code base minimal, auditing it relentlessly and REMOVING features they think either not needed or potentially risky. So, which approach is more secure?

This is the scary thing systemd can at build time have features removed. The smallest functional systemd is smaller than dash/bash. Yes that has fun cgroups around services timers and other things.

So on lines of code in a solution if you cut systemd to size with build options systemd wins over sysvinit every single time. Lines of code for security is a really bad metric.

Systemd removing functionality to improve security is in fact a option. OpenBSD claim is also bogus thinking they were backing openssl and other over-bloated items that had not been properly code audited.

Sel4 method of code auditing/developing is modern newer than OpenBSD development rules.

Ok, but systemd makes -no- attempt to abstract internal interfaces. It's a horrible, completely incomprehensible mess of spaghetti code. Sure it has less lines of code, but it damn sure isn't elegant. It's a horribly complex pile of slop. Incomprehensible code has no chance in any hell of being secure. I would love to see some fuzzing results.

Those results are interesting. IOT devices that have been fuzzed if the item is sysvinit exploits are more likely than systemd ones. The danger of a shell is overlooked.

Lets say something makes the choice of using bash as there shell in a iot device because that is what the sysvinit scripts they have to work with.

https://www.tldp.org/LDP/abs/html/devref1.html

Yep bash has direct means to use TCP. So can download stuff straight from initnet
Lets say we go busybox including command wget so infection can still download more.
What about the alternative toybox it has wget as well.

So how are you going to run your sysvinit without making it a security disaster.

The shells sysvinit solutions depend on are a horrible complex pile of slop of incomprehensible code. With a lot of features added to shells over the years that come highly dangerous.

It a surprise to a lot people that in lines of code you need to use to start a system with systemd is quite light. Systemd in a lot of ways does not have too many lines of code for what it does. Systemd in most cases does not have enough lines of code its too small. One thing about poorly coded code is that is can be ultra compact.

Big thing with systemd is all the parts you need to init and service manage a system are in fact included in 1 project so you get to see how many lines of code you are in fact using really clearly. The number of lines of C and other parts sysvinit solutions need to work is a lot bigger than the scripts its really simple to forget to count the shell and the add on programs that those scripts are using.

We are in real need of a properly designed from the ground up secure init and service management.

[aht0]

Ok, but systemd makes -no- attempt to abstract internal interfaces. It's a horrible, completely incomprehensible mess of spaghetti code. Sure it has less lines of code, but it damn sure isn't elegant. It's a horribly complex pile of slop. Incomprehensible code has no chance in any hell of being secure. I would love to see some fuzzing results.

I think you meant to quote the other guy

[duby229]

You base your argument first on a purely hypothetical guess (a), then proceed claiming that systemd has less code than this 'hypothetically equally functional' sysvinit would have (b).. And because of this, systemd is certainly more secure? That's one solid argument there.
Question tho: do most people need most features by systemd? Or not? Because they do get all it's potential risks regardless.



For some reason 'sel4' is not the path chosen by OpenBSD folks, who are chasing namely security. They are doing it by keeping code base minimal, auditing it relentlessly and REMOVING features they think either not needed or potentially risky. So, which approach is more secure?

Ok, but systemd makes -no- attempt to abstract internal interfaces. It's a horrible, completely incomprehensible mess of spaghetti code. Sure it has less lines of code, but it damn sure isn't elegant. It's a horribly complex pile of slop. Incomprehensible code has no chance in any hell of being secure. I would love to see some fuzzing results.

[duby229]

Wow, I've read some truly dumb shit in this thread, "the one true way", "deunixification", "systemd is a init", "security through complexity".... jesus fuckin christ! Are systemd zealots really this fuckin stupid??? Apparently yes...

[MartinN]

Wait what? A single init system reduces maintenance burden? And multiple init systems actually increase it? Developer time is not infinite and free? Really?

Shock horror. We've been only saying this for like 5 years. The delusional guys at Devuan et al feel free to toy around for a few years more. Delaying the inevitable sure is a fruitful effort, time well spent. Let the duplication of efforts continue!

The one thing, and I won't be humble here at all, that most tech/nerd types lack is humility and they collectively seem to suffer from NIH, and I don't think it gets better with age either, they just get more coy about it.

[aht0]

There is a horrible reality here if you in fact totally up all the lines of code to make a sysvinit system have all the features that systemd provides its in fact 40 times the number of lines of code of systemd (a). Yes systemd is in fact smaller that what it has replaced. So less code, less potential bugs and more security is in fact in systemd (b) favor over sysvinit solutions.

You base your argument first on a purely hypothetical guess (a), then proceed claiming that systemd has less code than this 'hypothetically equally functional' sysvinit would have (b).. And because of this, systemd is certainly more secure? That's one solid argument there.
Question tho: do most people need most features by systemd? Or not? Because they do get all it's potential risks regardless.

Same with a lot of the other broken solutions. Openrc maybe able to be competitive when with the same features as systemd on lines of code.
Of course I would like to see init system with better security design from the get go right down to using sel4 mathematically secured in code off the start line.

For some reason 'sel4' is not the path chosen by OpenBSD folks, who are chasing namely security. They are doing it by keeping code base minimal, auditing it relentlessly and REMOVING features they think either not needed or potentially risky. So, which approach is more secure?

[oiaohm]

To the latter.. Lol what? Rule of thumb: less code, less potential bugs, more security. Few million loc internally interlocked APIs, kept intentionally obscure and in constant change - to make harder not to use systemd is somehow "secure" for you?? Holy naivety..

There is a horrible reality here if you in fact totally up all the lines of code to make a sysvinit system have all the features that systemd provides its in fact 40 times the number of lines of code of systemd. Yes systemd is in fact smaller that what it has replaced. So less code, less potential bugs and more security is in fact in systemd favor over sysvinit solutions.

Same with a lot of the other broken solutions. Openrc maybe able to be competitive when with the same features as systemd on lines of code.

Of course I would like to see init system with better security design from the get go right down to using sel4 mathematically secured in code off the start line.

[aht0]

I wait for the day when Linux software stops resisting change and integrate better with systemd.
It brings So Many features that Linux needs, especially when it comes to security...

To the former, Linux software is an epithome to a change. To the ridiculous idea of change for the sake of change itself. New features are more important than fixing older issues. Nature of the evolutionary software. You just keep forgetting that evolution itself is Darwinian in principle - mutate too far or specialize too deeply and your resounding success might become story of extinction when conditions change. Because you can no longer neither turn back or adapt yet more. It's also a path of spiraling history and making same mistakes over and over again.

To the latter.. Lol what? Rule of thumb: less code, less potential bugs, more security. Few million loc internally interlocked APIs, kept intentionally obscure and in constant change - to make harder not to use systemd is somehow "secure" for you?? Holy naivety..