RE: RE: Athuorization lists

[qsrvbas@xxxxxxxxxxxx]

midrange-l-request@xxxxxxxxxxxx wrote:

>   6. RE: Athuorization lists (rob)
>
>And this is a very good technique.  I believe it's called "Application 
>Only Access".  It only has a few concerns.
>
>If your vendor does this, and somewhere nested down the list you are 
>granted a command line, then you have the access of the adopted initial 
>program.  You can check this by doing a DSPOBJAUT.  If you see yourself 
>there with object authority of *ADOPT (or is it *ADOPTED) then that is 
>what is happening.


Rob:

Very true. The way to prevent it is simple in an application, but that doesn't 
mean it doesn't happen.

Command-lines are only available in an app if they're somehow programmed in. It 
might be because a WRKSPLF command is on a menu or a program calls QUSCMDLN or 
a display file has an entry field where the typed-in value is passed to QCMDEXC 
or QCAPCMD. However it's done, it's done in a program.

To avoid the adoption security exposure, the basic technique is a wrapper 
program that's created as USEADPAUT(*NO). Instead of simply executing WRKSPLF, 
the application program would call a CL program that does WRKSPLF. That CL 
program provides the boundary by being set to USEADPAUT(*NO). Adopted authority 
from higher up is then not allowed to pass through that wrapper to the 
command-line. (The wrapper doesn't have to be CL; RPG, C or COBOL could work as 
well. But it does need to provide a program boundary.)


>What about the users that are allowed to download data?  Somehow or 
>another you have to give them the ability to do so.

There are various ways to control this, but all of them _ought_ to start with 
object authority.

One direct way is to provide a second logon ID that cannot effectively signon 
to a terminal session -- no initial program and *SIGNOFF for initial menu. The 
second profile could be granted authority as needed to views that can be 
downloaded and possibly to some that can be uploaded.

There's nothing seriously wrong with a user having two profiles (two 
identities, one interactive and one network access). Obviously it can take a 
bit more work to set up; but a second CRTUSRPRF isn't overly burdensome, 
especially if it's automated.

Better would be applications that actively allow for network access. Access 
through stored procedures becomes just another entry point for example.

Or perhaps access is through controlled work files, perhaps generated into the 
user's current library. A remote command populates the work file if authority 
allows it, and the work file is what can be downloaded/uploaded. The remote 
command CPP is where the entry-point-control could be.

In any case, why would network access be considered any different from 
green-screen? If a user can copy a file by downloading, is that different from 
copying via CPYF and green-screen? Of course, downloading brings the question 
of transporting off-site.

But it also implies a PC rather than a dumb terminal. Once a PC replaces the 
dumb terminal, controlling simple downloading is just the start.


>  We used an exit point to only allow them to download a particular 
>temp file.  Took them only about an hour to discover that they could copy 
>over this file with any data they wanted from a query and still download 
>it.

Heh. Yeah, while any given user might not think beyond the instructions 
he/she's been given, you can bet that there will be some that find the routes.

As always, though, they can only copy files they have authority to.

At PowerTech, we've put a feature called 'Memorized Transactions' into the 
exit-point solution we sell -- NetworkSecurity.  This provides granularity down 
to the level of specific transactions. If the only authorized transaction for a 
user is "SELECT FLDA, FLDB FROM FILEA", then "SELECT FLDA, FLB, FLDC FROM 
FILEA" will be rejected. If a file should be downloaded every week, then the 
same transaction should run every week. Other transactions camn be rejected -- 
if that's what you want to do.

But it takes programming effort to make such features work for multiple servers 
and to keep up with release changes such as new formats, not to mention PTFs. 
Other issues such as performance impact complicate it all. It isn't trivial for 
companies to do this themselves, and that's why we can stay in business.

Douglas asked about authorization lists and that goes to the question of object 
authority. They provide a very nice way to implement general object authority 
with control. Group profiles can complement them too. And it's also still 
possible to grant specific private authorities wherever they're actually needed 
without having to manage private authorities on every single object, for 
example when a particular file needs download access for a user (or group).

Fine theory for new applications and for sites that provide developers with the 
time to retro-fit apps that have evolved over a couple decades. It sounded like 
Douglas might be doing some new work, so he might as well put the app together 
correctly from the beginning. Authorization lists are a good place to start.

Tom Liotta


>midrange-l-request@xxxxxxxxxxxx wrote:
>
>>   1. Athuorization lists (Douglas W. Palme)
>>
>>Is there a clean way to keep up to date with authorization lists? We have 
>
>>revamped some of our menus and would like to control who has access 
>(*USE, 
>>*ALL, etc. ) to the program objects and even some menus.
>>
>>Some of the programs, workfiles, etc. would require authority to clear 
>them, 
>>etc. and I was wondering how some of the rest of you handle these types 
>of 
>>issues.
>>
>>I know I can give a user authority to a secific object but is that the 
>best 
>>way to handle it or use authorization lists?
>
>
>Douglas:
>
>Here's a small app structure:
>
>MENU1 is a menu program with --
> 1. Call PGMA
> 2. Call PGMB
> 3. Call PGMC
> 4. Go MENU2
>
>MENU2 is a menu program with --
> 1. Call PGMD
> 2. Call PGME
>
>PGMA does CLRPFM FILEA. PGMB does adds/changes/deletes to FILEA. PGMC does 
>inquiries over FILEA and refers to FILEB for secondary stuff.
>
>PGMD is a FILEB maintenance program. PGME is FILEB inquiry.
>
>There are two entry points to the app -- MENU1 & MENU2. There's no need 
>for any user to CALL PGMC for example because MENU1 option 1 does exactly 
>that. And there is no need to do a RUNQRY over FILEA because MENU1 option 
>3 can handle that.
>
>That is, there are only two objects that users need authority to -- MENU1 
>& MENU2.
>
>Why?
>
>Because there is a profile called PRF1 that owns MENU1 & MENU2 and those 
>programs are created with USRPRF(*OWNER). And all of the other objects in 
>the app are secured with the APPOBJ *AUTL and the only user on that list 
>is PRF1.
>
>Now, MENU1 & MENU2 are secured by a second *AUTL -- APPENTRY. When you 
>want a user to get into the app, you grant him/her *USE rights to 
>APPENTRY. That gives them rights to the application entry points but 
>nothing else.
>
>PGMA, PGMB, etc., are all created as USRPRF(*USER) USEADPAUT(*YES). When 
>MENU1 calls PGMA, PGMA can run even though the user has no authority to 
>it. The authority doesn't come from the user; it comes because the MENU1 
>program itself has authority via USRPRF(*OWNER) and PGMA was told that it 
>was allowed to use adopted authority. And when PGMA tries to clear FILEA, 
>the authority again doesn't come from the user; it comes from the adopted 
>authority that was passed to PGMA from MENU1.