Zed Shaw discusses this in several parts within the presentation; it's somewhat of a recurring theme.
ACLs as they're implemented on most operating systems are wicked limited; tracking attributes and access to anything beyond simple boolean HAVE_ID or !HAVE_ID or HAVE_THIS+HAVE_THAT logic gets really ugly with an ACL. And the classic ACLs are not at all dynamic, as is pointed out in the presentation. You can't easily tie the access control processing directly into the LDAP directory for employment status or into the system time for time-based rules, for instance.
Having access to conditional statements and such to manage access control is infinitely more flexible. This is the "Turing Complete" part of the presentation.
This processing all reminded me of what you can do with D inside the DTrace environment, too. But I digress.
ACLs (and RBAC, and most capability security models) are limited for a reason -- they allow you to prove that certain security properties will hold for your application. Without a solution to the halting problem, no such assertion can be made about security mechanisms expressed using Turing-complete languages.
That's not to say that ACLs are the last word -- they were defined and analyzed in depth in the 60s and 70s, and work in security theory marches on. Models such as information flow analysis, object capabilities, etc., allow for much richer policy definition while still making stronger guarantees about the security of the finished system.
While I actually like most of what Zed has to say in this talk, I think he's doing a grave disservice to the security theory community by dismissing out of hand everything they've done in the last 40 years.
Yes that provability is big - but I guess is his point is that with SOX and other legal requirements - that provability and applicability of ACLs is now completely out of the window, so its time to stop hammering the square peg into the round hole.
Laywers and the law don't care about provable security models and neither do the gold owners who want the system. Zed is absolutely right, build what they want even if it isn't provably secure. Test it sufficiently, cover all the cases you can, and move on.
Something doesn't have to be provable to work, the same applies to type systems. Lot's of things that aren't provable and would be forbidden by a static type system will happily chug along just fine in a dynamic system that does what you tell it.
When it's law vs theory, law wins. Unlike theory, the law doesn't have to make sense but you sure as hell better be able to show that you attempted to comply with it.
Thanks -- I did watch the presentation (http://news.ycombinator.com/item?id=420974) and I get how ACLs could be heavyweight and inflexible -- what I'm looking for are some concrete examples of how else people do it.
For example, does Ruby on Rails offer some framework for dealing with this? Or is it a 'just do it' kind of thing? Maybe it's not as complicated as I'm imagining it could be, and that's the point. But some example code would be good to look at.
I'll look into this further but thought I'd solicit here first.
His comment about it turning into 500 lines of code isn't an exaggeration, most likely. The truth is that it's so simple that one can hardly understand why anyone uses ACLs after you've implemented something like this. You create a series of functions that define the attributes you are interested in, there's some lightweight context maintenance, then in the core of the system (the "500 lines") you simply tie all the pieces together in accordance with the business rules. It's so simple it almost boggles the mind. Bog-standard refactoring will get you there in nothing flat, and of course you have full Turing-complete language constructs at your disposal.
One hint: Write the code in a functional style, i.e., Haskell style. Pass in the full context to the permission function. For instance, if you have a time-sensitive function, don't have the time-sensitive function call the system clock; have it extract the time from the context your provided. If you call the system clock, you'll never be able to write the tests you're going to need to write. Similarly for many things, like direct LDAP access or whatnot. The internal permission code needs to be a pure function. Fortunately, that doesn't make it any harder to write, even in an OO-based language.
If you want to get really slick because your context has multiple expensive operations like direct LDAP access (although this is a bad idea if you're going to be calling this frequently), you can even create two context implementations, one for testing that simply returns provided values and one that lazily goes out and gets LDAP data or whatever if you need it. Best of all worlds that way.
Thanks. Nice to have a sketch of the thing's structure. It's a finite state machine, where the 'attributes' are the states, and the code is the transition rule.
Comments
Any links? As only a sometime-programmer, the "ACL is Dead" idea is new to me. I could use some good examples.
http://en.wikipedia.org/wiki/Capability-based_security
Zed Shaw discusses this in several parts within the presentation; it's somewhat of a recurring theme.
ACLs as they're implemented on most operating systems are wicked limited; tracking attributes and access to anything beyond simple boolean HAVE_ID or !HAVE_ID or HAVE_THIS+HAVE_THAT logic gets really ugly with an ACL. And the classic ACLs are not at all dynamic, as is pointed out in the presentation. You can't easily tie the access control processing directly into the LDAP directory for employment status or into the system time for time-based rules, for instance.
Having access to conditional statements and such to manage access control is infinitely more flexible. This is the "Turing Complete" part of the presentation.
This processing all reminded me of what you can do with D inside the DTrace environment, too. But I digress.
Watch the presentation. It's worth your time.
ACLs (and RBAC, and most capability security models) are limited for a reason -- they allow you to prove that certain security properties will hold for your application. Without a solution to the halting problem, no such assertion can be made about security mechanisms expressed using Turing-complete languages.
That's not to say that ACLs are the last word -- they were defined and analyzed in depth in the 60s and 70s, and work in security theory marches on. Models such as information flow analysis, object capabilities, etc., allow for much richer policy definition while still making stronger guarantees about the security of the finished system.
While I actually like most of what Zed has to say in this talk, I think he's doing a grave disservice to the security theory community by dismissing out of hand everything they've done in the last 40 years.
Yes that provability is big - but I guess is his point is that with SOX and other legal requirements - that provability and applicability of ACLs is now completely out of the window, so its time to stop hammering the square peg into the round hole.
Laywers and the law don't care about provable security models and neither do the gold owners who want the system. Zed is absolutely right, build what they want even if it isn't provably secure. Test it sufficiently, cover all the cases you can, and move on.
Something doesn't have to be provable to work, the same applies to type systems. Lot's of things that aren't provable and would be forbidden by a static type system will happily chug along just fine in a dynamic system that does what you tell it.
When it's law vs theory, law wins. Unlike theory, the law doesn't have to make sense but you sure as hell better be able to show that you attempted to comply with it.
Thanks -- I did watch the presentation (http://news.ycombinator.com/item?id=420974) and I get how ACLs could be heavyweight and inflexible -- what I'm looking for are some concrete examples of how else people do it.
For example, does Ruby on Rails offer some framework for dealing with this? Or is it a 'just do it' kind of thing? Maybe it's not as complicated as I'm imagining it could be, and that's the point. But some example code would be good to look at.
I'll look into this further but thought I'd solicit here first.
His comment about it turning into 500 lines of code isn't an exaggeration, most likely. The truth is that it's so simple that one can hardly understand why anyone uses ACLs after you've implemented something like this. You create a series of functions that define the attributes you are interested in, there's some lightweight context maintenance, then in the core of the system (the "500 lines") you simply tie all the pieces together in accordance with the business rules. It's so simple it almost boggles the mind. Bog-standard refactoring will get you there in nothing flat, and of course you have full Turing-complete language constructs at your disposal.
One hint: Write the code in a functional style, i.e., Haskell style. Pass in the full context to the permission function. For instance, if you have a time-sensitive function, don't have the time-sensitive function call the system clock; have it extract the time from the context your provided. If you call the system clock, you'll never be able to write the tests you're going to need to write. Similarly for many things, like direct LDAP access or whatnot. The internal permission code needs to be a pure function. Fortunately, that doesn't make it any harder to write, even in an OO-based language.
If you want to get really slick because your context has multiple expensive operations like direct LDAP access (although this is a bad idea if you're going to be calling this frequently), you can even create two context implementations, one for testing that simply returns provided values and one that lazily goes out and gets LDAP data or whatever if you need it. Best of all worlds that way.
Thanks. Nice to have a sketch of the thing's structure. It's a finite state machine, where the 'attributes' are the states, and the code is the transition rule.
Test harnesses for this -- hm.