Why do I have this AUDIT EVENT (Sybase Interface File)

[henk van dorp]

Hi,

Can anybody explain this:

There are audit-messages for useraccount SYSTEM for accessing the file INTERFACES. :

Security audit (SECURITY) on HZPV99, system id: 26502
Auditable event: Object access
Event time: 25-AUG-2006 06:10:05.96
PID: 000F18DA
Process name: FIND_BLOCKER
Username: SYSTEM
Process owner: [SYSTEM]
Image name: DSA0:[SYBASE.BIN]ISQL.EXE;1
Object class name: FILE
File name: _DSA0:[SYBASE]INTERFACES.;3
File ID: (13926,3582,0)
Access requested: READ
Privileges used: SYSPRV,GRPPRV
Posix UID: -2
Posix GID: -2 (%XFFFFFFFE)
Sequence key: 32AEF5F8
Status: %SYSTEM-S-NORMAL, normal successful completion

Question:
Why does SYSTEM need the SYSPRV and/or GRPPRV to access this file?

================================================================================

HZPV99[SAVE]show audit
System security alarms currently enabled for:
ACL
Authorization
INSTALL
SYSGEN
Audit: illformed
Breakin: dialup,local,remote,network,detached,server
Logfailure: batch,dialup,local,remote,network,subprocess,detached,server

System security audits currently enabled for:
ACL
Authorization
INSTALL
SYSGEN
Audit: illformed
Breakin: dialup,local,remote,network,detached,server
Logfailure: batch,dialup,local,remote,network,subprocess,detached,server
FILE access:
SYSPRV: read,write,execute,delete,control
BYPASS: read,write,execute,delete,control
READALL: read,write,execute,delete,control

================================================================================


$ dir/sec dsa0:[000000]sybase.dir

Directory DSA0:[000000]

SYBASE.DIR;1 2 7-JUN-2001 09:34:20.62 [SYBASE] (RWE,RWE,RE,RE)

Total of 1 file, 2 blocks.
$ dir/sec dsa0:[sybase]interfaces.;

Directory DSA0:[SYBASE]

INTERFACES.;3 2 12-NOV-2005 09:19:45.95 [SYBASE] (RWED,RWED,,)
(IDENTIFIER=HYP_USER,ACCESS=READ)

Total of 1 file, 2 blocks.

$ dir/sec DSA0:[SYBASE.BIN]ISQL.EXE

Directory DSA0:[SYBASE.BIN]

ISQL.EXE;1 2121 7-JUN-2001 09:36:45.48 [SYBASE] (RWED,RWED,RE,RE)

Total of 1 file, 2121 blocks.

Thanks in advance

Henk

[Bart Zorn_1]

SYSTEM is not the owner of the file and neither GROUP nor WORLD have access. Only the SYSTEM protection remains, in other words, SYSPRV is needed.

HTH,

Bart Zorn

[henk van dorp]

Hi Bart,

thxs

If the account is not part of the systemgroup your explanation is clear to me.

I assumed that system (which belong to the systemgroup since its id is less than (S) MAXSYSGROUP) can access the file through systemgroup-protection without using the sysprv priv.

Guess this assumption is wrong?

grtz Henk

[Thomas Ritter]

I would have expected SYSTEM to be given access by the first column (RWED,RWED,,) and therefore no audit entry. As a test just use SYSTEM without SQL and see if an audit entry is created. Maybe SYSTEM executing ISQL is changing something ?

[John Gillings]

Henk,

> I assumed that system (which belong to
>the systemgroup since its id is less than
>(S) MAXSYSGROUP) can access the file
>through systemgroup-protection without
>using the sysprv priv.

It doesn't quite work like that. MAXSYSGROUP defines the UIC range for those users who have "implicit SYSPRV".

I concur with Thomas. The process should have accessed the file through the SYSTEM protection mask, and therefore not needed any privilege for the access.

Try DUMP/BLOCK=COUNT:1 against the file from an interactive session logged into SYSTEM. Does it generate an audit?

Maybe also try:

$ OPEN/READ/WRITE/SHARE test _DSA0:[SYBASE]INTERFACES.;3

and see what, if any audits are generated.

Repeat the with SET WATCH/CLASS=ALL enabled.

Also try adding an ACE to the file:

(IDENTIFIER=SYSTEM,ACCESS=R+W+E+D+C)

see if that makes any difference.

If none of the "normal" system accesses generate audit messages, you'll need to investigate exactly what the ISQL image is doing.

[John Gillings]

Henk,

Come to think of it... if you can execute a DIRECTORY/SECURITY from SYSTEM against the file without generating an audit alarm, then I'd expect all the DCL tests to behave the same. After all, the DIRECTORY command must access the file, and is subject to the same rules. That suggests ISQL is doing something unusual in the way it accesses the file.

$ SET WATCH/CLASS=ALL FILE

will generate LOTS of output, but may shed some light on how the security for the file is being processed/interpreted.

Regardless, keep in mind that SYSTEM is "special" and in some cases you cannot get reliable audit information about what it does (there are some potentially nasty recursion loops... for example, should AUDIT_SERVER, running as SYSTEM, audit the fact that it wrote an audit message to the audit journal?). For that reason, the generic problem description "auditing does odd things for processes running under SYSTEM" is usually filed under the same category as "doctor my head hurts when I bang it against this wall". ;-)

[henk van dorp]

Hi guys,

thnxs for your responces. Good to see there are people with compassion for worlds best OS ;>)

Well I'v typed as user SYSTEM the INTERFACE. file and it did generate an audit event the same way as it did with ISQL.EXE :

Security audit (SECURITY) on HZPV99, system id: 26502
Auditable event: Object access
Event time: 2-SEP-2006 22:15:01.36
PID: 0010C87E
Process name: SYSTEM
Username: SYSTEM
Process owner: [SYSTEM]
Terminal name: TNA530:
Image name: DSA0:[SYS0.SYSCOMMON.][SYSEXE]TYPE.EXE
Object class name: FILE
File name: _DSA0:[SYBASE]INTERFACES.;3
File ID: (13926,3582,0)
Access requested: READ
Privileges used: SYSPRV,GRPPRV
Posix UID: -2
Posix GID: -2 (%XFFFFFFFE)
Sequence key: 39879ED2
Status: %SYSTEM-S-NORMAL, normal successful completion

The following output is shown after SET WATCH/CLASS=ALL FILE

HZPV99>typ dsa0:[sybase]interfaces.;3
%XQP, Thread #0, FIB contents:
00000000 00000000 1B4D0000 00000002 00000000 00000183 00000000 00000000
00000000 00000000 00000000 00030000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
%XQP, Thread #0, FIB contents:
00000000 00000000 1B4D0000 00000002 00000000 00000183 00000000 00000000
00000000 00000000 00000000 00030000 00000000 00000001 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
%XQP, Thread #0, Volume protection: Access requested: 00000001, Status: 00000001, PrvUsd: 00000000
%XQP, Thread #0, File protection (6989,2,0): Access requested: 00000004, Status: 00000001, PrvUsd: 00000000
%XQP, Thread #0, Read only directory access (6989,2,0)
%XQP, Thread #0, Directory scan for: INTERFACES.;3, Status: 00000001
%XQP, Thread #0, Lookup (13926,3582,0) Status: 00000001
%XQP, Thread #0, FIB contents:
00000040 0DFE3666 00000000 00000000 00000000 00000003 00000000 00000000
00000000 00000000 00000000 01030000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
%XQP, Thread #0, FIB contents:
00000040 0DFE3666 00000000 00000000 00000000 00000003 00000000 00000000
00000000 00000000 00000000 01030000 00000000 00000001 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
%XQP, Thread #0, Volume protection: Access requested: 00000001, Status: 00000001, PrvUsd: 00000000
%XQP, Thread #0, File protection (13926,3582,0): Access requested: 00000001, Status: 00000001, PrvUsd: 00000001
%XQP, Thread #0, Read attributes: Access mode INTERFACES.;3 (13926,3582,0)
%XQP, Thread #0, Read attributes: Creation date INTERFACES.;3 (13926,3582,0)
%XQP, Thread #0, Read attributes: Expiration date INTERFACES.;3 (13926,3582,0)
%XQP, Thread #0, Read attributes: Backup date INTERFACES.;3 (13926,3582,0)
%XQP, Thread #0, Read attributes: Revision date INTERFACES.;3 (13926,3582,0)
%XQP, Thread #0, Read attributes: ASCII dates INTERFACES.;3 (13926,3582,0)
%XQP, Thread #0, Read attributes: Access mode INTERFACES.;3 (13926,3582,0)
%XQP, Thread #0, Read attributes: Journal flags INTERFACES.;3 (13926,3582,0)
%XQP, Thread #0, Read attributes: RU active INTERFACES.;3 (13926,3582,0)
%XQP, Thread #0, Read attributes: Statistics block INTERFACES.;3 (13926,3582,0)
%XQP, Thread #0, Read attributes: Find ACE by type INTERFACES.;3 (13926,3582,0)
%XQP, Thread #0, Read attributes: Record attributes INTERFACES.;3 (13926,3582,0)
%XQP, Thread #0, Read attributes: User file characteristics INTERFACES.;3 (13926,3582,0)
%XQP, Thread #0, Access INTERFACES.;3 (13926,3582,0) Status: 00000001
%XQP, Thread #0, FIB contents:
00000040 0DFE3666 1B4D0000 00000002 00000000 00220003 00000120 00000000
00000000 00000000 00000000 01030000 0000FFFF 000009D8 00000000 00000000
00000000 00000000 00000000 00000000 00000120 00000000 00000000 00000000
%XQP, Thread #0, FIB contents:
00000040 0DFE3666 1B4D0000 00000002 00000000 00220003 00000120 00000000
00000000 00000000 00000000 01030000 0000FFFF 00000001 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
%XQP, Thread #0, Control function (13926,3582,0) Status: 00000001

... [data of the file]....

%XQP, Thread #0, FIB contents:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00030000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
%XQP, Thread #0, FIB contents:
00000000 0DFE3666 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00030000 00000000 00000001 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
%XQP, Thread #0, Deaccess (13926,3582,0) Reads: 1, Writes: 0, Status: 00000001

Right!!! well, ehhhhhm, help! ;>)

Well notice the prvusd = 00000001 when accessing the file (I guess?????)

[Wim Van den Wyngaert]

http://h71000.www7.hp.com/doc/732FINAL/aa-q2hlg-te/aa-q2hlg-te.HTMl

and check the flow charts. If they are correct, users with GRPPRV use that priv first to evaluate access. So, the system field is used because you have GRPPRV, not because of belonging to the system group.

Wim

[henk van dorp]

Hi Wim,
thnx for the link, but I remain puzzled.

Step 1. Evaluating the ACL
I think we can all agree about the fact that this results in a NO-ACCESS as answer.
(SYSTEM doesn't have the HYP_USER identifier)

Step 2. Evaluate the protection code.
If the ACL did not grant access (it did) and the object's owner is not zero (it isn't; it belongs to SYBASE), the OS evaluates the protectioncode.
For cases where an ACL has denied access, the system examines two fields in the protection code (the system and owner fields) to determine if the user is allowed access. (in my opinion system must now gain access by the system protectionfield)
The user still acquire access by being member of the system or owner categories or by possessing privileges (this is when normal access was denied...)

Hmmmm,
Lets follow the charts (hoping we are viewing the same chart ;>) ):
Figure 3.
Matching Identifier? NO
Owner UIC=0? NO ==> jump to AA

Figure 4:
Requester's UIC = object's owner id? NO
jump to DD

Does Worlsfield in protection mask grant access? NO
Does object's owner have UIC identifier? YES
SYBASE
Is requester in same group as object's owner? NO (SYBASE = 220; SYSTEM = 1)
junp to EE

Figure 5:
Is requester (SYSTEM) entitled to system access (hmm most likely ;>) )
Does system field grant requested access?
(well this should be the case)
Jump to II

Figure 7:
Does object has access override? (not that I am aware off)
Has user granted access (it should have)
Access granted.

No SYSPRV of GRPPRV needed in my opinion.

Please let me know if I did miss something

grtz

Henk

[Wim Van den Wyngaert]

Henk,

Step 1 : you give access to HYP_USER but to get into no access you need ti say id=*, ACC=NONE in the acl. So exit BB is used.

And then you get to the prv section.

Wim

[Wim Van den Wyngaert]

BTW : this is a better link
http://h71000.www7.hp.com/doc/732FINAL/aa-q2hlg-te/00/00/39-con.html#determine-access

Wim