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

721–730 of 902 posts

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

#721

Post by tgv »

mike_hearn wrote: post #149
tgv wrote: post #145

Earlier quoted context omitted.

The point is that (even) the systemd maintainers do not vet their dependencies. As an attack vector, it is the (second?) highest level, yet they did not assume the responsibility. Everybody silently assumed they did, hence the shock. > Claims that systemd has bad security have to explain why it was already implementing practices ... No, they don't. It doesn't take away the fact that they did not check xz, and probabl…

Nobody was silently assuming the systemd maintainers were reviewing the source tarballs of every dependency for obfuscated back doors.

That would be irresponsible and strengthen the case against run0 as a replacement. And let's be honest this time: the argumentation is that it's there to replace sudo.

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

#722

Post by KWxIUElW8Xt0tD9 »

jimrandomh wrote: post #620

> Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, without inheriting any context from the client (well, admittedly, we do propagate $TERM, but that's an explicit exception, i.e. allowlist rather than denylist). I think in practice, this is going to be an endless source of problems, so much so that it won't be adopted. The usual use case of sudo is that you have…

One binary to rule them all, one binary to find them, one binary to bring them all and in the darkness bind them; in the Land of Lennart where the shadows lie. Bwaahahaha.

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

#723

Post by lyu07282 »

Netch wrote: post #667

A similar idea was tested in an experimental BSD clone in Berkeley in mid-1980s. (Great sorry I havenʼt kept link to the description, so rephrase with my own words. Maybe this was in the McKusickʼs book?) No suid or sgid was allowed. A daemon started from init and listening on a socket listened for connections, checked permissions and run the specified binary with requested permissions. A caller had to interact with…

44 years and ~20 local privilege escalation vulnerabilities later...

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

#724

Post by flexagoon »

metalspoon wrote: post #494
shrimp_emoji wrote: post #421

Earlier quoted context omitted.

Counterpoint: GNOME and the modern GTK framework (I needn't say more.)

Yes. I prefer having tools that do one thing well. That's the point of unix. How the user uses them should be up to her. GNOME offering a monolithic environment with heavy opinionation is the opposite.

How is GNOME a "monolithic environment"? The entire GNOME ecosystem is basically small apps that do a single thing well:

https://apps.gnome.org/

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

#725

Post by matrss »

adastra22 wrote: post #345
rpgwaiter wrote: post #318

Earlier quoted context omitted.

NixOS may be helping multiuser make a comeback, at least it is for me and my home servers. I no longer have to containerize my apps, i can have one baremetal server with a dozen+ services, all with their own users and permissions, and i don't have to actually think about any of the separation. Plus there’s network shares. Multiple people in my home with linux PCs, each with their own slice of the NFS pie based on use…

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.

> 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.

That's the thing, with NixOS you usually don't have to explicitly setup users and permissions. For most simple services, the entire setup is a single line of code in your NixOS configuration. E.g.

    services.uptime-kuma.enable = true;
will make sure that your system is running an uptime-kuma instance, with its own user and all.

Some more complex software might require more configuration, but most of the time user and group setup is not part of that.

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

#727

Post by jongjong »

zer00eyz wrote: post #534
jongjong wrote: post #505

Earlier quoted context omitted.

Technically not with virtual machines as the hardware is shared, though I agree, nowadays accounts and access control of the system belong to the virtualization layer below. The benefits of multiple accounts per machine are tiny and not worth the complexity for server setups. We could significantly simplify things by getting rid of the account system. The same could be said for a lot of systems like database servers.…

>> Typically it's just one database, one user (your application server) with full access This is a terrifying way to access databases. Super user, A Modify user (just below super but cant delegate rights) for schema changes. A read/write app user... Probably a pile of read only users who, have audit trails... You might want some admins or analytics users (who have their own scheme additions). The words security and a…

A simpler solution is to simply not give direct access to the database to anyone who doesn't own a large stake in the project. Expose it via a more restrictive CRUD interface with access control in the application layer.

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

#728

Post by TheRealDunkirk »

fullstop wrote: post #718
sapphire_tomb wrote: post #656

Earlier quoted context omitted.

My last job was at a UK bank. All our *nix systems were configured with a specific whitelist of commands that could be run via sudo. We found this an enormous pain in the arse when the powers that be decided to deploy ansible everywhere, and found that none of its "become" methods would work if sudo was set up like that.

I had a job once which had a sudo whitelist, but vi was included. !sh and you had root.

Classic case of #CorporateIT applying white paper "rules" and not understanding what they're doing. If I had a nickel...

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

#729

Post by cryptonector »

Spivak wrote: post #702
deng wrote: post #646

Earlier quoted context omitted.

> systemd is a large beast -- no need to make it larger with unrelated things 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 P…

People who just have an axe to grind with systemd really don't like when you point out that it's incredibly modular and follows the unix philosophy. I think what people mean to say but don't have the words for is that systemd is an East coast school of thought project and folks prefer "worse is better" style tools.

I like the idea behind systemd. I don't have an axe to grind. I don't want SysV init or whatever you might think.

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

#730

Post by bayindirh »

lyu07282 wrote: post #710
bayindirh wrote: post #690

Earlier quoted context omitted.

> And I'm kind of worried that when this breaks stuff, the systemd project is going to push forward with some plan to get rid of sudo, and not gracefully accept the feedback that this is breaking things. Given Lennart already declared SUID concept as “bad”, I think this is the game plan all along. Systemd: Do all the things, but not very well, and don’t listen to anyone.

I agree with Lennart so I'm curious what the argument is against the notion that SUID was a bad idea and we should move away from it in Linux?

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 tons of mechanisms and scenarios.

Security of sudo can be debated, but evolving current sudo to a better state step by step is miles better than banishing and rebuilding it and making it dependent on systemd + polkit. systemd already breaks tons of UNIX conventions and way more complicated than it should be.

When you think, it sounds like “conquering” another part of user space mixed with NIH (and we know the best), and making systemd more entrenched. systemd is already a pretty large surface area to attack to begin with.

XZ back door reached SSHd over libaystemd. Do we need another “integrated target” to attack in Linux?

Post reply on HN