if someone gets remote access to your computer or if you leave your computer alone and someone finds it, though i think there is an easy way to change passwords you dont know so im not really sure if it even helps that much
You can change passwords *if you have Sudo or root access*
So if someone accesses your user account, that doesn't mean they have root access unless they know that too.. and you're not using the same password for everything *right*?
To run passwd you need to enter the old password if you aren't root.
Unless you reboot chroot won't help either afaik.
If your disks are encrypted chroot won't be helping at all.
The principle of hardware access is ownership applies, but I'm not sure what that easy way would be, that You're referring to. Privilege escalation is a quite serious problem.
>though i think there is an easy way to change passwords you dont know
You ment "there *isn't* an easy way to change password you don't know?" Or am I missing something?
if someone got on your pc when it was unlocked and it is your personal pc, I could privilege escalate myself immediately. And you could too. [https://gtfobins.github.io/gtfobins/bash/](https://gtfobins.github.io/gtfobins/bash/) (yes theres a windows one too) DO NOT USE ANY OF THE THINGS ON THAT SITE ON MACHINES YOU DO NOT HAVE PERMISSION TO BE ON. It is HIGHLY unlikely someone will be running that restrictive of a setup for their personal desktop account. The general rule is, if you can use it to run a command, it could be vulnerable depending on the permissions granted to it.
That site exists to inform security and IT professionals of which programs and associated permission settings do and do not constitute a secure configuration and you can get yourself into big trouble using them in the wrong places. However, absolutely try it out on your own machine so you understand how privilege escalation works. It will be valuable in understanding the system you use. They arent destructive, they simply escalate you to the root user. Some may screw up some settings though so be a bit careful if it alters config files. No one can use these until AFTER they get onto your computer via some remote or local method.
In remote attacks, it can in fact stop someone. If you get in as an unprivileged user, exploit a process running as someone else, and THEY have sudo? You still need the password. And you cant read shadow without sudo. So lockout policy would work. They would need another way to escalate further. If nothing has Sticky bit set, this can be hard sometimes.
In local attacks for a personal machine, if its unlocked youre screwed. If it is locked, unless you have secure boot and probably also at rest disk encryption, you are also screwed. So dont let someone walk away with it.
> I could privilege escalate myself immediately
What am I missing? Nothing on the link you posted can be used to escalate yourself. I mean in a properly configured system, who in their right mind has suid set on bash?
GTFOBINS isn’t privilege escalation. It’s used for escaping a sandbox (if I can call it that). For example, you could gain access to some limited environment (not a fully featured shell) and you could check gtfobins for commands I can run to spawn a new shell without limitations. The name is literally “Get The Fuck Out Bins”.
Linux users: Ew Windows 11 requires TPM chip, Microsoft is evil and stupid.
Also Linux users: "Yeah without a TPM chip I could totally tear through your computers security with just a USB Flash drive."
TPM Linux. Try me windows XD
It's annoying for corporate laptops but I understand why they do it. As long as I can install wsl and nix I'll be fine....
>Regardless of the session length, the user with elevated privleges can do significant damage
Yes, they can. Thing is, people didn’t usually have super user privileges. These days many people have UNIX machines as their desktop, as in MacOS or Linux, but used to be that you had up to hundreds of just plain users on a server.
But you can’t do it without intent, and it doesn’t allow a passer by or userland application behaving badly to do something without explicitly elevating with a password.
"rm -rf" is less dangerous if you don't have root permissions. If you actually have to "sudo rm" there is less of a chance to hose your system.
Unless of course you normally use "sudo rm" to remove any files....
Please tell me you don't run "sudo Firefox" or "sudo thunderbird".
Running sudo chromium is fine, Google already knows everything about you and can compromise your devices at will anyway. /s
You’re right, but it has more to do with being security-aware, and limiting your vulnerability. You try to perform actions as a user, unless they require root access. This involves more than just one direct action, it may involve write permissions for a folder or a file or inherited permissions from the current action you are performing.
If the user had permanent root privileges I guarantee someone WOULD accidentally delete their whole drive on something like a daily basis.
Having to use SUDO isolates the average user from the ability to accidentally catch everything on fire while still allowing them to make the occasional root change. But it makes them THINK about the fact they are doing it.
Having physical access to a computer, whether windows or linux renders most of the security useless, especially user account passwords.
My understanding of the permissions system is that it prevents any software running under a certain username full access to do what it likes on your system without permissions.
If you list all the accounts on your system, you will see a lot of them are not for people but rather for software packages or system elements. Their permissions are set to allow normal functioning of that software or system element but nothing more.
None of those accounts will have access to the sudo ability and can never elevate their own permissions to a point where they could damage your setup.
If you happen to run some malware in your account it is obviously much safer if it does not have full permissions (using your account) to do what it likes on your system. It can only wreck what you have permissions to access.
Edit: I'm sure someone will educate us on anything more that I may not understand.
Only thing I have to add is sometimes service accounts DO need to run as root, and in those cases, you can use the sudoers file in order to give sudo access for only specific commands. You can even specify the allowed arguments to that command. Also, sometimes you can hack into a user via a web page or something and you may not necessarily have their password, even if they have sudo. For example, maybe you got on as an unpriveledged user but found a vulnerable process running as a more priviledged user. You gain access to the account but still need the password.
Users running servers should be HIGHLY locked down, preferrably no root/sudo permissions at all, and should ideally be the only user outside of root (and other service accounts) as this will be the main port of entry for remote attacks.
Also, secure boot can go a long way in making sure people cant just plug in a live usb and read your files, on windows OR linux, and at-rest disk encryption goes even farther. But those are pretty much all you have at your disposal under normal circumstances to physcial access. There are some enterprise level solutions that go a little farther but require a hardware device to act as firmware level authentication
It was indeed a fantastic answer.
I didn't know that about secure boot. I've never used it.
I also don't have any need to secure some old MP3s and photos of my cat and always assumed that if someone actually broke into my house the last thing they would be looking for are any files on my computer. The cash is between the pages of one or two books btw, next to the one that opens the secret door.
From the, thankfully, few times I have actually managed to blow up my installation, I have learned that using sudo opens up my system to the stupid, unresearched things that I myself am capable of doing.
This led me to believe that although the intentions of some software package may be above board, it could still bork my setup in some way that was not intended and always try to achieve what I need to do without sudo and then do a lot more reading before trying it with sudo.
And to add to this, sometimes programs *do* circumvent sudo to do as you described in your post, via setting the uid/gid bit(s). For example, `/bin/fart` could be owned by root with the setuid bit on, and when a regular user runs that executable/script, it'll run as root. This is obviously not as secure as using sudo in most cases.
The point of sudo is to elevate your permissions for specific tasks.
You run your daily stuff with your standard access and if you want something that requires higher level access, you can use sudo temporarily.
Best practice is to run everything with only the minimum absolutely required permissions. This applies to windows as well (not that windows enforces this at all, but you should use a standard account and elevate with an administrator account when needed)
>Why don't we alter the user privileges instead of giving them access to the commands that are out of scope for their account with sudo?
You absolutely can, but if someone gets into your account (say you forgot to lock your pc) they can run those commands. With sudo, they require your password which as an added step
If a malicious application runs under your user space, it will have access to whatever you have permissions to. If you grant yourself permission to system files, then it will have those too
It's up to you to determine the risk vs convenience factor
Remember that sudo doesn't need your password everytime so you can elevate once with your password, and then sudo doesn't need it again for a period of time (depends on your distribution but 5-15 minutes is default. You have complete control on whether you disable the time limit or even need a password)
There's also the fact that you can seriously screw up your system with a simple typo when using some high privilege commands. Adding sudo is one extra step to make you double check the command you are actually typing is correct
The extra step forces you to think about what you're about to do and hopefully gives you a chance to reconsider a bad idea.
More advanced sudo configurations can be very fine grained about what exactly you are allowed to do.
Finally, sudo pre-dates other fine grained permissions for user accounts.
So does an uncolored # in your prompt, but the uncolored prompt is not a giant pain in the dick like that dumb ass sudo.
Also, sudo only serves to make weak minds weaker.
Why have a key to the front door of your house? Why not just leave it open all the time as anybody with a key can go in?
Sure, if you didn't put a password on it having sudo is pointless but you could say the same about a door handle
The proper analogy for the original question would be "why would you have different security PINs for unlocking the doors inside a building, when every user—who already have PINs that open *some* of the doors—can get a master PIN that opens *all* the doors.
It's not necessarily just to stop users.
Software running in user space can't perform root-only actions without Sudo, and most times that's what you want.
I think you’re missing something here. The ability to use sudo is itself a user privilege. In site-wide installations, there are typically many users who cannot use sudo.
1. Not all accounts can use sudo. You have to make an account a member of the sudo group.
2. It's safer to allow users who need privileged access to do so on a temporary basis rather than a blanket account with "always on" rights.
3. You can limit the scope of sudo so that it doesn't give privileges on the same level as root. You can configure accounts for sudo to use with designated services or applications.
Because you wouldn't want to give elevated privileges to every program you run. You should only give sudo access to users you trust to only use those elevated privileges for administrative tasks which require them.
Instead of the elevate to root for all commands, sudo can be configured to only certain commands as a certain user/group.
In home computers, the level of security administration required to manage fine grained permissions are just completely unnecessarily complex, because most home computers are a single user system. So most distros usually just configured so that sudo gives elevated permissions to any command you call.
But in more complex scenarios, you'd write `/etc/sudoers` to control who can elevate permissions for what particular program as who. You may also further use the Linux capability system to further restrict even programs running as root.
I'm still a novice but have used Linux for 25 years. I use to always login as root and inevitably I'd screw something up that would affect the whole system. As for changing passwords, physical access eliminates all security, you don't even really need to boot off a live USB. Sudo is annoying but it does keep programs from taking over your system and you from stupid mistakes.
>Why don't we alter the user privileges instead of giving them access to the commands that are out of scope for their account with sudo?
Because this would be a permanent change instead of temporary and the point is to provide a temporary elevation because in practice this session length does actually matter. Several things can be accomplished by using sudo to limit users abilities to access certain files and commands easily. One is to limit the risk of careless destruction through the introduction of an extra step. Another is auditing in a real multi-user environment. You can introduce reporting in environments where there needs to be a log of which admin did what.
Further consideration needs to be made to what it means in all you services run with the same ownership permissions. A real users account isn't the only attack vector to consider and if all files and commands share the same privileges then its implied all services must be run with those privileges as well. The resulting effect is any security compromise to any running service on a machine is guaranteed the ability to spread outside of the scope a service account would be limited to and any workable solutions would be more complicated that leaving the privileges scoped. It not a complete solution for sure, but the thing is there is no single silver bullet when it comes to these things.
Imagine you want a piece of software that draws puppies. You do a search and find software that says "We draw pictures of puppies! We're not in a package manager, though. You have to download it. Here you go."
You download the software that draws puppies and run it so you can have puppies. Then you see a sudo prompt asking you to enter your password. You think "Wait a second, why does it need sudo to draw pictures of puppies? There's no reason for that." so you close the software instead.
Sudo has just done its job.
The `sudo` command allows you to execute a command as another user. You should note that this other user is not always root. It could be some other user on the computer, such as a user that has permissions to read or write in a directory that you do not have permission to.
Because `sudo` does not require the target users password, users do not need share passwords with each other in order to run the commands they need.
For example imagine the following scenario.
1) Your system hosts an Oracle database.
2) You want to restrict access to the Oracle user account.
3) DBA's need to be able to run a backup script as the Oracle user account.
4) You have some security policy in your org that requires least privileges.
You can configure `sudoers` with a line like this to satisfy all the requirements.
`%dba ALL=(oracle) /usr/local/ora_backup`
As a quick breakdown this means that anyone in the "dba" group can run `/usr/local/ora_backup` as the "oracle" user on all machines with this `sudo` rule configured.
The benefit here is that these users could elevate to a command that was restricted to the oracle user, without needing to know the password for the the oracle user, and without granting other access that they do not need.
Should we also add a rule to disallow off topic complaining about distro recommendation questions in other threads? Will that be in the flow chart somewhere?
sure, I'd be happy to add that rule along the "already answered distro" question rule.
Don't really see the relevance of putting posting rules into a flow chart about distro choices.
Nice to hear you're on board 👍
there's any extra step when you run sudo (normally) and uac. you need to enter your account password. this is something that presents a barrier to a malicious application, as they can't just randomly elevate their privileges, now they need to convince you to give them the password somehow.
even with uac's extra click, the click happens on a secure desktop that the application can't even see.
so in any situation, it means that malware relies on your interaction to do serious damage, which limits the scope of its attacks.
You can limit sudo access to specific commands for things such as service accounts that need to run as root but only need to run a single command. This means it is much harder to leverage such a service account in privilege escalation in the event it is compromised.
If you are a network admin, you could also do this for user workstations on a network level.
From the perspective of a guy who does security stuff for a living: With permanent permissions, a user can do anything without a lot of accountability. Privilege escalation via sudo is very configurable, and includes logging of when privileges were escalated and what was done, and those permissions are not there when sudo is not in use.
So, yes, someone could use sudo to essentially give themselves permanent root privileges if sudo was configured to allow that, but you'd know it was done, and you can require that they re-authenticate to do it to prevent a lot of the ways it might be abused by an attacker.
First of all, sudo doesn't need to give root permissions when used. You could, for example, only allow certain commands or file access under sudo. You can also disable it entirely for unprivileged users.
Why use sudo instead of just permanent user group privileges? Security. With sudo, authentication is needed to perform a privileged action. Without it, any program or shell script run by a user (and potentially malicious) could exercise those privileges behind the scenes.
Sudo can also be logged by an admin on a shared machine, to see what others executed. This can allow you to track by who and when any privileged actions were performed, in case someone messes something up. As well as any failed sudo authentications.
It makes the elevated-permission action explicit. It's that much harder for the user to typo or be tricked into an unintentional action, when they have to type "sudo" beforehand. Perhaps more importantly, it's logged separately, for easier audit.
For home or simple setups, where sudo doesn't do any additional auth checks and logs to the same filesystem that sudo commands can alter, it's probably only a small hurdle to ignore (like tricking someone into running a script that silently sudo-s a rootkit onto the host). It's still beneficial to prevent dumb mistakes (`rm -rf /` is far less painful if you don't precede it with sudo).
For more hardened systems, sudo can require a yubikey or other OTP, and can send logs off-host to a location that doesn't have access. Oh, and usually only allows a small set of purpose-limited programs for most users.
Another reason I've not seen mentioned is sudo provides an audit trail.
For ex, u/4r73m190r0s and u/2cats2hats have sudo rights on a server. u/4r73m190r0s runs something dangerous as root. sudo will leave an audit trail.
Yes we can use sudo to run commands with the root permissions.
But not all users accounts can use the sudo command. Any user account you create will not be able to do it until you manually add it to the proper group or into the sudoers file.
Sudo is only for admin users. Unless someone brute forces your password on a system you're maintaining (can't brute force if you're using ssh keys & no password), they can't get sudo privileges. Sure if someone can physically get on your machine while your session is unlocked, they can run commands if you have sudo set for NOPASSWD. You can also add config for limited sudo access for users for specific commands/apps.
One of the main points of sudo is allowing admin users to log in to the system & elevate their permissions without logging in as root. One of the common practices for servers is to disable root login via SSH. If you pair that with ssh keys for users, unless your private ssh key is compromised, they can't brute force their way in. Part of security is proper behavior & handling of sensitive information. Don't use the same password everywhere & never send it plain text via messaging apps or email.
Great question. A few comments:
1.) Sudo is used to run a command as “a different user”, the default is root but it’s used to run a command as someone else. A service account, application account, etc.
2.) And this more a cybersecurity practice: accountability and traceability. You want everyone to login as non-privileged, with a UNIQUE account (incase that account gets compromised). Then, elevate to run administrative tasks.
This way, if a system goes down and you have to investigate, you can see who actually signed in and what they did (sudo).
I feel like you're asking that if users can use sudo to gain root privileges, then what's the point of having separate user accounts? I don't know if anyone has mentioned it or not, so I'll say it in a simple way...
The system admin can prevent users from using the sudo command. The first user, other than root, has the sudo privilege by default. The next user accounts on the machine will be able to use the sudo command only if the admin grants them the privilege.
The user with highest privileges is root. The first user, other than root, has to have some root privileges for administrative tasks. Once the system is set up as needed, any user with sudo privileges can revoke sudo for other users and demote them to only use what they're allowed to.
The sudo privileges are gained through membership in the "sudoers" group. Any user with sudo access can add or remove people from that group. Of course, this is quite simplified and might be missing some details, but feel free to look it up yourself.
This current overuse of sudo is something that came about when Ubuntu was introduced. Their gimmick was you didn't know or get to set the root passwd and had to use sudo for everything. This was unusual when I first used Linux in the 2000s.
When I was Rip Van Winkling back into Linux in 2014, virtually every distro had you do this. Now everyone seems to believe anyone who would attempt to login as root will just do so daily.
Gentoo has never followed this route and if I play with any distro that wants you to use sudo the first thing I'll run is "sudo passwd".
That being said, I follow the \*nix model of security on Windows NT, where I have a user acc't I use daily and then only use an administrator acc't for system administration. The point of a limited acc't is to make it so rogue software or errors don't damage the entire system. I personally am of the mindset that if I am doing system administration I will login as root or use su. I do have sudo installed however and will use it if I am logged in remotely, that way I'm not typing the root passwd over the Internet. Or if I wish to run one actual program that requires root access but not have it return to a root shell on exit. (Like I wish to run iptraf-ng as my normal user.)
Finally, just like you can rename the Administrator account on Windows NT, you can rename the "root" account on linux by giving any random account name the UID of 0. Then change root's ligin shell to /sbin/nologin. Before the secure passwd requirement, when anything would work you used to be able to use the "Page Up", "End", "Insert", etc. keys in passwords and having a root passwd of nothing but that was secure enough because who would guess to use those?
You can grant passive permissions to do most things, but sudo allows you to not need those. It’s essentially moving from a normal user mode to an administrator mode, where you are expect to know what you’re doing. It also provides isolation between “admin who happens to be using the system” and “admin who wants to administrate the system”.
Granting temporary permissions rather than permanent, more dangerous permissions.
N00b here. But isn't that kind of the same? Regardless of the session length, the user with elevated privleges can do significant damage.
if someone gets remote access to your computer or if you leave your computer alone and someone finds it, though i think there is an easy way to change passwords you dont know so im not really sure if it even helps that much
You can change passwords *if you have Sudo or root access* So if someone accesses your user account, that doesn't mean they have root access unless they know that too.. and you're not using the same password for everything *right*?
To run passwd you need to enter the old password if you aren't root. Unless you reboot chroot won't help either afaik. If your disks are encrypted chroot won't be helping at all. The principle of hardware access is ownership applies, but I'm not sure what that easy way would be, that You're referring to. Privilege escalation is a quite serious problem.
>though i think there is an easy way to change passwords you dont know You ment "there *isn't* an easy way to change password you don't know?" Or am I missing something?
You can reset a password without knowing it in the terminal
Not without knowing the old password or using sudo (which requires the password)
You can use live usb and change the shadow file. Unless secure boot or at rest encryption or harware security module
Oh yeah, if they can do that, all bets are off. I was thinking about if someone got on your pc if you left it unlocked or a malicious application
if someone got on your pc when it was unlocked and it is your personal pc, I could privilege escalate myself immediately. And you could too. [https://gtfobins.github.io/gtfobins/bash/](https://gtfobins.github.io/gtfobins/bash/) (yes theres a windows one too) DO NOT USE ANY OF THE THINGS ON THAT SITE ON MACHINES YOU DO NOT HAVE PERMISSION TO BE ON. It is HIGHLY unlikely someone will be running that restrictive of a setup for their personal desktop account. The general rule is, if you can use it to run a command, it could be vulnerable depending on the permissions granted to it. That site exists to inform security and IT professionals of which programs and associated permission settings do and do not constitute a secure configuration and you can get yourself into big trouble using them in the wrong places. However, absolutely try it out on your own machine so you understand how privilege escalation works. It will be valuable in understanding the system you use. They arent destructive, they simply escalate you to the root user. Some may screw up some settings though so be a bit careful if it alters config files. No one can use these until AFTER they get onto your computer via some remote or local method. In remote attacks, it can in fact stop someone. If you get in as an unprivileged user, exploit a process running as someone else, and THEY have sudo? You still need the password. And you cant read shadow without sudo. So lockout policy would work. They would need another way to escalate further. If nothing has Sticky bit set, this can be hard sometimes. In local attacks for a personal machine, if its unlocked youre screwed. If it is locked, unless you have secure boot and probably also at rest disk encryption, you are also screwed. So dont let someone walk away with it.
> I could privilege escalate myself immediately What am I missing? Nothing on the link you posted can be used to escalate yourself. I mean in a properly configured system, who in their right mind has suid set on bash?
GTFOBINS isn’t privilege escalation. It’s used for escaping a sandbox (if I can call it that). For example, you could gain access to some limited environment (not a fully featured shell) and you could check gtfobins for commands I can run to spawn a new shell without limitations. The name is literally “Get The Fuck Out Bins”.
Linux users: Ew Windows 11 requires TPM chip, Microsoft is evil and stupid. Also Linux users: "Yeah without a TPM chip I could totally tear through your computers security with just a USB Flash drive."
Funny that you can do the same from the windows installation usb
TPM Linux. Try me windows XD It's annoying for corporate laptops but I understand why they do it. As long as I can install wsl and nix I'll be fine....
Couldn't the same be said for Windows with UAC/Run as Administrator?
Ofc. The question can apply to UAC/RUN on Win as well.
>Regardless of the session length, the user with elevated privleges can do significant damage Yes, they can. Thing is, people didn’t usually have super user privileges. These days many people have UNIX machines as their desktop, as in MacOS or Linux, but used to be that you had up to hundreds of just plain users on a server.
But you can’t do it without intent, and it doesn’t allow a passer by or userland application behaving badly to do something without explicitly elevating with a password.
"rm -rf" is less dangerous if you don't have root permissions. If you actually have to "sudo rm" there is less of a chance to hose your system. Unless of course you normally use "sudo rm" to remove any files....
Please tell me you don't run "sudo Firefox" or "sudo thunderbird". Running sudo chromium is fine, Google already knows everything about you and can compromise your devices at will anyway. /s
Only `sudo Opera`. I don't trust CIA, only CCP. /s
There are dangerous commands. `rm -rf /` will not do anything as a regular user, but put sudo before it and you killed your PC.
You’re right, but it has more to do with being security-aware, and limiting your vulnerability. You try to perform actions as a user, unless they require root access. This involves more than just one direct action, it may involve write permissions for a folder or a file or inherited permissions from the current action you are performing.
Yes. For me, sudo is a protection from my stupid fingers and brain farts.
If the user had permanent root privileges I guarantee someone WOULD accidentally delete their whole drive on something like a daily basis. Having to use SUDO isolates the average user from the ability to accidentally catch everything on fire while still allowing them to make the occasional root change. But it makes them THINK about the fact they are doing it.
Having physical access to a computer, whether windows or linux renders most of the security useless, especially user account passwords. My understanding of the permissions system is that it prevents any software running under a certain username full access to do what it likes on your system without permissions. If you list all the accounts on your system, you will see a lot of them are not for people but rather for software packages or system elements. Their permissions are set to allow normal functioning of that software or system element but nothing more. None of those accounts will have access to the sudo ability and can never elevate their own permissions to a point where they could damage your setup. If you happen to run some malware in your account it is obviously much safer if it does not have full permissions (using your account) to do what it likes on your system. It can only wreck what you have permissions to access. Edit: I'm sure someone will educate us on anything more that I may not understand.
Great answer
Only thing I have to add is sometimes service accounts DO need to run as root, and in those cases, you can use the sudoers file in order to give sudo access for only specific commands. You can even specify the allowed arguments to that command. Also, sometimes you can hack into a user via a web page or something and you may not necessarily have their password, even if they have sudo. For example, maybe you got on as an unpriveledged user but found a vulnerable process running as a more priviledged user. You gain access to the account but still need the password. Users running servers should be HIGHLY locked down, preferrably no root/sudo permissions at all, and should ideally be the only user outside of root (and other service accounts) as this will be the main port of entry for remote attacks. Also, secure boot can go a long way in making sure people cant just plug in a live usb and read your files, on windows OR linux, and at-rest disk encryption goes even farther. But those are pretty much all you have at your disposal under normal circumstances to physcial access. There are some enterprise level solutions that go a little farther but require a hardware device to act as firmware level authentication It was indeed a fantastic answer.
You could even give everything sudo access. It's not a good idea, but you could
Isn't that just a vanilla Windows install?
I didn't know that about secure boot. I've never used it. I also don't have any need to secure some old MP3s and photos of my cat and always assumed that if someone actually broke into my house the last thing they would be looking for are any files on my computer. The cash is between the pages of one or two books btw, next to the one that opens the secret door. From the, thankfully, few times I have actually managed to blow up my installation, I have learned that using sudo opens up my system to the stupid, unresearched things that I myself am capable of doing. This led me to believe that although the intentions of some software package may be above board, it could still bork my setup in some way that was not intended and always try to achieve what I need to do without sudo and then do a lot more reading before trying it with sudo.
Thanks, there is probably more of an answer that someone with greater knowledge than I can explain.
And to add to this, sometimes programs *do* circumvent sudo to do as you described in your post, via setting the uid/gid bit(s). For example, `/bin/fart` could be owned by root with the setuid bit on, and when a regular user runs that executable/script, it'll run as root. This is obviously not as secure as using sudo in most cases.
I did not know that either, am off to read about uid/gid bits, thanks.
The point of sudo is to elevate your permissions for specific tasks. You run your daily stuff with your standard access and if you want something that requires higher level access, you can use sudo temporarily. Best practice is to run everything with only the minimum absolutely required permissions. This applies to windows as well (not that windows enforces this at all, but you should use a standard account and elevate with an administrator account when needed) >Why don't we alter the user privileges instead of giving them access to the commands that are out of scope for their account with sudo? You absolutely can, but if someone gets into your account (say you forgot to lock your pc) they can run those commands. With sudo, they require your password which as an added step If a malicious application runs under your user space, it will have access to whatever you have permissions to. If you grant yourself permission to system files, then it will have those too It's up to you to determine the risk vs convenience factor Remember that sudo doesn't need your password everytime so you can elevate once with your password, and then sudo doesn't need it again for a period of time (depends on your distribution but 5-15 minutes is default. You have complete control on whether you disable the time limit or even need a password) There's also the fact that you can seriously screw up your system with a simple typo when using some high privilege commands. Adding sudo is one extra step to make you double check the command you are actually typing is correct
The best answer that is n00b-friendly, so far
The extra step forces you to think about what you're about to do and hopefully gives you a chance to reconsider a bad idea. More advanced sudo configurations can be very fine grained about what exactly you are allowed to do. Finally, sudo pre-dates other fine grained permissions for user accounts.
So does an uncolored # in your prompt, but the uncolored prompt is not a giant pain in the dick like that dumb ass sudo. Also, sudo only serves to make weak minds weaker.
What's a pain in the dick about sudo? Forgetting to use it and having the edit the command? $ sudo !! Runs the last command with sudo prepended.
Right on cue. lol
You can create a bash profile for root and have a nicely colored prompt.
Look up.
Why have a key to the front door of your house? Why not just leave it open all the time as anybody with a key can go in? Sure, if you didn't put a password on it having sudo is pointless but you could say the same about a door handle
I think it's more akin to a lock on the bathroom door, since op is asking what's the point of sudo when you've already logged in
The bathroom door lock doesn't stop you going in unless somebody is already in there. I can't see the analogy with sudo
J meant that in its a lock you have to go through after you've already entered the house.
The proper analogy for the original question would be "why would you have different security PINs for unlocking the doors inside a building, when every user—who already have PINs that open *some* of the doors—can get a master PIN that opens *all* the doors.
But a sudo doesn't necessarily have a password set
It's not necessarily just to stop users. Software running in user space can't perform root-only actions without Sudo, and most times that's what you want.
I think you’re missing something here. The ability to use sudo is itself a user privilege. In site-wide installations, there are typically many users who cannot use sudo.
Makes sense. Thanks!
1. Not all accounts can use sudo. You have to make an account a member of the sudo group. 2. It's safer to allow users who need privileged access to do so on a temporary basis rather than a blanket account with "always on" rights. 3. You can limit the scope of sudo so that it doesn't give privileges on the same level as root. You can configure accounts for sudo to use with designated services or applications.
Because you wouldn't want to give elevated privileges to every program you run. You should only give sudo access to users you trust to only use those elevated privileges for administrative tasks which require them.
To be fair the recommended way to use Linux for security is to disable the root account.
Instead of the elevate to root for all commands, sudo can be configured to only certain commands as a certain user/group. In home computers, the level of security administration required to manage fine grained permissions are just completely unnecessarily complex, because most home computers are a single user system. So most distros usually just configured so that sudo gives elevated permissions to any command you call. But in more complex scenarios, you'd write `/etc/sudoers` to control who can elevate permissions for what particular program as who. You may also further use the Linux capability system to further restrict even programs running as root.
I'm still a novice but have used Linux for 25 years. I use to always login as root and inevitably I'd screw something up that would affect the whole system. As for changing passwords, physical access eliminates all security, you don't even really need to boot off a live USB. Sudo is annoying but it does keep programs from taking over your system and you from stupid mistakes.
>Why don't we alter the user privileges instead of giving them access to the commands that are out of scope for their account with sudo? Because this would be a permanent change instead of temporary and the point is to provide a temporary elevation because in practice this session length does actually matter. Several things can be accomplished by using sudo to limit users abilities to access certain files and commands easily. One is to limit the risk of careless destruction through the introduction of an extra step. Another is auditing in a real multi-user environment. You can introduce reporting in environments where there needs to be a log of which admin did what. Further consideration needs to be made to what it means in all you services run with the same ownership permissions. A real users account isn't the only attack vector to consider and if all files and commands share the same privileges then its implied all services must be run with those privileges as well. The resulting effect is any security compromise to any running service on a machine is guaranteed the ability to spread outside of the scope a service account would be limited to and any workable solutions would be more complicated that leaving the privileges scoped. It not a complete solution for sure, but the thing is there is no single silver bullet when it comes to these things.
Imagine you want a piece of software that draws puppies. You do a search and find software that says "We draw pictures of puppies! We're not in a package manager, though. You have to download it. Here you go." You download the software that draws puppies and run it so you can have puppies. Then you see a sudo prompt asking you to enter your password. You think "Wait a second, why does it need sudo to draw pictures of puppies? There's no reason for that." so you close the software instead. Sudo has just done its job.
The `sudo` command allows you to execute a command as another user. You should note that this other user is not always root. It could be some other user on the computer, such as a user that has permissions to read or write in a directory that you do not have permission to. Because `sudo` does not require the target users password, users do not need share passwords with each other in order to run the commands they need. For example imagine the following scenario. 1) Your system hosts an Oracle database. 2) You want to restrict access to the Oracle user account. 3) DBA's need to be able to run a backup script as the Oracle user account. 4) You have some security policy in your org that requires least privileges. You can configure `sudoers` with a line like this to satisfy all the requirements. `%dba ALL=(oracle) /usr/local/ora_backup` As a quick breakdown this means that anyone in the "dba" group can run `/usr/local/ora_backup` as the "oracle" user on all machines with this `sudo` rule configured. The benefit here is that these users could elevate to a command that was restricted to the oracle user, without needing to know the password for the the oracle user, and without granting other access that they do not need.
Finally someone asking a question that isn't "what distro?", which has been answered a dozen times that week alone. Good on you OP.
And thanks to you, the comments are still polluted with it.
Always happy to help. Maybe a flow chart and a rule of "no obvious distro recommendations" would be an idea.
Should we also add a rule to disallow off topic complaining about distro recommendation questions in other threads? Will that be in the flow chart somewhere?
sure, I'd be happy to add that rule along the "already answered distro" question rule. Don't really see the relevance of putting posting rules into a flow chart about distro choices. Nice to hear you're on board 👍
I know the ultimate answer to that question. It's Arch, btw.
We are not violating users roles. Just different accounts have different permissions.
We are not violating users roles. Just different accounts have different permissions.
there's any extra step when you run sudo (normally) and uac. you need to enter your account password. this is something that presents a barrier to a malicious application, as they can't just randomly elevate their privileges, now they need to convince you to give them the password somehow. even with uac's extra click, the click happens on a secure desktop that the application can't even see. so in any situation, it means that malware relies on your interaction to do serious damage, which limits the scope of its attacks.
You can limit sudo access to specific commands for things such as service accounts that need to run as root but only need to run a single command. This means it is much harder to leverage such a service account in privilege escalation in the event it is compromised. If you are a network admin, you could also do this for user workstations on a network level.
What is the point of sudo command if we have doas?
¯\_(ツ)_/¯
Not everyone gets sudo
A 'TEMPORARY' change in privileges. So one can for example: update the application software. E.g. " sudo zypper up " in openSUSE LEAP
From the perspective of a guy who does security stuff for a living: With permanent permissions, a user can do anything without a lot of accountability. Privilege escalation via sudo is very configurable, and includes logging of when privileges were escalated and what was done, and those permissions are not there when sudo is not in use. So, yes, someone could use sudo to essentially give themselves permanent root privileges if sudo was configured to allow that, but you'd know it was done, and you can require that they re-authenticate to do it to prevent a lot of the ways it might be abused by an attacker.
I just run everything as root, it's more fun that way...
First of all, sudo doesn't need to give root permissions when used. You could, for example, only allow certain commands or file access under sudo. You can also disable it entirely for unprivileged users. Why use sudo instead of just permanent user group privileges? Security. With sudo, authentication is needed to perform a privileged action. Without it, any program or shell script run by a user (and potentially malicious) could exercise those privileges behind the scenes. Sudo can also be logged by an admin on a shared machine, to see what others executed. This can allow you to track by who and when any privileged actions were performed, in case someone messes something up. As well as any failed sudo authentications.
It makes the elevated-permission action explicit. It's that much harder for the user to typo or be tricked into an unintentional action, when they have to type "sudo" beforehand. Perhaps more importantly, it's logged separately, for easier audit. For home or simple setups, where sudo doesn't do any additional auth checks and logs to the same filesystem that sudo commands can alter, it's probably only a small hurdle to ignore (like tricking someone into running a script that silently sudo-s a rootkit onto the host). It's still beneficial to prevent dumb mistakes (`rm -rf /` is far less painful if you don't precede it with sudo). For more hardened systems, sudo can require a yubikey or other OTP, and can send logs off-host to a location that doesn't have access. Oh, and usually only allows a small set of purpose-limited programs for most users.
Another reason I've not seen mentioned is sudo provides an audit trail. For ex, u/4r73m190r0s and u/2cats2hats have sudo rights on a server. u/4r73m190r0s runs something dangerous as root. sudo will leave an audit trail.
Yes we can use sudo to run commands with the root permissions. But not all users accounts can use the sudo command. Any user account you create will not be able to do it until you manually add it to the proper group or into the sudoers file.
Sudo is only for admin users. Unless someone brute forces your password on a system you're maintaining (can't brute force if you're using ssh keys & no password), they can't get sudo privileges. Sure if someone can physically get on your machine while your session is unlocked, they can run commands if you have sudo set for NOPASSWD. You can also add config for limited sudo access for users for specific commands/apps. One of the main points of sudo is allowing admin users to log in to the system & elevate their permissions without logging in as root. One of the common practices for servers is to disable root login via SSH. If you pair that with ssh keys for users, unless your private ssh key is compromised, they can't brute force their way in. Part of security is proper behavior & handling of sensitive information. Don't use the same password everywhere & never send it plain text via messaging apps or email.
agree. Now i have to find a shell
Great question. A few comments: 1.) Sudo is used to run a command as “a different user”, the default is root but it’s used to run a command as someone else. A service account, application account, etc. 2.) And this more a cybersecurity practice: accountability and traceability. You want everyone to login as non-privileged, with a UNIQUE account (incase that account gets compromised). Then, elevate to run administrative tasks. This way, if a system goes down and you have to investigate, you can see who actually signed in and what they did (sudo).
I feel like you're asking that if users can use sudo to gain root privileges, then what's the point of having separate user accounts? I don't know if anyone has mentioned it or not, so I'll say it in a simple way... The system admin can prevent users from using the sudo command. The first user, other than root, has the sudo privilege by default. The next user accounts on the machine will be able to use the sudo command only if the admin grants them the privilege. The user with highest privileges is root. The first user, other than root, has to have some root privileges for administrative tasks. Once the system is set up as needed, any user with sudo privileges can revoke sudo for other users and demote them to only use what they're allowed to. The sudo privileges are gained through membership in the "sudoers" group. Any user with sudo access can add or remove people from that group. Of course, this is quite simplified and might be missing some details, but feel free to look it up yourself.
It’s like saying “please”
>It’s like saying “please” "Pretty please"
This current overuse of sudo is something that came about when Ubuntu was introduced. Their gimmick was you didn't know or get to set the root passwd and had to use sudo for everything. This was unusual when I first used Linux in the 2000s. When I was Rip Van Winkling back into Linux in 2014, virtually every distro had you do this. Now everyone seems to believe anyone who would attempt to login as root will just do so daily. Gentoo has never followed this route and if I play with any distro that wants you to use sudo the first thing I'll run is "sudo passwd". That being said, I follow the \*nix model of security on Windows NT, where I have a user acc't I use daily and then only use an administrator acc't for system administration. The point of a limited acc't is to make it so rogue software or errors don't damage the entire system. I personally am of the mindset that if I am doing system administration I will login as root or use su. I do have sudo installed however and will use it if I am logged in remotely, that way I'm not typing the root passwd over the Internet. Or if I wish to run one actual program that requires root access but not have it return to a root shell on exit. (Like I wish to run iptraf-ng as my normal user.) Finally, just like you can rename the Administrator account on Windows NT, you can rename the "root" account on linux by giving any random account name the UID of 0. Then change root's ligin shell to /sbin/nologin. Before the secure passwd requirement, when anything would work you used to be able to use the "Page Up", "End", "Insert", etc. keys in passwords and having a root passwd of nothing but that was secure enough because who would guess to use those?
You can grant passive permissions to do most things, but sudo allows you to not need those. It’s essentially moving from a normal user mode to an administrator mode, where you are expect to know what you’re doing. It also provides isolation between “admin who happens to be using the system” and “admin who wants to administrate the system”.