Yeah, that makes a lot of sense. Not needing the SUID bit on a complex tool is just a good idea. The simpler use cases can switch to doas, the use cases that require complex configuration can switch to something like run0, and the world of Linux is just a little bit harder to hack.
Agreed, this is a nice inclusion. I also hate sudoers with a passion - I already use doas but it’s not standard (in the Linux world anyway), but with systemd providing an alternative means that it’ll become a standard which most distros would adopt, and I hope this means we can finally ditch the convoluted sudoers file once and for all.
doas is quite popular in the BSD world, and was ported to Linux a few years ago (via the OpenDoas project).
For starters, it’s is a lot smaller than sudo - under 2k lines of code vs sudo’s 132k - this makes it lot more easier to audit and maintain, and technically less likely to have vulnerabilities.
Another security advantage is that doas doesn’t pass on the environment variables by default (you’d have to explicitly declare the ones you want to pass, which you can do so in the config).
The config is also a lot simpler, and doesn’t force you to use visudo - which never made sense to me, visudo should’ve just generated the actual config, instead of checking it after the fact. Kinda like how grubby or grub2-mkconfig works. But no need for that complexity with doas.
Eg, the most basic doas config could just have one line in the file: permit: wheel. Maybe have another line for programs you want to run without a password, like permit nopass dexter cmd pacman.
Makes sense considering people who moved from one micro-blogging service to another instead of giving up on the idea completely are probably the ones deeply committed to that flawed idea.
Blame the Mastodon team, if you’re not running a fork, you have to go into the source and adjust the character limit manually.
Nobody has to do it like this, Mastodon supports longer posts since other servers and clients support more, it’s seemingly just a choice from upstream.
I admit, I’m not a big fan of putting more functionality into systemd (or just of systemd in general), but that is a well-reasoned argument for having sudo live in the init system.
I wouldn’t rely on distros adopting it as a default. systemd has a whole range of features, like network management, that many distros still use other tools for, like NetworkManager and netplan.
The thing with this is: its just a symlink to the systemd-run binary, which talks to PID1 to spawn new processes (in separate cgroups IIRC). Its one of the most fundamental parts of systemd. Even the debian systemd package includes systemd-run.
I guess the other question is if some tools the distro provides might switch to supporting it by default. For example on Arch there is makepkg that should never be executed as root, but does internally call some things with elevated privileges (mostly pacman to install and remove packages). Currently it checks for sudo and if not falls back to su, but maybe it might be worth considering changing su for run0 if its guaranteed to be there.
I haven’t checked the details yet, but surely this will need configuration to decide what users are allowed to use run0. The binary might exist, ready to be configured (the same is true for many systemd deployments that use alternative network managers!) but without configuration to match, I don’t think run0 will be usable for users that don’t already have root access.
it does its authorization with polkit (which IIRC defaults to allow all wheel group members) and giving users that shouldn’t be allowed root access, root access, is not something you ever want. This is usually referred to as unauthorized privilege escalation. Also, it isn’t like sudo doesn’t need configuration.
Any code execution inside of a SUID binary basically becomes root access. That means that SUID binaries need a lot of security measures for everything they do. The more complex you make your SUID capable binary, the more work this adds, and the higher the probability that you’re introducing some kind of bypass vulnerability.
With sudo and to some extent doas, the process that should be in charge of vetting whether or not a user can become root/another user (and probably should only be doing that) is also parsing files, interacting with the network, possibly doing I/O on the filesystem. The binary is started as a user with limited permissions, but that user has full control of the binary’s environment.
With a root daemon (the one your system already needs if you’re running systemd in the first place), the binary that submits the elevation request can be as small as possible, and have no additional permissions. You can trick run0 into doing something, but that won’t give you root access, as polkit and other mechanisms actually decide if you’re root or not. If you’re not root, you’re not going to be able to seriously influence those daemons, even if you debug and monitor the memory of the application that’s communicating with them, or somehow manage to LD_PRELOAD some malware into it.
Take, for instance, CVE-2023–22809. This vulnerability allowed some users to write files with root permissions (think /etc/sudoers) when the low privilege user was permitted to only edit files on a whitelist, because rather than taking the root user environment variables, various sudo tools accepted the user’s environment variables (the ones you provide on the command line) to decide what editor to launch. This editor could (basically) be ‘nano /etc/passwd’ and when you sudoedit /etc/user/tool/file/here.conf (as specified in sido’s config), sudoedit would spawn an editor opening /etc/passwd instead.
In the daemon model of run0, the daemon would be the one evaluating its (root) environment variables and picking the editor. However, in sudo, the binary that allowed itself to become root, could also be directly influenced by the low privilege user, and its protections against tampering proved insufficient.
This entire class of attacks just isn’t viable when the binary the end user runs doesn’t have the ability to exert any control. All the important bits are on the “other side”, running as a different user, isolated from the low privilege side.
Thanks for taking the time to explain. I was trying to get my head around on how this works but could not understand much of it. A lot of people here are very much against systemd in all senses, but this sounds like a better approach. Even if it not done as systemd, makes more sense than checking files and getting elevated privileges for a scope and use guardrails everywhere
Yeah, that makes a lot of sense. Not needing the SUID bit on a complex tool is just a good idea. The simpler use cases can switch to
doas, the use cases that require complex configuration can switch to something likerun0, and the world of Linux is just a little bit harder to hack.Agreed, this is a nice inclusion. I also hate sudoers with a passion - I already use
doasbut it’s not standard (in the Linux world anyway), but with systemd providing an alternative means that it’ll become a standard which most distros would adopt, and I hope this means we can finally ditch the convoluted sudoers file once and for all.How does doas differ from sudo?
Never heard of the former until now.
doasis quite popular in the BSD world, and was ported to Linux a few years ago (via the OpenDoas project).For starters, it’s is a lot smaller than sudo - under 2k lines of code vs sudo’s 132k - this makes it lot more easier to audit and maintain, and technically less likely to have vulnerabilities.
Another security advantage is that
doasdoesn’t pass on the environment variables by default (you’d have to explicitly declare the ones you want to pass, which you can do so in the config).The config is also a lot simpler, and doesn’t force you to use
visudo- which never made sense to me,visudoshould’ve just generated the actual config, instead of checking it after the fact. Kinda like howgrubbyorgrub2-mkconfigworks. But no need for that complexity with doas.Eg, the most basic
doasconfig could just have one line in the file:permit: wheel. Maybe have another line for programs you want to run without a password, likepermit nopass dexter cmd pacman.Awesome. Thanks for the insight.
Essentially functionally stripped sudo, smaller in size than sudo. See also Pottering’s thoughts about the ecosystem
Nice to see that Mastodon has the same problem as Twitter with people trying to use it for long-form blog posts for some godforsaken reason.
Makes sense considering people who moved from one micro-blogging service to another instead of giving up on the idea completely are probably the ones deeply committed to that flawed idea.
Blame the Mastodon team, if you’re not running a fork, you have to go into the source and adjust the character limit manually.
Nobody has to do it like this, Mastodon supports longer posts since other servers and clients support more, it’s seemingly just a choice from upstream.
I admit, I’m not a big fan of putting more functionality into systemd (or just of systemd in general), but that is a well-reasoned argument for having sudo live in the init system.
I wouldn’t rely on distros adopting it as a default. systemd has a whole range of features, like network management, that many distros still use other tools for, like NetworkManager and netplan.
The thing with this is: its just a symlink to the
systemd-runbinary, which talks to PID1 to spawn new processes (in separate cgroups IIRC). Its one of the most fundamental parts of systemd. Even the debiansystemdpackage includessystemd-run.I guess the other question is if some tools the distro provides might switch to supporting it by default. For example on Arch there is
makepkgthat should never be executed as root, but does internally call some things with elevated privileges (mostlypacmanto install and remove packages). Currently it checks forsudoand if not falls back tosu, but maybe it might be worth considering changingsuforrun0if its guaranteed to be there.I haven’t checked the details yet, but surely this will need configuration to decide what users are allowed to use run0. The binary might exist, ready to be configured (the same is true for many systemd deployments that use alternative network managers!) but without configuration to match, I don’t think run0 will be usable for users that don’t already have root access.
it does its authorization with polkit (which IIRC defaults to allow all
wheelgroup members) and giving users that shouldn’t be allowed root access, root access, is not something you ever want. This is usually referred to as unauthorized privilege escalation. Also, it isn’t likesudodoesn’t need configuration.I read the original mastodon post by the developer of run0 and I am still don’t understand what the problem with SUID is.
Whats an example of an attack that would work with sudo and doas (which also uses SUID) and not on run0?
Any code execution inside of a SUID binary basically becomes root access. That means that SUID binaries need a lot of security measures for everything they do. The more complex you make your SUID capable binary, the more work this adds, and the higher the probability that you’re introducing some kind of bypass vulnerability.
With sudo and to some extent doas, the process that should be in charge of vetting whether or not a user can become root/another user (and probably should only be doing that) is also parsing files, interacting with the network, possibly doing I/O on the filesystem. The binary is started as a user with limited permissions, but that user has full control of the binary’s environment.
With a root daemon (the one your system already needs if you’re running systemd in the first place), the binary that submits the elevation request can be as small as possible, and have no additional permissions. You can trick run0 into doing something, but that won’t give you root access, as polkit and other mechanisms actually decide if you’re root or not. If you’re not root, you’re not going to be able to seriously influence those daemons, even if you debug and monitor the memory of the application that’s communicating with them, or somehow manage to LD_PRELOAD some malware into it.
Take, for instance, CVE-2023–22809. This vulnerability allowed some users to write files with root permissions (think /etc/sudoers) when the low privilege user was permitted to only edit files on a whitelist, because rather than taking the root user environment variables, various sudo tools accepted the user’s environment variables (the ones you provide on the command line) to decide what editor to launch. This editor could (basically) be ‘nano /etc/passwd’ and when you sudoedit /etc/user/tool/file/here.conf (as specified in sido’s config), sudoedit would spawn an editor opening /etc/passwd instead.
In the daemon model of run0, the daemon would be the one evaluating its (root) environment variables and picking the editor. However, in sudo, the binary that allowed itself to become root, could also be directly influenced by the low privilege user, and its protections against tampering proved insufficient.
This entire class of attacks just isn’t viable when the binary the end user runs doesn’t have the ability to exert any control. All the important bits are on the “other side”, running as a different user, isolated from the low privilege side.
Thanks for taking the time to explain. I was trying to get my head around on how this works but could not understand much of it. A lot of people here are very much against systemd in all senses, but this sounds like a better approach. Even if it not done as systemd, makes more sense than checking files and getting elevated privileges for a scope and use guardrails everywhere