systemd is supposed to be a system management daemon. It is an old approach that was abandoned at some point by unix with separate SUID binary approach. It might be considered as another half-turn in the revolving wheel of fate.
I eagerly await the day Systemd switches to using a binary database for configurations with a tree layout and a typed key/value pair storage. They can call it the Systemd Register Hive.
Already exists in Gnome, it's called DConf.
It's actually good though, since they at least thought of using a schema so it's not just a bunch of untyped loose keys and values.
Am I missing the joke on how embedded databases are a bad thing?
Text format configs are a nightmare that we've stockholmed ourselves into thinking we like. Off the top of my head:
* there are multiple configs where an errant comma, tab-instead-of-space, or invalid comment will break your entire system
* some conf.d dump dirs want a .conf extension. Others (sudoers) ignore any files with a dot. Still others don't care
* some pretend to be ini files but are a dollar-store discount variant
* many don't have manual pages
* some apply conf.d with higher priority than the base config, others don't
* many use bespoke DSLs that are only considered ok because theyve been around since the 1800s
Relevant to this submission, sudo manages to hit several of these at once, and is terribly documented to boot; as I recall the docs and examples for several of the alias options are ambiguous so you get to play with fire and hope you don't end up back in single user mode trying to unlock your system.
Forgive me if a schema-constrained, read-optimized, hierarchical config registry sounds wonderful. It doesn't need to be a bizarre format-- use sqllite if it makes you happy-- but I don't think I've heard a good argument against them other than "*binary bad*" or "*lol windoze*".
Personally see no issues with that, I'm all for better security, instead of some perceived value in backward compatibility (that I personally have no special use for), the people that need the compatibility still have the choice of going with a distro focusing on those things.
> I'm all for better security, instead of some perceived value in backward compatibility (that I personally have no special use for)
I'm all for better compatibility, instead of some perceived security (that I personally have no special use for).
Given that my first interaction with systemd was back in ~2016, when they decided to send SIGTERM instead of SIGHUP to child processes of a dropped SSH connection. Then insist that everybody else use the special systemd method of making background processes, as if this bizarre game of Simon Says was reasonable.
The only reason that this didn't end up causing mass breakage of `nohup`, `screen`, `tmux`, `emacs --daemon`, etc was because the systemd default of `KillUserProcesses=yes` was overridden by most distros. But it should never have been set as systemd default in the first place. Their choice to set it as a default (and subsequent doubling-down on that decision in the following discussions), show that they don't understand the role that foundational software plays.
At a very fundamental level, I do not expect competence from systemd core developers to be competent when deciding on changes that impact compatibility. I expect them to make decisions that make fix RedHat/GNOME-specific issues, exporting problems to everybody else in the process.
Lenhart Poettering, I just want to say one thing to you.
> You should be having a private conversation in the bedroom with yourself. Sincerely.
-- Winter Goat
I know that’s a joke, but seriously why not? The most important stuff on a personal computer is your own files, and you already have full access to them as a user. You are not going to do more harm to them as root than as a user.
I'm not joking. if you don't need privilege escalation from userspace why even have one installed? 99% of the time I'm running as a regular user, and when I need to do root things I press ctrl-alt-f2 and login as root. Don't get me started on how dumb I think the wheel group is.
On a desktop the root users only real purpose is to prevent you from accidentally hosing your own system. It is certainly valuable for that purpose, but yes the lack of any delineation between "me the user" and "some random program, I happen to be running" is a problem as EVERYTHING important is available to ANYTHING you are running on the machine.
The real interesting aspect of all the work in systemd is that it could facilitate a desktop environment that actually does isolate and contain different use cases of the system. It is certainly not going to be easy to implement this and would require a lot of work to integrate things, but having a centralize monolithic tool to manage the system environment can enable virtualizing desktop applications in ways that are otherwise very hard to do.
Imagine that you have some base username "JohnDoe" as well as a more sensitive user "JohnDoeFinancials" then when you try to give your web browser access to these more sensitive documents, it recognizes the need to run in a privileged mode, communicates via dbus with run0 to run in this elevated fashion...
The most interesting related problem I've found is passwordless sudo being disregarded as a huge security hole without addressing the problem that if the user level is compromised, then the sudo password prompt can't be trusted either. It's still an extra security layer though, but the Windows approach of escalation with a simple "secure UI element" which theoretically can't be mimicked (or can it?) isn't that silly.
Security reasons will be the most commonly mentioned ones, but there's more than that, a bunch of programs behave differently when running as root. You may have seen various warnings from programs really not wanting to run as root which is likely the most common form of the behavior change, but that's not the only case.
One example that's trapped me is Podman. "Normally" it processes `$HOME/.config/containers/containers.conf`, but when running as root it behaves differently, including not caring about that file despite root not exactly being homeless. Can't really recall names right now, but there are other programs too which follow the idea that you either run as a user confined in your home, or you run as root and your actions will affect the whole system.
I mean, we'd login as ourselves and su to root for a long while before sudo was in much use. Even once it got prevalent, the admins would just "sudo su - " and call it a day.
Meanwhile, the only sudo command the *NIX team is given by security (who control sudo) is "su - root"
Fun stuff. Honestly, though, I'm just lazy and don't want to type long commands if I can avoid it.
> the admins would just "sudo su - " and call it a day.
I still do that on all my servers
because there's basically nothing I do on there that doesn't require root access
Well `pkexec` has probably the same problem as `sudo` as it's a SETUID binary and had[ several security issues](https://security-tracker.debian.org/tracker/source-package/policykit-1) in the past
I feel like threads on microblogging platforms is a bit of a workaround. That should probably be its own Pid Eins blog post.
The point of microblogging is to coax people into producing small quickly read/viewed content. Writing threads (which people do on twitter as well) kind of erodes the social dynamic that was meant to be achieved by forcing small posts.
With effort, I can read that but I feel like by the time you go beyond a single reply then you should probably just write it on a blog and link to it from your mastodon.
Not quite, polkit is just a way to give unprivileged applications access to privileged things. There’s gtk and qt applications that prompt for a password when there’s a polkit rule that says that should happen, which is probably why you think it’s only GUI applications. But you could make a polkit rule that says “just do it without asking for a password”. And it could be for anything, interfacing with the kernel via /sys/class/… etc.
Hence why this run0 would use polkit as a backend. It’s basically just an interface that will give privileged access using polkit in the command line.
They describe it in the OP but I think the main differentiator is that it's communicating over a socket and the privileged application never attaches directly to your terminal or runs with information/parameters set from less privileged sources.
pkexec validates the requested action against the policy and then defers to a SUID binary to actually execute. The problem with SUID binaries is that they inherit the entire environment from their caller.
run0 is breaking the link between the executing with higher privilege and SUID binaries.
Early in the boot while the environment is still clean and well understood, init will fork and one of its children will become a "SUID handler" that listens for requests to run elevated actions. When a process needs to run with elevated privileges a message is sent to the SUID handler, which again forks, and the child process validates policy and (if allowed) execs the require action.
This way when you request that something be run elevated you know exactly what environment it is running in. This effectively eliminates all kinds of LD_PRELOAD attacks.
It seems like an _okay_ idea but it seems to overstate things at various points.
I'm not sure what "network access" in the context of `sudo` means. It's mentioned as if it's a separate thing from the LDAP plugin which would've been my guess from the name. Maybe the hostname field in the individual rules? If so I guess I could see how on modern systems that would be cruft since that's not how most people deploy sudo configuration anymore (usually through config management and in the context of servers being as single purpose as feasible).
Proxying over a socket sounds like an interesting approach.
While we're inventing new approaches, it would be interesting to see certain options like having policies where certain capabilities are dropped depending on the user invoking (such as non-admin users can't get or request CAP_NET_ADMIN) per system configuration.
As for the execution context, it's not really that big of an issue anymore. If we were sitting down and inventing something from scratch, yeah we'd probably want to separate out the context. But `sudo` as a package has undergone iterative improvements and fixes that address these concerns. It's also not half because they purposefully choose which variables to respect and is why you have to request preservation of variables. That's why they had to go back eight years to find a CVE relevant to the sudo approach.
There will still be use cases for `sudo` even if this becomes a thing, though. There are just some environments where the lab needs a certain certification and the criteria for it hasn't been updated in forever. There's also value in heterogeneous environments where having a single tool and approach to configuring it is helpful rather than something that requires systemd and therefore Linux.
**EDIT:**
I also personally don't like `run0` as a name because the last character isn't on or adjacent to qwerty home row. Meaning it's just kind of difficult to type at speed since you have to reach around the keyboard as such.
> That's why they had to go back eight years to find a CVE relevant to the sudo approach.
To be fair, that CVE has updates talking about it still being relevant as recently as 2023.
It sounded like means that it can check remote sources like ldap to validate that you have the rights to run the call you're running with sudo
As far as the lab case, it sounds like that would be the case for sudo or something like it.
something like "runa" (pronounced "run a") or `rune` (run elevated, pronunciation deliberately vague) could be good alternatives. unfortunately it's probably too late to change by now.
If you change your hostname and forget to update /etc/hosts to have it point again to localhost, you will notice even default sudo configuration (on Debian and Ubuntu at least) takes forever to let you in, I guess it is doing some DNS resolution or reverse reservation for logs 🙂
Name definitely needs improvement, at first I thought run0 was for running things as Ring 0 (kernel privileges) which it is not.
I don't like being polite to robots. I'll name mine `fu` thank you very much. (that's pronounced as "eff" + "yoo" not "foo" - but please understand that's directed to the robots, not you... unless you're a robot)
This sub can be summarised to:
Kde good
Systemd bad
Gnome bad
Unix Philosophy only (without knowing what or why)
I switched to Linux and my dog came back to life to high five me and everybody clapped.
Zomg new DE uses RAM instead of leaving all of it free.
Repeat ad-nauseum.
Red Hat is the army of demons that will unleash the end times, Mark Shuttleworth is Satan, selling usage data on Snaps to Microsoft to build his krugerrand-laundering house, and Canonical's main purpose is to kick puppies.
You got a lot of 90s Linux users / sysadmins who grew up a certain way. I can't relate even though I am exactly from that demographic. I had to unlearn my own expectations especially when it came to things like memory.
But one thing I've learned is that the people here are not nearly technically inclined as they think they are and a lot of their predisposition is based on cultural norms. Let me give you an example.
Back in the Google+ days, I made some post about how I used to reboot my servers with sync;sync;sync;reboot - the kernel devs saw the post and proceeded to mock me as anachronistic that they actually solved that problem of flushing the buffers of filesystems. (of course then they went off tangent as kernel devs are ought to do) I \*still\* do it because it's a no-op that doesn't do any harm and why should I trust them - it's my job on the line on theirs. But technically speaking I had to change gears because it is no longer a thing but it still feels culturally relevant to me. That's your 90s mindset right here.
The analysis is fundamentally correct.
Suppose we’re building an OS from scratch without Unix legacy. You’re going to need users which own processes, and a system user that can do anything. When you arrive at the question of how to implement elevated privileges, you already have enough components to implement a solution: you need a process that decides what privileges other users have.
The notion of setting a bit on a file… that’s obviously a hack, a redundant concept that can be removed. Occam’s razor cuts it away.
You could go one step further: a low privilege daemon whose job it is to decide if the user has appropriate privileges (essentially, reading sudoers), encrypts the request, and sends it to the system executor. Then the executor reads only encrypted messages from the privilege daemon and executes the requested command.
One of the checks the privilege daemon could do is check if the calling process or its parent are allowed to escalate privileges - so most processes aren’t even allowed to do the equivalent of execve(“sudo”).
> The notion of setting a bit on a file… that’s obviously a hack, a redundant concept that can be removed. Occam’s razor cuts it away.
This seems like an insufficient explanation. Care to justify further? "Hack" is very much in the eye of the beholder here, as it often is.
Because the bit does a highly dangerous thing that's quite far from what is desired: the setuid bit just requests an executable to be always run with root privilege. It's up to the executable (i.e. sudo)'s job to do something sensible and prevent the user from getting root with crafted input.
Securing setuid is really hard. A trivial `--log somefile` option to set a logfile is innocent enough in a normal program but with setuid the user can `--log /etc/password` and wreck havoc because the executable is able to write `/etc/password` *by design*.
I fully support systemd here since their approach is way more sensible than setuid.
EDIT: I recall back in the days Xorg were setuid and eventually someone figured they could symlink /var/log/Xorg.0.log to /etc/passwd or /bin/passwd
> the setuid bit just requests an executable to be always run with root privilege
They're a little bit more general than that: the setuid and setgid bits request that the executable be run with the UID/GID of the owner:group. This does not have to be root.
Exactly. This is why webservers run with their own user and group, because we can restrict what part of the storage they may have access to. If the webserver had access to /home they could've read maintenance files, or even ~/.ssh.
At the end of the day whatever binary is still going to run as root with the options supplied to it at the cli. What does this new mechanism do to prevent the exact behavior you have described with say --log?
The concerns with approaches like sudoers is more with environment variables and other things imported from the local environment.
The possibility of a command line argument attack is something you currently have to configure and restrict with sudoers file. In theory I believe you can lock down and protect against arguments with sudoers, in practice I think it is a lot harder, and I suspect it is often not done.
Fundamentally there are two kinds of things you need to do with elevated privileges:
1. Restarting system services. These are well defined actions, and should be controlled by the init process, as init is ultimately responsible for starting these services correctly. So its natural for init to have a lot of the tools necessary to elevate privileges and enforce policy around that.
2. More interactive type activities that sysadmins might need to perform to debug and initially configure the system. It can be pretty hard to define restrictions around these interactive activities, because you don't know what the sysadmin needs to do until he does it.
One of the problems with sudo is that it doesn't distinguish between these two. X11/Xorg properly constitutes a service and really should only be started from the scripts in /etc/init.d or /etc/rc.d or whatever. However it needed to run with elevated privs (because of kernel framebuffer permissions) and would either be marked SUID or approved to run with sudoers file, neither or which was capable of distinguishing a malicious "I'm running this from the command line" from a non-malicious "I told init to rerun this rc script".
The idea of run0 is that you no longer have to mark xorg binary as SUID or put it in sudoers. You can say "that isn't how you start X, you start X with `systemctl start X`", while at the same time using `run0` to perform the more generic operations that cannot be well defined in advance. Both use the same underlying mechanism to define and enforce policy (polkit) and to actual execute at the elevated level (communicating with the early stage helper that init forked during boot).
Because the user can no longer control the cli arguments of any run-as-root binary. OS launches a privileged daemon, and the sudo tool communicates with that daemon using a custom protocol over a socket. The daemon can be launched in a secure environment well before any user logs in. By the time a user gets to sudo, the log file will be already opened so the user has no chance to redirect it.
Basically instead of securing against everything that could possibly affect an Unix executable, one just secures a socket. The attack surface is much smaller.
From the fine man page:
```
All command line arguments after the first non-option argument become part of the command line of the launched process.
```
The command does indeed receive the arguments and offers no additional protections around the particular "issue" you've described. In fact sudo actually *can* limit down the options that are allowed to be passed in the sudoers configuration file, so for your particular worry, run0 provides weaker security controls.
To the core point of what you are concerned with though, you likely shouldn't grant sudo access(or run0 access) to a user who has shell access to a local system unless you have seriously audited all the options and features of the command that is being sudoed to, or as most organizations that have granted users login shell access to a server already have some degree of trust that your authorized users aren't actively trying to hack your system. Ideally both.
I'm not seeing how the communication over a socket stops the potential attack vector you're describing. If we're wanting to allow the user to escalate `foo`, then what's the difference between sudo just going "Okay sure thing, I ran your command" and sudo passing the command to a daemon that runs it instead?
From what I see, in both cases there's a need for sanitizing the command or you end up with --log-file shenanigans, so I must be missing a piece of this puzzle here.
Because there's usually an authentication test before running whatever thing. Sudo is running with root privileges _before_ the user has authenticated to it. That's why you can have a privilege escalation vulnerability within sudo, even when its an application used to escalate privileges.
Okay, your point is that you can attack the SUID sudo binary to abuse some of its flags?
Then how is adding some daemons, clients and encryption reducing the attack surface? Now you have a full protocol accessible via socket to corrupt a daemon running as root. And its from the guys who brought ping of death back to Linux and added a few RCE's and privilege escalations.
Minor technical point. The setuid bit causes the executable to be run as the files owner. It need not be root although it commonly is done that way.
You could use setuid bit to allow another unprivileged user to do something as you. Often this kind of stuff gets disallowed by other policies just because its such a massive security concern.
One of the best cases for Linux is that the owner/admin has control of the system.
You should be able to to write to /etc/password when you have appropriate privileges and you run a command to write there.
You can `ln -s /etc/password /var/log/Xorg.0.log` without access to `/etc/password`. Xorg with SUID will then happily overwrite `/etc/password` *for you*. Classic privilege escalation.
Nobody is arguing against that
The original comment means that it's incredibly easy for a setuid program to mess up it's access control and inadvertently give someone root privileges that it shouldn't. The example was an unprivileged user that should not be allowed anywhere near /etc/password abusing the fact that this hypothetical sudo can produce a log file to override /etc/password. So think `sudo --logfile=/etc/password -- /some/innocent/command/Im/allowed/to/run`
I guess I don't understand what's wrong with your example command. Are you saying there's a way for a user without write access to /etc/password to write there by using that example command
? In my opinion, if a root user tells a command to write its log file to a certain location, it should do it.
Edit:
Someone else replied to my comment and explained it is a privilege escalation issue. This makes more sense now, thanks!
You can implement sudo without setuid (as demonstrated by Systemd) but you can’t implement sudo without essential elements like users, processes, IPC and user privileges. If you can solve the “sudo problem” using only essential concepts, that is superior to a solution like setuid that requires additional concepts.
AFAIU, sudo doesn’t use IPC, (unless you count writing and reading from the invoking TTY, which doesn’t seem correct). Not needing IPC is what makes sudo seem (somewhat) parsimonious to me.
The original Unix doesn't have much in the way of any concepts of privileges. There are just files: user/group/other, and one (and only one) super user.
So in the original Unix it is effectively impossible for lower privileged Alice to ever do anything as anyone other than Alice. Her only recourse is to physically walk down the hall and ask "root" to please login to the machine and do this thing for her.
This was a rather annoying task for our dear sysadmin, and setuid was created as hack to enable Alice to run selected tasks as other users. In other words the SUID bit is a hack, to enable primitive policy over elevated actions.
It is extremely primitive and over time our policy has evolved. We now have lots of policy around elevated actions, and entire programs capable of enforcing policy. So the natural thing to do today is to delegate to those programs the power, and that is what we have done for 30+ years in increasingly sophisticated ways (initially with sudo, then later with polkit).
At this point the SUID bit is almost vestigal. You use "sudo" or "pkexec" to perform you action. They enforce policy and somehow execute the action. How they execute the action is something you should be agnostic towards. If they want to use a SUID bit thats fine, if they want to communicate with a service that forked from init that is also fine.
Need more time to read up on it. I like improving security. But I sometimes don't like the way people implement security changes, particularly when functionality suffers as a result bc they get a bit overzealous. (or would you call it "underzealous" if they are too lazy to figure out how to have the better security *without* removing any functionality?)
I quoted this in a comment on another thread but since I like the quote so much, I'll share it here too (taken from [here](https://security.stackexchange.com/a/6116/259634)):
> Security at the expense of usability comes at the expense of security
Still too early (for me at least) to tell how things lie but we will see. I'd like to understand what I *can't* do in `run0` that I *could* do in `sudo` before I make any final judgements (besides execute exploits obv). If the answer to that is that it can do all the same things, then I'd consider that a win. If not, my enthusiasm might be more muted.
Much as I hate the way the systemd project itself is run, the technical merits are strong here.
The set-UID-bit is a terrible concept that various projects have tried to get rid of or weaken over the years, with limited success.
Punting the problem to a userspace daemon makes a lot of sense.
The silly stuff with the red background not so much, but maybe someone will make a compatible run0 without the fluff.
> The silly stuff with the red background not so much, but maybe someone will make a compatible run0 without the fluff.
that is just the default setting that can be changed easily as explained in the original mastodon post [here](https://mastodon.social/@pid_eins/112353324518585654)
run0 will probably need some form of interoperability with sudo in order to see widespread adoption as a replacement of sudo. Unless run0 becomes a drop-in replacement (or has a compatibility layer), I don't see this going anywhere.
Is there a reason they couldn’t implement this as a change to the underlying implementation of sudo? For most users that don’t actually need sudo, they wouldn’t notice a difference. For users that do actually need sudo, add a “legacy sudo” flag.
because
1. systemd does not control the sudo project
2. the technical implementation relies on the fact that systemd is init, so unless you just want to gut sudo into being an alias for systemd-run you might as well not bother.
This is for the 95% of people who just install `sudo` and use the defaults. As in, they don't really need `sudo` and all of its capabilities, they just need a way to run a command as root once in a while. If you actually need `sudo`, it's still there in the repos.
OK, so 95% of the time when i run `sudo` or `su` I want to be `root`. Feels like this tool will do that.
From the reading I can't figure out for sure if it will let me run as any arbitrary user though, which is the other 5% of my need and what `sudo`/`su` is for. Or, at least, if it can, it reads like it assumes that you will only ever be running as `root` so they nee to make everything a little scarier for you so you know.
And now to see if I've started the `super user (do)` vs `substitute user (do)` argument.
Seems interesting, makes sense and doesn't seem to actually be a lot of new stuff, mostly just a `sudo`-like interface for an existing part of systemd.
How would it be called?
1. systemd-windowd
2. systemd-displayd
3. systemd-compositord
It would honestly be hilarious since it would very literally be a remaking of Xorg. A single server at the center of the universe with everything speaking to it.
Agreed. Specifically:
> For example, by default, it will tint your terminal background in a reddish tone while you are operating with elevated privileges.
It's actually an accessibility issue. But the key is
> by default
If it's configurable per user, it doesn't need to be a problem.
IMO, things like this are what cause the friction with systemd: The defaults they keep choosing (while often well meaning) are not what the community actually wants.
Like, I know for a fact that the sysadmins at my work will *not* modify whatever default is provided to us from the distro into our base image. So whatever RHEL/Ubuntu/etc choose is what we will be stuck with. This is the reality of quite a few people/orgs, that things like "create an alias/function then, or change a config" when I *can't* ship my personal .bashrc to every damn server I remote into.
Understand: I *like* the ideas of SystemD, and `run0` seems like a great idea. I question the implementation and considerations for actual usability. Such as "why have `0` in the name? That is an awkward char to type vs pure letters". There are other names that could have been chosen.
nothing? I doubt they'd do that until they have another use case for a wayland compositor though. Maybe for replicating VTs, but with scrollback allowed, since that stuff was removed from the kernel.
Alright everybody, this is what we trained for. You know the drill. It says systemd in the post title. What do we do? That's right, we re-hash the _exact_ same arguments and stale jokes from 2010. Don't worry, there's no need to understand any of the technicalities, anyone can repeat braindead mantras for upvotes. Try it. Repeat after me, "It's not the Unix way. Do one thing and do it well. PulseAudio. Lennart Poettering. Red Hat." I know, you don't know what an init system is, but trust me. Stick to the playbook and we'll all get upvotes.
That means we can throw in a Microsoft rant where we rag on Windoze and call it “Bill Gates’s Computer”. And we only refer to Microsoft as M$.
Think of how much karma we’ll get by recycling old content from Slashdot!
Also all decisions in FOSS should be taken solely for the benefit of Linux Ricing.
Anything that benefits enterprise or people who actually do real work on Linux is bloat.
I seriously cannot envision going back to pre systemd on our servers.
I did an internship in college where I worked with pre systemd Linux servers (Ubuntu 11.04 IIRC) it was so much worse.
Thankfully we were mostly shutting these things down in favour of systemd based servers.
Recycled comment.
____
I must admit, I never really did like sudo as a way to restrict privileges.
It always felt like a cludge that user roles where configured in a special file for it isolated from all other settings. Like apparmour it felt like a temporary fix to a know problem which sorta stuck.
Ideally, user privileges and roles should be dynamically assigned in an least privileged way.
This becomes even more important when you move to portable user environments like homed envisages.
So I am quite glad someone is looking a privilege escalation with a sober and serious look at security architecture of least run privileges.
> I never really did like sudo as a way to restrict privileges.
It escalates priviledges, it doesn't restrict them.
> It always felt like a cludge that user roles where configured in a special file for it isolated from all other settings.
I'd much rather have everything to do with priviledge escalation in one place than scattered elsewhere. For example: Auditing priviledges is much easier when it's all in one place. When it's scattered, it's very easy for something to slip through.
Something that I think many people miss is that sudo has significantly more control than just allowing a user to run an arbitrary thing as root. For the desktop, that doesn't matter so much, but when working on a large infrastructure, it's essential.
> Something that I think many people miss is that sudo has significantly more control than just allowing a user to run an arbitrary thing as root.
I'm wondering how many people here know you can allow user foo to run a subset of commands as user bar, while allowing bar to run some safer commands with no password, and others with a key required?
I think most people think sudo is as simple as doas. Wheras doas was written to simplify sudo.
Oh hey, finally! I've long wanted something along these lines.
Linux process mechanics haven't aged well. The setuid bit is a terrible mechanism in the modern age because processes inherit state, and dynamic linking has all sorts of complexities many developers are completely unaware of.
Also, PAM is a library at the mercy of the user. The system's authentication service should be its own thing, walled off from anything that might mess with it in any way. This would be both more secure, and easier to make secure. For instance separating auth into a separate process means SELinux can confine it separately.
In the article it says it's an already existing tool, system-run, with a symlink to a new name. So it's *going* to expand, it's going to make one functionality it already has more *visible*.
I mean, if systemd is trying to be the de facto official Linux userland (like FreeBSD has only one official userland), go for it? Bundle coreutils or busybox and util-linux as optional replaceable components while you're at it.
On a serious semi-related note, a way for Linux to utterly shit itself dramatically at the request of userspace (maybe allow PID 1 to tell Linux to panic) if some critical system component takes a nap sounds like a good idea. Linux already does this for init on its own, but to allow init to tell the kernel "hey if this super important process that can't be restarted without rebooting anyway receives SIGSEGV or SIGKILL, please panic the system to tell the user. Also, kdump, please make sure the coredump is of the process and not the kernel, thanks".
Things usually go right, but Linux is awfully unfriendly and vague to the average user when things go horribly wrong. Even power users. I need a fucking serial console or somehow figure out why pstore or kdump isn't working out of box on mainstream distros to know if Nvidia is to blame for the suddenly frozen screen with no additional info.
6.10 is supposedly getting a panic screen back (which it had one until 2015), at least.
> The tool is also a lot more fun to use than sudo. 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. It also inserts a red dot (unicode ftw) in the window title while you operate with privileges, and drops it afterwards.
... so the selling points include messing with your custom terminal colour scheme which may cause problems for people with certain types of colourblindness; and setting a unicode character in an environment variable, which means you need emoji fonts for it to work properly.
Nice.
As long I can alias sudo to it I don't care. But it will probably be something stupid like
USER=root CMD="shutdown -h" systemctl start-oneshot run-as.service
>Though, I really hope they don't end up calling the command 'run0'. That's a bitch to type.
That's my biggest problem with systemd and related projects, as well. They work well, but they just seem so incredibly over-engineered, with little apparent thought given to actual user experience. Sure, old-style config files can be cryptic, but once you learn their syntax, it tends to make a lot of sense and you don't easily forget it. cron is a good example. With systemd, PulseAudio, and the like, though, so many things are so counter-intuitive that I can never seem to retain it for very long.
Maybe it's just a personal problem, but it's the main reason I groan whenever I hear that they've decided to expand into a new area of the OS.
My favorite are the stupid commands and random files I need to remember to change my fucking NTP server and force a sync with….uhhh…`systemd-timesync`
The man pages alone should make the issue clear enough to skeptics. There are some nice things about systemd, but sometimes it does feel like they’re huffing jenkem over there. Look at all of the places unit files can get loaded from!
% run9
Command 'run9' not found
% run-
Command 'run-' not found
% runo
Command 'runo' not found
% run)
bash: syntax error near unexpected token `)'
% FUUUUUUUUU
FUUUUUUUUU: command not found
they need to stop sticking their fingers into other projects, seriously. We have modulary software guidelines in the unix community for damn good reasons.
I know, run0 just reminded me that Lennart seemingly does not care about typing convenience at all, the 0 is definitely harder than z or o, or even zero..
There seems to be broad support for the concept, but people are complaining about the name `run0`. I propose a re-brand. Instead of `0`, call it what it is, a **d**edicated **m**aster **c**ontroller.
One great way to get your NIH culture into every distro is to just bundle your ideas with something every distro already uses.
Problem solved.. But what problem are we really fixing here?
Yet another bloat solution in search of a problem
'sudo' is literally bloat. If you don't want bloat, use 'doas'. 'doas' is literally 100x smaller and does the same thing.
'run0' will replace it with a safer alternative that mostly uses underlying tools that are in systemd anyway.
You can call it NIH but it does something the alternatives don't and wont do.
The real problem with systemd is it centralizes control over how things are done at the project level. Which makes it a consolidation of power. It makes it the cathedral not the bazaar. A lot of the dislike for systemd comes from Lennart, and his attitude is the epitome of cathedral.
Except that distribution decide what to ship or not ship and systemd has little power over that. Linux is itself a cathedral. So is Gnome and many other things. Turns out a city needs both things.
Systemd/Linux
“Excuse me, that’s GNU/Systemd/Linux.”
systemd 95 is coming out soon.
SystemD 4.0/Warp
SD/2
What a glorious vista that will be
No, SystemD/Linux
“Excuse me, that’s FOSS/GNU/Systemd/Linux”
Gnu + Linux + Systemd
Systemd+Linux
Linux for Systemd
Systemd Subsystem for Linux
Or if they keep going, Linux Subsystem for SystemD
systemd is supposed to be a system management daemon. It is an old approach that was abandoned at some point by unix with separate SUID binary approach. It might be considered as another half-turn in the revolving wheel of fate.
History doesn't repeat, but it rhymes.
I don't think IBM/AIX quite got the message about system management daemons being bad.
I eagerly await the day Systemd switches to using a binary database for configurations with a tree layout and a typed key/value pair storage. They can call it the Systemd Register Hive.
Then we can introduce a tool to edit these configs. Call it Regedit
Genius! While we're at it, the _stream-of-bytes_ model is so stupid. Everything should be an object!
*Systemdit
Already exists in Gnome, it's called DConf. It's actually good though, since they at least thought of using a schema so it's not just a bunch of untyped loose keys and values.
I hate you so much for putting that thought into my head. Nothing personal.
We all know Lennart Poettering's endgame is "Linux NT"... Let the hate flow through you!
Windows didn't invent databases and there's nothing wrong with using them.
So **etcd**?
Am I missing the joke on how embedded databases are a bad thing? Text format configs are a nightmare that we've stockholmed ourselves into thinking we like. Off the top of my head: * there are multiple configs where an errant comma, tab-instead-of-space, or invalid comment will break your entire system * some conf.d dump dirs want a .conf extension. Others (sudoers) ignore any files with a dot. Still others don't care * some pretend to be ini files but are a dollar-store discount variant * many don't have manual pages * some apply conf.d with higher priority than the base config, others don't * many use bespoke DSLs that are only considered ok because theyve been around since the 1800s Relevant to this submission, sudo manages to hit several of these at once, and is terribly documented to boot; as I recall the docs and examples for several of the alias options are ambiguous so you get to play with fire and hope you don't end up back in single user mode trying to unlock your system. Forgive me if a schema-constrained, read-optimized, hierarchical config registry sounds wonderful. It doesn't need to be a bizarre format-- use sqllite if it makes you happy-- but I don't think I've heard a good argument against them other than "*binary bad*" or "*lol windoze*".
As a software dev..... nah. I'll keep my text configs
As a software dev all your configs are in a binary format only readable with a git client.
Windows is right over there. Designed by the guy who wrote OpenVMS no less! Lots of pedigree, and databases _galore_!
That was an invitation to provide a coherent argument against a settings database.
Systemd: Only a matter of time before we eat the kernel too.
you're all wrong. it's just gona be 'systemd' the OS soon xp
Personally see no issues with that, I'm all for better security, instead of some perceived value in backward compatibility (that I personally have no special use for), the people that need the compatibility still have the choice of going with a distro focusing on those things.
> I'm all for better security, instead of some perceived value in backward compatibility (that I personally have no special use for) I'm all for better compatibility, instead of some perceived security (that I personally have no special use for).
Given that my first interaction with systemd was back in ~2016, when they decided to send SIGTERM instead of SIGHUP to child processes of a dropped SSH connection. Then insist that everybody else use the special systemd method of making background processes, as if this bizarre game of Simon Says was reasonable. The only reason that this didn't end up causing mass breakage of `nohup`, `screen`, `tmux`, `emacs --daemon`, etc was because the systemd default of `KillUserProcesses=yes` was overridden by most distros. But it should never have been set as systemd default in the first place. Their choice to set it as a default (and subsequent doubling-down on that decision in the following discussions), show that they don't understand the role that foundational software plays. At a very fundamental level, I do not expect competence from systemd core developers to be competent when deciding on changes that impact compatibility. I expect them to make decisions that make fix RedHat/GNOME-specific issues, exporting problems to everybody else in the process.
Lenhart Poettering, I just want to say one thing to you. > You should be having a private conversation in the bedroom with yourself. Sincerely. -- Winter Goat
Systemd++
Just login as root, cowards.
I don’t need to login. I don’t have a password!
In Soviet Russia, computer logs into you!
Ah, found my generation!
Do you use Jesux distribution? Christians have nothing to hide!
I know that’s a joke, but seriously why not? The most important stuff on a personal computer is your own files, and you already have full access to them as a user. You are not going to do more harm to them as root than as a user.
I'm not joking. if you don't need privilege escalation from userspace why even have one installed? 99% of the time I'm running as a regular user, and when I need to do root things I press ctrl-alt-f2 and login as root. Don't get me started on how dumb I think the wheel group is.
On a desktop the root users only real purpose is to prevent you from accidentally hosing your own system. It is certainly valuable for that purpose, but yes the lack of any delineation between "me the user" and "some random program, I happen to be running" is a problem as EVERYTHING important is available to ANYTHING you are running on the machine. The real interesting aspect of all the work in systemd is that it could facilitate a desktop environment that actually does isolate and contain different use cases of the system. It is certainly not going to be easy to implement this and would require a lot of work to integrate things, but having a centralize monolithic tool to manage the system environment can enable virtualizing desktop applications in ways that are otherwise very hard to do. Imagine that you have some base username "JohnDoe" as well as a more sensitive user "JohnDoeFinancials" then when you try to give your web browser access to these more sensitive documents, it recognizes the need to run in a privileged mode, communicates via dbus with run0 to run in this elevated fashion...
The most interesting related problem I've found is passwordless sudo being disregarded as a huge security hole without addressing the problem that if the user level is compromised, then the sudo password prompt can't be trusted either. It's still an extra security layer though, but the Windows approach of escalation with a simple "secure UI element" which theoretically can't be mimicked (or can it?) isn't that silly. Security reasons will be the most commonly mentioned ones, but there's more than that, a bunch of programs behave differently when running as root. You may have seen various warnings from programs really not wanting to run as root which is likely the most common form of the behavior change, but that's not the only case. One example that's trapped me is Podman. "Normally" it processes `$HOME/.config/containers/containers.conf`, but when running as root it behaves differently, including not caring about that file despite root not exactly being homeless. Can't really recall names right now, but there are other programs too which follow the idea that you either run as a user confined in your home, or you run as root and your actions will affect the whole system.
I mean, we'd login as ourselves and su to root for a long while before sudo was in much use. Even once it got prevalent, the admins would just "sudo su - " and call it a day.
I usually `ssh [email protected]` myself
remember reading an old rant where the author condemned such practice calling it inappropriate of proper sysadmins. Good old days
Meanwhile, the only sudo command the *NIX team is given by security (who control sudo) is "su - root" Fun stuff. Honestly, though, I'm just lazy and don't want to type long commands if I can avoid it.
> the admins would just "sudo su - " and call it a day. I still do that on all my servers because there's basically nothing I do on there that doesn't require root access
How would this be different from polkit?
Well `pkexec` has probably the same problem as `sudo` as it's a SETUID binary and had[ several security issues](https://security-tracker.debian.org/tracker/source-package/policykit-1) in the past
Thx, that's the explanation I was looking for.
run0 apparently uses polkit. Details in https://mastodon.social/@pid_eins/112353324518585654
I feel like threads on microblogging platforms is a bit of a workaround. That should probably be its own Pid Eins blog post. The point of microblogging is to coax people into producing small quickly read/viewed content. Writing threads (which people do on twitter as well) kind of erodes the social dynamic that was meant to be achieved by forcing small posts. With effort, I can read that but I feel like by the time you go beyond a single reply then you should probably just write it on a blog and link to it from your mastodon.
Polkit I believe is geared towards GUI applications, but I could be totally wrong here.
Not quite, polkit is just a way to give unprivileged applications access to privileged things. There’s gtk and qt applications that prompt for a password when there’s a polkit rule that says that should happen, which is probably why you think it’s only GUI applications. But you could make a polkit rule that says “just do it without asking for a password”. And it could be for anything, interfacing with the kernel via /sys/class/… etc. Hence why this run0 would use polkit as a backend. It’s basically just an interface that will give privileged access using polkit in the command line.
So run0 is essentially a command-line focused version of pkexec then?
its technically a wrapper around systemd-run
They describe it in the OP but I think the main differentiator is that it's communicating over a socket and the privileged application never attaches directly to your terminal or runs with information/parameters set from less privileged sources.
pkexec validates the requested action against the policy and then defers to a SUID binary to actually execute. The problem with SUID binaries is that they inherit the entire environment from their caller. run0 is breaking the link between the executing with higher privilege and SUID binaries. Early in the boot while the environment is still clean and well understood, init will fork and one of its children will become a "SUID handler" that listens for requests to run elevated actions. When a process needs to run with elevated privileges a message is sent to the SUID handler, which again forks, and the child process validates policy and (if allowed) execs the require action. This way when you request that something be run elevated you know exactly what environment it is running in. This effectively eliminates all kinds of LD_PRELOAD attacks.
It seems like an _okay_ idea but it seems to overstate things at various points. I'm not sure what "network access" in the context of `sudo` means. It's mentioned as if it's a separate thing from the LDAP plugin which would've been my guess from the name. Maybe the hostname field in the individual rules? If so I guess I could see how on modern systems that would be cruft since that's not how most people deploy sudo configuration anymore (usually through config management and in the context of servers being as single purpose as feasible). Proxying over a socket sounds like an interesting approach. While we're inventing new approaches, it would be interesting to see certain options like having policies where certain capabilities are dropped depending on the user invoking (such as non-admin users can't get or request CAP_NET_ADMIN) per system configuration. As for the execution context, it's not really that big of an issue anymore. If we were sitting down and inventing something from scratch, yeah we'd probably want to separate out the context. But `sudo` as a package has undergone iterative improvements and fixes that address these concerns. It's also not half because they purposefully choose which variables to respect and is why you have to request preservation of variables. That's why they had to go back eight years to find a CVE relevant to the sudo approach. There will still be use cases for `sudo` even if this becomes a thing, though. There are just some environments where the lab needs a certain certification and the criteria for it hasn't been updated in forever. There's also value in heterogeneous environments where having a single tool and approach to configuring it is helpful rather than something that requires systemd and therefore Linux. **EDIT:** I also personally don't like `run0` as a name because the last character isn't on or adjacent to qwerty home row. Meaning it's just kind of difficult to type at speed since you have to reach around the keyboard as such.
> That's why they had to go back eight years to find a CVE relevant to the sudo approach. To be fair, that CVE has updates talking about it still being relevant as recently as 2023.
It sounded like means that it can check remote sources like ldap to validate that you have the rights to run the call you're running with sudo As far as the lab case, it sounds like that would be the case for sudo or something like it.
Reminds me of dom0 from qubes
something like "runa" (pronounced "run a") or `rune` (run elevated, pronunciation deliberately vague) could be good alternatives. unfortunately it's probably too late to change by now.
`rune`sounds cooler out of your two suggestions, also the "rune" vs "run E" pronunciation war would be hilarious.
Yeah run0 isn't a great name to type, but I'll just alias it
If you change your hostname and forget to update /etc/hosts to have it point again to localhost, you will notice even default sudo configuration (on Debian and Ubuntu at least) takes forever to let you in, I guess it is doing some DNS resolution or reverse reservation for logs 🙂 Name definitely needs improvement, at first I thought run0 was for running things as Ring 0 (kernel privileges) which it is not.
Let's make it "please" so robots don't rebel
im going to set this as an alias for sudo
`please !!` is brilliant -------- But I like `fuck !!` /meme
I don't like being polite to robots. I'll name mine `fu` thank you very much. (that's pronounced as "eff" + "yoo" not "foo" - but please understand that's directed to the robots, not you... unless you're a robot)
And not a single technical argument in the comments. Reddit at its best.
Not everyone wants to argue with 14-year-olds that think they know everything online.
This sub can be summarised to: Kde good Systemd bad Gnome bad Unix Philosophy only (without knowing what or why) I switched to Linux and my dog came back to life to high five me and everybody clapped. Zomg new DE uses RAM instead of leaving all of it free. Repeat ad-nauseum.
Ubuntu is incarnation of devil himself.
Red Hat is the army of demons that will unleash the end times, Mark Shuttleworth is Satan, selling usage data on Snaps to Microsoft to build his krugerrand-laundering house, and Canonical's main purpose is to kick puppies.
systemd bad but x11 which ironically also does way more than it should be doing = good.
You got a lot of 90s Linux users / sysadmins who grew up a certain way. I can't relate even though I am exactly from that demographic. I had to unlearn my own expectations especially when it came to things like memory. But one thing I've learned is that the people here are not nearly technically inclined as they think they are and a lot of their predisposition is based on cultural norms. Let me give you an example. Back in the Google+ days, I made some post about how I used to reboot my servers with sync;sync;sync;reboot - the kernel devs saw the post and proceeded to mock me as anachronistic that they actually solved that problem of flushing the buffers of filesystems. (of course then they went off tangent as kernel devs are ought to do) I \*still\* do it because it's a no-op that doesn't do any harm and why should I trust them - it's my job on the line on theirs. But technically speaking I had to change gears because it is no longer a thing but it still feels culturally relevant to me. That's your 90s mindset right here.
bro can you even install arch?
no...
The analysis is fundamentally correct. Suppose we’re building an OS from scratch without Unix legacy. You’re going to need users which own processes, and a system user that can do anything. When you arrive at the question of how to implement elevated privileges, you already have enough components to implement a solution: you need a process that decides what privileges other users have. The notion of setting a bit on a file… that’s obviously a hack, a redundant concept that can be removed. Occam’s razor cuts it away. You could go one step further: a low privilege daemon whose job it is to decide if the user has appropriate privileges (essentially, reading sudoers), encrypts the request, and sends it to the system executor. Then the executor reads only encrypted messages from the privilege daemon and executes the requested command. One of the checks the privilege daemon could do is check if the calling process or its parent are allowed to escalate privileges - so most processes aren’t even allowed to do the equivalent of execve(“sudo”).
> The notion of setting a bit on a file… that’s obviously a hack, a redundant concept that can be removed. Occam’s razor cuts it away. This seems like an insufficient explanation. Care to justify further? "Hack" is very much in the eye of the beholder here, as it often is.
Because the bit does a highly dangerous thing that's quite far from what is desired: the setuid bit just requests an executable to be always run with root privilege. It's up to the executable (i.e. sudo)'s job to do something sensible and prevent the user from getting root with crafted input. Securing setuid is really hard. A trivial `--log somefile` option to set a logfile is innocent enough in a normal program but with setuid the user can `--log /etc/password` and wreck havoc because the executable is able to write `/etc/password` *by design*. I fully support systemd here since their approach is way more sensible than setuid. EDIT: I recall back in the days Xorg were setuid and eventually someone figured they could symlink /var/log/Xorg.0.log to /etc/passwd or /bin/passwd
> the setuid bit just requests an executable to be always run with root privilege They're a little bit more general than that: the setuid and setgid bits request that the executable be run with the UID/GID of the owner:group. This does not have to be root.
Exactly. This is why webservers run with their own user and group, because we can restrict what part of the storage they may have access to. If the webserver had access to /home they could've read maintenance files, or even ~/.ssh.
At the end of the day whatever binary is still going to run as root with the options supplied to it at the cli. What does this new mechanism do to prevent the exact behavior you have described with say --log?
ya i was just thinking that. the mastadon post said something about polkit but wont you just need to prune/sanitize input elsewhere?
The concerns with approaches like sudoers is more with environment variables and other things imported from the local environment. The possibility of a command line argument attack is something you currently have to configure and restrict with sudoers file. In theory I believe you can lock down and protect against arguments with sudoers, in practice I think it is a lot harder, and I suspect it is often not done. Fundamentally there are two kinds of things you need to do with elevated privileges: 1. Restarting system services. These are well defined actions, and should be controlled by the init process, as init is ultimately responsible for starting these services correctly. So its natural for init to have a lot of the tools necessary to elevate privileges and enforce policy around that. 2. More interactive type activities that sysadmins might need to perform to debug and initially configure the system. It can be pretty hard to define restrictions around these interactive activities, because you don't know what the sysadmin needs to do until he does it. One of the problems with sudo is that it doesn't distinguish between these two. X11/Xorg properly constitutes a service and really should only be started from the scripts in /etc/init.d or /etc/rc.d or whatever. However it needed to run with elevated privs (because of kernel framebuffer permissions) and would either be marked SUID or approved to run with sudoers file, neither or which was capable of distinguishing a malicious "I'm running this from the command line" from a non-malicious "I told init to rerun this rc script". The idea of run0 is that you no longer have to mark xorg binary as SUID or put it in sudoers. You can say "that isn't how you start X, you start X with `systemctl start X`", while at the same time using `run0` to perform the more generic operations that cannot be well defined in advance. Both use the same underlying mechanism to define and enforce policy (polkit) and to actual execute at the elevated level (communicating with the early stage helper that init forked during boot).
Because the user can no longer control the cli arguments of any run-as-root binary. OS launches a privileged daemon, and the sudo tool communicates with that daemon using a custom protocol over a socket. The daemon can be launched in a secure environment well before any user logs in. By the time a user gets to sudo, the log file will be already opened so the user has no chance to redirect it. Basically instead of securing against everything that could possibly affect an Unix executable, one just secures a socket. The attack surface is much smaller.
From the fine man page: ``` All command line arguments after the first non-option argument become part of the command line of the launched process. ``` The command does indeed receive the arguments and offers no additional protections around the particular "issue" you've described. In fact sudo actually *can* limit down the options that are allowed to be passed in the sudoers configuration file, so for your particular worry, run0 provides weaker security controls. To the core point of what you are concerned with though, you likely shouldn't grant sudo access(or run0 access) to a user who has shell access to a local system unless you have seriously audited all the options and features of the command that is being sudoed to, or as most organizations that have granted users login shell access to a server already have some degree of trust that your authorized users aren't actively trying to hack your system. Ideally both.
I'm not seeing how the communication over a socket stops the potential attack vector you're describing. If we're wanting to allow the user to escalate `foo`, then what's the difference between sudo just going "Okay sure thing, I ran your command" and sudo passing the command to a daemon that runs it instead? From what I see, in both cases there's a need for sanitizing the command or you end up with --log-file shenanigans, so I must be missing a piece of this puzzle here.
Because there's usually an authentication test before running whatever thing. Sudo is running with root privileges _before_ the user has authenticated to it. That's why you can have a privilege escalation vulnerability within sudo, even when its an application used to escalate privileges.
Okay, your point is that you can attack the SUID sudo binary to abuse some of its flags? Then how is adding some daemons, clients and encryption reducing the attack surface? Now you have a full protocol accessible via socket to corrupt a daemon running as root. And its from the guys who brought ping of death back to Linux and added a few RCE's and privilege escalations.
Minor technical point. The setuid bit causes the executable to be run as the files owner. It need not be root although it commonly is done that way. You could use setuid bit to allow another unprivileged user to do something as you. Often this kind of stuff gets disallowed by other policies just because its such a massive security concern.
One of the best cases for Linux is that the owner/admin has control of the system. You should be able to to write to /etc/password when you have appropriate privileges and you run a command to write there.
You can `ln -s /etc/password /var/log/Xorg.0.log` without access to `/etc/password`. Xorg with SUID will then happily overwrite `/etc/password` *for you*. Classic privilege escalation.
Ah okay, thanks for the explanation.
Nobody is arguing against that The original comment means that it's incredibly easy for a setuid program to mess up it's access control and inadvertently give someone root privileges that it shouldn't. The example was an unprivileged user that should not be allowed anywhere near /etc/password abusing the fact that this hypothetical sudo can produce a log file to override /etc/password. So think `sudo --logfile=/etc/password -- /some/innocent/command/Im/allowed/to/run`
I guess I don't understand what's wrong with your example command. Are you saying there's a way for a user without write access to /etc/password to write there by using that example command ? In my opinion, if a root user tells a command to write its log file to a certain location, it should do it. Edit: Someone else replied to my comment and explained it is a privilege escalation issue. This makes more sense now, thanks!
You can implement sudo without setuid (as demonstrated by Systemd) but you can’t implement sudo without essential elements like users, processes, IPC and user privileges. If you can solve the “sudo problem” using only essential concepts, that is superior to a solution like setuid that requires additional concepts.
AFAIU, sudo doesn’t use IPC, (unless you count writing and reading from the invoking TTY, which doesn’t seem correct). Not needing IPC is what makes sudo seem (somewhat) parsimonious to me.
Correct — what I’m getting at is, we should aim for the OS to be parsimonious in its design . We can’t get rid of IPC, but we can get rid of setuid.
That's exactly what `run0` is trying to do, no?
The original Unix doesn't have much in the way of any concepts of privileges. There are just files: user/group/other, and one (and only one) super user. So in the original Unix it is effectively impossible for lower privileged Alice to ever do anything as anyone other than Alice. Her only recourse is to physically walk down the hall and ask "root" to please login to the machine and do this thing for her. This was a rather annoying task for our dear sysadmin, and setuid was created as hack to enable Alice to run selected tasks as other users. In other words the SUID bit is a hack, to enable primitive policy over elevated actions. It is extremely primitive and over time our policy has evolved. We now have lots of policy around elevated actions, and entire programs capable of enforcing policy. So the natural thing to do today is to delegate to those programs the power, and that is what we have done for 30+ years in increasingly sophisticated ways (initially with sudo, then later with polkit). At this point the SUID bit is almost vestigal. You use "sudo" or "pkexec" to perform you action. They enforce policy and somehow execute the action. How they execute the action is something you should be agnostic towards. If they want to use a SUID bit thats fine, if they want to communicate with a service that forked from init that is also fine.
Come on what did you expect
There's a HN thread too: https://news.ycombinator.com/item?id=40207545
It was posted an hour ago. Maybe give it more time before throwing in the towel?
Need more time to read up on it. I like improving security. But I sometimes don't like the way people implement security changes, particularly when functionality suffers as a result bc they get a bit overzealous. (or would you call it "underzealous" if they are too lazy to figure out how to have the better security *without* removing any functionality?) I quoted this in a comment on another thread but since I like the quote so much, I'll share it here too (taken from [here](https://security.stackexchange.com/a/6116/259634)): > Security at the expense of usability comes at the expense of security Still too early (for me at least) to tell how things lie but we will see. I'd like to understand what I *can't* do in `run0` that I *could* do in `sudo` before I make any final judgements (besides execute exploits obv). If the answer to that is that it can do all the same things, then I'd consider that a win. If not, my enthusiasm might be more muted.
Much as I hate the way the systemd project itself is run, the technical merits are strong here. The set-UID-bit is a terrible concept that various projects have tried to get rid of or weaken over the years, with limited success. Punting the problem to a userspace daemon makes a lot of sense. The silly stuff with the red background not so much, but maybe someone will make a compatible run0 without the fluff.
> The silly stuff with the red background not so much, but maybe someone will make a compatible run0 without the fluff. that is just the default setting that can be changed easily as explained in the original mastodon post [here](https://mastodon.social/@pid_eins/112353324518585654)
run0 will probably need some form of interoperability with sudo in order to see widespread adoption as a replacement of sudo. Unless run0 becomes a drop-in replacement (or has a compatibility layer), I don't see this going anywhere.
Is there a reason they couldn’t implement this as a change to the underlying implementation of sudo? For most users that don’t actually need sudo, they wouldn’t notice a difference. For users that do actually need sudo, add a “legacy sudo” flag.
because 1. systemd does not control the sudo project 2. the technical implementation relies on the fact that systemd is init, so unless you just want to gut sudo into being an alias for systemd-run you might as well not bother.
For users that do actually need sudo, "that use case isn't supported"
Might be challenging because part of what Leonard is proposing is to get rid of several features that sudo currently has.
This is for the 95% of people who just install `sudo` and use the defaults. As in, they don't really need `sudo` and all of its capabilities, they just need a way to run a command as root once in a while. If you actually need `sudo`, it's still there in the repos.
OK, so 95% of the time when i run `sudo` or `su` I want to be `root`. Feels like this tool will do that. From the reading I can't figure out for sure if it will let me run as any arbitrary user though, which is the other 5% of my need and what `sudo`/`su` is for. Or, at least, if it can, it reads like it assumes that you will only ever be running as `root` so they nee to make everything a little scarier for you so you know. And now to see if I've started the `super user (do)` vs `substitute user (do)` argument.
Seems interesting, makes sense and doesn't seem to actually be a lot of new stuff, mostly just a `sudo`-like interface for an existing part of systemd.
The good thing about new stuff is they learn from the previous projects and improve from them, if this is really an improvement i don't know why not.
Is this better than using doas?
Yes, because doas also requires the setuid bit.
Ok, who had “sudo replacement” in systemd expansion raffle?
*Wayland replacement*
How would it be called? 1. systemd-windowd 2. systemd-displayd 3. systemd-compositord It would honestly be hilarious since it would very literally be a remaking of Xorg. A single server at the center of the universe with everything speaking to it.
Actually a good idea. That basically just plan9 but over D-Bus instead of 9P.
wouldn't that be polkit
it is polkit under the hood
I dont like the whole "red tint" thing (personally I much prefer gnome consoles way of doing things where the titlebar is made red)
Agreed. Specifically: > For example, by default, it will tint your terminal background in a reddish tone while you are operating with elevated privileges. It's actually an accessibility issue. But the key is > by default If it's configurable per user, it doesn't need to be a problem.
IMO, things like this are what cause the friction with systemd: The defaults they keep choosing (while often well meaning) are not what the community actually wants. Like, I know for a fact that the sysadmins at my work will *not* modify whatever default is provided to us from the distro into our base image. So whatever RHEL/Ubuntu/etc choose is what we will be stuck with. This is the reality of quite a few people/orgs, that things like "create an alias/function then, or change a config" when I *can't* ship my personal .bashrc to every damn server I remote into. Understand: I *like* the ideas of SystemD, and `run0` seems like a great idea. I question the implementation and considerations for actual usability. Such as "why have `0` in the name? That is an awkward char to type vs pure letters". There are other names that could have been chosen.
What prevent them also include their own display manager?
why not their own kernel as well?
they already wrote their own bootloader, it just matter of time before linux got absorbed into systemd part
They didn't, systemd-boot is just an existing project (gummiboot) adopted into the systemd umbrella.
They tried that through kdbus but thank god they got stonewalled
Maybe Emacs can incorporate systemd then all Emacs will need is a good text editor for it's OS.
Why? Emacs can be launched as init :)
Evil mode exists, and it really isn’t so bad.
nothing? I doubt they'd do that until they have another use case for a wayland compositor though. Maybe for replicating VTs, but with scrollback allowed, since that stuff was removed from the kernel.
Alright everybody, this is what we trained for. You know the drill. It says systemd in the post title. What do we do? That's right, we re-hash the _exact_ same arguments and stale jokes from 2010. Don't worry, there's no need to understand any of the technicalities, anyone can repeat braindead mantras for upvotes. Try it. Repeat after me, "It's not the Unix way. Do one thing and do it well. PulseAudio. Lennart Poettering. Red Hat." I know, you don't know what an init system is, but trust me. Stick to the playbook and we'll all get upvotes.
Lennart is at Microsoft now. Need we say more?
So is the guy who caught the LZMA backdoor.
That means we can throw in a Microsoft rant where we rag on Windoze and call it “Bill Gates’s Computer”. And we only refer to Microsoft as M$. Think of how much karma we’ll get by recycling old content from Slashdot!
Also all decisions in FOSS should be taken solely for the benefit of Linux Ricing. Anything that benefits enterprise or people who actually do real work on Linux is bloat. I seriously cannot envision going back to pre systemd on our servers. I did an internship in college where I worked with pre systemd Linux servers (Ubuntu 11.04 IIRC) it was so much worse. Thankfully we were mostly shutting these things down in favour of systemd based servers.
Ever since RH was bought, I have eagerly awaited the complete IBM System/d release.
Then you'd have the z/System/d release when running in z/Series.
Recycled comment. ____ I must admit, I never really did like sudo as a way to restrict privileges. It always felt like a cludge that user roles where configured in a special file for it isolated from all other settings. Like apparmour it felt like a temporary fix to a know problem which sorta stuck. Ideally, user privileges and roles should be dynamically assigned in an least privileged way. This becomes even more important when you move to portable user environments like homed envisages. So I am quite glad someone is looking a privilege escalation with a sober and serious look at security architecture of least run privileges.
> I never really did like sudo as a way to restrict privileges. It escalates priviledges, it doesn't restrict them. > It always felt like a cludge that user roles where configured in a special file for it isolated from all other settings. I'd much rather have everything to do with priviledge escalation in one place than scattered elsewhere. For example: Auditing priviledges is much easier when it's all in one place. When it's scattered, it's very easy for something to slip through. Something that I think many people miss is that sudo has significantly more control than just allowing a user to run an arbitrary thing as root. For the desktop, that doesn't matter so much, but when working on a large infrastructure, it's essential.
> Something that I think many people miss is that sudo has significantly more control than just allowing a user to run an arbitrary thing as root. I'm wondering how many people here know you can allow user foo to run a subset of commands as user bar, while allowing bar to run some safer commands with no password, and others with a key required? I think most people think sudo is as simple as doas. Wheras doas was written to simplify sudo.
Oh hey, finally! I've long wanted something along these lines. Linux process mechanics haven't aged well. The setuid bit is a terrible mechanism in the modern age because processes inherit state, and dynamic linking has all sorts of complexities many developers are completely unaware of. Also, PAM is a library at the mercy of the user. The system's authentication service should be its own thing, walled off from anything that might mess with it in any way. This would be both more secure, and easier to make secure. For instance separating auth into a separate process means SELinux can confine it separately.
That's basically what sssd is.
In the article it says it's an already existing tool, system-run, with a symlink to a new name. So it's *going* to expand, it's going to make one functionality it already has more *visible*.
I'm calling it, we're getting Systemd kerneld at some point
When will systemd get around to bringing the 'ls' command into modernity?
I mean, if systemd is trying to be the de facto official Linux userland (like FreeBSD has only one official userland), go for it? Bundle coreutils or busybox and util-linux as optional replaceable components while you're at it.
Long live openrc
sudo rm -rf sudo
kernelpanic! - FAULT: micro-blackhole created
On a serious semi-related note, a way for Linux to utterly shit itself dramatically at the request of userspace (maybe allow PID 1 to tell Linux to panic) if some critical system component takes a nap sounds like a good idea. Linux already does this for init on its own, but to allow init to tell the kernel "hey if this super important process that can't be restarted without rebooting anyway receives SIGSEGV or SIGKILL, please panic the system to tell the user. Also, kdump, please make sure the coredump is of the process and not the kernel, thanks". Things usually go right, but Linux is awfully unfriendly and vague to the average user when things go horribly wrong. Even power users. I need a fucking serial console or somehow figure out why pstore or kdump isn't working out of box on mainstream distros to know if Nvidia is to blame for the suddenly frozen screen with no additional info. 6.10 is supposedly getting a panic screen back (which it had one until 2015), at least.
> The tool is also a lot more fun to use than sudo. 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. It also inserts a red dot (unicode ftw) in the window title while you operate with privileges, and drops it afterwards. ... so the selling points include messing with your custom terminal colour scheme which may cause problems for people with certain types of colourblindness; and setting a unicode character in an environment variable, which means you need emoji fonts for it to work properly. Nice.
At this pace, systemd may develop a drop-in replacement of X11 before Wayland gets "ready"
I've been using Wayland for years at this point. It's "ready" for a lot of use cases.
In related news: systemd changes its name to Emacs.
You mean you guys don't have a vmsystemz kernel in /boot?
As long I can alias sudo to it I don't care. But it will probably be something stupid like USER=root CMD="shutdown -h" systemctl start-oneshot run-as.service
Why
[удалено]
>Though, I really hope they don't end up calling the command 'run0'. That's a bitch to type. That's my biggest problem with systemd and related projects, as well. They work well, but they just seem so incredibly over-engineered, with little apparent thought given to actual user experience. Sure, old-style config files can be cryptic, but once you learn their syntax, it tends to make a lot of sense and you don't easily forget it. cron is a good example. With systemd, PulseAudio, and the like, though, so many things are so counter-intuitive that I can never seem to retain it for very long. Maybe it's just a personal problem, but it's the main reason I groan whenever I hear that they've decided to expand into a new area of the OS.
My favorite are the stupid commands and random files I need to remember to change my fucking NTP server and force a sync with….uhhh…`systemd-timesync` The man pages alone should make the issue clear enough to skeptics. There are some nice things about systemd, but sometimes it does feel like they’re huffing jenkem over there. Look at all of the places unit files can get loaded from!
% run9 Command 'run9' not found % run- Command 'run-' not found % runo Command 'runo' not found % run) bash: syntax error near unexpected token `)' % FUUUUUUUUU FUUUUUUUUU: command not found
Really? Ridiculous
"Do ~~one~~ every thing and do it well."
… and do it ~~well~~ with mediocrity.
Every day I'm thankful for the existence of Devuan... I switched to it back when they released Jessie and have been loving it ever since.
they need to stop sticking their fingers into other projects, seriously. We have modulary software guidelines in the unix community for damn good reasons.
What are these guidelines?
And who enforces them?
"They"
God damn can this thing please stop creeping?
The real problem with systemd is that it's not implemented as several hundred docker containers.
SNU systemd not unix edit: i dont support this, im just mocking systemd.
Please dont use something similar to kerberos, overengineered crap.
What? Are you taking about the authentication protocol? All the complexity in that is necessary to deliver the performance and security features, no?
systemctl (did i get that right??) is already long, the 0 after run is just, not humane!😆
The command is `run0`, not `systemctl run0`.
I know, run0 just reminded me that Lennart seemingly does not care about typing convenience at all, the 0 is definitely harder than z or o, or even zero..
There seems to be broad support for the concept, but people are complaining about the name `run0`. I propose a re-brand. Instead of `0`, call it what it is, a **d**edicated **m**aster **c**ontroller.
One great way to get your NIH culture into every distro is to just bundle your ideas with something every distro already uses. Problem solved.. But what problem are we really fixing here? Yet another bloat solution in search of a problem
'sudo' is literally bloat. If you don't want bloat, use 'doas'. 'doas' is literally 100x smaller and does the same thing. 'run0' will replace it with a safer alternative that mostly uses underlying tools that are in systemd anyway. You can call it NIH but it does something the alternatives don't and wont do.
The real problem with systemd is it centralizes control over how things are done at the project level. Which makes it a consolidation of power. It makes it the cathedral not the bazaar. A lot of the dislike for systemd comes from Lennart, and his attitude is the epitome of cathedral.
Except that distribution decide what to ship or not ship and systemd has little power over that. Linux is itself a cathedral. So is Gnome and many other things. Turns out a city needs both things.
What now??
**Doas** already exists: https://en.wikipedia.org/wiki/Doas
`doas` as the same core issue as `sudo`, it requires the setuid bit. The `doas` improvements over `sudo` are more like band-aids over a gaping wound.
Honestly the design as described seems sensible