sudo make install, ok, great, some of the many operations you need to do requires privileges? Better give elevated privileges to all operations!
Even worse with GUI: enter your password to install. Now I have absolutely no clue what the scope of sudo is.
Of course I don't want to enter my password for all individual cp and mv operations, but if sudo had a better/smaller scope that'd be great.
On the other hand, having to always explicitly specify all the fine grained capabilities a process might need is a pain, too.
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.
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.
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...
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.
net.ipv4.ip_unprivileged_port_start=80
Ref: https://www.kernel.org/doc/htmldd/latest/networking/ip-sysct...
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.
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.
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.
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.
Now on a server, sudo for a single user probably doesn't make sense, just use root and keep it simple.
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.
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?
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 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
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.
OpenBSD has something like this https://man.openbsd.org/pledge.2
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.
Ugh, that's what I get for not reading before clicking submit...
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.
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...
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.
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.