Re: [Bug-myserver] ideas about how improve security file

[Alexandru IANCU]

On Thu, 2008-08-28 at 20:29 +0200, Giuseppe Scrivano wrote:
> Hi,
> 
> what do you think about solve the problem in a more general way?  At the
> moment we have ACTION to define simple rules like, if the Host is "foo"
>  then deny any request.
> What do you think about offer something like:
> 
> 
> <CONDITION name="Request.resource" value="secret_file">
> 
>       <CONDITION name="Http.Host" value="localhost">
>               <DEFINE name="Http.Trace" value="NO" />
>               <RETURN value="ALLOW" />
>       </CONDITION>
> 
>       <CONDITION name="User.name" value="root">
>               <RETURN value="ALLOW" />
>       </CONDITION>
> 
> 
>       <RETURN value="DENY" />
> </CONDITION>
> 
> 
> In this way we will read the XML security file like a routine

What about security file being a routine? I mean what about giving up
XML format and write conditions into a scripting language(tcl?!) and
execute them from code? Why would we need to keep XML format for
something that can be easily written and understood(by humans) into a
scripting language?

> , the first
> encountered return will be executed, in this case: order of rules
> matters!  It will be possible to specify conjunctions and disjjunctions
> for rules, negations can be possible using another directive like
> CONDITION_NOT.
> 
> On the path it will be possible to define values, with DEFINE, these
> values are evaluated only once and saved in a hashmap.  Later it will be
> possible to access these values by an API like:
> 
> env.getValue("Http.Trace", USER_SECURITY | VHOST_SECURITY |   
>              MAIN_CONFIGURATION);
> 
> Obviously similar mechanisms will be added in other configuration files.
> 
> 
> The user definition can be done separately or in the same XML file, at
> this point I think there is no need to offer the possibility to use
> different username/password at a file granularity, it will make things
> easier to support new mechanism like PAM and LDAP.

I agree, not for now.

> 
> Users can be specified like:
> 
> <USER name="root" password="verylongpassword"/>

or passphrase - allow spaces also, not just alphanum/control chars.

> 
> There is need of clear password because the HTTP Digest scheme needs it
> (maybe we can find a better solution to its implementation).
> At this point we can have two new categories of plugins, validators and
> password keepers.  The former will be used to do the first part of the
> work with rules, the latter to define tuples <username, password>, LDAP
> and PAM will be one of these.  Seriously the password keepers need a
> better name but I don't have good ideas now.
> 
> An example of validators can be lisp or scheme:
> 
> (cond ((and (eq user "root") (eq host "localhost")) 'ALLOW)
>       ((not (eq host "localhost")) 'DENY))
> 
> not that bad after all :)
> 
> or python:
> 
> if user.user == "root" and req.host == "localhost":
>       return ALLOW
> 
> if not req.host == "localhost":
>       return DENY
> 
> and in any language we will support.
> 

if we decide to use scripts for rules validators will no longer be
necessary. This would be another advantage to use a scriping language
there. We can choose to use more scriping languages not only one.
What do you think?

> 
> 
> The only doubt about this scheme is for MIME types.  Should they be
> handled differently?  Should we imagine something like:
> 
> <CONDITION name="User.name" value="root">
>       <MIME>
>       .......  ---- MIME block like in MIMEtypes.xml.
>       </MIME>
>       <RETURN value="ALLOW" />
> </CONDITION>
> 
> 
> Doing in this way we can have a MIME types manager for each request that
> is filled with MIME types found on the path, in case the MIME for the
> file is not found the generic one is used (vhost scoped or global one).

if you really want to add this, ok but I think we can live without it
for now :)

> 
> Any comment?
> 
> Happy hacking,
> Giuseppe
> 

Best Regards,
Andu.