How did the attacker gain your user’s privileges? Malware-infected user installation? A vulnerability in genuine software running as your user? In most scenarios these things only become worse when running as root instead.
The scenario OC stated is that if the attacker has access to the user on the server then the attacker would still need the sudo password in order to get root privileges, contrary to direct root login where the attack has direct access to root privileges.
So, now i am looking into this scenario where the attack is on the server with the user privileges: the attacker now modifies for example the bashrc to alias sudo to extract the password once the user runs sudo.
So the sudo password does not have any meaningful protection, other then maybe adding a time variable which is when the user accesses the server and runs sudo
Then you can’t gain root privileges on your server. Are you really arguing for less security because it’s inconvenient?
This is end-user behavior and it’s honestly embarrassing. You should realize your security posture is much more important than “I left my phone on the other room”
ffs…am I dealing with children here?
You’ve accessed your server as a user, and then you su - to root.
You don’t need a phone or a yubi or a dreamcatcher, or a unicorn.
Please stop with your pretension.
You’re so far out of your league that it’s embarrassing to me that I’ve bothered to answer.
And what do you suggest to use otherwise to maintain a server? I am not aware of a solution that would help here? As an attacker you could easily alias any command or even start a modified shell that logs ever keystroke and simulates the default bash/zsh or whatever.
And who is going to edit your .bashrc?
The attacker that is currently with user privileges on the server?
How did the attacker gain your user’s privileges? Malware-infected user installation? A vulnerability in genuine software running as your user? In most scenarios these things only become worse when running as root instead.
The scenario OC stated is that if the attacker has access to the user on the server then the attacker would still need the sudo password in order to get root privileges, contrary to direct root login where the attack has direct access to root privileges.
So, now i am looking into this scenario where the attack is on the server with the user privileges: the attacker now modifies for example the bashrc to alias sudo to extract the password once the user runs sudo.
So the sudo password does not have any meaningful protection, other then maybe adding a time variable which is when the user accesses the server and runs sudo
Simple solution is to not use sudo.
Sorta like Slackware’s default.
Nah just set up PAM to use TOTP or a third party MFA service to send a push to your phone for sudo privs.
…and if you don’t have your phone attached to your hand…?
Then you can’t gain root privileges on your server. Are you really arguing for less security because it’s inconvenient?
This is end-user behavior and it’s honestly embarrassing. You should realize your security posture is much more important than “I left my phone on the other room”
This thread is embarrassing,
The person you’re responding to could wipe your ass with a cli.
ffs…am I dealing with children here?
You’ve accessed your server as a user, and then you su - to root.
You don’t need a phone or a yubi or a dreamcatcher, or a unicorn.
Please stop with your pretension.
You’re so far out of your league that it’s embarrassing to me that I’ve bothered to answer.
I…I don’t understand the question.
Also, yubikey or any other token. Plenty of MFA options compatible with sudo.
And what do you suggest to use otherwise to maintain a server? I am not aware of a solution that would help here? As an attacker you could easily alias any command or even start a modified shell that logs ever keystroke and simulates the default bash/zsh or whatever.
$ su -
And how would you not be able to hijack the password when you have control over the user session?
You would have to know the root password.
Oh that’s dastardly
that’s why root owns my .bash* stuff
I don’t think that actually works; the attacker could just remove .bashrc and create a new file with the same name.
If the .bashrc is immutable, the attacker can’t remove it.
That’s how it works.
The home directory would need to be immutable, not bashrc.
?
It’s .bashrc, not bashrc, and .bashrc is in the home directory.
If .bashrc is immutable, it can’t be removed from home.
It’s the directory that needs to be writable to delete files, not the file itself.
Although the immutable bit (if that’s what you’re talking about - I thought you meant unsetting the write bit) might change that, I’m not sure.
you’re right. that’s something i wanted to look into. guess setfacl would do the trick?
“chattr +i” is what I use to make things immutable
thanks
deleted by creator