Hi Krzysztof,
On Wed, Jan 28, 2009 at 03:02:43PM +0100, Krzysztof Oledzki wrote:
> >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
oh good point BTW, I forgot about "req". You're pretty right, since
the reason I opened 1.3.16 last summer was in order to support
response acls !
> req load /etc/acl/blah.acl
>
> $ cat /etc/acl/blah.acl:
> deny if ...
> allow if ...
> deny if ...
> (...)
I like the principle of "load". But I still have one concern. I
have been trying to find a solution for it a few months ago with
no success : let's say that you let the user edit "blah.acl". He
will write rules referencing only ACLs not defined in this file
but somewhere else. This is absolutely the worst we can do, as
it will lead to a lot of copy-paste errors and switching between
files during editing.
So I wondered if it would be wise to declare ACLs in this file
too. I believe it is not, because we would mix two data types
in the same file which is wrong from a user's point of view.
That's in part what led me to think about the ability to store
immediate values. Once again, people using these files will have
a lot of immediate data in there (basically, those files will be
fed by tools, from databases or logs). So maybe we should simply
not accept any reference to an external ACL in those files, and
only accept immediate values ?
Also something else about the "load". Once people start using
that, they'll want to update the file live and reload the file
after every update (they must not chroot then). But it means
that maybe we should not really "load" the files in the middle
of all other ACLs, but instead open a branch in the middle of
all others, with just a reference, that we can cut when
reloading.
> We may start with implementing a sequential ordering for req (request) and
> supporting three default targets: deny, tarpit and allow.
And "redirect" please ;-)
In fact, I think you should not touch "block" for now, as it's evaluated
very early, independant of this new sequence. We would just have to emit
a big warning when loading a new config using "block" and suggest moving
those lines to the top of the ACLs and changing it with "req deny".
> We may later add "rsp" (responce) and more targets.
yes.
Hmmm, while we're talking about the language, one of the important parts
that were lying on my drafts was the notion of "inbound" and "outbound"
to define where the ACLs match. From memory (I have to check the papers
at work), it would lead to :
req in layer 4 rules
req in layer 7 rules
req in rewrite rules
switching
persistence
load-balancing
req out rewrite rules
req out rules
I'm missing a few stages (and now, I'm sure I had noted that in an
xfig file, I need to find it).
> >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"?
hehe I thought about that this morning when going to work :-)
Indeed, parenthesis are a bad idea. But having a method for
grouping is still needed, or at least being able to specify a
modifier (-i), an operator (-gt, -lt) and a value. Maybe we
should imply enclose them by parenthesis, something like that :
req allow if (hdr(host) -i www) (src 10.0.0.0/8)
> Maybe it would be better to add two new keywords: "ifacl" or "unlessacl"?
If I understand what you propose, I don't think it will solve the
issue as I don't see how I could combine two ACLs with this method.
However, a minor modification might consist in having an "acl()"
function :
req allow if acl(hdr(host) -i www) ...
> >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.
I'm well aware of it. People are asking for updates, I have started
working on those updates and not completed the work due to lack of
time, and a minored evaluation of the amount of work. I can't throw
all of this work to the bin now that we're getting closer, and I
know that for people to more easily contribute, we need some concrete
material to discuss.
> >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.
Yes I agree with it provided you also include "redirect" and you
keep in mind that later we'll make it evolve towards "in" and "out",
with probably "in" being the default when not specified.
BTW, may be you have noticed, I have updated the master git tree
on the site (and a snapshot was published yesterday). The HTTP
part is far more easy to modify without being perturbated by
lower layers, and vice-versa. Those who want tons of new features
and new L7 protocols (POP, SMTP) will be happy. At least, I hope :-)
Cheers,
Willy
