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

71–80 of 150 posts

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

#71

Post by indymike »

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…

> someone may actually own the computer system in question,

And that person may not be the systemadmin

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

#72

Post by derefr »

dathinab wrote: post #39
cookiengineer wrote: post #21

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

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 different user” is just the trivial case of “over the network.”

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

#74

Post by pram »

e28eta wrote: post #70

I’m curious how Twenex worked, that a non-operator (root) account was able to patch the kernel. Maybe the kernel files were unprotected, because it’d be absurd for ordinary users to want to change them? Or did he have to use an exploit to elevate his privileges?

Probably just didn't have filesystem permissions of any kind.

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

#76

Post by jcrawfordor »

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…

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.

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

#77

Post by dooglius »

markstos wrote: post #54
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?

Qubes is enough of a pain to use that another OS project started to try to take the concept and make it more usable: https://spectrum-os.org/ Doing so has proved hard and slow so far, and Spectrum hasn't had a usable release for the masses yet.

> Initial versions of Spectrum will have the user be responsible for writing Nix code for each application and resource, and the combinations they make between them.

As a qubes user, I think this is interesting but it definitely does not sound more usable.

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

#78

Post by jcrawfordor »

atahanacar wrote: post #53
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…

If everything is a file, and files can have permissions, then you can simply allow the "program user" access to those files using groups.

The group model is far too inflexible to make this realistic... A file can only have one group, and people use more than one application. ACLs are available on Linux (although seldom used) and help to address this problem, but the ergonomics are very poor. Since ACLs don't address the issue of syscalls, IPC other than file based, etc., It hasn't really made sense to make them the focus or application isolation efforts. The kernel namespacing and capabilities features are a lot more attractive for this use and are more similar to the historic approach of chroot... But the tools still aren't great.

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

#79

Post by ilyt »

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.

Only sounds like "irony" if you don't understand problem.

The problem is not isolation or lack of it. The problem is that app require complex set of permissions for both users files and other apps.

App might want to send notification to notification daemon. But app should not be able to pretend to be another app, whether by name or icon. And good luck trying to stop malicious app from just making same/similar enough icon and spelling Firefox with some fancy UTF characters to go around it.

And that's pretty simple case! And already very hard on kernel/OS level to solve. Now look at files.

You might want to allow graphical editor to open any graphical file, regardless of location.

You might want to allow that same editor to only edit some of them.

But for browser, you might want to allow saving new files, but not editing/rewriting existing ones, because it is not an editor, and should have no business editing the files.

Or, allow browser tab browsing certain URL (say, web image editor) to modify the files, but not the image sharing webpage that only needs to read the file.

Now we not only have insanely granular permissions per app, the different actions from "app" (web browser is basically container for multiple applications at that point) also need different permissions.

It has nothing to do with "unix bad", or "unix wrong", to actually separate the applications without hardships on the user (like fucking with permissions every time one app needs to touch files of another app) is just very very hard

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

#80

Post by marcus0x62 »

ilyt wrote: post #75

That doesn't make any sense ? Why it should check some random group ?

The idea is to only allow user accounts in the wheel group to invoke su to take on root privileges. So, if someone had access to a random user account and knew the root password it wouldn’t do them any good.
Post reply on HN