RE: Authority annoyances, continued...

Here's a quick example of where O/S security crosses application security.

We run JDE world, and adopt a similar security model to the IBM recommended
one - i.e. adopted security and lock everything else down. While this
provides good security on a day to day basis, there are always loopholes.
JDE provides the option to set up menus which call OS/400 commands. As the
user has adopted authority by now, they have full access to the OS
commands, unless they're locked out of application security.

But of course, everyone knows this and makes sure that every entrance into
their app security is locked down.


....

Don't they?

Never forget that there is more than one way to skin a cat. And people will
always find more ways to do it.





                    "Bale, Dan"
                    <D.Bale@handleman.co
                    m>
                                               To:     security400
                    Sent by:
                    security400-admin@mi       cc:
                    drange.com                 Subject:     RE: [Security400] 
Authority annoyances,
                                                continued...

                    22-Aug-2001 14:12
                    Please respond to
                    security400@midrange
                    .com






This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
I think I know the answer to this, but I need to ask.  If a program's
adopted authority is *OWNER and the owner is king-of-everything/*ALLOBJ
security officer, etc. etc., and that program updates a file that is
owned by PAYROLL user and has *PUBLIC *EXCLUDE on it, will the program
still update that file?

To expand on Larry's example, if a program with adopted authority
provides no access to a command line, can we consider ourselves "safe"?
In such a case, what happens when a user is in the middle of such a
program, and hits the Attn key to pull up Operational Assistant, hits
F9=Command Line, is the user still operating under the adopted authority
of the program he was in?

Dan Bale
IT - AS/400
Handleman Company
248-362-4400  Ext. 4952
D.Bale@Handleman.com
  Quiquid latine dictum sit altum viditur.
  (Whatever is said in Latin seems profound.)

-------------------------- Original Message --------------------------

> -----Original Message-----
> From:   Larry Bolhuis [SMTP:lbolhuis@arbsol.com]
> Sent:   Tuesday, August 21, 2001 11:00 PM
> To:     security400@midrange.com
> Subject:     Re: [Security400] Authority annoyances, continued...
>
> Dan,
>
> > That's why *I think* I like the USRPRF(*OWNER) approach with
> programs.
> > Sure makes it easy as it concerns authorization.  If I can run the
> whole
> > program without authority issues, then my worries are over by using
> > USRPRF(*OWNER).  Rhetorical question: Why not create all
> applications
> > this way?  Go ahead, scare me!
>
>   USRPRF(*OWNER) is the way to go here. The program is guaranteed the
> authority it needs and the user either CAN submit (or call) it or they
> can't.
>
>   Now why not do this all the time??? Well because unless you review
> the
> program carefully and know and understand EVERY caommand in there it
> could open a Mack Truck size secuirty whole in your system.  FOr
> example
> if a program adopting *OWNER owned by QSECOFR called some utility that
> had a command line option, the user just became King.  Or a Fkey that
> displays spool files, "Saaaaay, paychecks, this could be
> interesting..."  Just a couple simple examples!
>
>   - Larry
_______________________________________________
This is the Security Administration on the AS400 / iSeries (Security400)
mailing list
To post a message email: Security400@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/security400
or email: Security400-request@midrange.com