Sudo feels like a broken concept to me because it's there to protect the machine and other users.

But these days many computers are only used by one user.

Everything I care about on my computer is readable by my user and a program running as my user could put fake binaries in my path.

A - I have access to quite a few *nix servers, where multiple login users and/or services with district UIDs are a thing.

B - Not sure how practical most of this is yet, but there's cool stuff around isolating individual programs even on single-user machines.

C - My desktop has a couple things that listen on the network, and it's nice that they only have access to specific things.

For desktop use, sudo let's you elevate your permissions as necessary (polkit kinda replaces some sudo stuff, but similar concept). The reason you want this is when you run anything, it will _by default_ run as your unprivileged user, not root. That is a huge security benefit and pretty standard across desktop OS these days.

Now on a server, sudo for a single user probably doesn't make sense, just use root and keep it simple.

> That is a huge security benefit and pretty standard across desktop OS these days.

But is it really though? That's the parent was alluding to.

I have the same feelings - all my important data are readable/writeable as my user, if I somehow manages to run a malicious program as my normal user it's game over as far as I'm concerned, having root would cause no extra damage.

Root access can be more insidious, like adding a crypto miner in the background or some other kind of virus masquerading as a system process. Your data would still be there, just silently being exfiltrated, along with your keystrokes/passwords.

Are you suggesting running everything as root?

As in when you setup a new vm or whatnot, that you shouldn't create a user account to run thing as?

Does this include things like nginx not dropping privileges to run as a user?

With just one user managing the server, for sysadmin tasks like SSH, use root, especially if you're going to sudo everything you do anyways. For services, they should still run as unprivileged users.

This is why the concept of "granular permissions" is so important on modern pcs, and I personally think linux is severely lacking in this regard.

Flatpack et al. have improved this situation somewhat, but come with their own drawbacks. Linux needs a central application-level permission system like Android, where I can grant/revoke e.g. internet access to applications. Frankly, I should never have to use sudo to install anything in my daily life, that is unfortunately not the case with the common ubuntu install, and will probably stay this way for a long time.

Yeah, for the most part today any user who is logged in is somebody I trust with the machine. What needs to be restricted is what _applications_ can do.

My browser shouldn’t ever be allowed to to write to /etc/shadow regardless of whether it’s running as root or not. AppArmor gets us part of the way there but the UI to make everything play nice is too difficult.

Android’s security model makes a lot of sense to me, and from what I understand it’s all based on top of normal UNIX user/group privileges, just with per-app users/groups. I’d like to see more desktop distros experiment with it.

Could you have a system where each capability has its own group, and each executable has capabilities represented by their group memberships? Then it would be easy to build a UI on top of those groups to manage fine-grained permissions.

To be fair, it's the permission model that's not kept up with use cases. On a multiuser system sudo makes a lot of sense.

I feel that most computers may be used by 1 user but belong to someone else with their own requirements as to what is permissible. Company laptops seem to be more common than personal machines. Most will just have iPads and phones For personal use.

Well, kinda. For user, sure, but we could definitely get some security from having more granular permission for apps that the user runs (without going into extremes like Qubes OS).

For example, sound demon like pulseaudio runs as your user (...for some reason, fucking Lennart) but it really should not have write access to anything aside from its own config and for 99,99% users also not have access to read anything your user owns aside from its own config.

Even browsers should probably be limited, or user should at least get prompt, there is little reason to allow browser to dig around your system willy nilly, let alone in locations like ~/.ssh

You can sudo to other users besides root.

For installing things, you generally need write permissions to /usr/bin and likes. So you could create an user with such privileges and sudo to that.

The real issue, I think, is Linux not being capability based, so there's no programmatic way for scripts to communicate which sort of permissions are needed.

> communicate which sort of permissions are needed

OpenBSD has something like this https://man.openbsd.org/pledge.2

Unfortunately not. Pledge is _awesome_, but it's a different thing.

Pledge protects the system from buggy well-intentioned, cooperative software that could have bugs. What's needed is something that protects the system from ill-intentioned, uncooperative software.

> buggy well-intentioned, cooperative software that could have bugs

Ugh, that's what I get for not reading before clicking submit...

SELinux was intended to address this very thing. It's a complex beast that people find too difficult to understand and thus usually it gets disabled.

I see this attitude in pentesting too on embedded systems. A developer encounters a problem they don't quite understand but the problem disappears when they run their app as root, so away we go.

The real broken concept here is root. Why do I have to give a process the ability to do anything it wants with the system if I want it just to write to a file in /etc, or to bind to port 80?

On the other hand, having to always explicitly specify all the fine grained capabilities a process might need is a pain, too.

Port 80 doesn't need root access. Have an administrator `setcap cap_net_bind_service=+ep /your/binary/here` and you can use any port you want.

Files within /etc do, for security reasons, but there's no reason why you couldn't use user groups or other ACLs to secure those folders.

chown /etc to nobody:wheel and chmod it to g+rwx; users in group wheel will now be able to manage /etc. You've got to make sure you set your umask right if you do use sudo for /etc again, but that's also just part of your system configuration.

Yes, having to always explicitly specify all the fine grained capabilities a process might need is a pain, too.

With Ubuntu's AppArmor you can run a lot of software without hassle because the ACLs come with the OS package.

> Have an administrator `setcap cap_net_bind_service=+ep /your/binary/here` and you can use any port you want.

And remember to do it again every time the binary is updated :/

> chown /etc to nobody:wheel and

Bad idea! nobody is supposed to own no files at all. You run untrusted services (or untrusted users without account; something like anonymous FTP access) as nobody. This would potentially allow the least trusted entity to change your configs.

Apart from that. Since root can read any file anyways there is no reason to change the owner. And some programs may complain if the configuration is not owned by root.

> And remember to do it again every time the binary is updated :/

Depends on the way the file is replaced; if it's overwritten and not deleted + created, the flag should stick around I believe.

> Bad idea! nobody is supposed to own no files at all. You run untrusted services (or untrusted users without account; something like anonymous FTP access) as nobody. This would potentially allow the least trusted entity to change your configs.

You're right, should've used root:wheel rather than nobody:wheel. Oops...

Having a process request its required capabilities and sudo displaying that list to the user, who can agree to sudo giving giving them only those capabilities would be good.

Changing ownership of /etc/ and directories under it like that sounds fine in theory but in practice breaks in many ways.

I did some extensive testing of this some years ago (on Debian/Ubuntu) and many system services and tools expect/require these directories to have specific ownership and permissions.

In the context I was experimenting with it was pretty simple too - renaming the UID 0 'root' account to some other name. That revealed that many tools actually test for "root" (the string) not uid == 0.

As I dug into the code of those tools I found many would also check and insist on particular ownership and modes on the directories and files.

I forget which one really annoyed me, but 'all' I wanted to do was allow members of group 'adm' to read/write into a particular sub-directory of /etc/ but the service would bail out if the directory wasn't owned by "root":"root" (or 0:0) and had 0700 permissions which is a pain when wanting to run services unprivileged and using 'setcap' to enable capabilities without starting as UID 0 and dropping privileges.

An alternate approach is to set the sysctl for this:

    net.ipv4.ip_unprivileged_port_start=80

Or whatever port you want unprivileged to start at. If you set it to 0 it means any user can bind to any port < 1024.

Ref: https://www.kernel.org/doc/htmldd/latest/networking/ip-sysct...

Go ahead, send your commits to the Linux kernel then.

Being able to write to /etc/ is effectively just granting full access, since there's lots of things in there that can run code.

Doing fine-grained access is really hard; even without "root" you still have things like, say, "archive_command" in postgresql.conf which will allow running people to run arbitrary commands as the postgres user, and is that really what you want? There's lots of little things like that ranging from application configurations to crontabs to your init system.

set-uid is especially dangerous, so that's the best target for removal.

Sudo has two protective jobs. One is to completely prevent people from elevating if they aren't in sudoers. The second is a best-effort attempt at preventing people from blowing their own foot off, by running most commands without privileges.

If you are in sudoers and you are compromised, then there are like a million ways of getting root for a malicious program. They could override your sudo, override your terminal, override your shell, override your de, even override say "cat" so that instead of exiting when it is done, it starts a shell that mitms all your commands and waits for a sudo one.

> sudo make install

Even ignoring security issues, all of make getting elevated privileges can cause other issues as well.

All it takes is the incremental build system being a little finicky, and "sudo make install" could rebuild an object as root, and now one or more of your ".o" files are owned by root and your build directory is broken.

You can just allow those smaller scope commands and nothing else in sudo.

That's a part of a reason for its complexity it does allow you to do anything between "make user be another user with all priviledges" to "just allow to run this particular command and nothing more".

Having one that had option for more limits would be interesting (say use cgroups to change running user but disallow command from modifying anything aside from this one single directory you specified) but, well, that's way more code that also needs to be secure...