Re: Security?

Œ
Hello Benjamin,

You wrote:
>I am currently writing a program with sockets. Besides TCP it makes use of
>UNIX domain sockets, for descriptor passing. The API description for 
>sendmsg() states, that the _TARGET_ of the message must be running with the
>user identity of the sender or have *ALLOBJ. There is another API to do this
>give_descriptor (I think), which requires the same to stand for the _SOURCE_.
>What is the rationale behind having two APIs for the same purpose but with
>opposite security requirements? 

The reason for the two APIs is that early AS/400 TCP it didn't support local 
sockets (Unix domain or AF_UNIX) so although sendmsg() existed it could not be 
used to pass descriptors.

giveDescriptor() and takeDescriptor() were provided (I think at VRM310) to 
allow descriptors to be passed between jobs.  However, they have their own set 
of annoying behaviour:
        1/ takeDescriptor() blocks if there is nothing to receive thus forcing 
jobs into some sort of synchronization via data queues or similar.
        2/ giveDescriptor needs the internal job id of the target job thus 
requiring additional communication mechanisms (usually a data queue) to pass 
the job id.

The requirement for one side of the connection to have *ALLOBJ is due to the 
ability to pass descriptors to files for which the non-*ALLOBJ side may not 
have authority.  Note that *ALLOBJ is ONLY required if the source and target 
jobs run under different user profiles.

sendMsg was enhanced (at VRM420 I think) to support passing descriptors and I 
think the change regarding which job needed *ALLOBJ occurred at this point.  
I'm guessing here but I think it was probably felt that passing a descriptor 
from an *ALLOBJ process to a non-*ALLOBJ process posed a security risk 
especially since descriptors can represent files and therefore a file to which 
the target job may not be authorized.  It seems cleaner to move up the 
authority hierarchy than down it.  I know Unix will let you do this sort of 
thing (i.e., parent process accepts a descriptor to a file for which it is not 
authorised from a child that uses set-user-id to run as root) but I don't think 
that works on the AS/400.  An AS/400 program accomplishes similar needs by 
adopting authority.

>For the sendmsg(): it just makes unix to OS/400 portin harder, and doesn't add 
>value. 

It doesn't make it harder at all unless you have made design decisions based 
around platform-specific behaviour and the added value is increased security.  
You need to do exactly the same things on the AS/400 as you do on Unix to pass 
descriptors:

        1/ create a local socket via socketpair()
        2/ spawn a process passing one end of the socket pair (unix may use 
spawn or more likely fork and exec (or just exec))
        3/ use the connected socket to pass other descriptors

--or--
        1/ create local socket() and bind() a path to it
        2/ wait for a process to connect() to the local socket
        3/ use the connection to pass other descriptors

The only difference I can see is that on the AS/400 both processes must have 
the same user ID (or the descriptor receiver must have *ALLOBJ).  Unix appears 
to allow any process to pass a descriptor to any other process -- but I'm not 
sure about that.

It is actually easier to implement Unix semantics using sendmsg() than it was 
using givedescriptor().  You should use sendmsg() and recvmsg() rather than 
givedescriptor() and takedescriptor() unless you need to target a release 
earlier than VRM420.

It would also be better to ensure that the source and target job run under the 
same user profile rather than requiring *ALLOBJ authority.  That's no hardship 
if one job spawns the others, the spawned jobs will inherit the user profile.

>The same OS/400 allows ondinary users change the size of shared pools (why?), 
>respond to operator messages (again, why?) and there may be more.

Different issue although still security related -- users can only do what they 
are authorized to do.  You need *USE and *ADD authority to the mŒssage queue to 
reply to message.  The default authorities will allow any user to answer 
messages but changing the QCRTAUT system value and restricting authority to 
existing message queues will handle that. 

I will admit that allowing all and sundry to run CHGSHRPOOL or WRKSHRPOOL seems 
shortsighted but the 'sundry' users ought to have LMTCPB(*YES) specified on 
their profiles which will stop them running the commands from a command line 
and you can specifically exclude *PUBLIC from those commands if you desire.

Regards,
Simon Coulter.

«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
«» FlyByNight Software         AS/400 Technical Specialists       «»
«» Eclipse the competition - run your business on an IBM AS/400.  «»
«»                                                                «»
«» Phone: +61 3 9419 0175      Mobile: +61 0411 091 400           «»
«» Fax:   +61 3 9419 0175      mailto: shc@flybynight.com.au      «»
«»                                                                «»
«» Windoze should not be open at Warp speed.                      «»
«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
+---
| 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
+---