bug-myserver
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Giuseppe Scrivano
Subject: Re: [Bug-myserver] ideas about how improve security file
Date: Thu, 28 Aug 2008 20:29:43 +0200
User-agent: Mozilla-Thunderbird 2.0.0.16 (X11/20080724)

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, 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.

Users can be specified like:

<USER name="root" password="verylongpassword"/>

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.



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).

Any comment?

Happy hacking,
Giuseppe





reply via email to

[Prev in Thread] Current Thread [Next in Thread]