Re: Security?

[Benjamin Budai <BENJI@xxxxxxxxxxxxxx>]

On Sat, 6 Jan 2001, Simon Coulter wrote:

>> Œ
>Hello Benjamin,
>
----CUT HERE----
>
>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.

TCP/IP has nothing to do with local sockets. The socket API itself should 
support local, TCP, UDP and other sockets.

>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.

Never tried, just read about. I went directly to sendmsg() and recvmsg().

>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.

It seems logical, but if having *ALLOBJ in one side of the socket poses a 
security risk then IBM should have discontinued one oft the APIs. It 
didn't therefore such a threat does not exist OR it's fully integrated 
with OS/400 (what a value!)

>>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. 

I don't see increased security. If you don't want someone to intercept a 
descriptor simply deny access to the socket in the IFS. OS/400 has finer 
control over authority than traditional UNIX.  
 
>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.

The unix source required minimal changes to compile on the OS/400. It 
runs, but becouse of the security restrictions it fails.  

>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.

I agree.

>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.

Okay, but lets take a look at this scenario:
A server is listening on a TCP port and on a local socket. The clients 
(remote or local) send control information to the server. If the server 
finds a match between a TCP and a local client's control information, 
then passes the TCP socket descriptor to the local client, and closes the 
connection. At this point the two clients are connected with a TCP 
socket, and the server is not connected to the clients.

The local client is not a child process, but an arbitrary interactive 
job. As the server should serve many clients concurrently, setting the 
user identity of the server to that of the client is complicated, and 
requires the server having *ALLOBJ. I see 4 other "solutions":

[a] Give the local clients *ALLOBJ.
    As these are mainly interactive jobs, giving *ALLOBJ to every user poses
    real security risk. Maybe adopted authotity...
[b] Setting the client's user identity to that of the server.
    Requires access to a set of APIs for profile switching and others.
    Not a nice solution, and makes the application totally OS/400 specific.
[c] Redesign the application logic.
    Lot of work, but this is the cleanest way to go. I have the new design
    already in my mind.
[d] Give up.
    Bad message to others willing to port applications to the AS/400.  
    Not a real option.

>>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. 

If you revoke *ADD, you won't be able to send messages to that queue. 
Seems bad design that the same authority is needed to send a message to 
someone and answer a message for someone. I would prefer not having an 
email address if everyone could reply to the mails I got.

>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.

I did it when I first noticed. Too bad that many administrators rely on 
IBM shipped settings, and I fear that there are more "trapdoors" I'm not 
aware of.

Regards,

Benjamin Budai

>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
+---