Re: Pipeline Parameters by Default

Thank you for picking this up and taking this to the mailing list.
Maybe we can make some progress on this and iron out some
misunderstand we might have.

Before going over the points in your message, let me mention two use
cases I have in mind as we talk about parameters:

1) A pipeline is called from the command line and parameters are the
mechanism used to pass command line arguments to the pipeline.
2) A web framework maps URI to pipelines and parameters is the
mechanism used to pass request parameters to the pipeline. E.g. on
loads http://server/approve-transaction.xpl?id=123 and the pipeline
approve-transaction.xpl is called with a parameter "id" that has a
value "123".

In both cases, I imagine 3 different actors:

A) End-users: they call the pipeline from the command line in (1) and
use the web site in (2).
B) Pipeline authors: they write the pipeline and invoke steps
(stylesheets through the XSLT component, other components, other
pipelines, ...). Those step are potentially written by someone else.
C) Step authors: write the other pipelines, stylesheets, or components
used by pipeline authors.

The behavior of steps can be influenced by the parameters they
receive. If by default, parameters received by the pipeline are
automatically passed to all the steps, an end-user can influence the
behavior of steps by passing parameters to the pipeline, without that
influence being made clearly apparent to the pipeline author. If the
end-user is well-intentioned, we might call this flexibility. But it
the end user is ill-intentioned, this becomes a security risk.

To make this even more concrete, imagine that pipeline which handles
an expense report it receives as an input document. Amongst other
things the pipeline calls a stylesheet that implements business logic
checking if the expense report is receivable. That stylesheet has a
parameter "always-approve", with default value false(). The pipeline
author is not careful and doesn't explicitly set the value of this
parameter to false() nor writes additional code to prevent parameters
from being passed to the stylesheet. This allows some ill-intentioned
end-users to pass always-approve=true to the pipeline and have their
expense report always approved.

With this in mind, I consider that:

i) It is not wise to have parameters received by the pipeline passed
by default to all the steps.
ii) Requiring pipeline authors to make it explicit in the their code
when they want parameters received by the pipeline to be passed to a
step will make some pipelines slightly more verbose. But this is not
an unreasonable burden on the pipeline author in the light of (i).

On 6/7/07, Alex Milowski <alex@milowski.org> wrote:
> I reject the argument against this because of security concern as:
>
>   * parameters are no different than pipeline inputs or outputs in
>      terms of security.  That is, if you are concerned about pipeline
>      invocation from a security perspective, all inputs--xml or parameters--are
>     equally troubling.

There are few important differences between inputs and parameters:

1) Inputs to the pipeline must be declared by the pipeline. If a
pipeline has a input always-approve, the pipeline will have a <p:input
port="always-approve"/>. This is not the case for parameters. The fact
that the pipeline might receive parameters won't even be explicit.
2) The defaulting story we for inputs doesn't say that if a pipeline
has an input "always-approve" port, then that port is automatically
connected to any input port named "always-approve" that a step might
have.

To do with inputs what we are considering to do with parameters, we
would have to say that one can call the pipeline passing a document to
an input port that is not declared by the pipeline and that this
document will be passed to any step in the pipeline that has an input
port with the same name. I wouldn't consider this to be a good idea
either.

>   * the pipeline author now has the control to exclude pipeline
>     parameters from a step.  This means a pipeline author can write
>     a "secure step" than can't be affected by pipeline parameters

Yes, the pipeline author has that choice. The pipeline author can
indeed by adding some markup write a "secure step". But I would like
this to be the default, rather than requiring the pipeline author to
do extra work to make things secure.

>  * true security relies upon securing the execution environment from
>    doing harm to the local system (e.g. as a "jail" or "secure VM").  As such,
>    parameters, inputs, and outputs have little to do with this.

Yes, securing the execution environment is part of your security
story. If your pipeline engine is handling HTTP requests, you want
that engine to be executed by a non-privileged user. If your pipelines
send queries to a database, you want pipelines to do so using a
non-privileged database user. But as you know, this is not the whole
story.

Alex
-- 
Orbeon Forms - Web 2.0 Forms, open-source, for the Enterprise
http://www.orbeon.com/

Received on Sunday, 10 June 2007 16:24:52 UTC