Advantages of systemd over sysVinit

[f33dm3bits]

most of you with systemd would have been exposed. I would not have been. For me,

The ssh backdoor discovered in xz utils was specifically designed to exploit systems where the openssh server is installed and reachable from the internet, which the latter is not the case for most desktop users. Sure if they had either physical access or access through through another vulnerability already then they could have used it escalate their privileges.

SysV (or whatever init system you use) can just as easily be compromised by a "helper" tool because all Linux systems rely on these helper tools because remember. Linux is only the kernel. The kernel itself. Is NOT an operating system.

Do you think in an issue like this in the BSD projects is less likely to happen because of BSD being developed as a full os?

 

[dcbrown73]

Do you think in an issue like this in the BSD projects is less likely to happen because of BSD being developed as a full os?

Honestly, there are humans developing these operating systems. Not only can humans' make mistakes, but they can also have "agendas" as happened here with this planned out scheme with xz.

So, by default. The answer is most definitely, yes.

Look at pfsense and when pfsense paid ugh, what was his name to add Wireguard to pfsense and then pfsense had no choice, but to rip it out. This is what I meant in my last post that it wasn't a systemd (or replace with whatever app name here), that it was a code management issue.

The BSD community came together to review the Wireguard code that was added to pfsense when it was submitted to the BSD community and they ended up rejecting it.

That is what should have happened to the xz codebase. These flaws were detected by valgrind (at first and again by Microsoft), but when the issue was raised. The developer made excuses as to why they were there, and the process broke down and they didn't follow up. At least not until someone else outside of that process (Microsoft with valgrind again) detected the "curious" anomalies.

At work, we are implementing all kinds of code control tools in our DevOps / GitOps processes. Code gets scanned by 4-6 different scanners which helps us release safer, cleaner code. Soon, we will all be safer because of tools like these, but there is a process and that process can break down. (not to mention, there is no such thing as 100% secure)

 

[The Duck]

^^^.....that from @CaffeineAddict

I know close to zero re init
probably not much more re systemd

What I DO know is......IT WORKS.

I have a PC which brings a smile to my face, every day. That is no mean feat.

Onward & Upward, LINUX.

I'm right there with ya as for not knowing much about either.

What I know is I'm using two different no systemd Linux distros and both are working great.

 

[MikeWalsh]

@The Duck :-

I'm right there with ya as for not knowing much about either.

What I know is I'm using two different no systemd Linux distros and both are working great.

With ya there, buddy. Puppy has never used systemd, has always used a "home-brewed" init based on SysVinit.......and has, to the best of MY knowledge, always performed admirably.

But perhaps I'm not very demanding! (Either that, or I simply don't care one way or t'other...)

In the Puppy community, we have many individuals that have an interest in, and specialise in different aspects of the OS. Some ARE more concerned with what makes the system "tick" than in what they can actually DO with it; in my case, I'm more interested in what the user can run on top of the OS. Both are equally important, of course; without a functional OS under it, software is no earthly good. Equally, however, without useful software the OS itself is about as much use as a chocolate teapot.....

~~~~~~~~~~~~~~~~~~~~~~~~​

Many members occasionally ask how to get certain apps running; when you look into it, often systemd is required - or at least, certain bits of it. We'll experiment, find out what's what, add the bits of systemd that appear to be needed, and 99 times out of 100 things will then work. As a hobbyist community, this is all grist to t'mill......just part of a day's work for us.

Each to their own, of course.......but I do like that we can have sensible discussions around all this kind of stuff here at Linux. org, without it devolving into a flame-war & name-calling. It's quite refreshing!


Mike.

 

[The Duck]

@The Duck :-


With ya there, buddy. Puppy has never used systemd, has always used a "home-brewed" init based on SysVinit.......and has, to the best of MY knowledge, always performed admirably.

But perhaps I'm not very demanding! (Either that, or I simply don't care one way or t'other...)

As long as it works when I need it to is what I care about.

Yeah maybe at one time I did want to know the whys and hows it all works.

These days nah.

Each to their own, of course.......but I do like that we can have sensible discussions around all this kind of stuff here at Linux. org, without it devolving into a flame-war & name-calling. It's quite refreshing!


Mike.

It is quite refreshing isn't it.

 

[ron.alan]

SysV (or whatever init system you use) can just as easily be compromised by a "helper" tool because all Linux systems rely on these helper tools because remember.

Sure, I know that. But the fact is that it wasn't targeted by this specific backdoor. Why is that?

I will let you figure out which it is as I'm not looking to argue.

Neither am I. I am putting this thread to rest (for me).

 

[KGIII]

Sure, I know that. But the fact is that it wasn't targeted by this specific backdoor. Why is that?

Because you go for the widest attack possible, impacting the most systems you can.

Pretty simple, really. This could have happened with a zillion other components. It's a social engineering hack more than anything else. It was clever, but nothing all that special.

Neither am I. I am putting this thread to rest (for me).

Probably for the best, but it didn't seem right to leave it with a question that had such a simple answer.

 

[ron.alan]

Because you go for the widest attack possible, impacting the most systems you can.

Yes, I already knew the answer. There's safety in obscurity.

One reason why I don't use a distro with systemd.

 

[KGIII]

There's safety in obscurity.

STO can be included in security, albeit a weak security by itself. I'll assume you're smart enough to not rely on STO by itself.

Here's a well-regarded paper on the subject:

CWE - CWE-656: Reliance on Security Through Obscurity (4.14)

Common Weakness Enumeration (CWE) is a list of software weaknesses.

cwe.mitre.org

 

[ron.alan]

Interesting write-up, but that's not what I meant. I meant exactly what you wrote, that someone who is trying to slip a backdoor into the wild is going to try for the "widest attack possible, impacting the most systems . . . ." (That's why I didn't write "security through obscurity," but safety in obscurity.)

In other words, systemvinit is no longer the most widespread init system, so an attack through it would be counter-productive for all the bad actors out there.

 

[dos2unix]

It appears Debian is jumping om the systemd bandwagon.

Adding systemd-boot support in debian-installer

I never realized until I read that post that Debian doesn't currently support secure boot.

 

[GatorsFan]

My Expirion Linux has no systemd but uses SysVInit since it is Devuan based - personally I think SysVInit is a little faster then systemd since it uses less RAM - you can argue which is better all day long - but I think in the end it just a personal preference thing - whatever works for you

 

[CaffeineAddict]

I never realized until I read that post that Debian doesn't currently support secure boot.

Debian does support secure boot but it might take additional effort to configure it.
on some hardware such as my MSI mobo there is no way to make it work due to buggy MSI function in UEFI.

 

[dos2unix]

Debian does support secure boot but it might take additional effort to configure it.

Apparently 12 does? Apparently 11 didn't?

If I go to 5 different websites, I get 5 different answers. Even from CoPilot.
I suppose I should just build a VM, then I would know for sure.

 

[CaffeineAddict]

I suppose I should just build a VM, then I would know for sure.

That's how I know it works, I'm using virtual UEFI with secure boot (OVMF) in a VM and it works.

Apparently 12 does? Apparently 11 didn't?

I think secure boot was supported since 10 or so.

You also need to manually sign your drivers like nvidia to be be able to boot.

If I go to 5 different websites, I get 5 different answers. Even from CoPilot.

Sadly info on the net is incomplete and doesn't cover all use cases.