Re: Anti-virus for i5OS

[Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>]

James Lampert wrote:
> If you mean "required QSECOFR authority" for installation, then you're 
> locking yourself out of an awful lot of commercial software that 
> requires it. QuestView used to require both *ALLOBJ and *SECADM for 
> installation (we recently determined that the *SECADM requirement was no 
> longer necessary, and dropped it from installation of the new release).
>   
Not to argue, but I don't require any such security to install PSC/400.  
It's a matter of design.

> Likewise, if you mean "required QSECOFR authority" to launch a server, 
> well, if the server isn't running under an account with enough authority 
> to spawn off child-server jobs under the account of whatever user signs 
> on, then if the server works at all (which ours won't), then it would 
> have to spawn off the jobs under the same user profile it's running in, 
> and THAT's a far bigger security breach. (Yes, I know, the child-server 
> job can be changed to use the signed-on user's authority, but I've never 
> heard of a way to change it so it shows up in WRKACTJOB under any user 
> other than its original one).
>   
But the answer is not to blindly give it QSECOFR authority, but instead 
to give the product's primary profile *USE authority to only those 
profiles it should spawn.  Sorry, but this is a huge hole.  As to 
WRKACTJOB, it shows current user by default.  Not sure which release 
that changed.

> If you mean "required QSECOFR authority" to run, well, occasionally some 
> API required by an application will be restricted, and require the app 
> to run under owner authority with a highly prived owner. The Program 
> Creation API was that way at one point.
This sort of breach is highly unusual and must be explained to both the 
customer and their auditors.  Forcing QSECOFR for any reason should be 
tightly controlled and only enabled on an as-needed basis.

I think, though, that in your case specifically James a lot of this has 
to do with supporting back levels of the operating system.  As security 
has been tightened over the years, you're stuck with the conundrum of 
whether you use a single method for all releases or you have separate 
versions for each release.  I wouldn't want to have to make that 
particular decision <grin>.

Joe