Live data from Hacker News

Run0, a systemd based alternative to sudo, announced

mastodon.social

661–670 of 902 posts

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

#661

Earlier quoted context omitted.

I think these problems are basically negligible because the amount of people trying to "configure sudo to be safe to use for unprivileged users, by only allowing specific things to run with it" is negligible. Virtually all users of sudo are using it on their own computer which they are the sole user and ultimately the administrator of. Even in corporate contexts where the company owns the machine instead of the user,…

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.

Not even using "su" as become_method? Granted, it would require the root's password, so it's another tradeoff, but...

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

#662

Earlier quoted context omitted.

If the lesson of xz was "reduce supply chain attack surface" then the freedesktop people clearly haven't received it yet.

Fedora has used PolKit for 12 years now, and the javascript rules have probably been a thing for about as long.

Doctors recommended cigarettes for decades. What should give everyone similar pause is xz was found unintentionally.

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

#663
post #52

Earlier quoted context omitted.

What relevance does this have? Poettering's complaint is that sudo is way too big for a SUID binary, sshd is not a SUID binary? And neither Poettering nor the systemd developers patched said, the Debian people did that. Seems weird to blame systemd for that?

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 "code running as root", it's "code running as root in an attacker-controlled environment". That last part is the important one.

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

#664

Earlier quoted context omitted.

His positions are mostly controversial because he challenges the way things have been done for a long time. Whenever he presents some new idea/architecture my first reaction is often confusion. Why would he change something that has worked so well for such a long time? But then I take the time to read up on the reasoning behind his ideas and then things start to make sense. Even when something isn't exactly broken, t…

He's controversial because numerous times his ego has so severely clouded his judgemental that he refuses to see egregious bugs in his programs for what they are. Just one example: https://github.com/systemd/systemd/issues/6237#issuecomment-... The "people hate him because he makes new stuff" narrative is just more ego-protecting cope. Many developers of other new systems are widely respected and appreciated because…

Or in Linus Torvalds' words[1]:

It does become a problem when you have a system service developer who thinks the universe revolves around him, and nobody else matters, and people sending him bug-reports are annoyances that should be ignored rather than acknowledged and fixed. At that point, it's a problem.

[1]: https://lkml.org/lkml/2014/4/2/580

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

#665
post #45

systemd has been a net positive for the linux ecosystem. remember when you had to write bash scripts to start, stop, restart services and handle any other signals you want to send it? nowadays it's a unit file (basically just an ini file) away with relatively straightforward API. and you can actually declare startup dependencies and other useful relationships past just "prepend a number signifying when it should run…

> systemd has been a net positive for the linux ecosystem. You're presuming to speak for an awful lot of people there, on a topic that would be difficult to measure. > since the beginning of systemd people have moaned > it's quite annoying that the armchair linux experts complain Now you're overgeneralizing, and doing so in a dismissive and patronizing way. Here are a few examples of problems I have with systemd: Sys…

> It offers no manual skip option

ctrl-alt-del skips iirc?

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

#666

Earlier quoted context omitted.

> I also wasn't a fan of the tinting. From the linked mastodon thread: > For example, by default it will tint your terminal background in a reddish tone while you are operating with elevated privileges. That is supposed to act as a friendly reminder that you haven't given up the privileges yet, and marks the output of all commands that ran with privileges appropriately. (If you don't like this, you can easily turn it…

I for one love to type out 13 extra characters to a 4 character command to disable dumb choices by the developer. On a more serious note, I wonder what random ASCII escape sequences we can send.

> I for one love to type out 13 extra characters

FWIW, systemd is normally pretty good at providing autocomplete suggestions, so even if you don't want to set up an alias you'll probably just have to type `--b ` to set it.

> I wonder what random ASCII escape sequences we can send.

According to the man page source[0]:

> The color specified should be an ANSI X3.64 SGR background color, i.e. strings such as `40`, `41`, …, `47`, `48;2;…`, `48;5;…`

and a link to the relevant Wikipedia page[1]. Given systemd's generally decent track record wrt defects and security issues, and the simplicity of valid colour values, I expect there's a fairly robust parameter verifier in there.

In fact, given the focus on starting the elevated command in a highly controlled environment, I'd expect the colour codes to be output to the originating terminal, not forwarded to the secure pty. That way, the only thing malformed escapes can affect is your own process, which you already have full control over anyway.

(Happy to be shown if that's a mistaken expectation though.)

[0] https://github.com/systemd/systemd/blob/main/man/run0.xml

[1] https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_(Select_G...

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

#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 the started program using pipes.

It seems the complexity of passing all to pipes was why the approach was rejected. Instead, the checking of inherited environment was strengthened. "Everything new is well forgotten old."

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

#668
post #392

Earlier quoted context omitted.

Don’t think of it as relearning a tool, think of it as learning one tool which works for everything. You no longer have to implement your own log rotation, compression, etc. or work out which configuration each program needs to do that in the manner you expect – for example, “is it safe to rotate a log file?” requires you to know implementation details on each program.

>think of it as learning one tool which works for everything. For how long? I've been around for decades at this point with people telling me how the newest and greatest thing will obsolete everything that came before it. The best way to look through logs is still to materialize them in as text in a files hierarchy and use find with grep to look for issues.

I’ve been doing this for decades, too, but I don’t miss having to deal with everyone inventing multiple log hierarchies, different rotation conventions, compression strategies, etc. not to mention all of the other things which systemd removed from daily toil around process management.

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

#669
post #85
post #19

Earlier quoted context omitted.

Is it? Does systemd's sudo replacement also have a lot of complex code running as root in a suid binary? Because that's what he's complaining about

The complaint might be valid. The solution, to shoehorn yet another functionality on systemd will in no way reduce complexity or attack vectors, merely shift them, again, like with all systemd solutions.

What difference does it make if it's part of the systemd project or not? Do things suddenly become a more problematic attack vector when they're organizationally part of the systemd project instead of the sudo project?

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

#670

Earlier quoted context omitted.

> systemd has been a net positive for the linux ecosystem. You're presuming to speak for an awful lot of people there, on a topic that would be difficult to measure. > since the beginning of systemd people have moaned > it's quite annoying that the armchair linux experts complain Now you're overgeneralizing, and doing so in a dismissive and patronizing way. Here are a few examples of problems I have with systemd: Sys…

Systems isn't blocking the shutdown. Systems is being blocked by a service. Since you are saying that you can't track down the exact service, you must be using a container runtime like docker or LXC which is not transmitting the kill signal properly to the container to shut it down. The container itself then keeps running for whatever reason. This entirely depends on your particular setup and has very little to do wi…

> Since you are saying that you can't track down the exact service,

That is not what I said.

Post reply on HN