On Tue, 17 Mar 2015 10:07:37 -0500, Walt Farrell <[email protected]> wrote:
>
>It is not specifically that the programs may misbehave, but that the users may 
>misbehave. If you trust the users not to misbehave, then you can safely let 
>them run the program. If you don't trust them, then you should not let them 
>run it.
> 
Clarification:  "... should not let them run it *in*a*privileged*state*."  I 
like John M's
idea of running subtasks in separate address spaces, fork() or BPX1EXM.  He 
mentioned
the complications.  SMP/E has a head start: the DDDEF list could be passed to 
the child
process, and it could perform the allocations.  (Not so)SMOP.

>I do wish that IBM would describe the exact nature of the possible user 
>misbehavior. Then folks like Charles would know more about the kind of program 
>behavior they need to consider when deciding whether it's safe to invoke a 
>program while running APF-authorized. Of course, if the possible user 
>misbehavior were described in detail, then the malicious users would also know 
>more about how to look for such potentially exploitable situations. That makes 
>it difficult to convince everyone to improve that documentation.
>
Nowadays, if I specify NOWAIT on all my DDDEFs, I believe (not rigorously 
tested)
I can run SMP/E unauthorized.  It would be a favor to me if SMP/E, when it runs
unauthorized, did not enforce the RACF checks.  I suspect this would not be 
widely
beneficial.  And other programmers might need the utilities to run authorized 
anyway.


On Tue, 17 Mar 2015 10:18:26 -0500, Walt Farrell <[email protected]> wrote:
>...
>When you go to return to the system it's quite possible that you'll go to an 
>address selected by the rogue routine, and it will be running with APF 
>authority at that point.
>
Sigh.  Cf. UNIX, which certainly doesn't let exit() branch to a user-modifiable 
address.
A better designed END SVC would branch, not to the R15 in a key 8 RSA, but to a
caller's address kept in protected storage.

>This can only be fully safe if you never have any key 8 storage, or if you 
>copy all your key 8 data to a system key area before you invoke the 
>unauthorized program, and never use the old key 8 storage again. That would be 
>made a bit easier for you if your program was added to the PPT as running in a 
>system key. Then your initial save area and everything you GETMAIN would be in 
>that system key by default. But if you start out in key 8, you have more work 
>to do.
> 
For a modest start, I can naively wonder why, by default, authorized programs 
don't
start in a system key?  Oops! would the STM on entry S0C4?  Than could be fixed 
by
copying the RSA to that system key and addressing that with R13.

I suppose all the conventions were established before there was any such thing 
as
a nonzero "system key".

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to