Re: Installing running applications as QSECOFR

[Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>]

David Gibbs wrote:
> Sure, but the same programs that move the QSECOFR owned objects along 
> the special path are used to move normal objects along a normal path. 
> Which authorities are used?
>   
My point is that perhaps the profiles used during normal operation of 
the tool shouldn't be the same as the profile used for moving QSECOFR 
owned objects.  And then, if the tool didn't adopt QSECOFR specifically, 
any attempt to move a security object from a non-security profile would 
fail, and in fact would be impossible.

I don't know, we seem to be at an impasse.  I've done enough security 
work from my standpoint to think that, given a little time, you could 
avoid the necessity for QSECOFR access EXCEPT in the rare occasion when 
you manage a QSECOFR-owned object.  That sort of work should require a 
regular application programmer to sign off and then sign back in with a 
special profile, one that has been specifically created to handle 
QSECOFR-owned objects.

Done this way, you would not need QSECOFR on installation, nor would you 
ever need to specifically switch to QSECOFR.

But we've gone far, far afield.  It's unlikely MKS is going to change 
its philosophy.  But if I were an auditor, I would still be waiting for 
a good reason to grant QSECOFR authority to an SCM product.  One profile 
that uses the product, specifically to create QSECOFR objects, sure.  
But not the product in general.

Joe