[owasp-intrinsic-security] Fwd: Introducing ABE (with almostdefinitive syntax specs)

Giorgio Maone giorgio.maone at gmail.com
Sat Dec 20 19:34:05 EST 2008

---------- Forwarded message ----------
From: Giorgio Maone <giorgio.maone at gmail.com>
Date: Sun, Dec 21, 2008 at 1:32 AM
Subject: Re: [owasp-intrinsic-security] Introducing ABE (with
almostdefinitive syntax specs)
To: Bil Corry <bil at corry.biz>

Precedence, as drafted in the spec, decreases from the top to the bottom,
both inside each rule and in the ruleset as a whole. Whatever matches first
wins, therefore the suggestion to put the most specific rules on the top
(e.g. Allow from SELF),  to give them precedence, and most general rules
(e.g. Deny ALL) on the bottom, to catch the remainders. The visual
feedback-driven UI will always modify the topmost matching rule, if any, or
will produce a topmost rule.

Then, when rules from different sources are merged, they're structured this

   1. User's custom rules, highest precedence.
   2. Site-provided rules (those coming from the site which publish its own
   property), middle precedence.
   3. Community" rules (those downloaded from a centralized authority),
   lowest precedence--

-- G

On Sat, Dec 20, 2008 at 8:12 PM, Bil Corry <bil at corry.biz> wrote:

> Arshan Dabirsiaghi wrote on 12/20/2008 10:40 AM:
> > The second is, even if we could magically turn on Origin everywhere,
> > we would still need to develop the rule framework we see in ABE.
> > Hopefully this will encourage security-aware application architects
> > into making more consolidated, easy to describe apps.
> And beyond Origin, there's also CSP (Content Security Policy) which Giorgio
> mentioned in an earlier thread:
>        http://people.mozilla.org/~bsterne/content-security-policy/<http://people.mozilla.org/%7Ebsterne/content-security-policy/>
> If you have an interest, there's been some discussion about it on the
> mozilla.dev.security list:
> http://groups.google.com/group/mozilla.dev.security/browse_thread/thread/b2525aac8bda30cd/fe91d742ab324499
> The difference between CSP and ABE comes down mostly to a site-centric
> solution (CSP) versus a user-centric solution (ABE).  It'll be great once we
> have CSP, ABE and the Origin header implemented in browsers and websites.
>  The big challenge then will be education; we're still struggling to get
> sites to use the Secure and HTTPOnly flags on cookies...
> > Maintaining the rulesets seems to be the hard part - without
> > community support we'll never be able to keep up with the latest
> > rules from all the popular Web 2.0 sites. This means Giorgio has to
> > work extra hard on the auto-update and auto-learning process. It's
> > conceivable that the rules could change every day. Do we deliver new
> > updates every day?
> For sites that provide their own ruleset, then it sounds like the changes
> will be picked up on the next session (or the user can clear their cache and
> get them immediately).
> For sites that don't provide their own ruleset, then regardless if you
> create your own (manually or learned) or import a community-provided one, if
> it breaks something (triggers ABE), then ABE will have to prompt the user to
> allow/deny an exception, and offer to "learn" to it permanently.
> This is where it becomes tricky.  Say the user doesn't allow an action,
> makes their choice permanent, but then later wants to allow it.  The average
> user is probably not going to be savvy enough to edit the raw rules; having
> a GUI/Wizard that helps fix that issue is important.  Something like "show
> me all the rules for this site" then be able to add/modify/delete them using
> a GUI.
> Even trickier, precedence of rules.  From the spec, it sounds like the most
> restrictive rules are in effect.  So if the user has some rules and the
> server has some rules, then ABE must blend them together, always choosing
> the most restrictive of them.  Now add in a community set also.  Is it a
> separate set, so now ABE has to blend from three sources?  Or upon importing
> the community set of the rules, does ABE do a one-time blend with the user
> rules and store that?  I'm thinking of a scenario where the user allows
> something, but the community rules do not, and since the community rules are
> more restrictive, they win.  The user might be unhappy that suddenly the
> community rules have "broken" the site in question.  Or perhaps on import,
> ABE asks the user to resolve conflicts.
> - Bil
> _______________________________________________
> owasp-intrinsic-security mailing list
> owasp-intrinsic-security at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-intrinsic-security
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-intrinsic-security/attachments/20081221/a2392b0c/attachment-0001.html 

More information about the owasp-intrinsic-security mailing list