641–650 of 902 posts
Earlier quoted context omitted.
is it? most HPC (if GPU clusters count) are probably in industry and managed by containers
HPC admin here. Yes. First, we use user level container systems like apptainer/singularity, and these containers run under the user itself. This is also same for non academic HPC systems. From schedulers to accounting, everything is done at user level, and we have many, many users. It won’t change anytime soon.
Earlier quoted context omitted.
Agreed. I've taken to treating my linux installs like I used to treat Windows: no internet access expect application specific. For example, I run a Visionfive 2 OpenBSD install with squid, everything else has to go through that.
Curious why squid and not pf?
Earlier quoted context omitted.
What widgets? Gnome has just the one black bar at the top.
And it's a thick monster with all kinds of extra crap (I'm my not so humble opinion) shoved in it.
Earlier quoted context omitted.
> First, getting rid of setuid (I guess you'd have to get rid of the whole thing, not just the permission bit) is not the same as making systemd an integral part of the OS. It absolutely is. sudo allows you to execute code as another user. If you want to do that without giving sudo itself administrative privileges, this has to be done through the service manager, which creates a completely new, elevated process and h…
Decoupling/single-reponsibility is sort of lesson #1 in software engineering. > then come up with a better one. Really?
Well said. What makes you think systemd does not do this? Have you ever even looked at systemd in any amount of detail? Do you think it is one big binary running as PID1 doing everything?
Earlier quoted context omitted.
I’m not sure how “I don’t have to actually think about any of the separation” meshes with the fact that you explicitly setup multiple users and configured file and group permissions accordingly. You clearly put a lot of thought into it. Alternatively, containers really are a no-thinking-required solution. Everything maximally isolated by default.
There have been no big cves of container escapes for a while now. I guess it can be considered secure enough.
Earlier quoted context omitted.
And I disagree with that. The 'sudo problem' is a good example why it makes sense to handle init and login by the same system (note I'm not meaning "same binary" here, in fact, they are separate binaries in systemd). The SUID approach for sudo has been a problem for decades, and it needs to go. I don't really care if it's done by systemd, or if we agree on another system like S6 that was mentioned in another thread -…
I agree with u/constantcrying. This should not be part of systemd. It should be a separate service [started by systemd]. Reasons: - systemd is a large beast -- no need to make it larger with unrelated things - the Unix philosophy seems to be applicable here - the result should be portable to non-systemd systems
I think I sufficiently explained why it is very much related.
> the Unix philosophy seems to be applicable here
Systemd very much follows the unix philosophy. It is not one big binary, but actually consists of dozens and dozens of tools communicating with each other through protocols.
> the result should be portable to non-systemd systems
Portable on what basis? POSIX?
I think we're entering a point where GNU/Linux should be called Systemd/Linux
Earlier quoted context omitted.
> There is absolutely no reason to tie your new sudo replacement to systemd It is said right there: the reason is to avoid the awkward SUID issues, and to have a privileged process create the process.
Instead you get awkward state management issues. Will the child really inherit everything it needs from the parent or has systemd forgotten to transmit something? If I chroot and then run0 will that process also run in the chroot? What about systems with older versions of systemd?
> If I chroot and then run0 will that process also run in the chroot?
That's an interesting question and it's not quite clear to me what should be the answer. For example, one legit answer might be that it would not work at all (in which case you would need to use some other tool that fits your needs), or another would be that the policy can decide what to do in that case.
But wouldn't you agree that it is better security hygiene to explicitly opt-in to inheriting properties when going to an elevated security level, instead of opting out from them?
Earlier quoted context omitted.
# journalctl -f _PID=${your_pid} # option 1 # systemctl status ${your_pid} # option 2 [1]: https://www.freedesktop.org/software/systemd/man/latest/jour... [2]: https://www.freedesktop.org/software/systemd/man/latest/syst...
These absolutely SUCK as answers to that question. They entirely miss the point. They provide a specific answer to a general problem. The problem with systemnd is it assumes that it's possible for all needs to be predicted and accounted for ahead of time. While "look around at directories and files, and grep within them" works after the fact without any special knowledge or tools. The person who wrote the log file di…
Earlier quoted context omitted.
I wouldn't be affected regardless, because SSH doesn't depend on my init system.
The attacker had essentially full control over a very fundamental library in the Linux ecosystem. They could have leveraged that in a hundred ways. The attacker chose to target a very specific component of a very specific system. It was their choice, not some sort of technical requirement that made it impossible to use a different attack vector. Just as they chose not to target other Linux distributions that use syst…
Now I want you to imagine that every piece of software has a score, which tells you how useful it is to hackers. Systemd has a high score, and hence it was chosen for this attack. Your argument is that: there are other pieces of software with a high score so it's fine for Systemd to also have one, since without it there would be other things to attack. My argument is that we should reduce the amount of software that has a high score. Do you think my reasoning or your reasoning will lead to a more secure ecosystem?