RE: Anti-virus for i5OS

Joe,

Wasn't SSA one of the ones requiring QSECOFR for BPCS and then every 3rd
party add on package to BPCS did the same thing ?

And there was no way around that if you wanted to install it.

NOT saying your were responsible for that :-)

Chuck

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta
Sent: Tuesday, April 01, 2008 3:29 PM
To: Midrange Systems Technical Discussion
Subject: Re: Anti-virus for i5OS

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