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

121–130 of 150 posts

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

#121

Post by [deleted] »

ilyt wrote: post #79
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.

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…

[deleted]

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

#122

Post by josefx »

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.

> Which is what apparmor and firejail/sandboxes kind of want to embrace but in practice people just care too less.

In practice I don't have the time to debug every shitty little app armor integration for weeks. I lost days to libvirt-manager because its app armor support was enforced and not even half assed. Some configuration paths would automatically get whitelisted in its auto generated app armor profiles, others would just get you a file not found until you whitelisted them manually. The process responsible for generating these profiles would also silently kill itself if it encountered a path that was on its internal ban list, have fun debugging that when you do things like using an alternative bios rom, which by default are all stored in a blocked path.

Apparmor feels like security through obscurity, unless you already know that you are dealing with app armor fuckery there is no chance in hell that you will be able to run your application and not being able to run anything is the holy grail of security.

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

#123

Post by seabird »

Dylan16807 wrote: post #110
seabird wrote: post #38

Earlier quoted context omitted.

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.

Non-administrative users are given administrative privileges to complete their work all the time, even today. Misuse results in them being disciplined or fired. Heavy-handed privilege controls are very often a drain on the productivity of users and can result in stupid or dangerous (from a security standpoint) workarounds. 20 years on, you have to exercise more judgement in what you allow considering modern risks, but the idea that you shouldn't make things harder for people over a small number of bad actors that you can handle at an organizational level is still a good one.

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

#124

Post by skissane »

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.

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

I think one problem with the UNIX design is that UIDs/GIDs are a flat namespace, and commonly only 32-bits in size (even on 64-bit systems), when what is really needed to meet contemporary requirements is a hierarchy, either with an unlimited number of levels, or at least generous limits. Allow a user to create sub-uids (such as one per an application) and even sub-sub-uids (a web browser might create a sub-sub-uid for each website the user visits).

I think the Windows design of variable-length SIDs is in principle superior to the POSIX approach.

(Although, not necessarily in practice - it isn’t uncommon for Windows to make design decisions which in theory are superior to those of UNIX, but the practical implementation of them is full of warts, backward compatibility hacks, arbitrary limitations, and undocumented black boxes, which end up canceling out a lot of the theoretical advantage.)

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

#125

Post by fsflover »

effie wrote: post #96
_lvbh wrote: post #26

Earlier quoted context omitted.

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.

If you're targeted by state, Qubes on a PC isn't secure enough. It sits at a weird place, where it is stronger than your regular Linux, and showcases interesting ideas, but is quite restrictive in what you can do and doesn't provide any real security guarrantees. It's an open-source small shop project. Xen bugs and kernel bugs are too frequent, big boys know them/buy them/make them/exploit them, surely silently for y…

Snowden is using and recommending Qubes [0]. Only 25% of Xen bugs on average affect Qubes [1] and never lead to escapes. What is restrictive about Qubes? I do everything I need on it.

[0] https://twitter.com/Snowden/status/781493632293605376

[1] https://www.qubes-os.org/security/xsa/

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

#126

Post by atahanacar »

jcrawfordor wrote: post #78
atahanacar wrote: post #53

Earlier quoted context omitted.

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

>A file can only have one group, and people use more than one application

But users can be in multiple groups. You can have files with groups like "graphics, audio" etc. and give access to the application users by adding that user to the relevant groups.

>IPC other than file based

This isn't UNIX model though, is it?

Though I agree with you. Given the current state of programs, file permissions aren't enough for isolation.

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

#127

Post by cookiengineer »

colonwqbang wrote: post #82
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.

Maybe on the server/desktop side of things. In embedded Linux the "user per app" scheme is very useful and is embraced.

The issue I have with it is that a lot of living off the land techniques are caused by this false sense of how UNIX user and group management is supposed to work.

I mean, the correct approach would be to have groups even for specific network protocols because capabilities are not enough to sandbox a binary correctly, and the network group is pretty much pointless.

And then there's icmp, which brings us to the ping binary which on lazy distributions still has an SUID flag set, as well as glibc which still allows LD_PRELOAD by default because it is intended functionality from the perspective of its developers.

Most of these privilege escalation exploits can be mitigated, if users and groups and capabilities are managed correctly.

In practice I probably would recommend to use the systemd seccomp sandboxes because most of these quirks have been abstracted away there and are configurable in the service files - like file/folder access, user/group randomization, chrooting, capabilities etc.

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

#128

Post by tryauuum »

josefx wrote: post #122
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.

> Which is what apparmor and firejail/sandboxes kind of want to embrace but in practice people just care too less. In practice I don't have the time to debug every shitty little app armor integration for weeks. I lost days to libvirt-manager because its app armor support was enforced and not even half assed. Some configuration paths would automatically get whitelisted in its auto generated app armor profiles, others…

Regarding the last paragraph... Apparmor writes pretty verbose messages visible in journalctl (and in dmesg I think), so it's not really an obscurity

I used libvirt with apparmor and was pretty satisfied with it

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

#129

Post by aragilar »

skissane wrote: post #124
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 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. I think one problem with the UNIX design is that UIDs/GIDs are a flat namespace, and commonly only 32-bits in size (even on 64-bit systems), when what is really needed to meet contemporary requirements is a hierarchy, either with an unlimited number of levels, or…

Have you heard of user namespaces? They would match all your requirements it seems.

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

#130

Post by fsflover »

Dylan16807 wrote: post #105
invalidator wrote: post #81

Earlier quoted context omitted.

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?

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

Yes, if you only have a USB keyboard, it will work. Manual creation of a USB VM then is recommended for security: https://www.qubes-os.org/doc/usb-qubes/

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

Of course you are right. TemplateVMs provide /root partition to AppVMs and software should be installed normally to the former. At every AppVM reboot, their /root is reset to the one from TemplateVM. Ordinary, persistent VMs are also possible. Details: https://www.qubes-os.org/doc/getting-started/

Post reply on HN