RBAC Audit log only shows root info

[Shah Sahib]

Hello folks,

I need help. I installed RBAC B.11.23.04 on our ia64 box running B.11.23 v2.

Everything went ok, we had some custom roles configured, authorization, etc etc.

The problem I am having is in the audit log. I do not see a record for any user other than root. Its all info about root.

By default RBAC auditing will audit all users, all commands and all terminals.

I have played with turning AUDIT_FLAG on and off using the userdbset commands. I have edited the /etc/default/security file and set AUDIT_FLAG to 1 and 0.

Nothing works, when I run the audisp cmd, i get logs full of only root results.

Why cant I see other users? btw we have SUDO running on the system, would that make any diff?

[Duncan Edmonstone]

Have you read the section entitled

"Configuring HP-UX RBAC to Generate Audit Trails"

here:

http://docs.hp.com/en/5991-8678/ch03s05.html

HTH

Duncan

[Shah Sahib]

Yes I did, it is in fact the only document that seems to be around. I googled for anything new on RBAC, but nothing useful on auditing. Could not even find anything that explains the output of the cryptic audit log, but in any case I need to be able to see other users first.

Any idea why only root would show up in the audit log and no other user?

[Duncan Edmonstone]

Hi,

I found this note in the 11iv3 man page for rbac:
__________________________________________
If the audit filter database file does not exist, or is not accessible, then the audit records will still be generated. However, if the audit filter database file exists, but is empty, then no audit records will be generated.
__________________________________________

so if the file /etc/rbac/aud_filter exists but is empty, no-one is audited.

Not sure if thats the case on 11iv2

HTH

Duncan

[Shah Sahib]

Yes, that was a good clue, however by default that file is not there and audisp shows all events|all users|all ttys being monitored, so montoring is on, but only shows root related stuff.

I created this file and still nothing, it is monitoring everything, yet only root stuff shows, thats why its maddening.

I have read and re-read the manual, just going in circles.

RBAC is pretty useless without meaningful audit logs, the front end is pretty, but the tail is missing.... hah!

[Shah Sahib]

This is all I see in the audit file...

071114 15:08:16 2988 S 57 1 -1 0 0 0 0 ?????
[ Audit tag: 0: -1:root:200711122141 ]
[ Effective privileges: "BASIC" ]
[ Permitted privileges: "BASIC" ]
[ Retained privileges: "BASIC" ]
[ Event=utssys; User=root; Real Grp=root; Eff.Grp=root; ]

RETURN_VALUE 1 = 0;
PARAM #1 (addr of char) = 2147464848
PARAM #2 (int) = 0
PARAM #3 (int) = 8
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
071114 15:08:16 2988 S 57 1 -1 0 0 0 0 ?????
[ Audit tag: 0: -1:root:200711122141 ]
[ Effective privileges: "BASIC" ]
[ Permitted privileges: "BASIC" ]
[ Retained privileges: "BASIC" ]
[ Event=utssys; User=root; Real Grp=root; Eff.Grp=root; ]

RETURN_VALUE 1 = 0;
PARAM #1 (addr of char) = 2147464848
PARAM #2 (int) = 0
PARAM #3 (int) = 8
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
071114 15:08:16 2988 S 57 1 -1 0 0 0 0 ?????
[ Audit tag: 0: -1:root:200711122141 ]
[ Effective privileges: "BASIC" ]
[ Permitted privileges: "BASIC" ]
[ Retained privileges: "BASIC" ]
[ Event=utssys; User=root; Real Grp=root; Eff.Grp=root; ]

RETURN_VALUE 1 = 0;
PARAM #1 (addr of char) = 2147464848
PARAM #2 (int) = 0
PARAM #3 (int) = 8
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
071114 15:08:16 2988 S 57 1 -1 0 0 0 0 ?????
[ Audit tag: 0: -1:root:200711122141 ]
[ Effective privileges: "BASIC" ]
[ Permitted privileges: "BASIC" ]
[ Retained privileges: "BASIC" ]
[ Event=utssys; User=root; Real Grp=root; Eff.Grp=root; ]

RETURN_VALUE 1 = 0;
PARAM #1 (addr of char) = 2147464848
PARAM #2 (int) = 0
PARAM #3 (int) = 8
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
071114 15:08:16 2988 S 57 1 -1 0 0 0 0 ?????
[ Audit tag: 0: -1:root:200711122141 ]
[ Effective privileges: "BASIC" ]
[ Permitted privileges: "BASIC" ]
[ Retained privileges: "BASIC" ]
[ Event=utssys; User=root; Real Grp=root; Eff.Grp=root; ]

RETURN_VALUE 1 = 0;
PARAM #1 (addr of char) = 2147464848
PARAM #2 (int) = 0
PARAM #3 (int) = 8
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
071114 15:08:16 805 S 19456 1230 -1 0 0 0 0 ?????
[ Audit tag: 0: -1:root:200711122141 ]
[ Effective privileges: "BASIC" ]
[ Permitted privileges: "BASIC" ]
[ Retained privileges: "BASIC" ]
[ Event=logoff; User=root; Real Grp=root; Eff.Grp=root; ]

SELF-AUDITING TEXT: EN_LOGOFF SID 805 PGRP 805 PPID 1230 PID 805 registrar
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
071114 15:10:10 855 S 552 1230 -1 0 0 0 0 ?????
[ Audit tag: 0: -1:root:200711122141 ]
[ Effective privileges: "BASIC" ]
[ Permitted privileges: "BASIC" ]
[ Retained privileges: "BASIC" ]
[ Event=procxsec; User=root; Real Grp=root; Eff.Grp=root; ]

RETURN_VALUE 1 = 0;
PARAM #1 (int) = 4
PARAM #2 (int) = -1
PARAM #4 (int) = 40
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
071114 15:10:10 855 S 60 1230 -1 0 0 0 0 ?????
[ Audit tag: 0: -1:root:200711122141 ]
[ Effective privileges: "BASIC" ]
[ Permitted privileges: "BASIC" ]
[ Retained privileges: "BASIC" ]
[ Event=umask; User=root; Real Grp=root; Eff.Grp=root; ]

RETURN_VALUE 1 = 0;
PARAM #1 (int) = 0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
071114 15:10:10 855 S 60 1230 -1 0 0 0 0 ?????
[ Audit tag: 0: -1:root:200711122141 ]
[ Effective privileges: "BASIC" ]
[ Permitted privileges: "BASIC" ]
[ Retained privileges: "BASIC" ]
[ Event=umask; User=root; Real Grp=root; Eff.Grp=root; ]

RETURN_VALUE 1 = 0;
PARAM #1 (int) = 18
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
071114 15:10:10 855 S 15 1230 -1 0 0 0 0 ?????
[ Audit tag: 0: -1:root:200711122141 ]
[ Effective privileges: "BASIC" ]
[ Permitted privileges: "BASIC" ]
[ Retained privileges: "BASIC" ]
[ Event=chmod; User=root; Real Grp=root; Eff.Grp=root; ]

RETURN_VALUE 1 = 0;
PARAM #1 (file path) = 0 (cnode);
0x40000003 (dev);
2753 (inode);
(path) = /etc/opt/resmon/log/registrar.log
PARAM #2 (int) = 420
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
071114 15:10:10 855 S 19456 1230 -1 0 0 0 0 ?????
[ Audit tag: 0: -1:root:200711122141 ]
[ Effective privileges: "BASIC" ]
[ Permitted privileges: "BASIC" ]
[ Retained privileges: "BASIC" ]
[ Event=logoff; User=root; Real Grp=root; Eff.Grp=root; ]

SELF-AUDITING TEXT: EN_LOGOFF SID 855 PGRP 855 PPID 1230 PID 855 registrar
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Duncan Edmonstone]

Taariq,

I'm afraid the only 11.23 box I currently have access to I can't 'play' with, so I'm stuck with old fashioned auditing on myy 11.11 box... still maybe the issue is in the auditing subsystem, not in RBAC.

What's the output of

audusr

and

audevent

HTH

Duncan

[Shah Sahib]

Thanks Duncan...I agree with you, the RBAC seems to be functioning fine, something in the SAM setting. I see that the audisp -u user audit_file is looking to SAM for users and not a RBAC user file, I had initially thought it would look into the RBAC user database.

Poking around in SAM, found out the audusr cmd is only for trusted systems, gives you a warning if you try to change SAM auditing about the system not being trusted and to use the secweb tool, cmd being secweb -t.

Out of curiosity, i went ahead and said to convert the system to trusted, it refused saying shadow passwords were enabled but still let me continue to the audit menu.

There I realized I could turn RBAC auditing on or off, while I tried to set the AUDIT_FLAG to 0 via secweb and it made no affect.

Strange, the function that should not work in SAM re:audting users and events on a non-trusted system, actually worked, and the tool meant for adjusting auditing on a non-trusted system re: secweb did not work.

So I am waiting to speak with the HP RBAC team, I am sure I am overlooking something and they will make me feel stupid....haha! Thats ok, I will share my findings here as RBAC should become more popular thanks to SOX.

[Shah Sahib]

Sorry...here is the output ofthe audevent cmd....

audusr as I said, gave me a warning 'system not converted to trusted mode'...

[Sirajuddin Sharieff · Accepted solution]

Hi,

You can use the following procedure to setup Auditing for Role Based Access Control.

1. Configure the system to audit Pass/Fail events
# audevent -PFe admin

2. Configure the location and name of the audit output file and enable auditing on the system by executing the following
command

# audsys -n -c /tmp/aud.out -s 2048

3. Create a user example 'john' on the system

# useradd john

4. Create a role example drole using the following command

# roleadm add drole

5. Assign an authorization to the role, for example if we want drole to run the command /sbin/dmesg then assign
hpux.admin.log.read,* authorization to the role

# authadm assign drole hpux.admin.log.read

6. Assign a user 'john' for the 'drole'

# roleadm assign john drole

7. Login to the system as 'john' and execute the following command

# privrun /sbin/dmesg

8. Login as 'root' and execute the following command to extract RBAC audit events from the audit log

# audisp /tmp/aud.out | fgrep privrun

SELF-AUDITING TEXT: ACCESS CONTROL CHECK:successful; username=john; program=privrun; euid=0; ruid=110;
egid=20; rgid=20; role=drole; operation=hpux.admin.log.read; object=*;
SELF-AUDITING TEXT: ACCESS CONTROL CHECK: privrun: attempt to execute command: command='/usr/sbin/dmesg ';
username=john; program=privrun; euid=0; ruid=110; egid=20; rgid=20; role=drole; operation=hpux.admin.log.read;
object=*;

(From the above you can see that Non root events also gets logged to the
Audit Trail)

[Shah Sahib]

thank you, i ran the entire process as you described, did not work. fgrep privrun shows nothing, even though it ran fine under user john.

Do I need to configure the acps.conf file or acps at all? what about the custom aud_filter?

I did not configure compartments, is this needed? I wanted to begin with just barebone setup first and to get basic audit logs in the /tmp/aud.out but as you can see am getting nothing.

[Sirajuddin Sharieff]

If there is a /etc/rbac/aud_filter file and if it is empty then you will not get any audit events recorded. I would suggest remove/move the /etc/rbac/aud_filter and try the same procedure. OR mention the following in the /etc/rbac/aud_filter and
try the same procedure
drole, hpux.admin.log.read, *

[Shah Sahib]

ok...added the line in aud_filter and logged in as john and ran privrun, checked as root results of grep, still nothing. Then removed the file aud_filter, tried again, still nothing.

I have set the AUDIT_FLAG to 0 on the /etc/default/security file.

stop / start the audsys

zero out the audit file

Ran cmd "# userdbset -u john AUDIT_FLAG=1"

verfied with "# userdbget -a" its in the userdb.

Ran "# userdbck -f"

have also tried

"# audevent -p -F" and other variations of auditing pass/fail, pass only, fail only...nothing worked.

tried the privrun steps again, stil no go....

the audit report still throws out only root related stuff.

btw when audevent was configured to only audit failed events, running the audisp cmd showed all events, users and ttys were being monitored.

Thanks for you help all, I opened a case with HP and will post the results of findings here later, meanwhile feel free to share any ideas.

[TwoProc]

Just guessing, but the manual made this statement on page 1:

HP-UX RBAC administration commands do not need to be wrapped with the privrun command because they are setuid=0. The HP-UX RBAC administration commands run with privileges equal to root regardless of who invokes them. Access control checks limit who can use the HP-UX RBAC administrative commands.

Does maybe RBAC run not only "RBAC administration commands" as root, but also ALL commands, so that they would all appear to be root?

[Shah Sahib]

Twoproc, you may have something there, look at the output of the audit log above, notice there is a chmod a few logoffs as well a umask entries in the event, usually atrributed to users, could also be scripts but I had been the only one on this test box and had been running some chmod commands, I wonder if it has something to do with the sudoers file? although i use sudo, but i do have full authority in the sudoers file....? I can find out Monday, will login as user john who is not in the sudoers group and chmod and see if anything...problem with doing this on a test box is there is no user traffic....i will generate some traffic next week.

[Sirajuddin Sharieff]

Please try the following:

1. Set AUDIT_FLAG=1 (This value was 0 earlier) in /etc/default/security file

2. Execute the following
# userdbset -u john AUDIT_FLAG=1

3. Switch on the audit event
#audevent -PFe admin

4.Configure the location of audit file
# audsys -n -c /tmp/aud.out -s 2048

5. Login as user 'john' and execute
the following command.
# privrun /sbin/dmesg

6. Login as root and see whether you get audit log messages in the audit log /tmp/aud.out

# audisp /tmp/aud.out | fgrep privrun

I hope this helps.

[Shah Sahib]

thanks SS, tried your proc exactly, but it still does not show the user in the audit log. The HP tech was also not able to determine why no other user shows up in our log, everything was checked, the swlist for the product, bundle, patches, RBAC and audit log settings in SAM and via userdb cmds were determined to be 'not broken'. The security file had AUDIT_FLAG=1, also confirmed settings via the secweb tool, nothing seems to work. HP did a simple test, create anew user in SAM, set auditing to check for Success/Failure for LOGINS, logged in as the new user, check the audit log via SAM, no entry showed up for the user, tried the same via command line, using userdbset -u testuser AUDIT_FLAG=1, verfied the flag was set with the userdbget -u AUDIT_FLAG, it was set to 1. Checked audevent for events being monitored, set audevent to log all events, check events for a user or a cmd like login or privrun or dmesg by testuser shows nothing when using either SAM audit log or audisp -u testuser audit_log_file or grepping for cmds like audisp audit_log_file | fgrep privrun or dmesg, etc etc....

Even removed shadow passwords, blew away the database in userdb and uninstalled RBAC, re-installed everything, went through the steps, nothing. We have converted system to Trusted from non-trusted, still negative.

This may require a further escalation as the HP tech had no new input other than what the documentation and forum posters here have already described.

Please feel free to post any other ideas you all may have. I am attaching the swlist output for the TrustedMigration bundle which includes RBAC just for yuxs.

[Shah Sahib]

Solution was found by inhouse technical support team, however sadly am unable to post details due to proprietary nature of resolution.

Thanks greatly to all who participated.

Note: HP support was unable to resolve issue, when they obviously should have. A very lackluster and unacceptable level of support was afforded to attempt and resolve this issue.

[Shah Sahib]

closed

[Dennis Handly]

>Note: HP support was unable to resolve issue, when they obviously should have

Did you have them file a bug report so the experts in the lab can look at it?

[Shah Sahib]

No we did not get that far, the HP support person asked us to convert our systems to trusted from non-trusted so he could verify if RBAC was broke. That was unacceptable as our production env has non trusted standard setup and a resolution had to be found per our production setup, we would not allow voodoo tactics.

At that point, HP support refused further help, which was shocking to say the least, I reminded him that per HPs doc, the newer version of RBAC works with trusted and non trusted systems. Then he argued he did not know how our server was setup, this after I had sent him a list of installed sw, shouldnt it have been his job to escalate it to the labs for further forensic work instead of blatently refusing to help because we would not allow him to convert our system to trusted? It was ridiculous and absolutely unacceptable, however this is the first time I have had a HP tech say this, usually they will not push and work around our established setup which is the right way to support a production environment.

Anyway, let this gripe be a reminder to all to not let any support person change your env in order to fix the problem, I am sure if they un-install everything sans a bare OS core, the problem would probably fix most issues, but is that acceptable to you?