Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Run0, a systemd based alternative to sudo, announced

mastodon.social

Post reply on HN
Print view View original

791–800 of 902 posts

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

#791

Post by Analemma_ »

1oooqooq wrote: post #752
sfink wrote: 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.…

I continue to be baffled at this widespread belief that Poettering somehow hoodwinked every single major Linux distro into accepting a shit product with, idk, hypnosis or something.

Is it not possible that systemd is simply better than the alternatives, and the distro owners are smart enough to notice that, instead of just wrapping themselves cultish mantras about The Unix Way and how anything which resembles a design used in Windows is bad by definition? Or could that not possibly be it and he must've used mind control magic.

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

#792

Post by bayindirh »

crabbone wrote: post #749
bayindirh wrote: post #730

Earlier quoted context omitted.

SUID mechanism doesn’t always “elevate to root”. It’s a mechanism to “run as another user” and with SGID allows great flexibility in user permission management. You can allow all kinds of (responsible) user switch tricks for multi-admin servers and multi-user systems. Focusing all of this to sudo and framing SUID as “just implemented to enable sudo” is not painting the correct picture. Moreover, removing SUID breaks…

All these ideas that tie permissions to a file completely fail when files need to be accessed either over network, or inside a container. I can see how the original authors didn't consider these cases, because they simply weren't there yet... but knowing what we know today: SUID is an awful idea.

Sorry for my ignorance, but what’s a scenario that you run a SUID/GUID binary from a network or a container?

If you access and run, it’s SSH or similar, so it works on the system scope. If it’s a container built correctly, it has its own users and isolation already, so it shouldn’t be able to fire any binary on your “base” system, and any effect is already in the container scope.

I have never had the need to SUID/GUID a non executable, and didn’t need to trigger something on the system inside a container in the last ~20 years.

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

#793

Post by lupusreal »

alserio wrote: post #772
lupusreal wrote: post #712

Earlier quoted context omitted.

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.

For sure, there are limits. In this particular case, maybe we say that SystemD shouldn't support weird usernames beginning with numbers, but the other half of the law should still apply. The conservative emission would be logging an error message, not running that unit file as root.

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

#794

Post by EvanCarroll »

AshamedCaptain wrote: post #692
tommiegannert wrote: post #246

This is playing on the difference between hoping that sudo does the right thing juggling setuid and capabilities, and having a strict IPC boundary between privilege levels. It sounds like a great use of systemd, for those who want to use it.

There's like 3 components involved in making setuid safe (the kernel, the dynamic loader, and your exec), and at least one of them wasn't doing its job correctly (the dynamic loader). IPC by definition involves a superset of these components. There's no reason to think that if you can't make a simple setuid binary safe, you can make IPC safe. IPC is an order of magnitude more involved. Specially because in order to g…

It's not clear why the request parser would have to be trusted. I assume you're just speaking about the call to execve running in context? That's not much of a request parser. At the point that you tell `run0` to launch a shell, you're not calling the actual commands to the shell the request parser, right?

I also think the notion of an untrusted client is kind of a hashed out thing. As said in the post itself, `run0` is an interface to `systemd-run`. `systemd-run` as a client may be more _involved_ but it doesn't seem like that has any relevance to whether or not it's more secure. It's a separate layer for the insecurity. While sudo is a single process, if it was two processes it wouldn't all have to run as root. That by necessity means something that was previously running as root isn't, which makes it more secure -- not less, right?

The actual elevator process is systemd itself which already runs as init on every machine you'll have `run0`. But by nature it's always the top of the process tree, it seems like it's _less_ complex to have systemd-init the immediate parent process. There are fewer thing that can leak into or be inherited by the spawned process.

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

#795

Post by nialv7 »

pessimizer wrote: post #424
nialv7 wrote: post #307

Earlier quoted context omitted.

Can you even hear what you are saying? Don't you find it ridiculous to blame the XZ backdoor on systemd, instead of the actual hacker? Even if systemd did not exist, the hacker would have just picked something else to infiltrate.

> Don't you find it ridiculous to blame the XZ backdoor on systemd, instead of the actual hacker? This is a great argument against all computer security. If you believe in securing your computer, you're supporting hackers. Because if you ever believe that a lock has failed, you're saying the thief is innocent; that's how logic works.

Well, you conveniently ignored half of my point. Even without ssh depending on systemd (dependency introduced by distro maintainers, not systemd, mind you), a backdoor in xz can still exploit your system in a myriad of ways.

And secondly, I would say even if nobody is going to blame me, I would still secure my systems. Why? To protect my data of course.

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

#796

Post by 0x457 »

crabbone wrote: post #751
yorwba wrote: post #626

Earlier quoted context omitted.

I don't know what your sudo does, but mine requires the --preserve-env flag if you want the new process to have access to all your environment variables. The thing you're saying is going to be an endless source of problems should already be an endless source of problems! (And I think I've been briefly confused by some missing environment variable once or twice so far.)

Even without the flag, sudo preserves a bunch of stuff. And it's not even consistent. Some implementations preserve locale setting, while others don't for example.

It depends on what options sudo us built with. Notably `--disable-env-reset` option.

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

#797

Post by gnufx »

richardwhiuk wrote: post #358
gnufx wrote: post #336

Earlier quoted context omitted.

Visit the research computing environment sometime, for instance. The libzma SSH compromise was considered very worrying, after all.

That didn't need multi-users.

No, but that's the case I've overwhelmingly seen over the decades. Anyway, are you going to redesign ssh not to require a user, for instance? I assume you wouldn't want sshd running as the putative single user.

[I'm all for replacing notions of privileges/permissions with capabilities.]

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

#798

Post by gnufx »

opless wrote: post #587
gnufx wrote: post #326

In fact, if factotum were implemented on Unix along with an analogue to the Plan 9 capability device, venerable programs like su and login would no longer need to be installed ‘‘setuid root.’’ — https://plan9.io/sys/doc/auth.html

Plan9port has factotum. Plan9 has a completely different security model. The Hostowner (usually Glenda) is essentially "root" and you're at the mercy of the filesystem regarding file privileges etc. AFAIK there is no way to "become" glenda.

I haven't followed Plan 9 for ages, but I'm puzzled why Cox & co wrote "Plan 9", then. However, the point was more about the capability-oriented security in a Unix successor, and how you can use file handles as a sort of cabability without the global namespace. (They're often quoted as examples capabilities in POSIX, but that's ignoring the global namespace.)

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

#799

Post by AshamedCaptain »

EvanCarroll wrote: post #794
AshamedCaptain wrote: post #692

Earlier quoted context omitted.

There's like 3 components involved in making setuid safe (the kernel, the dynamic loader, and your exec), and at least one of them wasn't doing its job correctly (the dynamic loader). IPC by definition involves a superset of these components. There's no reason to think that if you can't make a simple setuid binary safe, you can make IPC safe. IPC is an order of magnitude more involved. Specially because in order to g…

It's not clear why the request parser would have to be trusted. I assume you're just speaking about the call to execve running in context? That's not much of a request parser. At the point that you tell `run0` to launch a shell, you're not calling the actual commands to the shell the request parser, right? I also think the notion of an untrusted client is kind of a hashed out thing. As said in the post itself, `run0`…

> It's not clear why the request parser would have to be trusted [...] I assume you're just speaking about the call to execve running in context

No, I'm talking about the part which is going to parse the command line, arguments, environment, decide whether the user is allowed the elevation or not, decide which environment, file descriptors, etc. are to be passed through, etc. All of this must NOT be in the same context as the caller, as it can simply fake all these decisions. You need to handle this from a process running in another context (suid or not).

> While sudo is a single process, if it was two processes it wouldn't all have to run as root

Yes it would ? At least one of them would need to be suid for the actual execution. But the problem is that the process which was NOT suid would be running as the same user as the caller, so by the same reason as above -- you cannot trust what it does. The only thing the non-root process would be able to do is to massage the request a bit, then forward it (IPC!) to the root/suid process which you CAN trust. We are just moving the security border, and it is not clear what would be gained by it.

In this proposal, instead of a suid binary, you have a constantly running "sudod" process (or worse, pid 1), but otherwise is the same. Everything must be IPC'd to it.

> There are fewer thing that can leak into or be inherited by the spawned process.

To have this IPC complexity just because apparently we can't figure out how to do suid without inheriting anything is bonkers.

As a trade-off you now have a user-accessible IPC system with the _gazillion_ possible vulnerabilities it entails. At least before you needed root to talk to pid1..

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

#800

Post by viraptor »

metta2uall wrote: post #545
viraptor wrote: post #30

Earlier quoted context omitted.

That's not a great summary of lzma. It was systems adding custom patch to ssh which used a systemd-related library which it didn't really need in the first place. It's a stack of issues that don't have much to do with systemd itself really. But re. expanding the attack surface - unlikely. Systemd's primary purpose is to start processes with the right environment / permissions. systemd-run/run0 basically give you the…

Isn't it a fault of systemd that libsystemd had a dependency on libxz? (because it implements too many things). It should have been possible to add the notification functionality using a tiny libsystemd-notify.

It's not a fault. They needed xz for some functionality and didn't want to split that library into multiple pieces. That's just a choice.

But either way, you could always do notification in a few lines yourself (probably as many as you needed to link that library in the first place). I've done multiple 3-line "implementations" in Python and Ruby in the past and never linked it for example.

Post reply on HN