Dumb Linux/Sudo question from a confused Win admin.

langenoir

I just received a mass email from a coworker and I’m a bit confused by it. Now since I’m not really the guy that works day in day out inside the Linux VMs I’m almost 99% sure I haven’t done this, but I still would like to know what it means. I mostly work on the VMWare vSphere, Windows, Storage, and DR side of things.

The message says

“most of admins are violating policy by copying the bash executable into their home folders, naming it something else, and running that via sudo.”

First issue, I thought whenever I was in the command line I was in a shell of some sort, be it bash, korn, C shell, etc?

Second, I thought it was proper to use sudo as opposed to su- as root has too many privileges.


Third, if I write a script with

#!/bin/bash

and run it from my home folder am I doing something wrong? Is what they’re saying something like, you should be able to run scripts from your home folder without using sudo to elevate?

UnixGuy

I don't really understand what "policy violation" is your user talking about. Maybe ask for clarification on what the policy exactly is?

using sudo is basically running the script with elevated privilege. If your user is configured to be a sudo user then basically you have the authority to use it. I'm not clearly sure what policy is being violated.

Yes, when you login to a linux box you are essentially running it via a shell. Think of the shell as the command line equivalent of your GUI (explorer.exe)

Whether it's bash or korn or anything else...no freakin difference, unless your company has some kind of 'policy' that prevents the usage of certain shells (and I'd question why..)


Nothing's wrong with running the script from your home folder...again unless the script executes things on a local folder? Not sure why it's a problem to be honest. Ask for clarification from that user. That user seem hostile

langenoir

Thank you for the response UnixGuy.

He probably is being hostile, he feels like some grave error has been made. But the thing is this company has a lot of policies and it seems like you never know when you're breaking one until you have already done so and someone is pointing it out. Asking for more info on the policy was one of the first things I plan on doing this morning.

I will say this, I do remember one of the Linux guys telling me he had a trick around when sudo didn't work, but I was under the impression this was being used in lieu of not having to wait for this guys slow team to fixing it, as opposed to us not being able to use it. I know I do have sudo on some boxes and the ones I did not were because it had not been configured yet and should have been.

UnixGuy

I don't envy you, you're dealing with an idiot (to put it mildly).

From the email I could tell that this person is difficult to deal with.

Not sure what's wrong with having different file names in a directory...

Also, it seems that he doesn't really know to configure proper auditing/logging on his systems and he is blaming it on you guys.



Best is to keep quiet with this kind of person, there is no winning.


I can't for the life of me figure out what he means by running a shell using sudo?

say someone run's a command "sudo ls -l"...ok that's a command that's run on a shell...maybe he 'audits' this shell...and when you run an entire script "sudo ./script.sh" (for example) then that script is run on a different shell...why is that a problem? because he doesn't know how to audit that?


Why does he have to show his CIO the logs of a script run?

Where I work..every login is logged, and every command run by every user is logged...whether the user is root/sudo.///bla bla...we actually log the user's employee number.....This is how auditing and security is configured...rather than asking users to run the scripts in certain ways or name the files in certain ways lol.


I'd try to ignore this guy if I were you...

Verities

UnixGuy wrote: »

I don't envy you, you're dealing with an idiot (to put it mildly).

From the email I could tell that this person is difficult to deal with.

Not sure what's wrong with having different file names in a directory...

Also, it seems that he doesn't really know to configure proper auditing/logging on his systems and he is blaming it on you guys.



Best is to keep quiet with this kind of person, there is no winning.


I can't for the life of me figure out what he means by running a shell using sudo?

say someone run's a command "sudo ls -l"...ok that's a command that's run on a shell...maybe he 'audits' this shell...and when you run an entire script "sudo ./script.sh" (for example) then that script is run on a different shell...why is that a problem? because he doesn't know how to audit that?


Why does he have to show his CIO the logs of a script run?

Where I work..every login is logged, and every command run by every user is logged...whether the user is root/sudo.///bla bla...we actually log the user's employee number.....This is how auditing and security is configured...rather than asking users to run the scripts in certain ways or name the files in certain ways lol.


I'd try to ignore this guy if I were you...

I got midway through that second post and realized the same thing about the "linux" admin. Agreed with UnixGuy, just ignore the idiot and carry on.

langenoir

Ok I’ve figured it out. I talked to one of the other Linux guys that I feel somewhat ok with talking to about this, only because of some of the things you already said UnixGuy.

Basically people are coping the bash binary and putting it in their home directory. Then they rename it. Then they sudo the new file which I guess opens a new Bash shell, so that they don’t have to run sudo for every command because they’re tired of doing that. They don’t want to have to elevate every command because they think it’s cumbersome. They call it a "root backdoor." The guy I talked to said that doing this keeps them from tracking every single elevated command for auditing later. I don't think the guys are doing it nefariously.

UnixGuy wrote: »

> Why does he have to show his CIO the logs of a script run?

Because I work for a big company and they have ridiculous auditing procedures. Supposedly if we fail these audits clients cancel their contracts. This company is probably overly concerned with security. I’m probably not even supposed to share this email, which I’m about to take down the text, but I guess if I felt comfortable talking about it with the guy who wrote it, we probably wouldn’t have had the issue in the first place.

I can see why he’s upset, but I’m sure there’s other ways of doing this. I can tell by the way the set up the vSphere, that they’re not as competent as they think they are. Our cloud provider has a whitepaper, detailing exactly how to set up the vSphere, and they still didn’t get it right… Mostly right, but some of the things they missed were kind of a big deal. If it doesn’t involve the vSphere in some way, I generally try to keep my mouth shut. But I thanked him for letting me know and said even though I know I haven’t done this, I’ll keep it in mind for the future.

Thanks UnixGuy.

Verities

langenoir wrote: »

Ok I’ve figured it out. I talked to one of the other Linux guys that I feel somewhat ok with talking to about this, only because of some of the things you already said UnixGuy.

Basically people are coping the bash binary and putting it in their home directory. Then they rename it. Then they sudo the new file which I guess opens a new Bash shell, so that they don’t have to run sudo for every command because they’re tired of doing that. They don’t want to have to elevate every command because they think it’s cumbersome. They call it a "root backdoor." The guy I talked to said that doing this keeps them from tracking every single elevated command for auditing later. I don't think the guys are doing it nefariously.


Because I work for a big company and they have ridiculous auditing procedures. Supposedly if we fail these audits clients cancel their contracts. This company is probably overly concerned with security. I’m probably not even supposed to share this email, which I’m about to take down the text, but I guess if I felt comfortable talking about it with the guy who wrote it, we probably wouldn’t have had the issue in the first place.

I can see why he’s upset, but I’m sure there’s other ways of doing this. I can tell by the way the set up the vSphere, that they’re not as competent as they think they are. Our cloud provider has a whitepaper, detailing exactly how to set up the vSphere, and they still didn’t get it right… Mostly right, but some of the things they missed were kind of a big deal. If it doesn’t involve the vSphere in some way, I generally try to keep my mouth shut. But I thanked him for letting me know and said even though I know I haven’t done this, I’ll keep it in mind for the future.

Thanks UnixGuy.

That makes more sense and sounds like some write ups may be in order. I wonder if putting an ACL, excluding write permissions for the users, on the directory they're pulling the binary from would prevent them from being able to put it into their home directory and renaming it. The only other idea I would have is if you guys are using HIPS, blocking execution of scripts from the home directory.

UnixGuy

Good call!

chopsticks

Learn something new! Thanks!

W Stewart

Have they never heard of sudo su? That switches your user to the root user so you can run commands as root without having to type your password over and over again. I believe sudo -i will do the same thing as well. These guys need to read some man pages.

ChooseLife

W Stewart wrote: »

Have they never heard of sudo su? That switches your user to the root user so you can run commands as root without having to type your password over and over again. I believe sudo -i will do the same thing as well. These guys need to read some man pages.

Nope. This is done on purpose. Switching to the root user as opposed to elevating individual commands with sudo makes auditing impossible.

DoubleNNs

Doesn't using "sudo su," "sudo -i," or "sudo -s" still allow you to audit in the future?

apr911

DoubleNNs wrote: »

Doesn't using "sudo su," "sudo -i," or "sudo -s" still allow you to audit in the future?

sudo -i and sudo -s have the same "problem" as sudo as the elevated session will eventually timeout, requiring you to re-enter your sudo password. Depending on the security policy this can require credentials for every command, after a period of inactivity or after a period of time regardless of activity


Sudo su - puts you into the root user which would allow you to audit the root user but not who was running as the root user. This is particularly problematic in large environments with lots of users all of whom have sudo access as they can all escalate to root and then, while you would be able to audit what was done as root, you would not have the ability to audit which user ran what commands as root.

For example, Bob and John both login to the same server. Using sudo, John and Bob both run commands and at the end, John reboots the server. Because Sudo was used throughout the session, every command that utilized sudo was logged in the audit log basically stating "User used sudo to run command" so an audit log might look something like:

John used sudo to run "service network restart"
Bob used sudo to run "traceroute google.com"
John used sudo to run "shutdown -r now"

With sudo su, the logs would look like this:

John used sudo to run "su -"
Bob used sudo to run "su -"
root ran command "service network restart"
root ran command "traceroute google.com"
root ran command "shutdown -r now"

*NOTE:This is not an accurate portrayal of what would be seen in a linux audit log, it is a simplified representation of the information that may be available.


As you can see, you lose identity for who ran what command in the elevated prompt. In this case, sudo su should be disabled but it sounds like the company has already taken that step and so someone realized that running sudo /bin/bash would have a similar result. This is naturally not a function that should be allowed so it is also denied but running cp /bin/bash ~/mybash and then running sudo ./mybash would get around the vast majority of the settings intended to prevent privilege escalation in this manner.


Additionally, one of my first inclinations when reading the email was the idea that users were being placed in a shell other than bash. There could be a number of reasons for doing this, including a company policy that says not to run bash (most distros wont run without bash) so user execute access to /bin/bash is restricted but truthfully the first that comes to my mind is running a restricted-shell that only allows certain actions/commands. By copying /bin/bash to ~/mybash and running it there, you get around the policies restricting execute access on bash or any other restriction of the restricted-shell or other shell you are in.

W Stewart

I see. These guys are just using a clever backdoor.