There are little (to no?) situations where su has a good reason to check wheel. You either have the password, or you don't have it. But not something in-between. Outside of any ideology, in a scenario where you use su to become root, it's a very odd choice to link the wheel group to su; because if you know the password to the "root" user, and you have physical or remote access to the computer, you can likely just log…
Why GNU su does not support the `wheel' group (2002)
51–60 of 150 posts
Re: Why GNU su does not support the `wheel' group (2002)
#52There are little (to no?) situations where su has a good reason to check wheel. You either have the password, or you don't have it. But not something in-between. Outside of any ideology, in a scenario where you use su to become root, it's a very odd choice to link the wheel group to su; because if you know the password to the "root" user, and you have physical or remote access to the computer, you can likely just log…
Re: Why GNU su does not support the `wheel' group (2002)
#53Earlier quoted context omitted.
The irony behind it is that one could argue that we are using UNIX wrong, because technically each program should run as its own user with its own groups. Which is what apparmor and firejail/sandboxes kind of want to embrace but in practice people just care too less.
the problem is "just that" is not good enough because programs often to need to have part of the capabilities of the user which started them, just a very well controlled subset of them, something which the UNIX model can't properly represent (through you can hack it on-top of it) There is also the problem of having by default "owner-user owner-group other" as permission sets for files and executable. This works if ot…
Re: Why GNU su does not support the `wheel' group (2002)
#54Earlier quoted context omitted.
The solution is to use https://qubes-os.org . My daily driver, can't recommend it enough.
Qubes is one of those things that, I think, everyone knows is better but it seems just far enough away to not want to change. How big of a change is it? If you are, say, a Linux terminal native can you just pick up and run?
Doing so has proved hard and slow so far, and Spectrum hasn't had a usable release for the masses yet.
Re: Why GNU su does not support the `wheel' group (2002)
#55Earlier quoted context omitted.
Yes, Unix was designed to protect users from each other but the modern need is to protect applications/invocations from each other. It is unfortunate that Unix wasn't really designed for the modern use case. Basically https://xkcd.com/1200/
The irony behind it is that one could argue that we are using UNIX wrong, because technically each program should run as its own user with its own groups. Which is what apparmor and firejail/sandboxes kind of want to embrace but in practice people just care too less.
Re: Why GNU su does not support the `wheel' group (2002)
#56Earlier quoted context omitted.
Yes, Unix was designed to protect users from each other but the modern need is to protect applications/invocations from each other. It is unfortunate that Unix wasn't really designed for the modern use case. Basically https://xkcd.com/1200/
The irony behind it is that one could argue that we are using UNIX wrong, because technically each program should run as its own user with its own groups. Which is what apparmor and firejail/sandboxes kind of want to embrace but in practice people just care too less.
Next problem will be sharing data between programs that legitimately need to do so; if I had an _emacs user that owned my source code, how do I make it non-painful for the _gcc user to read the source and write the resulting executables (which would end up in a directory owned by _emacs)? What about git, various preprocessors/generators, formatters, linters?
You'd have to step out of the traditional UNIX authn/authz model to effectively implement that. It's what various security-focussed OS's have been doing for a while anyway; e.g. OpenBSD implements unveil, which "hides" entire branches of the VFS tree. For example, if git has no business reading or writing files outside of the currently operated on repository, it can restrict itself very early in the process life - before proceeding to perform any of the "tricky" operations that are the common sources of security bugs.
Re: Why GNU su does not support the `wheel' group (2002)
#57Earlier quoted context omitted.
What is special about the 'wheel' group and what is su even "checking" in the first place? Users who aren't in the wheel group aren't supposed to be able to become root, even if they have the password. Isn't it just supposed to switch user? And what are the implications of not-checking whatever it was supposed to check? Someone who steals the root password (say, by looking over the sysadmin's shoulder) would be able…
Native question: if you can `sudo`, can't you just `sudo bash`? What can you do with `su` that you couldn't do with `sudo bash`? Or is the wheel group not really about being able to sudo?
`su` predates `sudo` by a decade doesn’t offer the fine-grained control `sudo` has. With `su` if you have the root password, you can do anything you want as root. With `sudo` admins can configure what commands users are allowed to run as root and could specifically block `sudo bash` from running.
Re: Why GNU su does not support the `wheel' group (2002)
#58Earlier quoted context omitted.
The solution is to use https://qubes-os.org . My daily driver, can't recommend it enough.
I tried it for a week. Feels like overkill so I instead went for Fedora Silverblue & have everything in isolated podman containers. Of course, I’m not being targeted by the state so my threat model is much lower.
Re: Why GNU su does not support the `wheel' group (2002)
#59A different reason why it's good that it doesn't support wheel: - it makes it smaller, less code which can go wrong - su isn't limited to "set user root" but wheel tends to be - it avoids having to handle many kind of subtle problems with group based permission handling in linux It's just not a bad idea to have a very minimalist program like su and then delegate all more complicated "acting as user" permission handli…
I don't think GNU has ever committed to any kind of minimalist philosophy. Have you seen the number of flags every command has? ls has almost the entire alphabet taken.
I think the convention itself is good - I prefer long flags in scripts for improved readability.
But GNU is anything but minimal - compare GNU ls[1] with BSD ls[2], and try to recall the last time you needed --dereference-command-line-symlink-to-dir.
[1]: https://linux.die.net/man/1/ls
[2]: http://man.openbsd.org/lsRe: Why GNU su does not support the `wheel' group (2002)
#60Earlier quoted context omitted.
The irony behind it is that one could argue that we are using UNIX wrong, because technically each program should run as its own user with its own groups. Which is what apparmor and firejail/sandboxes kind of want to embrace but in practice people just care too less.
Unix doesn't make it easy for an unprivileged user to switch to a different user account for just one app though. Plus it gets more complicated when your application wants to save something to the disk so it can be accessed by a different application.