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

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.

To solve this problem, you should use the commercial CaclMgr software, that's a more secure solution and you can achieve the desired result by creating a special group, and put those accounts in that group, and then use CaclMgr to grant that group to have root or dba and app admin privilege to run certain commands, scripts.
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".

Why should one favor closed source, commercially licensed software?
Are you incidentally the vendor, creator or reseller of said software?


"More secure" than what? Please explain objectively, in detail and without hyping a certain product?

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 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.

1 members found this post helpful.

the wzce site is over 10 years old, out-dated.

Now obviously I have a slight advantage over regular forum users but calculate the odds of you dodging my questions but still having a favorable reply posted to my question within 24 hours? That's called using a shill, Roger Gong, and it makes your efforts all the more suspect.

For security technical issue, I try to understand it and try to find solution, and if people face the same issue, I would tell them what I already know.

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".

It's not allowed to be presented here?

If you want to advertise on Linuxquestions.org then you need to get permission: you start the process by sending Jeremy a message.

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?

The options are there to give the administrator the ability to do what is required.
Considering that the software is aimed at security, ALL bugs fixed would be related to security.
Allowing the user to change anything about the script is considered a security violation. And since you depend on CaclMgr to detect it after the fact means it is already too late.
If a "person can run strace to attch to the process" using passwd, then your system has already been compromised, and it doesn't matter what else you have as that person has root.
Ah no. if a person hacks root they can do damn well whatever they want to. And no local log files are safe.
Just because the people auditing the software missed something does not mean they weren't looking. Proprietary software still has more bugs per unit of code than open source code. Mostly because fewer people are looking for problems. People that write software are frequently too focused on the problem they are solving, and don't spot exceptions. That is why automated testing helps - though the testing tools can only detect what they were programmed to detect.
It is more secure. And if you don't feel it is, audit the code yourself. Prove it is not as secure.

Then offer the patches to make it more secure.

That is how open source improves.