Subject: RE: script extensibility I-D

From: "Wallis, David" <[email-masked]>
Date: Tue, 3 Jul 2001 20:27:24 -0500

David> 1) I notice that the principal updating smLaunchStart is not
David> required to be the same as smLaunchOwner. ... This seems
David> undesirable in that it is unexpected behavior.

>From: Juergen Schoenwaelder [mailto:[email-masked]]
>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.

Reading RFC 2592 is a prerequisite for defining a launch button?
I think I would prefer a more intuitive behavior.

--------------------------------------------------------------

David> 2) The principal performing the set operation (on
David> smLaunchStart) must have read access to the script. This too
David> seems undesirable.

>From: Juergen Schoenwaelder [mailto:[email-masked]]
>This 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.

But it doesn't prevent that! Even with this check in place, you
are free to define whatever launch buttons you wish, and this 
check will never prevent any definitions, because this check
is not performed at the time the launch button is created but 
instead is performed at the time the launch button is used. It
does prevent other people from using your scripts, assuming you
have set up the read view to so restrict access.

It is true that the VACM does not have the notion of execute
permissions. However, write permission on smLaunchStart is a
perfectly adequate substitute, as its only purpose is to be
written to once to trigger each run. It should not be made writable
to those who are not allowed to launch using that button. But
requiring the script to be readable is an unnecessary divulging
of information for purposes unrelated to the information being 
divulged. It is unnecessary and undesirable.

It does make sense to restrict the defining of launch buttons, but
the check provided in this RFC is not the way to do that. Instead,
a check needs to be made at launch button creation time. There are
two possibilities: 1) only smScriptOwner is able to define launch
buttons for that script; or 2) anyone able to read an agreed upon
column of smScriptTable (say smScriptRowStatus) may define launch
buttons for that script. There is no need to check all columns, and
no need to make script readability the test (or part of the test).

--------------------------------------------------------------

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.

>From: Juergen Schoenwaelder [mailto:[email-masked]]
>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.)

Nevertheless, you may want to rethink the design at this point because
it is an inconsistent use of smScriptOperStatus, which in all other 
contexts is used to *report* script status, not as a trigger to control
further operations on the script object. And furthermore, reporting 
`enabled' in smScriptOperStatus should indicate that the script is
*already* enabled, not that it is merely eligible to be enabled. 
(This is the way it is documented on page 20.) You also run the risk
with this design of introducing nonterminating loops where attempting to
report `enabled' after a reload triggers another reload operation.

As a user of the script, what would I look at to determine if the
script was ready to run or not? Would it not be smScriptOperStatus, 
and would the appropriate state not be `enabled'? If the status says
it is `enabled' *before* it is reloaded, the status lies. I suspect
another smScriptAdminStatus setting may be needed.

--------------------------------------------------------------

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?

>From: Juergen Schoenwaelder [mailto:[email-masked]]
>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.

I have no quarrel with providing for such a need. But I do question
providing it as the default; and I also question providing it without
any controls such as specific script versioning, or time limits, or
explicit revokability, or any other safeguards.

--------------------------------------------------------------

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? 

>From: Juergen Schoenwaelder [mailto:[email-masked]]
>You are under control which script is executed. Did you read section
>8? It has concrete examples how this works.

Section 8 says nothing about any safeguard whereby I could revoke my
security profile if the script is changed by someone other than me.
There is nothing in the RFC about any versioning on the script or the
launch buttons, only the languages and the language extensions. I am
not able to control anything other than the tokens given for the name
and the owner of the script when I define a launch button, as far as
this RFC is concerned. (I may or may not be in control of the views of
the script and the launch button--I should be, but this RFC does not 
require it.) There is no guarantee that the owner and name tokens will
continue to associate to the same script over time.

--------------------------------------------------------------

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.

>From: Juergen Schoenwaelder [mailto:[email-masked]]
>Nobody asked for it.

Script security is in the group's charter. It's our job to think of these
things without being asked.

--------------------------------------------------------------

David Wallis

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 4 Jul 2001 18:17:06 +0200

>>>>> Wallis, David writes:

David> Reading RFC 2592 is a prerequisite for defining a launch
David> button?  I think I would prefer a more intuitive behavior.

Its pointless to argue which behavior is intuitive or not since we
will never reach conclusion on that. The WG decided quite some time
ago to do it in the way it is described in RFC 2592 and so far I have
not heard about any real-world problems with that.

>> From: Juergen Schoenwaelder [mailto:[email-masked]] This
>> 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> But it doesn't prevent that! Even with this check in place, you
David> are free to define whatever launch buttons you wish, and this
David> check will never prevent any definitions, because this check is
David> not performed at the time the launch button is created but
David> instead is performed at the time the launch button is used. It
David> does prevent other people from using your scripts, assuming you
David> have set up the read view to so restrict access.

Its good to see that you start to understand how things work. And,
since you seem to like Unix semantics, I can create symbolic links
that point to the middle of nowhere and I can create symbolic links
that point to something I am not allowed to read. This is all fine
until I try to execute/open the file behind the symbolic link. RFC
2592 does just that.

David> It is true that the VACM does not have the notion of execute
David> permissions. However, write permission on smLaunchStart is a
David> perfectly adequate substitute, as its only purpose is to be
David> written to once to trigger each run. It should not be made
David> writable to those who are not allowed to launch using that
David> button.

And this is what you are free to configure. The point is that a
security administrator wants to delegate the right to create launch
buttons to VACM users since you can not reasonably expect that the
security administrator must configure VACM for every launch button
that will be created. And thus, a user can create lunch buttons that
point to other scripts. And this is fine as long as there are read
permissions. If you have read permission, than you can make your own
copy anyway. So if you want to protect a script so that others can not
use it, then you configure VACM to prevent read access to it.

(A Unix script which is world readable can be executed by everybody on
the system, even if the execute bit is only set for the user. You just
make a copy of the script and you can run it. If you want to protect
the script so that others can't use it, you must restrict read
access.)

David> But requiring the script to be readable is an unnecessary
David> divulging of information for purposes unrelated to the
David> information being divulged. It is unnecessary and undesirable.

Not true. See above.

David> It does make sense to restrict the defining of launch buttons,
David> but the check provided in this RFC is not the way to do
David> that. Instead, a check needs to be made at launch button
David> creation time. There are two possibilities: 1) only
David> smScriptOwner is able to define launch buttons for that script;
David> or 2) anyone able to read an agreed upon column of
David> smScriptTable (say smScriptRowStatus) may define launch buttons
David> for that script. There is no need to check all columns, and no
David> need to make script readability the test (or part of the test).

I disagree. Doing the check when you hit the button seems to be more
strict, especially if VACM rules change after scripts and launch
buttons have been created.

David> --------------------------------------------------------------

>> state machine and loading the script into the runtime only makes
>> sense when smScriptOperStatus transitions to `enabled'. (Note the
>> error states for instance.)

David> Nevertheless, you may want to rethink the design at this point
David> because it is an inconsistent use of smScriptOperStatus, which
David> in all other contexts is used to *report* script status, not as
David> a trigger to control further operations on the script
David> object.

Not true. The smScriptOperStatus reports the current state of a state
machine which does lots of things once you set smScriptAdminStatus to
enabled. I fail to see the point.

David> And furthermore, reporting `enabled' in smScriptOperStatus
David> should indicate that the script is *already* enabled, not that
David> it is merely eligible to be enabled.  (This is the way it is
David> documented on page 20.)

The *AdminStatus/*OperStatus is a well understood pattern in MIB
designs. Are you saying all MIBs that use this approach are broken?

David> You also run the risk with this design of introducing
David> nonterminating loops where attempting to report `enabled' after
David> a reload triggers another reload operation.

I fail to see that risk.

David> As a user of the script, what would I look at to determine if
David> the script was ready to run or not? Would it not be
David> smScriptOperStatus, and would the appropriate state not be
David> `enabled'? If the status says it is `enabled' *before* it is
David> reloaded, the status lies. I suspect another
David> smScriptAdminStatus setting may be needed.

I do not understand your problem. RFC 2592 says:

       The smScriptOperStatus object may have the following values:
        - `enabled' indicates that the script is available and can
           be started by a launch table entry.

Is that not clear enough? Can you please write up concrete wordings
that you think are needed? I just do not see what is wrong.

David> --------------------------------------------------------------

>> 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> I have no quarrel with providing for such a need. But I do
David> question providing it as the default; and I also question
David> providing it without any controls such as specific script
David> versioning, or time limits, or explicit revokability, or any
David> other safeguards.

So than submit a concrete proposal request to the WG and convince the
WG (not necessarily me) that something like this is needed. [Note that
the revision of RFC 2592 was just accepted by the IESG and will now go
to the RFC editor. So you have to wait for some time to get any
changes into the document.]

David> --------------------------------------------------------------

>> From: Juergen Schoenwaelder [mailto:[email-masked]] You
>> are under control which script is executed. Did you read section 8?
>> It has concrete examples how this works.

David> Section 8 says nothing about any safeguard whereby I could
David> revoke my security profile if the script is changed by someone
David> other than me.  There is nothing in the RFC about any
David> versioning on the script or the launch buttons, only the
David> languages and the language extensions. I am not able to control
David> anything other than the tokens given for the name and the owner
David> of the script when I define a launch button, as far as this RFC
David> is concerned. (I may or may not be in control of the views of
David> the script and the launch button--I should be, but this RFC
David> does not require it.) There is no guarantee that the owner and
David> name tokens will continue to associate to the same script over
David> time.

You are talking about new features. This is fine but right now not
really on my list of things to worry about. So I prefer to stay away
for script versioning discussions.

David> --------------------------------------------------------------

>> From: Juergen Schoenwaelder [mailto:[email-masked]] Nobody
>> asked for it.

David> Script security is in the group's charter. It's our job to
David> think of these things without being asked.

David> --------------------------------------------------------------

The WG has spend some brain cycles on this in the past and so far I
did not hear you saying that something is really fundamentally broken
with RFC 2592. So that is good news.

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