I am talking about QSECOFR to run. And I am talking about applications that someone other than
operations or developers would be using. If the package required QSECOFR to run, I would find
something else rather than leave the security hole open.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of James
Lampert
Sent: Tuesday, April 01, 2008 3:37 PM
To: Midrange Systems Technical Discussion
Subject: Re: Anti-virus for i5OS
Murphy, Mark wrote:
I would not allow a package that required QSECOFR authority to be
used in production by anyone but the security officer, and only under
restricted circumstances. Certainly not by a user.
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).
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).
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.
midrange.com
