Originally posted by andrnils
View Post
Announcement
Collapse
No announcement yet.
Debian May Need To Re-Evaluate Its Interest In "Init System Diversity"
Collapse
X
-
-
Originally posted by Alliancemd View PostI 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 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..
Comment
-
Originally posted by aht0 View PostTo 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..
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.
- Likes 1
Comment
-
Originally posted by oiaohm View PostThere 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.
Question tho: do most people need most features by systemd? Or not? Because they do get all it's potential risks regardless.
Originally posted by oiaohm View PostSame 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.
Comment
-
Originally posted by anarki2 View PostWait 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!
Comment
-
Originally posted by aht0 View PostYou 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?Last edited by duby229; 25 September 2019, 03:30 PM.
- Likes 1
Comment
-
Originally posted by duby229 View Post
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.
- Likes 1
Comment
-
Originally posted by aht0 View PostYou 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.
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.
Originally posted by aht0 View PostFor 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?
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.
Originally posted by duby229 View PostOk, 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.
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.
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.
Comment
-
Originally posted by oiaohm View Post1 I was not the one who based argument on lines of code.
Originally posted by oiaohm View PostLike or not embedded developers have sized up systemd multi times. Systemd many build options that distributions don't get.
Originally posted by oiaohm View PostThis 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.
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.
Originally posted by oiaohm View PostSo 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.
Originally posted by oiaohm View PostOpenBSD claim is also bogus thinking they were backing openssl and other over-bloated items that had not been properly code audited.
Originally posted by oiaohm View PostSel4 method of code auditing/developing is modern newer than OpenBSD development rules.
Originally posted by oiaohm View PostThose 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.
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 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.
Originally posted by oiaohm View PostThe 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.
Originally posted by oiaohm View PostIt 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.
Originally posted by oiaohm View PostWe are in real need of a properly designed from the ground up secure init and service management.
- Likes 1
Comment
Comment