
How We Engineered CMS Airship to Be Simply Secure - CiPHPerCoder
https://paragonie.com/blog/2017/03/how-we-engineered-cms-airship-be-simply-secure
======
BuuQu9hu
Okay, I'll compare and contrast with my own expectations.

First, "simply secure" to me means adopting a capability-security model. CMS
Airship unfortunately appears to not be capability-based. On the other hand,
there's little existing art for designing capability-safe CMSs, and certainly
users aren't ready for capability-safe systems, so perhaps it's for the best.

The usage of PHP, on the other hand, is very disappointing and, in 2017,
inexcusable. (Yes, I know that it started in 2016. It was inexcusable in 2016
too.)

SameSite cookies are cool but not on the standards track, and I'm sick of
Chrome-specific stuff. I also wish to reiterate the standard position that
cookies are terrible and it would have been so nice if HTTP/2 had remembered
to replace them with browser-side identifiers. (Thanks Google.)

libsodium is a great building block.

Ignoring the meta-issue of whether automatic upgrades of this sort of software
are appropriate, the "Keyggdrasil" update system appears to have been
thoughtfully designed.

ACLs are the great antipattern of our time. I hope that capabilities will
eventually end the crime of ACLs. It's fine if you disagree with this point,
but please read
[http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf](http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf)
and then consider whether you still disagree.

Thoughtful engineering continues to be a theme with programming tools meant to
help programmers write secure code by default. The POST fields, the ACL
design, etc. suggest certain patterns which probably do improve code quality
in their users' systems.

The design of the file uploader is good, and it strikes close to a capability-
security concept; the file system is a great example of _ambient authority_ ,
which grants too much power to applications. Removing that root file system
access is important.

Finally, treating DDoS as a security issue is an interesting step. I've been
treating it as an economic problem personally.

Summary: Well-engineered compared to its competitors, but falls far short of
my ridiculously high expectations.

~~~
CiPHPerCoder
> The usage of PHP, on the other hand, is very disappointing and, in 2017,
> inexcusable. (Yes, I know that it started in 2016. It was inexcusable in
> 2016 too.)

No, it's really not.

[https://dev.acquia.com/podcast/69-php-secure-it-if-you-do-
it...](https://dev.acquia.com/podcast/69-php-secure-it-if-you-do-it-right-
anthony-ferrara)

Until someone produces concrete evidence that proves the statement "It is
impossible to write secure PHP code", I tend to issue a challenge to these
sentiments and then discard them.

Furthermore, if it is currently impossible to write secure PHP code, then
that's a problem that needs to be fixed. Over 82% of the Internet runs PHP.
Fixing the language would be an enormous win.

Alternatively, if it's not impossible to write PHP code, then it's not
"inexcusable" to write software in PHP.

> First, "simply secure" to me means adopting a capability-security model. CMS
> Airship unfortunately appears to not be capability-based. On the other hand,
> there's little existing art for designing capability-safe CMSs, and
> certainly users aren't ready for capability-safe systems, so perhaps it's
> for the best.

> ACLs are the great antipattern of our time. I hope that capabilities will
> eventually end the crime of ACLs. It's fine if you disagree with this point,
> but please read
> [http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf](http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf)
> and then consider whether you still disagree.

Capabilities seem more appropriate in a distributed system (Tahoe-LAFS comes
to mind). ACLs are great for a centralized system (one website, many
visitors).

Otherwise, you've just turned an O(n) maintenance burden into an O(n^2)
maintenance burden by having an explicit and pedantic whitelist of permissions
copied and pasted across every user in the system. This doesn't seem to offer
any value if most (99.99%) of your users will have the same set of
permissions.

I'd like to think, given the sort of software Airship is, ACLs are more
appropriate. Furthermore, it's much simpler to maintain.

I'd also like to think that, given the flexibility of our ACL system (role-
based or user-based, whitelist, overlapping contexts, per-site action matrix)
that we reach a good balance of security and usability.

Maybe I'm failing to see it, but what is the tangible security gain of
capabilities over ACLs to an open source content management system written in
a scripting language behind a single webserver?

Or more to the point: What is the threat model in which capabilities are more
appropriate than ACLs for such a software project?

Or is the answer something to the tune of, "It's more explicit and easier to
formally verify in an academic context?" It's okay if it is, I just want to
know.

> Summary: Well-engineered compared to its competitors, but falls far short of
> my ridiculously high expectations.

Heh, I'll take that as a compliment.

