Live data from Hacker News

Run0, a systemd based alternative to sudo, announced

mastodon.social

771–780 of 902 posts

Re: Run0, a systemd based alternative to sudo, announced

#771
post #663

Earlier quoted context omitted.

The complaint is that the code architecture of systemd results in security problems for their _customers_. The inclusion of a library to send notifications shouldn't have external dependencies, it shouldn't need them. The library is included in the customer's codebase at execution time, so it is a hole in the customer's security model. This immediately opens a supply chain attack vector (which is what we saw). This i…

"Systemd is bad because Debian patched OpenSSL to add an unnecessary dependency on a systemd library" is just not a good argument, sorry. Nothing about the "code architecture" of systemd caused the xz issue. And again, Poettering's complaint with sudo is specifically about it being a SUID binary, so this discussion isn't even related to the thing you're accusing them to be hypocritical about... SUID is more than just…

By "code architecture" I mean the packaging of their client libraries.

This attack demonstrates that they should be tightly focused and have minimal downstream dependencies.

I don't have any experience with systemd, but typically, people will bundle _all_ of their client libraries into one .so and say "use that".

However, what needs to happen is there should be multiple .so's, one for each sub-API. At least there should be libraries for frequently used shim code (like notifications seems to be).

Then systems that need to push information don't need to pull in the dependencies for other parts of the overall systemd interface.

I can't think of a reason why pushing local notifications would require a compression library. The notifications should be information heavy already, so not very compressible.

As I said, it's a growth and project age thing. One moment you're on one side of a line, the next you have to skill up and do things differently.

How the team responds is what is important. That is why people are objecting to the SUID work. Not because sudo isn't a hole, but that the systemd team isn't considered responsive enough to take it on.

I know I'm taking lessons from this to my work. It's an unpleasant mirror for me to look in.

Re: Run0, a systemd based alternative to sudo, announced

#772

Earlier quoted context omitted.

> Just one example: https://github.com/systemd/systemd/issues/6237#issuecomment- ... 1. He gave a clear reason why it is how it is 2. He realizes it is/might be frustrating 3. even `adduser` will not allow it by default 4. The issue that it still runs the unit even with config errors has been addressed: https://github.com/systemd/systemd/commit/bb28e68477a3a39796... (~2 weeks after the issue was opened)

His reason, although clear, is also plainly wrong. Such usernames although bizarre may be encountered by SystemD so it shouldn't break when it sees them. Computer programs, particularly important ones, should be conservative in what they emit and liberal with what they accept and that means not breaking when they encounter weird but technically permissible usernames. His response should have been "Golly, that's a wei…

Disclaimer: I know nothing about the particular bug. Postel's Law has its tradeoffs, and its fuzzy lines are a nice place for security issues to arise.

Re: Run0, a systemd based alternative to sudo, announced

#773

Can someone explain what this is / how it works to someone who has done a considerable amount of programming but lacks this kind of operating system level knowledge? I was under the impression that ‘sudo’ was baked into the entire system. Like ‘cd’ or ‘ps’. How exactly can you just swap out sudo? Does that involve swapping out chmod as well?

sudo is just another program, it's not "baked in" as such. It just ships with many (not all) distros. I remember having to install it from repos in the past on a new system: https://github.com/sudo-project/sudo

Reminds me of an assignment I had at uni to implement sudo in C. You get elevated permissions using the setuid bit, and can verify the password of $USER against /etc/passwd.

Re: Run0, a systemd based alternative to sudo, announced

#774

Earlier quoted context omitted.

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…

When a hacker chooses to attack something, that isn't random. They had to look at a lot of different pieces of software, and decide which would be the best to attack. The choice in this case was Systemd. In other words, if you are looking to do malicious things, Systemd is helpful. 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…

The size of libsystemd is immaterial in the case of xz. The attackers had control of xz, and wanted to load it from sshd.

There's lots of projects that link xz, big and small. Patching sshd to include any of them would have implemented the backdoor.

Re: Run0, a systemd based alternative to sudo, announced

#775
post #381

Earlier quoted context omitted.

> and they're all portable... I think that portability is a deliberate anti-goal of systemd. > In contrast, if you want to use, say, run0, you must run systemd as PID 1, No, you must run something on pid 1 that implements the spec, similar to how musl can be used instead of glibc - they both implement the same spec. Run0 expects pid 1 to behave a certain way, much like my web browser expects web servers to behave a c…

> I think that portability is a deliberate anti-goal of systemd. Yes, and that is one of the things I dislike about it. (In fairness, the list of things I like about it and the list of things I dislike about it are both fairly long.) > No, you must run something on pid 1 that implements the spec, similar to how musl can be used instead of glibc - they both implement the same spec. > Run0 expects pid 1 to behave a cer…

Once upon a time, there was only one web browser too.

Re: Run0, a systemd based alternative to sudo, announced

#776
post #735

I wish systemd would die or just be just an init system. This whole thread is people suggesting vague and non obvious solutions to things that people already knew how to do with just linux utilities now with some weird other binary.

what a bizarre point of view.

everything other than "being an init system" is a compile time option in systemd, so your complaint is that ... other people are building OSes and turning these things on?

which OS are you working on that provides all these convenient features and large-scale integration of software with them, with code that isn't in systemd?

Re: Run0, a systemd based alternative to sudo, announced

#777

Earlier quoted context omitted.

We use Userify which manages multiple user logins (via SSH) and sudo usage.. there are definitely many, many use cases for teams logging into remote servers, and most security frameworks (PCI-DSS, HIPAA, NIST, ISO 27000) require separate credentials for separate humans. Sudo has some issues, but it works very well and is well understood by many different tools.

It could all be simplified and map one to one to your identity provider credentials at a higher level. Having a complicated user system on the servers makes it a problem.

Userify doesn't seem complicated.. it is just Linux users, created with adduser just like you'd type in at the command line: https://github.com/userify/shim/blob/master/shim.py#L227

Re: Run0, a systemd based alternative to sudo, announced

#778

Earlier quoted context omitted.

This is a perfect example of a choice that a developer makes to suit his/her personal preference and environment, believing that everyone does (or should) use their computer the same way. Which is sadly becoming a more common trend. I like the idea, but I don't think it should be on by default. The rest of us have just used root-specific shell prompts for the last few decades or so.

It's fine. Not every software needs to be infinitely configurable and open source just in case the configurations don't cover the needs of all. We need opinionated software, if you don't want to make any choice for me, you can't even give me an assembly editor for fear of forcing your CPU arch of choice.

I don't understand the part about the assembly editor, but I'm not sure I agree with the rest.

Whenever I hear someone describe their software as "opinionated," I have found what that usually means is that the developer thinks they are smarter than everyone else and all of the unfriendly attitude that usually comes along with that.

Whoever made the decision that run0 should turn your terminal red by default doesn't understand that there are practically infinite terminal configurations out there that this will interfere with or be outright incompatible with. My argument is that the decision comes from a place of ignorance of the sheer diversity of the users of the software, not from a place of, "we are so smart, and are the first ones to think of this feature."

Re: Run0, a systemd based alternative to sudo, announced

#779

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.

I thought most containers shared the same user, ie. `dockremap` in the case of docker.

I understand academia has lots of different accounts.

Re: Run0, a systemd based alternative to sudo, announced

#780
post #747

Earlier quoted context omitted.

Huh. I'm not at all a fan of how Poettering operates, but it's neither the ideas nor the implementation where I'd fault him. Well, it depends on what you mean by implementation, I guess; I'm talking about the core "how does it do its thing", not the interface by which you use it. I think Poettering has great ideas and great implementation. It's the execution and interface that are often terrible. If the square peg do…

you have the wrong view point. he just have a different opinion than you. he single handled managed to fool RH and all distros into turning Linux administration just like windows. systemctl list of services is so inspired by the atrocious windows' admin list of services (which have 3 fields supposed to describe the service, but they all just tell you the name again). it's no wonder his reward was a job at Microsoft.…

It's inspired by Apple's launchd.
Post reply on HN