I.e. how malware could easily catch your Sudo password without root access.
Peeps, bad news, Linux is damn insecure.
By simply placing an alias in your bashrc they could already grab your sudo password.
Another bad news, this Windows “okay” Button without any password is actually more secure.
In other words: a compromised system at the User level can easily compromised at the admin level if there are no additional checks/measures in place.
Same for Windows. Just change the link to a Programm you commonly need the press OK to to you maleware. Profit.
The proper way to handle issues like these is process level permissions (i.e. capability systems), instead of user level. Linux CGroups, namespaces, etc. are already moving that way, and in effect that’s the way windows is trying to head too. (Windows has its own form of containerization called AppContainers, which UWP apps use. Windows also has its own capability system).
Either you’re trolling - in which case, sod off back to Reddit - or you have a woeful misunderstanding of how Linux user permissions work.
Please explain how someone might “simply change” someone else’s .bashrc without either already having access to that user account, or root access on the whole machine?
The idea is malware you installed would presumably run under your user account and have access. You could explicitly give it different UIDs or even containerize it to counteract that, but by default a process can access everything it’s UID can, which isn’t great. And even still to this day that’s how users execute a lot of processes.
If you containerize, the application (malware) will run under the user configured in the image, unless you override it, and in a separate mount namespace, unless you change that, which makes the “alias sudo” trick extremely unlikely.
Even running under a separate user anyway prevents almost fully the attack you mention, unless the separate user has root privileges or the DAC_OVERRIDE capability is assigned to the binary (assigning it requires CAP_SYS_ADMIN).
In short, the attack you mention is a common persistence and privilege escalation vector, which is relatively easy to detect (watch for changes to shell profiles), although preventing it requires some care.
I just want to point out that in single-user machines (e.g. personal computers) escalating to root is anyway fairly unnecessary, given that all the juicy stuff (ssh keys, data, etc.) is anyway probably running under/owned by that user.
Yep! You can also get pretty far even without containers. At the end of the day containers are just sandboxing using namespaces, and systemd can expose that pretty trivially for services, and tools like bubble wrap / flatpak let you do it for desktop apps. In an ideal world every package would only use the namespaces it needs, and stuff like this would largely not be a concern.
Regarding Windows all I read is that this “admin permission dialog” is launched in some form of sandbox where no software can access it. Not sure about faking input devices though, and I am also not promoting Windows for Security
True, but that doesn’t necessarily matter if I can compromise the privileged app instead. I could replace it, modify it on disk, or really any number of things in order to get myself a hook into a privileged position.
Just injecting code in some function call which launches malware.exe would do the trick. Ofc signature checks and the like can help here - but those aren’t a given. There’s any number of ways you can elevate yourself on a system based off of user security if your threat model is malicious processes. Linux (and windows) will stop users from accessing each other’s crap by default, but not processes.
Or: supply chain attacks. Now your official app without any modifications is malicious.
It’s not about someone, it’s about something. A lot of us aren’t (only) using Linux as a server OS, but for desktop too, and desktop usage involves running much more different kinds of software that you simply just can’t afford to audit, and at times there are programs that you can’t choose to not use, because it’s not on you but on someone on whom you depend.
Then it’s not even only that. It’s not only random shit or a game you got that can edit your bashrc and such, but if let’s say there’s a critical vulnerability in a complex software you use, like a web browser, an attacker could make use of that to take over your account with the use of a bashrc alias.
Nearly all tools (with flatpak and portals progressing into better directions but probably never finished) have rw permissions everwhere.
The modern OS threat model is not other users, as private users mostly have single user systems. It is malware and software doing nasty things.
On Linux this always worked out somehow, but grabbing your sudo password is not hard, just alias sudo to a script reading your argument, reading your password, and piping the password to the real sudo. You dont even notice it but that script just got your sudo password.
I.e. how malware could easily catch your Sudo password without root access.
Peeps, bad news, Linux is damn insecure.
By simply placing an alias in your bashrc they could already grab your sudo password.
Another bad news, this Windows “okay” Button without any password is actually more secure.
In other words: a compromised system at the User level can easily compromised at the admin level if there are no additional checks/measures in place. Same for Windows. Just change the link to a Programm you commonly need the press OK to to you maleware. Profit.
The proper way to handle issues like these is process level permissions (i.e. capability systems), instead of user level. Linux CGroups, namespaces, etc. are already moving that way, and in effect that’s the way windows is trying to head too. (Windows has its own form of containerization called AppContainers, which UWP apps use. Windows also has its own capability system).
Either you’re trolling - in which case, sod off back to Reddit - or you have a woeful misunderstanding of how Linux user permissions work.
Please explain how someone might “simply change” someone else’s .bashrc without either already having access to that user account, or root access on the whole machine?
The idea is malware you installed would presumably run under your user account and have access. You could explicitly give it different UIDs or even containerize it to counteract that, but by default a process can access everything it’s UID can, which isn’t great. And even still to this day that’s how users execute a lot of processes.
Windows isn’t much better here, though.
If you containerize, the application (malware) will run under the user configured in the image, unless you override it, and in a separate mount namespace, unless you change that, which makes the “alias sudo” trick extremely unlikely.
Even running under a separate user anyway prevents almost fully the attack you mention, unless the separate user has root privileges or the DAC_OVERRIDE capability is assigned to the binary (assigning it requires CAP_SYS_ADMIN).
In short, the attack you mention is a common persistence and privilege escalation vector, which is relatively easy to detect (watch for changes to shell profiles), although preventing it requires some care. I just want to point out that in single-user machines (e.g. personal computers) escalating to root is anyway fairly unnecessary, given that all the juicy stuff (ssh keys, data, etc.) is anyway probably running under/owned by that user.
Yep! You can also get pretty far even without containers. At the end of the day containers are just sandboxing using namespaces, and
systemdcan expose that pretty trivially for services, and tools like bubble wrap / flatpak let you do it for desktop apps. In an ideal world every package would only use the namespaces it needs, and stuff like this would largely not be a concern.Regarding Windows all I read is that this “admin permission dialog” is launched in some form of sandbox where no software can access it. Not sure about faking input devices though, and I am also not promoting Windows for Security
True, but that doesn’t necessarily matter if I can compromise the privileged app instead. I could replace it, modify it on disk, or really any number of things in order to get myself a hook into a privileged position.
Just injecting code in some function call which launches
malware.exewould do the trick. Ofc signature checks and the like can help here - but those aren’t a given. There’s any number of ways you can elevate yourself on a system based off of user security if your threat model is malicious processes. Linux (and windows) will stop users from accessing each other’s crap by default, but not processes.Or: supply chain attacks. Now your official app without any modifications is malicious.
It’s not about someone, it’s about something. A lot of us aren’t (only) using Linux as a server OS, but for desktop too, and desktop usage involves running much more different kinds of software that you simply just can’t afford to audit, and at times there are programs that you can’t choose to not use, because it’s not on you but on someone on whom you depend.
Then it’s not even only that. It’s not only random shit or a game you got that can edit your bashrc and such, but if let’s say there’s a critical vulnerability in a complex software you use, like a web browser, an attacker could make use of that to take over your account with the use of a bashrc alias.
Nearly all tools (with flatpak and portals progressing into better directions but probably never finished) have rw permissions everwhere.
The modern OS threat model is not other users, as private users mostly have single user systems. It is malware and software doing nasty things.
On Linux this always worked out somehow, but grabbing your sudo password is not hard, just alias
sudoto a script reading your argument, reading your password, and piping the password to the real sudo. You dont even notice it but that script just got your sudo password.Dont know what Reddit has to do with that