On Tue, 27 Jan 2009, Willy Tarreau wrote:
Hi Krzysztof,
Hi Willy,
On Tue, Jan 27, 2009 at 05:50:08PM +0100, Krzysztof Piotr Oledzki wrote:
From 5368532099b8e8c2c6970df8a2d1463a7eaa72bc Mon Sep 17 00:00:00 2001
From: Krzysztof Piotr Oledzki <[email protected]>
Date: Tue, 27 Jan 2009 16:47:15 +0100
Subject: [MEDIUM] access control (block) rework - rfc
Allow more advanced access control:
- rename 'block' to 'deny'
- implement 'allow'
- implement 'order': allow,deny and deny,allow (default)
- implement new check_cond_list() helper function
RFC quality patch.
I'm interested by your change, but not 100% because of the "order" addition.
I've come across many cases where it's not possible to write some ACLs
using only this "order" approach. As soon as you have three conflicting
sets, you cannot write the config.
Example : you want to allow access to your application from the company,
but not from your training room, except the instructor's PC. So you want
to allow 192.168.0.0/16 except 192.168.0.0/24 but you still want to allow
192.168.0.1.
With sequential rules, it could be written that way :
allow 192.168.0.1
deny 192.168.0.0/24
allow 192.168.0.0/16
deny 0.0.0.0/0
With "order", you're blocked.
Good point. It proofs that this is a definitely wrong way to solve it, so
we need a different solution.
After seeing many configurations that people write, I have realized that
what is really needed is this sequential ordering, but not only with
allow/deny, but also with some actions such as use_backend, redirect,
tarpit and things like this. In fact, everything which is acting on the
traffic's destination.
Ack.
However, there was a long term project of supporting ACLs from files.
I have still not worked on this because I don't know how those should
be handled. If we only put values there, it's limited to little usages
such as blacklisting. If we put more complex rules, the files will be
hard to write and might often prevent the process from starting up due
to syntax errors.
But with your order idea, it might get simpler. People who need ACLs
from files are basically ISPs or large network admins. They don't
want complex configs, they want to enumerate the hosts and network
which are granted some access or denied some access. So the principle
of the order could help them write two sets files, one of which
enumerates allowed hosts, and another one enumerating denied networks,
for instance. The config could look something like this :
acl admin src 192.168.0.1
acl visitors src 192.168.0.0/24
acl monitoring src 172.16.0.0/24
allow if admin or monitoring
deny if visitors
access allow /etc/acl/allow.acl deny /etc/acl/deny.acl
The "access" options (allow, deny) would then tell in which order
to check the allow and deny files.
How about something like this:
req allow if admin or monitoring
req tarpit if badrequest
req deny if visitors
req load /etc/acl/blah.acl
$ cat /etc/acl/blah.acl:
deny if ...
allow if ...
deny if ...
(...)
We may start with implementing a sequential ordering for req (request) and
supporting three default targets: deny, tarpit and allow. We may later add
"rsp" (responce) and more targets.
Also BTW, there's something else I had planned. Right now you cannot
write rules without an ACL for whatever object. While this is handy
for complex configs, this is very boring for small configs. I'd like
to be able to use the verb as a function in the rules.
For instance, instead of always having to write :
acl admin src 192.168.0.1
allow if admin
you could write :
allow if src(192.168.0.1)
The last changes I made to the rules in order to add better checks
and typing have made that a lot easier. It would of course prevent
caching, as "src(192.168.0.1)" would automatically be compiled into
an implicit ACL, but caching is still not implemented, and people
who would need caching will certainly not use this anyway because
they'd want to factor out common information.
Indeed, your "instant acl's" idea seems very useful. However, I'm not sure
if it is OK to distinguish it by parenthesis - how whould you like to
write it for "hdr(host) -i localhost"? Maybe it would be better to add
two new keywords: "ifacl" or "unlessacl"?
I still have a lot of drafts on paper that I need to write down in
files and drawings about the proposed evolution of content processing.
Next week I'm on holidays and I hope to be able to advance on the
doc and on publishing all those old thoughts.
It would be very nice to read them.
That said, I'm clearly in favor of "deny" instead of "block" and
adding "allow" ;-)
OK. So if you agree on my "req {allow|deny|tarpit} {if|unless} acl"
idea I'll try to rework my patch that way.
Feel free to comment, as I think we're still lacking a lot of features
in this area, and at the same time it's the one that we cannot break
with newer versions due to the complexity of some setups. I've seen
configs with hundreds of "reqiallow"/"reqideny" that will almost
certainly be converted to the ACLs due to the huge amount of work.
I don't want to fall in that trap again.
Right.
Best regards,
Krzysztof Olędzki
