- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Audit Sudo privilege
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-02-2010 02:01 AM
тАО06-02-2010 02:01 AM
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?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-02-2010 02:45 AM
тАО06-02-2010 02:45 AM
Re: Audit Sudo privilege
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.
Horia.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-02-2010 02:48 AM
тАО06-02-2010 02:48 AM
Re: Audit Sudo privilege
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-02-2010 03:00 AM
тАО06-02-2010 03:00 AM
Re: Audit Sudo privilege
"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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-02-2010 03:20 AM
тАО06-02-2010 03:20 AM
Re: Audit Sudo privilege
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-02-2010 04:30 AM
тАО06-02-2010 04:30 AM
Re: Audit Sudo privilege
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.
Bill Hassell, sysadmin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-02-2010 05:34 AM
тАО06-02-2010 05:34 AM
Re: Audit Sudo privilege
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-02-2010 06:35 AM
тАО06-02-2010 06:35 AM
SolutionTo 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-02-2010 07:18 AM
тАО06-02-2010 07:18 AM
Re: Audit Sudo privilege
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-02-2010 11:57 PM
тАО06-02-2010 11:57 PM