rfc3179.txt

RFC 的详细文档！

   7. If the received message is a `536' 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'
      and `smRunError' are updated.






Schoenwaelder & Quittek       Experimental                     [Page 19]

RFC 3179                    SMX Protocol 1.1                October 2001


   8. If the received message is a `537' 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'
      and `smRunError' are updated and the `smScriptException'
      notification is generated.

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

7.  Example SMX Message Flow

   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
      < 532 0 44 2 "waiting for response"
      > status 18 42
      > status 19 44
      < 432 12
      < 231 19 2
      < 231 18 2
      > 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

8.  Transport Mappings

   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



Schoenwaelder & Quittek       Experimental                     [Page 20]

RFC 3179                    SMX Protocol 1.1                October 2001


   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.

   For simplicity and security reasons the transport over bi-directional
   pipes is the preferred transport.

   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.

8.1.  SMX over Bi-directional Pipes

   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.

8.2.  SMX over TCP

   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:

   -  The TCP connection must originate from the local host.

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

9.  Security Considerations

   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.






Schoenwaelder & Quittek       Experimental                     [Page 21]

RFC 3179                    SMX Protocol 1.1                October 2001


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

10.  Changes from RFC 2593

   The following non-editorial changes have been made:

   1. Added the `536' and `537' replies which may be generated
      asynchronously by runtime engines to report error conditions.



Schoenwaelder & Quittek       Experimental                     [Page 22]

RFC 3179                    SMX Protocol 1.1                October 2001


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

   3. Relaxed the rules for ProfileChars to also include the characters
      ':'  and '_', which are frequently used in namespaces and
      identifiers.

   4. Changed the SMX protocol version number from 1.0 to 1.1.

   5. Added a second (and preferred) transport over a bi-directional
      pipe due to security risks when a shared secret is passed through
      an operating system's environment variable.

   6. Made the `Authenticator' in the `211' reply optional.

11.  Acknowledgments

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

12.  References

   [1]  Levi, D. and J. Schoenwaelder, "Definitions of Managed Objects
        for the Delegation of Management Scripts", RFC 3165, September
        2001.

   [2]  Lindholm, T., and F. Yellin, "The Java Virtual Machine
        Specification", Addison Wesley, 1997.

   [3]  J.K. Ousterhout, "Tcl and the Tk Toolkit", Addison Wesley, 1994.

   [4]  Fritzinger, J.S., and M. Mueller, "Java Security", White Paper,
        Sun Microsystems, Inc., 1996.

   [5]  Levy, J.Y., Demailly, L., Ousterhout, J.K., and B. Welch, "The
        Safe-Tcl Security Model", Proc. USENIX Annual Technical
        Conference, June 1998.






Schoenwaelder & Quittek       Experimental                     [Page 23]

RFC 3179                    SMX Protocol 1.1                October 2001


   [6]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

   [7]  Schoenwaelder, J., and J. Quittek, "Secure Internet Management
        by Delegation", Computer Networks 35(1), January 2001.

13.  Authors' Addresses

   Juergen Schoenwaelder
   TU Braunschweig
   Bueltenweg 74/75
   38106 Braunschweig
   Germany

   Phone: [phone]
   EMail: [e-mail]


   Juergen Quittek
   NEC Europe Ltd.
   C&C Research Laboratories
   Adenauerplatz 6
   69115 Heidelberg
   Germany

   Phone: [phone]
   EMail: [e-mail]
























Schoenwaelder & Quittek       Experimental                     [Page 24]

RFC 3179                    SMX Protocol 1.1                October 2001


14.  Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Schoenwaelder & Quittek       Experimental                     [Page 25]