Limiting Linux Service Account Access

We are utilizing a perl script for process monitoring that we obtained from the content exchange here on thwack. We utilize a special service account for APM to use when it logs into the linux servers. It is the same service account used for monitoring windows servers as well. We have the service account "locked down" on the windows machines, but have yet been able to find out how to do it on the linux machines.

The script utilizes the command ps -ef for process checks. We would like the service account to only be able to run the script and be contained to it's home directory. Since this service account is shared among several server admin groups, we would like to lock it down on the linux side.

I would like to know if anyone is trying to secure the way they are monitoring their linux processes. If so, how were you able to do so? I was thinking about trying restricted shell, but heard it might not work with the ps -ef command. I was also thinking about writing a custom shell, but thought I would post the question here.

Thanks in advance.

Find more posts tagged with

Linux

shell

apm

script

Accepted answers

jodros

I now have the service account limited and APM is still able to monitor services. In order to accomplish this, I changed the shell for the service account to rbash. I then created a directory under the /home/serviceaccount/ called programs and edited the .bash_profile to reflect this directory. Soft links were created for each command needed to run. After some trial and error, the following soft links were needed, /usr/bin/perl, /bin/ps, /bin/grep. The script was also copied to the /home/serviceaccount/programs directory. I then changed APM linux script monitor command line to perl programs/nameofperlscript.pl nameofprocesstocheck and the script body to "null." The body is not called if the ${SCRIPT} macro is not used in the command line.

After making these changes, APM is able to monitor for the service running and the service account is locked to its home directory with limited commands.

Thanks for all of the assistance.

All comments

aLTeReGo

If you want a normal user to call ps as root you have to look at the set-uid permission. From the setuid article on Wikipedia:

setuid and setgid (short for "set user ID upon execution" and "set group ID upon execution", respectively)1 are Unix access rights flags that allow users to run an executable with the permissions of the executable's owner or group. They are often used to allow users on a computer system to run programs with temporarily elevated privileges in order to perform a specific task. While the assumed user id or group id privileges provided are not always elevated, at a minimum they are specific.

See also the man page of chmod

sudo

If instead you want a normal user to execute something executable by root only use sudo. It will allow you to configure which user will be able to execute what.

jodros

Thanks for replying aLTeReGo. Actually wanted to go the route of utilizing rbash as the shell assigned to the service account. I created a directory under the service account home called commands. I then created softlinks from /bin/ps to /home/serviceaccount/commands. This works great.

However, when I try to run a test from APM, it is telling me that it is unable to run a cd to get out of it's home directory. I can't tell if this is the script or APM in general that is trying to cd, but that is now the issue I am trying to resolve.

Do you know what permissions are necessary for APM to do script monitoring?

The script I am using is:

jodros

I just tried changing the shell back to bash, but leaving the /.bash_profile pointing to the home/serviceaccount/commands directory. I then tried testing the APM script again and it is showing a new error indicating APM trying to create the script locally with cat.

I think the best thing to do at this point would be to list exactly what APM does when it runs a script to monitor a process. It might be easier too if I load the script locally on the linux server and then just call that script on APM.

bobross

If you have the ${Script} in the command line, Solarwinds will SSH to the box, transfer the script to the listed Working directory, then execute it from there. More specific then that will have to come from one of the staffers.

We've had to go the route of loading the file on the server locally once or twice. If you have to deploy this on dozens of *nix server this could get a bit tedious though. Just be sure to change the command line from ${Script} to the full path to the file.

aLTeReGo

bobross is correct. Permissions required by APM are dependent upon the script itself. You can always copy the script to the server locally and execute it there to determine if you're encountering a permissions related issue.

jodros

After making these changes, APM is able to monitor for the service running and the service account is locked to its home directory with limited commands.

Thanks for all of the assistance.