Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why GNU su does not support the `wheel' group (2002)

ftp.gnu.org

Post reply on HN
Print view View original

101–110 of 150 posts

Re: Why GNU su does not support the `wheel' group (2002)

#101

Post by effie »

geoelectric wrote: post #98
effie wrote: post #94

Earlier quoted context omitted.

> I have more than one interactive user account on some of them. I put these accounts to the wheel group, to avoid ever using a root password. Why have multiple different unix users if all have the same power of the root user? They aren't isolated from each other, they aren't less powerful than root. So why not just use the already existing single root account?

Seems like it’d actually decrease security as now there are several different “root” logins that could be compromised. Though I suppose, with further thought, it’s not significantly worse than having them in sudoers, in that particular respect.

That's why the same question really applies to standard but insane practice of using sudo to get root. There is no security difference between root and lowuser that can sudo into root.

Sudoing into root from lowuser account is in some scenarios potentially more dangerous than just using both accounts separately, as the user who uses root regularly/very often gets accustomed to the fact his commands are powerful and can screw his system, so mistakes almost never happen. While sudoing all the time creates a false sense of security and the user is more likely to run harmful command with sudo.

Re: Why GNU su does not support the `wheel' group (2002)

#102

Post by labster »

fiddlerwoaroof wrote: post #92
Someone wrote: post #87

Earlier quoted context omitted.

> You might want to allow graphical editor to open any graphical file, regardless of location. More likely, you want to temporarily give them permission to specific files you indicate. A graphical editor doesn’t have reason to read any file that the user didn’t explicitly picked for editing/viewing. That’s how Mac OS works nowadays (possibly except for the ‘temporarily’; I don’t know the details): applications can on…

You can do this on basically any modern unix by passing file descriptors over a unix socket: the “graphical editor” server would launch as a user that can’t access anything except a socket and then users would open files by pushing an open fd to the editor over its socket.

While true and actually pretty cool, a comment like this is a pretty good explanation of why we haven’t had widespread adoption of Linux on the desktop. I can imagine the users’ eyes glazing over.

Re: Why GNU su does not support the `wheel' group (2002)

#103

Post by HKH2 »

cookiengineer wrote: post #21
jml7c5 wrote: post #16

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

> in practice people just care too less.

I tried to use Apparmor and SELinux, but how policies work is beyond me. Snap's sandboxing seems to be the closest thing to user-friendly sandboxing, but it's still not that user-friendly.

Re: Why GNU su does not support the `wheel' group (2002)

#104

Post by zeroimpl »

effie wrote: post #101
geoelectric wrote: post #98

Earlier quoted context omitted.

Seems like it’d actually decrease security as now there are several different “root” logins that could be compromised. Though I suppose, with further thought, it’s not significantly worse than having them in sudoers, in that particular respect.

That's why the same question really applies to standard but insane practice of using sudo to get root. There is no security difference between root and lowuser that can sudo into root. Sudoing into root from lowuser account is in some scenarios potentially more dangerous than just using both accounts separately, as the user who uses root regularly/very often gets accustomed to the fact his commands are powerful and c…

Yeah I don’t really understand why when I ssh into a VM in the cloud I have to first connect as a static dummy username like ec2-user then sudo to root.

Re: Why GNU su does not support the `wheel' group (2002)

#105

Post by Dylan16807 »

invalidator wrote: post #81
bee_rider wrote: post #24

Earlier quoted context omitted.

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?

Mostly yes. Your applications run in a standard Linux environment and if you pop up a terminal, hey, it's your favorite distro and it works. There's some learning curve for features which exist for valid reasons, especially around communicating between domains. For instance, copy-and-paste between qubes requires extra steps. Plugging in a USB keyboard or mouse doesn't just work - you have to authorize it first (just…

Please tell me the USB devices that were there at install time get authorized.

> You can install software using apt-get inside a qube, but it won't persist across reboots - you have to update the OS template.

> I want those extra steps and complications

Is it wrong of me to say that enabling persistence, with snapshots, on a qube should be a single toggle?

Re: Why GNU su does not support the `wheel' group (2002)

#106

Post by fiddlerwoaroof »

labster wrote: post #102
fiddlerwoaroof wrote: post #92

Earlier quoted context omitted.

You can do this on basically any modern unix by passing file descriptors over a unix socket: the “graphical editor” server would launch as a user that can’t access anything except a socket and then users would open files by pushing an open fd to the editor over its socket.

While true and actually pretty cool, a comment like this is a pretty good explanation of why we haven’t had widespread adoption of Linux on the desktop. I can imagine the users’ eyes glazing over.

I wouldn’t tell a user this, but developers of the desktop environments and distributions are leaving a lot of the design space unexplored.

Re: Why GNU su does not support the `wheel' group (2002)

#107

Post by derefr »

jcrawfordor wrote: post #76
derefr wrote: post #72

Earlier quoted context omitted.

Process owned by human-user fork(2)s and then exec(2)s suid program owned by program-user; program owned by program-user then does most of the work; but calls back over a domain socket to program owned by human-user to get it to do things on the program-user’s behalf. Picture: local DB client, remote DB server. Server can stream a file to the client for the client to write to disk. “On the same machine, as a differen…

This doesn't actually provide the benefit of application isolation though; if the software is malicious or vulnerable the as-user component could be as well. Remember that the biggest use case for application isolation is untrusted applications. Essentially any setuid-based approach to isolation requires a trusted developer using very good practices to remain secure, and that's why it's faded away.

What's insecure about setuid if the setuid user isn't a privileged user? For example, a setuid-nobody program, shouldn't be any more insecure than a systemd service spawned as User=nobody, no?

(Also, implied is that any untrusted logic lives in the spawned program, while the "client" program is simple and auditable. As I said: like a database client vs a database server. Or how about: like a client that wants to print something, vs. a print server embedding untrusted printer drivers!)

Re: Why GNU su does not support the `wheel' group (2002)

#108

Post by dathinab »

derefr wrote: post #72
dathinab wrote: post #39

Earlier quoted context omitted.

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…

Process owned by human-user fork(2)s and then exec(2)s suid program owned by program-user; program owned by program-user then does most of the work; but calls back over a domain socket to program owned by human-user to get it to do things on the program-user’s behalf. Picture: local DB client, remote DB server. Server can stream a file to the client for the client to write to disk. “On the same machine, as a differen…

like I sayed: hacks

Re: Why GNU su does not support the `wheel' group (2002)

#109

Post by gorgoiler »

fiddlerwoaroof wrote: post #92
Someone wrote: post #87

Earlier quoted context omitted.

> You might want to allow graphical editor to open any graphical file, regardless of location. More likely, you want to temporarily give them permission to specific files you indicate. A graphical editor doesn’t have reason to read any file that the user didn’t explicitly picked for editing/viewing. That’s how Mac OS works nowadays (possibly except for the ‘temporarily’; I don’t know the details): applications can on…

You can do this on basically any modern unix by passing file descriptors over a unix socket: the “graphical editor” server would launch as a user that can’t access anything except a socket and then users would open files by pushing an open fd to the editor over its socket.

This sounds interesting but I don’t understand what the underlying mechanism is. For me, a file descriptor is just an int corresponding to something I can read from and write to and a socket just carries bytes. I don’t understand how an FD can be sent over a socket or, if it can, how that’s anything more than just sending an int?

Re: Why GNU su does not support the `wheel' group (2002)

#110

Post by Dylan16807 »

seabird wrote: post #38
bell-cot wrote: post #2

Reaction: Mr. Stallman's idyllic worldview does not seem to admit that someone may actually own the computer system in question, or otherwise have legal rights to set limits on who uses the system, when, and for what purposes. And what was allowed by the social norms of the tiny 1980's *nix computing world, or what you can get away with when you're as famous as Mr. Stallman...those may not translate well to other con…

Stallman's ideas are often informed by high trust environments and business arrangements where the cost of the software itself is a fraction of the TCO. There's a big disconnect between the environment where Stallman made up his mind (large education/business environments) and how most people are introduced to free software (low cost entry into technical computer usage). I used to think Stallman was an ideologue from…

Withholding source code is obnoxious in any era. But that's a pretty distant issue from administrative privileges.
Post reply on HN