Subject: RE: script extensibility I-D

From: Randy Presuhn <[email-masked]>
Date: Mon, 25 Jun 2001 14:40:09 -0700 (PDT)

Hi -

> Message-ID: <[email-masked]>
> From: "Ayers, Mike" <[email-masked]>
> To: "Wallis, David" <[email-masked]>,
>         Juergen Schoenwaelder
> 	 <[email-masked]>
> Cc: [email-masked]
> Subject: RE: script extensibility I-D
> Date: Mon, 25 Jun 2001 16:06:26 -0500
> List-Id: IETF disman Working Group mailing list <disman.dorothy.bmc.com>
...
> 	You're pretty vociferous for someone who isn't sure...

WG chair says: This is not a useful technical comment.  Behave!

...
> 	Wrong.  It is the responsibility of the designer to make a system as
> safe, reliable, secure, etc. as possible.  It is the responsibility of the
> implementor to verify the safety, reliability, security, etc., in the
> implementatation, and the responsibility of the end user to verify these
> traits in its end use.  This is not written down somewhere so much as it is
> the way things work out.  People often try to use a model where all the
> responsibility is in one pair of hands, but such attempts tend to end badly.

As WG chair, I must point out that the IESG requires that
standards-track specifications (which this isn't) include
an analysis of the security of specification being proposed.
If the proposed protocol is intrinsically insecure or unsafe,
there's not much an implementor can do about it.

...
> 	Therefore, if you think that there is a real security hole, please
> let us know exactly what it is.  Trepidations carry little technical merit.

I think the potential holes regarding script storage and
environment variables have been adequately described.

> > >(b) We did not propose to send the script code over standard input.
> > >    I just said the SMX is carried over a POSIX pipe.
> > 
> > Then may I humbly suggest that you consider the possibility 
> > of sending the
> > script over standard input to the runtime engine.
> 
> 	Okay - why?
...

This should be obvious: it avoids the need to expose
environment variables to establish a trusted communication
channel, and the runtime system would not need ANY rights
with respect to the script storage medium.

This might be overkill.

Personally, I'd prefer there to be a no-environment variables,
TCP-capable specification, but since this isn't standards
track and we use a different architecture to deal with this
in our products, I'm staying on the sidelines.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Jun 2001 12:25:56 +0200

>>>>> Randy Presuhn writes:

Randy> I think the potential holes regarding script storage and
Randy> environment variables have been adequately described.

Sorry, I still do not understand the problem David Wallis has with the
fact that SMX passes file names around. If you understand it, can you
please try to paraphrase it so that I can understand it as well?

Or are you saying that the proposed addition to the security
considerations section which I have posted recently covers David's
concerns?

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>