Systemd Adds New "ProtectSystem Strict" Option, Other New Tunables

[jrch2k8]

When people say "UNIX like" they mean that it exposes the facilities of UNIX (VFS, TTY, the process abstraction, UNIX sockets, device files, core utilities, etc.) in the way UNIX exposes them; which is the case for GNU/Linux. I don't know how else you could think of it.

If you mean that it also has features that did not exist in UNIX, then sure; but Solaris had all of this shit a while ago and nobody is complaining.
Compared to how useful GNU/Linux is today, UNIX is a piece of crap; I don't see why anyone would consider it some golden ideal.

I think your interpretation can be right but the way i see it is more or less complicated depending your PoV.

Kernels as i see it have 2 big constructs:

1.) Kernel side API
2.) Kernel userspace API

so my problem with the "Like" definitions start here, any kernel regardless of its design can replicate(or export if it sound better) an kernel userspace API and for example, Windows do this with their Unix Layer on top on the NT kernel/userspace dark magic, Apple do something like this too between MACH and BSD, Solaris even had this on some form, So since all this kernels can provide a common userspace API, are they all like each other?

i particularly believe this is wrong, regardless of the API everything else is different and not all provide the same level of performance, stability, etc. So i consider a family of kernels should be judged as "Like" when its actual internal APIs are similar enough on mutually existant features.

If we judge Unixes and Linux using kernel side API they are not even 3rd political cousin related "Like" anymore but if we judge them using common existant userspace API basically almost every kernel outhere is "Unix Like" this days. so i preffer the first since i consider it's more accurate.

Of course there is a truckload of other parameters to use but well i don't wanna go too deep on this since i don't care about it enough this days

[ssokolow]

I am feeling like this should be the default. With this approach, packages for an given software are responsible for providing the scripts that lock them down. If it was the other way around (I.E, like android manifest), they would request access to some parts of the system, making it way easier to identify rogue services.
Or am I wrong?

That said, it would probably break backward compatibility if it was enforced. Maybe a progressive switch?

That's basically what's going on.

SystemD provides a layer that's less than idea but can cover the system with, at most, distro packager tweaks. Meanwhile, projects like Flatpak work on providing an APK analogue that projects can switch over as the required features become available.

(eg. Flatpak plans to offer an API where the application can access the filesystem outside its sandbox by asking the sandbox system to present the user with an Open/Save dialog outside its control and then receiving an open file handle in return... similar to how in-browser apps get local file access)

If you want to write your own per-application sandboxing without waiting (or use application profiles written by others), I know of two "run this in a sandbox" utilities:

Firejail is the most featureful solution here and now, but runs more code setuid.

Bubblewrap was split out from Flatpak to be the most minimal setuid core possible. There's a lot of functionality it will never have because "that can be handled purely in un-privileged code, so that's Flatpak's job". (Stuff like PulseAudio security)

[xeekei]

Systemd really needs to change their name. Everytime they add something people think the actual init system is getting something new. I'm sick of these threads. Isn't Btrfs the new thing to fight about?

[starshipeleven]

Systemd really needs to change their name. Everytime they add something people think the actual init system is getting something new. I'm sick of these threads. Isn't Btrfs the new thing to fight about?

That's the same for many linux kernel features threads. People shouting about "bloat" when it's something that in 90% of the distros won't even be compiled in.

[Guest]

I think its the wrong direction for you guys to take but there are some in the Linux community that have a a total lack of respect for Unix. It's extreme hubris to believe that there is so much innovation past Unix in Linux when it's lacking so much. Every once in a while its good to peek outside your echo chamber and get some air.

I've got something better for you: BSD don't give a shit about 'true' Unix. Unix is dead. Probably every modern system moved years ahead of the one you're calling 'unix'. But wait! You can always use crap like os x which is considered as 'unix' todays. However, they're using init system similar to systemd.

[jacob]

Can we just say that Linux is no longer a "Unix like" operating system?

I wish it was the case...

[unixfan2001]

Now I don't know what *bonehead* decided to make the system log a binary proprietary thing

1. It's not proprietary.
2. In a way, text files are binary too.
3. The way journald works is based on the utmost basic security principles. Logs you (or, more importantly, an intruder) can rewrite on demand and with nothing more than "cat" or an instance ov vi(m) are useless!
4. Good luck reading a massive, largely unformatted text log. Let alone parse it.

I think its the wrong direction for you guys to take but there are some in the Linux community that have a a total lack of respect for Unix.

"Those who don't understand UNIX are doomed to reinvent it poorly."

I think that sentence applies nicely to you and all the other people who whine about systemd not being Unix-like, when it is defacto more Unix-like than everything mustered by the BSD people.

Your beloved sysvinit is nothing more but a poor-man's Windows autostart. As is the rest of your architecture. Complete, Windows-like crap, with "choice" as the often touted excuse for not offering sane standard solutions by default.

Every once in a while its good to peek outside your echo chamber and get some air.

Personally, I think you should follow your own advice there.

[unixfan2001]

Now I don't know what *bonehead* decided to make the system log a binary proprietary thing

1. It's not proprietary.
2. In a way, text files are binary too.
3. The way journald works is based on the utmost basic security principles. Logs you (or, more importantly, an intruder) can rewrite on demand and with nothing more than "cat" or an instance ov vi(m) are useless!
4. Good luck reading a massive, largely unformatted text log. Let alone parse it.

I think its the wrong direction for you guys to take but there are some in the Linux community that have a a total lack of respect for Unix.

"Those who don't understand UNIX are doomed to reinvent it poorly."

I think that sentence applies nicely to you and all the other people who whine about systemd not being Unix-like, when it is defacto more Unix-like than everything mustered by the BSD people.

Your beloved sysvinit is nothing more but a poor-man's Windows autostart. As is the rest of your architecture. Complete, Windows-like crap, with "choice" as the often touted excuse for not offering sane standard solutions by default.

Every once in a while its good to peek outside your echo chamber and get some air.

Personally, I think you should follow your own advice there.

[interested]

"Those who don't understand UNIX are doomed to reinvent it poorly."

I think that sentence applies nicely to you and all the other people who whine about systemd not being Unix-like, when it is defacto more Unix-like than everything mustered by the BSD people.

What exactly Unix is may be open for various interpretations, but you have an interesting point. In many ways systemd is far more "Unix" than eg. SysVinit systems ever was. Like obeying the "Rule of Repair" (not allowing a system with missing essential disks to boot because that may lead to silent data corruption), or the "Rule of Generation" that basically states that SysVinit and friends are anti-Unix designs, since you should avoid hand-hacking, and let programs generate code instead, just like systemd does.

It is quite clear that the systemd developers knows their Unix stuff well.

[starshipeleven]

What exactly Unix is may be open for various interpretations, but you have an interesting point. In many ways systemd is far more "Unix" than eg. SysVinit systems ever was. Like obeying the "Rule of Repair" (not allowing a system with missing essential disks to boot because that may lead to silent data corruption), or the "Rule of Generation" that basically states that SysVinit and friends are anti-Unix designs, since you should avoid hand-hacking, and let programs generate code instead, just like systemd does.

It is quite clear that the systemd developers knows their Unix stuff well.

Oh noes, I thought this "Unix philosophy" thing was bullshit the anti-systemd crowd came up with...
By looking up the rule names you cited...
It actually exists, it actually makes sense, and it even spanks sysvinit and similar turd hard. Now I'm going to drop these things from the orbit on anyone that dares mention Unix against systemd.

https://en.wikipedia.org/wiki/Unix_philosophy

Rule of Repair
Developers should design programs that fail in a manner that is easy to localize and diagnose or in other words “fail noisily”. This rule aims to prevent incorrect output from a program from becoming an input and corrupting the output of other code undetected.

Rule of Generation
Developers should avoid writing code by hand and instead write abstract high-level programs that generate code. This rule aims to reduce human errors and save time.

Also there is also:

Rule of Modularity
Developers should build a program out of simple parts connected by well defined interfaces, so problems are local, and parts of the program can be replaced in future versions to support new features. This rule aims to save time on debugging code that is complex, long, and unreadable.