Audit Sudo privilege

[unix fan]

In our organization, couple of HP-Unix servers is accessed by OS administrator and application administrator. Application administrator needs Sudo privilege for their Application specific user to maintain their application.

Please help me to find out the log/option where the activities can be tracked while they are performing with his SUDO privilege. Or in other word can the activity be separately trackable while administrator is enjoying root privilege through SUDO?

[Horia Chirculescu]

Hello,

There is no easy way to do that. You must create a script that will do the job. The problem is that this can be affected by the user that is having root privilege.

You (as the the system admin) could restrict the commands permitted to be run with root privileged. Check those commands to not start sub-shells that can be escaped.

Best regards,
Horia.

[Suraj K Sankari]

Hi,
you can install third party tools for tracking....
In my previous org. we have powerbroker tools its very strong tool.
see the below thread to more information...
http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1275475518059+28353475&threadId=956140

Suraj

[Matti_Kurkela]

1.)
"sudo privilege" does not have to be the same thing as "root privilege". If the application is run as a particular non-root userid, sudo can be configured to allow access to that userid *only*.

This sudoers definition would allow user "appadm" to run any commands as user "appuser", but nothing as root.

appadm apphost=(appuser) ALL

If you want to allow a certain group of users to access the appuser account through sudo, that is simple too:

%appadmgrp apphost=(appuser) ALL


The correct usage for sudo would then be:

sudo -u appuser
or
sudo -u appuser -i

With this sudoers configuration, commands like "sudo su - appuser" would NOT be possible.

(The latter command will open a shell session as appuser for the user entering the command. You might not want your users do this: see below.)

2.)
If the application administrator is allowed to run a shell on a different userid through sudo, then sudo can only document that the application admin started a shell running as that user. What he/she did with that shell will remain outside the logs.

To get a full record of activities on a different userid, you must either limit the list of commands allowed through sudo to absolute minimum (disallowing any commands which include a "escape to shell" or "run a shell command" feature), or use a session recorder like sudosh together with sudo:

http://sourceforge.net/projects/sudosh/

3.)
Because basic shell-internal commands like "cd" and input/output redirections are tricky or impossible to use when running individual commands through sudo, minimizing the list of allowed commands will be a very difficult job unless you use group access permissions to allow the application admins to access the application files using their regular, personal user accounts.

But if you need full record of all inputs & outputs done on the application userid, then something like sudosh is the way to go.

There are also commercial solutions like PowerBroker from a company called BeyondTrust. I haven't used it, but others have mentioned it often in situations where total auditability is a requirement.

http://www.beyondtrust.com/PowerBroker.aspx?section=PowerBroker

MK

[unix fan]

Hi All,
To be very precisely my requirement:

Would like to audit the list of activity application administrator performs when application administrator issues the command "sudo su" and submit the list command to our auditor.
But the list should not contain any activity which performs by user: root during that time.

Will PowerBroker or sudosh sufficie for this purpose?
Regards,
Chandan Laskar

[Bill Hassell]

>> application administrator issues the command "sudo su" and submit the list command to our auditor.

sudo su is a very bad idea. Similarly, sudo sh or sudo ksh should NEVER be allowed for application administrators. Once the admin issues the su or starts a shell, you have potentially lost the ability to reliably log anything the user decides to run. If your system has been setup properly, there will be a .sh_history in root's HOME directory but there is nothing preventing the sudo user from erasing this file. And there is nothing to separate normal root user commands from sudo su commands.

sudo is not just a tool to find out what damage a user has caused, it can prevent damage -- which is better than repairing things. In the sudoers file, the application admin is only allowed to run a few commands and must run them like this:

sudo application-command [ and options ... ]

The user may complain that they don't like typing sudo for every command, but the alternative is the admin must ask the HP-UX administrator to type the commands. After all, if the system is broken or destroyed by this user, the HP-UX administrator will usually be held accountable.

[unix fan]

So do you mean to say, No tool will help me in this case?

[Matti_Kurkela · Accepted solution]

Yes. If you allow the application administrator to run a shell as root, you've already given him/her the master key for your system: anything you can do, he/she can undo. He/she can disable any auditing features you configure, and edit all local log files to remove anything he/she does not want you to see.

To fix the problem, you must re-design your application configuration so that root access will not be needed to administer it.


- Create a separate non-root user ID for the purpose of running the application (hereafter called "appuser")


- Set file permissions so that the application can write to all the files it needs, and nowhere else. (Yes, you will have to examine the application and/or its documentation.)

This is usually easiest to do by first creating an empty directory (or a separate filesystem, if you want), chown'ing it to the appuser, then using the appuser account to install the application. If the application's installer can run as non-root, it will usually set the permissions correctly automatically.

If the application must be installed using swinstall, you must go through the application directory hierarchy and chown/chgrp/chmod the appropriate files and directories as required.

If the application has its own installer and it explicitly requires root access, try very hard to find out why. If it's just for e.g. adding some lines to /etc/services, just document it. If the application installer sets up "setuid root" permissions on an executable, you should examine that executable *very* thoroughly. What does it do, and why does the application need it? Is it necessary for the purpose you're using the application for? Can you disable it?


- Use sudo to allow the application administrator(s) to access to the appuser account only, **NOT** the root account. If your auditing requirements demand it, implement PowerBroker or sudosh, and make them save their data to some directory that is not writeable by the application admin(s) nor the appuser account.

This will guarantee that the application admins *cannot* remove or alter the audit logs.


- If the application absolutely requires access to privileged network ports (TCP/UDP 0-1023), the application usually has a built-in feature for switching to another userID after opening the port.

Use this feature, design a script for starting the application (as simple as possible!) and make the script writable by root only. Then configure sudo to allow the application admin(s) to run *only* this non-editable script as root.

Example sudoers file setting:
%appadmingrp apphost=(root) /usr/local/bin/startapp.sh

MK

[unix fan]

Thanks Kurkela

[dirk dierickx]

my point of view is also that allowing 'sudo si' defeats the purpose of sudo. if you would not allow this, you could basicly use the syslog/sudolog as your audit report.