How to determine UID of OE caller? 
Author Message
 How to determine UID of OE caller?

If I have a routine running under OpenEdition (aka UNIX System
Services), in other words something I started from a shell command
line, and this routine issues a space switch PC to my non-UNIX address
space (say an ordinary MVS subsystem), how do I determine if the
issuer of the PC is running with uid(0) ?

Is there a better way of assigning an authorized status to a C program
running under UNIX ?  I understand APF can be used, but it sounds as
though there are significant usability problems, and it probably can't
be used if the program is to live in an HFS file.

Whatever method I use needs to perform well, so something like asking
SAF/RACF is probably not reasonable.

Thanks...

Tony H.



Fri, 23 Nov 2001 03:00:00 GMT  
 How to determine UID of OE caller?

Tony Harminc wrote

Quote:
>If I have a routine running under OpenEdition (aka UNIX System
>Services), in other words something I started from a shell command
>line, and this routine issues a space switch PC to my non-UNIX address
>space (say an ordinary MVS subsystem), how do I determine if the
>issuer of the PC is running with uid(0) ?

If you cared enough to know, you could issue the GETUID() call. However, its
not clear that such knowledge would be of any value to you.

It would be an integrity violation for a subsystem product to do ANYTHING
that the caller was not expressly permitted to do. You would have to
determine the user's authority in one of the relevant, established MVS ways.
e.g. Sup state, system key, PKM allowing a system key or JSCBAUTH on. You
would also be required to call the ESM (RACF/ACF2 etc) via RACROUTE/RACCHECK
if you planned to access any resource secured that way.

Quote:
>Is there a better way of assigning an authorized status to a C program
>running under UNIX ?  I understand APF can be used, but it sounds as
>though there are significant usability problems, and it probably can't
>be used if the program is to live in an HFS file.

APF authorization is an ancient and, some would say, obsolete way to verify
that a user can access/modify a resource. In general, we need to ensure that
the user has a privilege level suitable to accomplish whatever he is asking
us to do. If that means we need to ask SAF, then so be it.

Quote:
>Whatever method I use needs to perform well, so something like asking
>SAF/RACF is probably not reasonable.

Maybe. Or not. We (BMC) have subsystem code that does this very thing
utterly routinely. We do take the trouble to construct our internal
interfaces ahead of time such that we can use the most expeditious path, but
still, if we need to ask the security system we do it. Its part of the cost
of maintaining system integrity.

Chris



Fri, 23 Nov 2001 03:00:00 GMT  
 How to determine UID of OE caller?

Quote:

>If I have a routine running under OpenEdition (aka UNIX System
>Services), in other words something I started from a shell command
>line, and this routine issues a space switch PC to my non-UNIX address
>space (say an ordinary MVS subsystem), how do I determine if the
>issuer of the PC is running with uid(0) ?

Why not do the getuid() call in the UNIX address space, then send that
information across when you do the PC? If all you really want to do
if verify uid(0), that seems the easiest way. If you want to only allow
some options to a uid(0) user, I'd check the uid() and validate the
request in the UNIX code, before doing the PC. That way, if the caller
is not authorized, you don't have the overhead of the PC. I realize that
you may want a "thin client", so this may not appeal to you. OTOH, a PC
can be expensive, so it may be worth it to "fatten" the client with
this type of test.

Just some thoughts,
John



Sat, 24 Nov 2001 03:00:00 GMT  
 How to determine UID of OE caller?
On Mon, 7 Jun 1999 17:45:31 -0500 "Chris Craddock"

Quote:

>>If I have a routine running under OpenEdition (aka UNIX System
>>Services), in other words something I started from a shell command
>>line, and this routine issues a space switch PC to my non-UNIX address
>>space (say an ordinary MVS subsystem), how do I determine if the
>>issuer of the PC is running with uid(0) ?

>If you cared enough to know, you could issue the GETUID() call. However, its
>not clear that such knowledge would be of any value to you.

Thank you - looks like BPX1GUI is what I need.  But why would it not
be of value to know the uid ?

Quote:
>It would be an integrity violation for a subsystem product to do ANYTHING
>that the caller was not expressly permitted to do. You would have to
>determine the user's authority in one of the relevant, established MVS ways.
>e.g. Sup state, system key, PKM allowing a system key or JSCBAUTH on. You
>would also be required to call the ESM (RACF/ACF2 etc) via RACROUTE/RACCHECK
>if you planned to access any resource secured that way.

This is a very odd claim.  The whole point of PCing to a subsystem is
to allow the subsystem to do things that the caller is not permitted
to do, in a controlled manner.

I think you've misunderstood what I want to do.  I want to base some
portion of the subsystem's action on the uid - specifically whether or
not the uid is 0.  It would be absurd to call this an integrity
violation.  If other components of the system can, say, grant or deny
access to a file based on the uid, why can I not base some part of
what I do on the same thing ?  I am not going to something stupid like
return control in supervisor state, or access resources not permitted
to the caller, just because the uid is 0.

Quote:
>>Whatever method I use needs to perform well, so something like asking
>>SAF/RACF is probably not reasonable.

>Maybe. Or not. We (BMC) have subsystem code that does this very thing
>utterly routinely. We do take the trouble to construct our internal
>interfaces ahead of time such that we can use the most expeditious path, but
>still, if we need to ask the security system we do it. Its part of the cost
>of maintaining system integrity.

Sure - we know how to make SAF calls run fast.  But there's a good
chance that I/O is going to be required on such a call, with all the
problems that entails.  I'd rather have something fast and guaranteed
not to wait.  I don't see any such guarantees on the BPX1 services,
but it seems pretty likely that in an already dubbed address space
testing the uid isn't going to take more than a few instructions.

Tony H.



Sat, 24 Nov 2001 03:00:00 GMT  
 How to determine UID of OE caller?

Tony Harminc wrote

Quote:
>>It would be an integrity violation for a subsystem product to do ANYTHING
>>that the caller was not expressly permitted to do. You would have to
>>determine the user's authority in one of the relevant, established MVS
ways.

>This is a very odd claim.  The whole point of PCing to a subsystem is
>to allow the subsystem to do things that the caller is not permitted
>to do, in a controlled manner.

Not an odd claim, an accurate one. A subsystem can do anything at all, but
it must ensure that it does NOT do anything that the caller was not
PERMITTED to do. There is a significant difference between a user being
permitted to perform some function under the auspices of a subsystem, and
being able to perform that function themselves.

In other words, any privileged program (e.g. your subsystem) cannot just
assume that the user has authority over a dataset (based on say, UID=0), or
that the user can access storage in another key, or any of a myriad of more
subtle issues.

Quote:
>I think you've misunderstood what I want to do.  I want to base some
>portion of the subsystem's action on the uid - specifically whether or
>not the uid is 0.  It would be absurd to call this an integrity
>violation.

You might think it absurd. However, you might subsequently be astonished.
Ensuring system integrity and data integrity is way harder than it appears
to the casual observer. There are folks in the mid Hudson valley who spend
their lives doing system integrity audits of IBM software and they have an
altogether different view. The biggest exposures are often the simplest -
making assumptions based on something you "know" about the user without
referring to a higher authority.

Quote:
>If other components of the system can, say, grant or deny
>access to a file based on the uid, why can I not base some part of
>what I do on the same thing ?

Its ok, so long as you don't second guess the system's security mechanisms.
For HFS files it may well be sufficient, but it would certainly NOT be
sufficient for anything else. To satisfy integrity rules, you MUST call the
ESM and let it decide. It is not sufficient to know that the caller is uid
0.

Quote:
>I am not going to something stupid like
>return control in supervisor state, or access resources not permitted
>to the caller, just because the uid is 0.

So the reason for knowing the uid was...?

Quote:
>Sure - we know how to make SAF calls run fast.  But there's a good
>chance that I/O is going to be required on such a call, with all the
>problems that entails.

Its not your problem, its RACF's or ACF2's. What's the problem with a little
delay? RACROUTE has options for avoiding these problems.

Chris



Mon, 26 Nov 2001 03:00:00 GMT  
 How to determine UID of OE caller?

Quote:

>>If I have a routine running under OpenEdition (aka UNIX System
>>Services), in other words something I started from a shell command
>>line, and this routine issues a space switch PC to my non-UNIX address
>>space (say an ordinary MVS subsystem), how do I determine if the
>>issuer of the PC is running with uid(0) ?

>Why not do the getuid() call in the UNIX address space, then send that
>information across when you do the PC? If all you really want to do
>if verify uid(0), that seems the easiest way. If you want to only allow
>some options to a uid(0) user, I'd check the uid() and validate the
>request in the UNIX code, before doing the PC. That way, if the caller
>is not authorized, you don't have the overhead of the PC. I realize that
>you may want a "thin client", so this may not appeal to you. OTOH, a PC
>can be expensive, so it may be worth it to "fatten" the client with
>this type of test.

Um, how would I prevent the fabled <malicious user> from bypassing the
test and then doing the PC himself?  In other words, the PC is what
controls the transition from the unauthorized to the authorized state
(however one may wish to define "authorized"), and doing checking on
the user side of the PC seems unlikely to provide much security.

Tony H.



Tue, 27 Nov 2001 03:00:00 GMT  
 How to determine UID of OE caller?
On Thu, 10 Jun 1999 08:55:57 -0500 "Chris Craddock"

Quote:

>>>It would be an integrity violation for a subsystem product to do ANYTHING
>>>that the caller was not expressly permitted to do. You would have to
>>>determine the user's authority in one of the relevant, established MVS
>ways.

>>This is a very odd claim.  The whole point of PCing to a subsystem is
>>to allow the subsystem to do things that the caller is not permitted
>>to do, in a controlled manner.

>Not an odd claim, an accurate one. A subsystem can do anything at all, but
>it must ensure that it does NOT do anything that the caller was not
>PERMITTED to do. There is a significant difference between a user being
>permitted to perform some function under the auspices of a subsystem, and
>being able to perform that function themselves.

I think we're saying exactly the same thing in different words.

Quote:
>In other words, any privileged program (e.g. your subsystem) cannot just
>assume that the user has authority over a dataset (based on say, UID=0), or
>that the user can access storage in another key, or any of a myriad of more
>subtle issues.

Well, it *is* reasonable to assume that a uid(0) caller has authority
to any HFS file (well there may be some exceptions, but as long as the
user can't supply arbitrary filenames it's reasonable).

Quote:
>>I think you've misunderstood what I want to do.  I want to base some
>>portion of the subsystem's action on the uid - specifically whether or
>>not the uid is 0.  It would be absurd to call this an integrity
>>violation.

>You might think it absurd. However, you might subsequently be astonished.
>Ensuring system integrity and data integrity is way harder than it appears
>to the casual observer. There are folks in the mid Hudson valley who spend
>their lives doing system integrity audits of IBM software and they have an
>altogether different view. The biggest exposures are often the simplest -
>making assumptions based on something you "know" about the user without
>referring to a higher authority.

I'm not a casual observer; I've been writing authorized code since
1974 when IBM issued the MVS Statement of System Integrity.  I think I
understand it pretty well, but I'm always willing to learn,
particularly in the Brave New World of OS/390 UNIX.  As for making
assumptions without referring to a higher authority, how does a user
get a uid of 0 without going through the higher authority (i.e. SAF) ?
The uid is part of the user's RACF OMVS segment (or equivalent in ACF2
or TSS).  There's no way that I know of, unless it's via a bug in the
UNIX System Services code to get your uid set to 0.  Such a bug is
quite possible, of course, but the damage should be limited because,
as I said earlier:

Quote:
>>I am not going to something stupid like
>>return control in supervisor state, or access resources not permitted
>>to the caller, just because the uid is 0.

>So the reason for knowing the uid was...?

In this example, I have an internal log file (in storage, written to
by multiple callers, etc. etc.), and I want to flag entries made by
uid(0) callers differently from those made by others.  Rather like
flagging WTOs with a + if they come from unauthorized callers.

Tony H.



Tue, 27 Nov 2001 03:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Eruby with different uid

2. Running CGIs under my uid - going slowly insane.

3. UID/GID in python

4. How can I use UID command in IMAPLIB?

5. cgi use root uid

6. Set UID scripts?

7. A uid merger

8. getting username from uid

9. Changing UID in Tcl/Expect?

10. BUG: TCL uses real rather than effictive UID/GID

11. BUG: TCL uses real rather than effictive UID/GID

12. How to find uid

 

 
Powered by phpBB® Forum Software