× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: Package Vendor that changes IBM command Defaults.
  • From: "MCPARTLAND, Stan" <stanley.mcpartland@xxxxxxxxxx>
  • Date: Tue, 22 Jun 1999 15:13:19 -0700

The following are some of the standard requirements we have for security
when we evaluate software.  Failing to meet these requirements may not rule
out a vendor, but definitely has an impact on our selection process.  You
would be surprised at how easy it is to get a command entry screen with
QSECOFR authority in some software packages.

- Secure command line access and control of access to systems commands and
menus.
- No hidden, undocumented access to the system.
- No switching of user profile handles.
- Secure use of adoptive authority and user profiles on JOBD's.
- No second level passwords and user profiles.
- The application's security must be based on individual user profiles.
- The application must provide field level security.
- There must be no dependence on QSECOFR authority adoption. The application
software must not require QSECOFR authority to install.
- Objects must be owned by a non-IBM provided user profile.

Stan

-----Original Message-----
From: John Earl [mailto:johnearl@toolnet.com]
Sent: Tuesday, 22 June, 1999 9:52 AM
To: MIDRANGE-L@midrange.com
Subject: Re: Package Vendor that changes IBM command Defaults.


Roger,

Yikes!   These folks are out of control!

A couple of points are worth making.   First, by modifying critical pieces
of the
operating environment they are opening your client's system up for every
program
that is every compiled on that system.  Because AS/400's are typically
muli-tuser
and multi-application platforms, this company is putting their customers
boxes at
great risk.  If the customer has a program (not part of their package) that
presents
the user with a command line, and you compile that program using a profile
that has
some high level of authority, and then an end user did damage through the
command
line because the program adopted authority,  would a court find that the
vendor was
liable for the damage?  I don't know the answer, but I would bet it would be
a good
fight.  I think this vendor ought to be given the opportunity to ponder
their legal
culpability.

The second point to bring up is why does QSECOFR need to own anything?
Does the
application require that all users of the application be able to delete
every object
on the system (*ALLOBJ special authority), create and delete user profiles
(*SECADM)
and even alter storage and reconfigure ASPs (*SERVICE).  By running all
applications
under QSECOFR authority they are giving _everyone_ who can access a command
line
from the application the ability to completely hose the system.  And it is
not for
the vendor to say who does and does not get access to the command line, you
have
considerations in your shop that may make it necessary to provide the
accounting
supervisor command line access.  That doesn't mean you want her running
communicaitons trace and deleting Audit journals.

The other problem that can occur with forcing you to use an IBM profile for
ownership is that profiles can fill up.  If a profile owns two many objects
it runs
out of space to record it's ownership and then simply will not allow you to
create
new objects under that profile.  If everybody makes QSECOFR the owner you
could run
into this problem.

I understand that the vendor is _trying_ to do the right thing by creating
an
Applicaiton Only Access sort of a system, (assuming that *PUBLIC has no
rights to
all the applicaiton objects......   boy I sure hope that's true!).  But in
order to
do this correctly, the vendor should provide their own (owner) user
profile(s) that
has no special authority.  Using any IBM profile, and especially QSECOFR,
provides
users of the package with all sorts of extra authority that they don't
really need,
and puts data at risk.

Special Authorities within an application packageare seldom required.  In
the few
instances that they are, a specific program can be crafted to adopt
authority for
the specific purpose at hand.   Granting every program in an entire package
the
ability to adopt QSECOFR is gross negligence, IMHO.

jte






Roger Vicker wrote:

> Hello,
>
> <<MODE(*RANT)>>
> I have a customer where a vendor (name withheld to protect the GUILTY) for
one
> of their packages, during a version upgrade, changed all the program
create
> commands to USRPRF(*OWNER) AUT(*ALL) and all the file create commands to
> USRPRF(*OWNER) LVLCHK(*NO) AUT(*ALL). To top it off they compiled as a
member of
> QSECOFR. I plan to explain to the vendor Wednesday morning how disastrous
this
> can be, especially on a system where theirs is one of many packages plus
> multiple in-house development. Also, this is the WRONG way to make changes
(to
> the QSYS library objects) even if they were justified. I doubt if they
realize
> that anyone could Trojan horse one of their called programs to gain
complete
> system access. Even if theirs was the only package on the box they have a
> payroll module which all this leaves wide open!
>
> <<MODE(*REQUESTER)>>
>
> What I would like, without creating a total flame war, is a FEW items from
this
> esteemed group to show them as a backup to my lesson on how to play nicely
as a
> software package vendor. I can accept the USRPRF(*OWNER) _IF_ the owner is
a
> special package owner and properly managed but definitely not QSECOFR!
>
> <<MODE(*HUMBLE)>>
> Thanks In Advance.
>
> Roger Vicker, CCP
>
> --
> *** Vicker Programming and Service *** Have bits will byte ***
www.vicker.com
> ***
> We weld anything but the crack of dawn.
>
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
david@midrange.com
> +---



--
John Earl                                              johnearl@toolnet.com
PowerTech Toolworks                         206-575-0711
PowerLock Network Security              www.400security.com
The 400 School                                    www.400school.com
--


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.