Subject: Re: script extensibility I-D

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 2 Jul 2001 21:40:04 +0200

>>>>> Wallis, David writes:

David> I didn't find such a draft. But I did find
David> http://www.ietf.org/rfc/rfc2592.txt which answers some
David> questions, but generates some as well.

David> 1) I notice that the principal updating smLaunchStart is not
David> required to be the same as smLaunchOwner. Assuming this is
David> deliberate, in effect all scripts are run setuid as
David> smLaunchOwner. I.e. they run with the security profile
David> associated not with the person that pushed the launch button,
David> but the person who defined the launch button. This seems
David> undesirable in that it is unexpected behavior.

I think RFC 2592 documents this very clearly and thus I fail to see
why this would be unexpected behavior for someone who has read RFC
2592.

David> 2) The principal performing the set operation (on
David> smLaunchStart) must have read access to the script. This too
David> seems undesirable. In a production environment there are many
David> vendors who would desire if at all possible that their scripts
David> be stored such that they may be executed but not read. This
David> coupling of execute access with read privilege means that snmp
David> does not support such a concept as execute-only scripts.

This is test is needed to ensure that you can not create launch
buttons for scripts owned by someone else. Note that VACM does not
have the notion of execute permissions and thus we had to express
execute permissions with read/write permissions.

David> 3) The implementation is made further awkward in that all
David> columnar objects in the smScriptTable (except `not-accessible')
David> must be checked for read access rather than having a single
David> column serve as a surrogate for the entire row, or having a
David> row-oriented operation.

I have no clue what a "row-oriented operation" is. Anyway, I think the
test as documented is just fine as it avoids running into a security
trap just because VACM administrators do not realize the special
semantics of a single object.

David> 4) "A compliant implementation does not have to support script
David> suspension and the smRunState `suspended'. Such an
David> implementation will change into the `suspending' state when the
David> smRunControl is set to `suspend' and remain in this state until
David> smRunControl is set to `resume' or the script terminates."
David> This is bad design because you get the same response whether
David> suspend is supported or not, therefore you don't know whether
David> the `suspending' state actually means that a suspension is
David> imminent or it is not imminent. It would seem better design to
David> require that an implementation not supporting suspend should
David> say so with an appropriate error code in response to the
David> suspend command.

This has been changed in the latest draft, which is
<draft-ietf-disman-script-mib-v2-04.txt>.

David> 5) In section 5.3 there is an apparent typo in "The Script MIB
David> implementation reloads the modified script code once the
David> smScriptOperStatus changes to `enabled' again." I believe it
David> should reload in response to smScriptAdminStatus being set, not
David> smScriptOperStatus which should be set once the reload is
David> complete.

No. Setting smScriptAdminStatus to enabled triggers a more complex
state machine and loading the script into the runtime only makes sense
when smScriptOperStatus transitions to `enabled'. (Note the error
states for instance.)

David> 6) The design decouples the ownership of a script from the
David> principal under whos security profile it will execute, as well
David> as the one actually requesting this particular run. Is this
David> really desirable?

Yes. This is what the WG decided. There seems to be an operational
need to be able to install scripts that execute with privileges which
are not owned by the guy who is allowed to press the launch button.

David> How can effective control over the use of your security profile
David> be maintained when you are not in control of either the script
David> to be executed or the timing of the execution? 

You are under control which script is executed. Did you read section
8? It has concrete examples how this works.

David> There are no controls that say, for example, if the script
David> changes then the launch button is invalidated, or the launch
David> button is valid for a limited time period only, and then
David> expires.

Nobody asked for it.

David> 7) There is also the interesting problem of what to do when the
David> principal who updates a script is not the one who originally
David> created it. Because of the requirement that managers be able to
David> name their scripts without clashes, the owner is made a
David> qualifier of the name. Thus, when ownership changes hands, all
David> script names change, and all launch buttons must be updated. If
David> a team of sysadmins all need to make changes to a large body of
David> scripts as a joint effort, this becomes a nightmare.

It depends. In most cases, you would install scripts by using role
names rather than user names. A script which controls network access
servers would probably installed under owner nas-admin and the folks
who are in charge of controlling network access servers would be
granted access to the MIB based on a suitable VACM configuration.  So
it is actually the VACM configuration which maps user names to access
rights and which needs to be updated if you hire new people to take
care of your network access servers.

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