Re: [PATCH] [MEDIUM] access control (block) rework - rfc

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 Received on 2009/01/28 22:30