RE: Special authority use ... Auditing

Thanx for your comments Ed ... Let me clarify my reason for suggesting an audit 
record for Special Authority use.

>Could the design of this new audit record be such that it would capture all
>the reasons that someone was allowed to access a function or an object?

This wasn't the intent of my suggestion. I was just wondering if it would be 
possible for an audit record to be deposited "if" a Special Authority was the 
reason a user was allowed to access and object. In this case, *SAVSYS 
authority. If the reason was that the user had *OBJEXIST rights to the object, 
then there would be no reason to deposit anything to the audit journal. 

So lets say that user has *OBJEXIST rights to OBJ1 and they also have *SAVSYS 
special authority... I don't see a problem with a record being deposited to the 
journal if *SAVSYS authority was checked first. At that point in time this 
journal entry would still be telling me that this user was allowed to save OBJ1 
because they had *SAVSYS authority. Once *SAVSYS authority was removed and the 
user tried to save the object again, nothing would be deposited to the journal. 
They could still save the object because they have *OBJEXIST to it and this 
would be ok too. The reason behind journal entries for Special Authority 
*SAVSYS use isn't to record what can be saved, but that Special Authority was 
used to save it. If a user has *OBJEXIST rights to an object, then it is given 
that they can save and delete the object. Most likely they own it anyway. 

>Could the design of this new audit record be such that it would capture all
>the reasons that someone was allowed to access a function or an object?

It wouldn't have to be. All it really needs to do is record that Special 
Authority was the reason access was given. I wasn't suggesting that audit 
records be deposited to describe all reasons a user was allowed access to any 
particular object, just when they got that access because of a Special 
Authority.

I can still see this as being a valuable tool for a System Administrator. 
Especially if it was extended to record if Special Authority use resulted in 
the access to any "object". 

I could see having journal records deposited when *SAVSYS, *SECADM, *AUDIT, 
*IOSYSCFG, and *SERVICE are the reason access to an object was granted by the 
system. Special Authority like *JOBCTL and *SPLCTL, wouldn't be included 
because these Special Authorities provide access to function as opposed to 
permanent objects. 

*ALLOBJ wouldn't need to be logged either since you already know that a user 
with that authority can access anything. 

It wouldn't be helpful to have the access to every object on the system logged 
in the audit journal, as backups are being performed by a QSYSOPR profile. So a 
way to exclude certain user profiles from this auditing process would be needed 
too.


Kenneth 



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Ed Fishel
Sent: Monday, March 27, 2006 8:04 AM
To: Midrange Systems Technical Discussion
Cc: Midrange Systems Technical Discussion;
midrange-l-bounces@xxxxxxxxxxxx
Subject: RE: Special authority use ... Auditing


Kenneth Graap wrote on 03/24/2006 04:27:15 PM:

> Don't you agree that it would be a great addition to i5/OS
> auditing to be able to analyze the audit journal for some kind of
> record that indicated Special Authority was being used to "gain
> access" to a function or object?

I agree that it would be useful in some cases, but possibly not as useful
as I believe that you think it would be. For example in the case of *SAVSYS
special authority a user can save an object if they have *SAVSYS or if they
have *OBJEXIST to the object being saved. I do not know which order these
authority checks are done but for this discussion I will assume that the
*SAVSYS check is done first. If that is the case and if the system were
writing a new special-authority-used audit record then you would be able to
see that the user used *SAVSYS to save an object. It would be possible for
someone to draw at least two wrong conclusions from this new audit record.

1. If someone did not want a user to save an object they might remove their
*SAVSYS special authority. Unfortunately, the user might still be able to
save the object because of the users, or their group profiles, *OBJEXIST
authority to the object.

2. On the other hand if someone were looking at this new audit record
because they wanted to remove *SAVSYS from all users that did not need it
then they might not remove it from this user because they see that the user
is using *SAVSYS. But this would not be correct for any user that has
*OBJEXIST authority to the objects they save.

Could the design of this new audit record be such that it would capture all
the reasons that someone was allowed to access a function or an object?
Possibly, but doing that would be a lot of work and would probably require
the system to do additional authority checks.  We would have to change all
the places in the system that check a special authority. My guess is that
this would be more work than the work to add the new AF-K special authority
audit record in V5R3.

Today when the system does an authority check like the one for *SAVSYS
special authority or *OBJEXIST object authority it does not do both checks
at the same time. It does one check and if the user passes that check they
are authorized. If they fail the first check then the second check is done
and if they pass that check then they are authorized. If they don't pass
either check then they are not authorized to the function and either an
AF-K (special authority failure) or an AF-A (object authority failure)
audit record is written.

Ed Fishel,
edfishel@xxxxxxxxxx