Subject: new SMX revision submitted

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 28 Jun 2001 16:58:53 +0200

I have submitted a new revision of our SMX specification as an
ID. Until it shows up, you can grab a copy from:

<http://www.ibr.cs.tu-bs.de/~schoenw/draft-schoenw-rfc-2593-update-04.txt>

Below is the unified context diff or the nroff sources relative to the
previous ID.

/js

Index: smx.me
===================================================================
RCS file: /usr/home/schoenw/CVS/ietf/smx/smx.me,v
retrieving revision 1.5
diff -U10 -r1.5 smx.me
--- smx.me	2001/06/11 14:09:16	1.5
+++ smx.me	2001/06/28 14:27:38
@@ -28,21 +28,21 @@
 Request for Comments: xxxx                               TU Braunschweig
 Category: Experimental                                        J. Quittek
 					                 NEC Europe Ltd.
 							       June 2001
 
 .sp1
 .ce 2
 Script MIB Extensibility Protocol Version 1.1
 .sp 1
 .ce 1
-<draft-schoenw-rfc-2593-update-03.txt>
+<draft-schoenw-rfc-2593-update-04.txt>
 
 .ti 0
 Status of this Memo
 .PP
 This document is an Internet-Draft and is in full conformance with all
 provisions of Section 10 of RFC 2026.  Internet-Drafts are working
 documents of the Internet Engineering Task Force (IETF), its areas,
 and its working groups.  Note that other groups may also distribute
 working documents as Internet-Drafts.
 .PP
@@ -188,52 +188,28 @@
 runtime system security profile when a script is started.
 
 .sh 1 "Start of Runtime Systems and Connection Establishment"
 .PP
 The SNMP agent starts runtime systems based on the static properties
 of the runtime system (multi-threaded or single-threaded) and the
 operating system security profiles. Starting a new runtime system
 requires to create a process environment which matches the operating
 system security profile.
 .PP
-The SNMP agent initially passes information to the runtime system by
-means of environment variables. The information is needed to establish
-a trusted communication channel between the SNMP agent and a runtime
-system.
-.PP
-The SNMP agent first creates a listening TCP socket which accepts
-connections from runtime systems. It is the responsibility of the
-runtime system to establish a connection to this TCP socket once it
-has been started. The port number of the listening TCP socket is
-passed from the SNMP agent to the runtime system in the environment
-variable SMX_PORT.
-.PP
-The SNMP agent must ensure that only authorized runtime systems
-establish a connection to the listening TCP socket. The following
-rules are used for this purpose:
-.ip "   -" 8
-The TCP connection must originate from the local host.
-.ip "   -" 8
-The SNMP agent queries the runtime system for a security cookie
-and closes the TCP connection if no valid response is received
-within a given time interval. The security cookie is a random
-number generated by the SNMP agent and passed to the runtime
-system as part of its environment. The cookie is found in the
-environment variable SMX_COOKIE.
-.PP
-The security assumption here is that access to the process environment
-is protected by the operating system.
-.PP
-Alternate transports (e.g. UNIX domain sockets) are possible but not
-defined at this point in time. The reason to choose TCP as the
-transport protocol for SMX was that TCP is supported by all potential
-runtime systems, while other transports are not universally available.
+In order to prevent SMX communication from untrusted peers the SNMP
+agent has to choose a secure SMX transport. This memo defines two
+transports in Section 8: (a) a bi-directional pipe using standard
+input/output streams on the runtime engine side, and (b) a TCP
+connection where the SNMP agent acts as a listening server that
+accepts only connections from local runtime engines that authenticate
+themselves with a secret shared between the agent and the runtime
+engine.
 
 .sh 1 "SMX Messages"
 .PP
 The message formats described below are defined using the Augmented
 BNF (ABNF) defined in RFC 2234 [6]. The definitions for `ALPHA',
 `DIGIT', `HEXDIG', `WSP', `CRLF', `CR', `LF', `HTAB', `VCHAR' and
 `DQUOTE' are imported from appendix A of RFC 2234 and not repeated
 here.
 
 .sh 2 "Common Definitions"
@@ -273,21 +249,21 @@
   ExitCode	=  "1"		; smRunExitCode `noError'
   ExitCode	=/ "2"		; smRunExitCode `halted'
   ExitCode	=/ "3"		; smRunExitCode `lifeTimeExceeded'
   ExitCode	=/ "4"		; smRunExitCode `noResourcesLeft'
   ExitCode	=/ "5"		; smRunExitCode `languageError'
   ExitCode	=/ "6"		; smRunExitCode `runtimeError'
   ExitCode	=/ "7"		; smRunExitCode `invalidArgument'
   ExitCode	=/ "8"		; smRunExitCode `securityViolation'
   ExitCode	=/ "9"		; smRunExitCode `genericError'
 
-  Cookie	= HexString	; authentication cookie
+  Authenticator	= HexString	; authentication cookie
 
   Version	= "SMX/1.1"	; current version of the SMX protocol
 
   Argument	= HexString / QuotedString	; see smRunArgument
 
   Result	= HexString / QuotedString	; see smRunResult
 
   ErrorMsg	= HexString / QuotedString	; see smRunError
 
 .PP
@@ -306,23 +282,23 @@
 following character is treated as an ordinary character.
 
 `Argument' and `Result' is either a QuotedString or a HexString.  The
 Script MIB defines script arguments and results as arbitrary octet
 strings. The SMX protocol supports a binary and a human readable
 representation since it is likely that printable argument and result
 strings will be used frequently. However, an implementation must be
 able to handle both formats in order to be compliant with the Script
 MIB.
 
-The `Cookie' is a HexString which does not carry any semantics other
-than being a random sequence of bytes. It is therefore not necessary
-to have a human readable representation.
+The `Authenticator' is a HexString which does not carry any semantics
+other than being a random sequence of bytes. It is therefore not
+necessary to have a human readable representation.
 
 .sh 2 "Commands"
 .PP
 The following ABNF definitions define the set of SMX commands which
 can be sent from the SNMP agent to a runtime system.
 
   Command =  "hello"   WSP Id CRLF
 
   Command =/ "start"   WSP Id WSP RunId WSP Script WSP Profile 
 		       WSP Argument CRLF
@@ -370,21 +346,21 @@
 
   x0z	syntax errors that don't fit any other category
   x1z	replies for commands targeted at the whole runtime system
   x2z	replies for commands targeted at scripts
   x3z	replies for commands targeted at running instances of scripts
 
 The third digit gives a finer gradation of meaning in each category
 specified by the second digit. Below is the ABNF definition of all
 reply messages and codes:
 
-  Reply =  "211" WSP Id WSP Version WSP Cookie CRLF
+  Reply =  "211" WSP Id WSP Version *1(WSP Authenticator) CRLF
 				; identification of the 
 				; runtime system
 
   Reply =/ "231" WSP Id WSP RunState CRLF
 				; status of a running script
 
   Reply =/ "232" WSP Id CRLF	; abort of a running script
 
   Reply =/ "401" WSP Id CRLF	; syntax error in command
 
@@ -463,24 +439,23 @@
 engine detects any syntax error which is not explicitly mentioned or
 which cannot be identified uniquely, a generic `401' reply is sent
 indicating that the command cannot be executed.
 
 .sh 3 "Processing the `hello' Command"
 .PP
 When the runtime system receives a `hello' command, it processes it as
 follows:
 
 .ip "   1." 8
-The runtime system obtains the security cookie from its process
-environment.
-.ip "   2." 8
-The runtime system sends a `211' reply containing the security cookie.
+The runtime system sends a `211' reply. If the runtime system has
+access to a shared secret, then the reply must contain the optional
+`Authenticator', which is a function of the shared secret.
 
 .sh 3 "Processing the `start' Command"
 .PP
 When the runtime system receives a `start' command, it processes it as
 follows:
 
 .ip "   1." 8
 The syntax of the arguments of the `start' command is checked. The
 following four checks must be made:
 .ip "        (a)" 14
@@ -649,54 +624,63 @@
 implementing the Script MIB generates SMX commands. It also describes
 how the SNMP agent processes replies to SMX commands.
 
 .sh 3 "Creating a Runtime System"
 .PP
 New runtime systems are started by the SNMP agent while processing
 set requests for a `smLaunchStart' variable. The SNMP agent first
 searches for an already running runtime systems which matches the
 security profiles associated with the `smLaunchStart' variable. If no
 suitable runtime system is available, a new runtime system is started
-by preparing the environment for the new runtime system and starting
+by either
+.ip "   (a)" 8
+starting the executable for the runtime system in a new process which
+conforms to the operating system security profile, and establishing a
+bi-directional pipe to the runtime systems standard input/output
+streams to be used for SMX transport, or
+.ip "   (b)" 8
+preparing the environment for the new runtime system and starting
 the executable for the runtime system in a new process which conforms
 to the operating system security profile. The SNMP agent prepares to
-accept a connection from the new runtime system. The `smRunState' of
-all scripts that should be executed in this new runtime system is set
-to `initializing'.
+accept a connection from the new runtime system.
+.PP
+The `smRunState' of all scripts that should be executed in the new
+runtime system is set to `initializing'.
 
 .sh 3 "Generating the `hello' Command"
 .PP
-The `hello' command is generated once a connection request from a
-runtime system has been accepted. The SNMP agent sends the `hello'
-command as defined in section 5.2. The SNMP agent then expects a reply
-from the runtime system within a reasonable timeout interval.
+The `hello' command is generated once an SMX connection is
+established.  The SNMP agent sends the `hello' command as defined in
+section 5.2. The SNMP agent then expects a reply from the runtime
+system within a reasonable timeout interval.
 
 .ip "   1." 8
 If the timeout expires before the SNMP agent received a reply, then
 the connection is closed and all data associated with it is deleted.
 Any scripts that should be running in this runtime system are aborted,
 the `smRunExitCode' is set to `genericError' and `smRunError' is
 modified to describe the error situation.
 .ip "   2." 8
 If the received message can not be analyzed because it does not have
 the required format, then the connection is closed and all data
 associated with it is deleted. Any scripts that should be running in
 this runtime system are aborted, the `smRunExitCode' is set to
 `genericError' and `smRunError' is modified to describe the error
 situation.
 .ip "   3." 8
 If the received message is a `211' reply, then the `Id' is checked
 whether it matches the `Id' used in the `hello' command. If the `Id'
 matches, then the `Version' is checked. If the `Version' matches a
-supported SMX protocol version, then the `Cookie' is checked whether
-it matches the cookie passed to the runtime system. If any of these
-tests fails, then the connection is closed and all data associated
+supported SMX protocol version, then, if present, the `Authenticator'
+is checked. If any of the tests fails or if the SNMP agent requires an
+authenticator and it did not receive a matching `Authenticator' with
+the `211' reply, then the connection is closed and all data associated
 with this runtime system is deleted. Any scripts that should be
 running in this runtime system are aborted, the `smRunExitCode' is set
 to `genericError' and `smRunError' is modified to describe the error
 situation.
 .ip "   4." 8
 Received messages are discarded if none of the previous rules applies.
 
 .sh 3 "Generating the `start' Command"
 .PP
 The `start' command is generated while processing set-requests for a
@@ -911,24 +895,24 @@
 script with the `RunId'. Otherwise, `smRunState' and `smRunError' are
 updated and the `smScriptException' notification is generated.
 .ip "   9." 8
 If the received message is a `538' reply, then the SNMP agent checks
 whether a running script with the given `RunId' exists in the runtime
 system. Processing of the notification stops if there is no running
 script with the `RunId'. Otherwise, `smRunState' is set to
 `terminated' and the `smExitCode' is updated.
 
 .bp
-.sh 1 "An Example SMX Message Flow"
+.sh 1 "Example SMX Message Flow"
 .PP
-Below is an example SMX message exchange. Messages send from the SNMP
-agent are marked with `>' while replies send from the runtime system
+Below is an example SMX message exchange. Messages sent from the SNMP
+agent are marked with `>' while replies sent from the runtime system
 are marked with `<'. Line terminators (`CRLF') are not shown in order
 to make the example more readable.
 
   > hello 1
   < 211 1 SMX/1.1 0AF0BAED6F877FBC
   > start 2 42 "/var/snmp/scripts/foo.jar" untrusted ""
   > start 5 44 "/var/snmp/scripts/bar.jar" trusted "www.ietf.org"
   < 231 2 2
   > start 12 48 "/var/snmp/scripts/foo.jar" funny ""
   < 231 5 2
@@ -941,36 +925,107 @@
   > hello 578
   < 211 578 SMX/1.1 0AF0BAED6F877FBC
   > suspend 581 42
   < 231 581 4
   < 532 0 44 7 "test completed"
   < 538 0 44 1
   > abort 611 42
   < 232 611
 
 .bp
+.sh 1 "Transport Mappings"
+.PP
+In order to prevent SMX communication from untrusted peers the SNMP
+agent has to choose a secure SMX transport. This memo defines two
+transports in Section 8: (a) a bi-directional pipe using standard
+input/output streams on the runtime engine side, and (b) a TCP
+connection where the SNMP agent acts as a listening server that
+accepts only connections from local runtime engines that authenticate
+themselves with a secret shared between the agent and the runtime
+engine.
+.PP
+For simplicity and security reasons the transport over bi-directional
+pipes is the prefered transport.
+.PP
+Further transports (e.g. UNIX domain sockets) are possible but not
+defined at this point in time. The reason for choosing pipes and TCP
+connections as the transport for SMX was that these IPC mechanisms are
+supported by most potential runtime systems, while other transports
+are not universally available.
+
+.sh 2 "SMX over Bi-directional Pipes"
+.PP
+The SNMP agent first creates a bi-directional pipe. Then the agent
+creates the runtime system process with its standard input and
+standard output streams connected to the pipe. Further authentication
+mechanisms are not required.
+." On POSIX compliant systems, this can be achieved by
+." a sequence of pipe(), fork(), dup2() and execve() system calls.
+
+.sh 2 "SMX over TCP"
+.PP
+The SNMP agent first creates a listening TCP socket which accepts
+connections from runtime systems. Then the agent creates the runtime
+system process.  It is then the responsibility of the runtime system
+to establish a connection to the agent's TCP socket once it has been
+started.   The SNMP agent must ensure that only authorized runtime
+systems establish a connection to the listening TCP socket. The
+following rules are used for this purpose:
+.ip "        -" 11
+The TCP connection must originate from the local host.
+.ip "        -" 11
+The SNMP agent must check the `Authenticator' in the `211' reply if
+authentication is required and it must close the TCP connection if no
+valid response is received within a given time interval.
+
+.bp
 .sh 1 "Security Considerations"
 .PP
-The SMX protocol runs on top of a local TCP connection. Protocol
-messages never leave the local system. It is therefore not possible to
-attack the message exchanges if the underlying operating system
-protects local TCP connections from other users on the same machine.
-
-The only critical situation is the connection establishment phase. The
-rules defined in section 4 ensure that only local connections are
-accepted and that a runtime system has to identify itself with a
-security cookie generated by the SNMP agent and passed to the runtime
-system process as part of its environment. This rule ensures that
-scripts will only be executed on authorized runtime systems. This
-scheme relies on the protection of process environments by the
-operating system. Well maintained UNIX operating systems have this
-property.
+The SMX protocol as specified in this memo runs over a bi-directional
+pipe or over a local TCP connection between the agent and the runtime
+system. Protocol messages never leave the local system. It is
+therefore not possible to attack the message exchanges if the
+underlying operating system protects bi-directional pipes and local
+TCP connections from other users on the same machine.
+
+The transport over a bi-directional pipe specifies that the pipe is
+created and connected to the standard input/output stream of the
+runtime engine by the agent before the runtime engine is started.  It
+is therefore not possible that an unauthorized process can exchange
+SMX messages over the bi-directional pipe.
+
+In case of the TCP transport, the only critical situation is the
+connection establishment phase. The rules defined in section 8 ensure
+that only local connections are accepted and that a runtime system has
+to authenticate itself with an authenticator if the agent requires
+authentication. It is strongly suggested that agents require
+authentication, especially on multiuser systems.
+
+The SMX 1.0 specification in RFC 2593 suggested a scheme where the
+authenticator was passed to the runtime engines as part of the process
+environment. This scheme relies on the protection of process
+environments by the operating system against unauthorized access.
+Some operating systems allow users to read the process environment of
+arbitrary processes. Hence the scheme proposed in RFC 2593 is
+considered unsecure on these operating systems. This memo does not
+dictate the mechanism by which the runtime obtains the shares secret.
+It is the responsiblity of implementors or administrators to select a
+mechanism which is secure on the target platforms.
+
+The SMX protocol assumes a local script storage area which is used to
+pass script code from the SNMP agent to the runtime systems. The SMX
+protocol passes file names from the agent to the runtime engines. It
+is necessary that the script files in the local script storage area
+are properly protected so that only the SNMP agent has write access.
+Failure to properly protect write access to the local script storage
+area can allow attackers to execute arbitrary code in runtime systems
+that might have special privileges.
 
 The SMX protocol allows to execute script under different operating
 system and runtime system security profiles. The memo suggests to map
 the smLaunchOwner value to an operating system and a runtime system
 security profile. The operating system security profile is enforced by
 the operating system by setting up a proper process environment. The
 runtime security profile is enforced by a secure runtime system
 (e.g. the Java virtual machine or a safe Tcl interpreter) [7].
 
 .sh 1 "Changes from RFC 2593"
@@ -981,29 +1036,38 @@
 asynchronously by runtime engines to report error conditions.
 .ip "   2." 8
 Added the `538' reply which can be used to signal the (normal or
 abnormal) termination of a running script. This new reply replaces the
 `534' and `535' replies, which are now deprecated.
 .ip "   3." 8
 Relaxed the rules for ProfileChars to also include the characters ':'
 and '_', which are frequently used in namespaces and identifiers.
 .ip "   4." 8
 Changed the SMX protocol version number from 1.0 to 1.1.
+.ip "   5." 8
+Added a second (and prefered) transport over a bi-directional pipe due
+to security risks when a shared secret is passed through an operating
+system's environment variable.
+.ip "   6." 8
+Made the `Authenticator' in the `211' reply optional.
 
 .sh 1 "Acknowledgments"
 .PP
 The protocol described in this memo is the result of a joint project
 between the Technical University of Braunschweig and C&C Research
 Laboratories of NEC Europe Ltd. in Heidelberg. The authors like to
 thank Matthias Bolz, Cornelia Kappler, Andreas Kind, Sven Mertens, Jan
 Nicklisch, and Frank Strauss for their contributions to the design and
-the implementation of the protocol described in this memo.
+the implementation of the protocol described in this memo.  The
+authors also like to thank David Wallis for pointing out a security
+risk in SMX 1.0 with passing a cookie via an operating system
+environment variable.
 
 .sh 1 "References"
 .ip [1]
 Levi, D., and J. Schoenwaelder, \*(lqDefinitions of Managed Objects for the
 Delegation of Management Scripts\*(rq, RFC xxxx, xxx 2001.
 .ip [2]
 Lindholm, T., and F. Yellin, \*(lqThe Java Virtual Machine 
 Specification\*(rq, Addison Wesley, 1997.
 .ip [3]
 J.K. Ousterhout, \*(lqTcl and the Tk Toolkit\*(rq, Addison Wesley, 1994.