Detailed Loging As Users sudo to Shared Account and continue to work
My users are using Red Hat Enterprise Linux 6. My goal is to differentate what users are performing sudo activity, after they su "to" a shared account. Below is the process my users peform:
Step 1 users loign with there unique user credentials Step 2 users then su to a shared account Step 3 As the shared account users peform sudo activity In step 1 and 2 I have an audit trail of which unique user logged in and which unique user preformed an su and to what account. In step 3 my audits only record that the shared account peformed sudo activity and it records what sudo activity, in /var/log/secure. The problem is I can not trace back step 3 to a unique user, and instead all the sudo activity is being recorded as being peformed as the shared account. This recording and type of recording is driven by the rsyslog.conf file (sylog.conf in Red Hat 5) and is performing what it is designed to do. I'm asking that the system record in further detail the unique user that is emulating the shared account. A good example of where this is being recored is the in audit.log (/var/log/audit/audit.log). In the audit.log it actually records activity generated by a unique user (auid - actual user id) along with the group id (guid), sudo id, etc. Essentally the audit.log records in the record the unique user along with who the user was emulating and what commands were executed or files accessed. Unfortuneately audit.log is not desinged to record general sudo activity, instead this is driven by /etc/rsyslog.conf and recorded in /var/log/secure. Does anyone now what addititonal lines I can add to the /etc/rsyslog.conf to have it list/record the unique user or UID associated with the sudo activity, not just what sudo activity the shared user account performed? A million thanks, Johnny Mac |
Can you track the PID or parent PID in those files?
If so, the parent of any command should be the shell that launched it, and the parent of that shell will be the original user's shell. For example: A user logs into the machine, they're given a shell with PID 13243 The user runs su to the shared account, they're given a shell with PID 13334, and parent PID 13243 The user runs something as sudo, it logs the PID of the process, as well as the PID of its parent (13334), which you can then cross-reference back to their original shell of 13243 and determine the original user |
Attempted to locate PID and Parent PID
After provoking the system I did locate the inital PID assigned to the user login (in /var/log/secure) but after logging into the shared account and provoking a sudo event, I could not find an associated Parent PID (PPID) to this event in /var/log/secure or /var/log/audit/audit.log. The /var/log/audit/audit.log does display PPID data if I isolate activity or file access in the /etc/audit/audit.rules however, my audit.rules is focused on failed activity (such as users trying to change the date/time on the system) or all access to security relivant files (such as users trying to delete audit.log).
Should I be looking at a different log in order to find the PPID when general users who perform a succesful suod action? A million thanks in advance, Johnnn Mac |
I'd force users to do everything through 'rootsh' (doesn't necessarily have to be root-privileged tasks) as together with the audit service, combined with remote syslog, you may not have a concise but a (nearly) complete audit trail.
|
Quote:
There is a test machine with CaclMgr available for public to test, available at 54.186.62.42, can use ssh to login to account "roger" with password "roger098". |
Quote:
Are you incidentally the vendor, creator or reseller of said software? Quote:
|
I opened a few pages related to the software and they are all broken. I'd ignore that software(caclmgr), since they can't even keep their web pages up.
|
We have used CaclMgr for many years
We needed a secure privilege delegation software.
In the past, we evaluated sudo, but at that time, we found sudo had provided too many options, that's bad thing for maintain security for user to use the software and also more complicated software could have more bugs. We also monitored the bug fixes of the software, found a lot of the bugs fixed were related with security, so this software has a bad reputation for security. We found the CaclMgr software many years ago, and tested it and compared with sudo, found it provided a lot of help to maintain privilege delegation security, just an example, when we need to grant DBA privilege to a user to run a script, we just need to use a dba account to do so, and if by mistake the script permission was not set up properly, the target user can modify it, the CaclMgr can detect it. The current version we use even can provide pretty good protection for password: with sudo, when the software prompts user to enter password, the password can be stolen by malicious person if that person can run strace to attach to the process, or by reading the tty that user uses. CaclMgr can detect those attacks. Even the logs generated CaclMgr will be more trustworthy than the logs generated by sudo by default. I have used linux since slackware 1.0. Some people believe open source will make sofwtare more secure, but from the sudo problem, the OpenSSH Ebury problem, and now the openssl heartbleed problem, they just tell the opposite stories: those are very popular software, have many vendors include those software in their distributions, should have many security people checked the codes. So, my conclusion is whether a software will be more secure or not is not very related with whether it's open source or not, it's more related with who are the developers. |
Probably you looked at the old site?
Quote:
|
Quote:
|
I'm a UNIX/Linux technical person, interested in security related stuff
Quote:
|
No you don't. I'd say you're just here to advertise your closed source, commercially licensed software and dodging any questions about it.
Please do not do that anymore on LQ unless you have reached prior agreement with Jeremy, LQ's owner, allowing you to advertise your socalled "software". |
Are you saying if a problem's solution involves commercial software
Quote:
|
Quote:
Do note that actually getting permission to promote your software does not detract from the fact that your software is closed source (and therefore a liability as it is not open to public scrutiny), that you categorically dodge any requests for clarification and that you are using highly questionable tactics to promote it (scaremongering, shill). Do you understand what I am saying? |
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Then offer the patches to make it more secure. That is how open source improves. |
All times are GMT -5. The time now is 12:51 PM. |