instances and ACLs

2024-11-26 15:13:02 +00:00 · 2019-07-18 16:37:33 -04:00 · 2019-07-18 16:37:33 -04:00 · 15fc950a42
commit 15fc950a42
parent affeb7885f
1 changed files with 151 additions and 0 deletions
--- a/README.org
+++ b/README.org
@ -412,9 +412,160 @@ structurally insufficient to be the /foundation/ of our approach.
    -- Marc Stiegler, [[http://www.skyhunter.com/marcs/ewalnut.html][E in a Walnut]]
 #+END_QUOTE
 Part of the major narrative of the federated social network at the
 moment is that running an instance is an excellent opportunity to host
 and support a community, maybe of people like you or people you like.
 Different rules may apply differently on different instances, but
 that's okay; choose an instance that matches your personal philosophy.
 So you run an instance.
 On your instance, maybe some bad behavior happens from some users.
 You begin to set up policies.
 You perhaps even ban a user or two.
 But what about bad behavior that comes from the outside?
 This is a federated social network, after all.
 Blocking a user is fine.
 Blocking an instance or two is fine.
 But what happens when anyone can spawn a user at any time?
 What happens when anyone can spawn an instance at any time?
 Self-hosting, which originally seemed like something to aspire
 to, becomes a threat to administrators; if anyone can easily spawn
 an instance, host administrators and users are left playing
 whack-a-mole against malicious accounts.
 It seems like our model is not set up to be able to handle this.
 Soon enough, you are tired of spending all your free time
 administrating the instance blocklist.
 You begin to set up the ability to share automatic blocklists between
 friends.
 But the governance of these lists seems fraught at best, and prone
 to in-fighting.
 Worse yet, you seem to have improperly gotten on several blocklists
 and you're not sure how.
 The criteria for what is and isn't acceptable behavior between
 instances varies widely, and it's unclear to what extent it's worth
 appealing.
 It dawns on you: the easier approach isn't a deny-list, it's an
 allow-list (aka a whitelist).
 Why not just trust these five nodes?
 It's all you have energy for anymore.
 Except... what if you aren't one of the five major nodes?
 Suddenly you see that other nodes are doing the same thing, and
 people are de-federating from /you/.
 It's not worth running a node anymore; if you aren't on one of the top
 five... hold up... top three instances anymore, nobody gets your
 messages anyway.
 This is the "nation-state'ification of the fediverse", and it results
 in all the xenophobia of nation-states traditionally.
 Sure, border guards as a model on the fediverse aren't as bad as
 in the physical world; they can't beat you up, they can't take your
 things (well, maybe your messages), they can't imprison you.
 And yet the problem seems similar.
 And it's only going to get worse until we're back at centralization
 again.
 A fundamental flaw occurred in our design; we over-valued the role
 that instances should play /altogether/.
 While there is nothing wrong with blocking an instance or two, the
 network effect of having this be the foundation is re-centralization.
 Furthermore, it doesn't even reflect human behavior; few people
 belong to only one community.
 Alice may be a mathematics professor at work, a fanfiction author
 in her personal time, and a tabletop game enthusiast with her friends.
 The behaviors that Alice exhibits and norms of what is considered
 acceptable may shift radically in each of these communities, even if
 in all of these communities she is Alice.
 This isn't duplicitous behavior, this is normal human behavior,
 and if our systems don't allow for it, they aren't systems that
 serve our users' needs.
 But consider also that Alice may have one email account, and yet may
 use it for all three of these different communities' email mailing
 lists.
 Those mailing lists may be all on different servers, and yet Alice
 is able to be the right version of Alice for each of those communities
 as she interacts with them.
 This seems to point at a mistake in assumptions about the federated
 social web: the instance is not the community level, because users
 may have many varying communities on different instances, and each
 of those instances may govern themselves very differently.
 So far the problems with "perimeter security" described above have
 been examples restricted to the social level.
 As it turns out, perimeter security has another problem when we start
 thinking about authorization called the "confused deputy problem".
 For example, you might run a local process and consider that it
 is localhost-only.
 Whew!  Now only local processes can use that program.
 Except now we can see how "perimeter security" is "eggshell security"
 by how easy it is to trick another local program to access resources
 on our behalf.
 An excellent example of this where
 [[https://lists.gnu.org/archive/html/guile-user/2016-10/msg00007.html][Guile's live-hackable REPL suffered a remote execution vulnerability]].
 Except... Guile didn't appear to "do anything wrong", it restricted
 its access to localhost, and localhost-only.
 But a browser could be tricked into sending a request with code that
 executed commands against the localhost process.
 Who is to blame?
 Both the browser and the Guile process appeared to be following
 their program specifications, and taken individually, neither seemed
 incorrect.
 And yet combined these two programs could open users to serious
 vulnerability.
 Perimeter security is eggshell security.
 And the most common perimeter check of all is an identity check,
 the same paradigm used by Access Control Lists.
 It turns out these problems are related.
 *** Access Control Lists
 Up until recently, if you drove a car, the car did not determine
 whether you could drive it based on who you are, as your identity.
 If you had a key, you could drive it, and it didn't matter who you
 were.
 Nonetheless, since Unix based its idea of authority on "who you are",
 this assumption has infected all of our other systems.
 This is no surprise: people tend to copy the models they have been
 exposed to, and the model that most programmers are exposed to is
 either Unix or something inspired by Unix.
 But Unix uses ACLs (Access Control Lists), and ACLs are
 [[http://waterken.sourceforge.net/aclsdont/current.pdf][fundamentally broken]].
 In no way do Access Control Lists follow the
 [[https://en.wikipedia.org/wiki/Principle_of_least_privilege][Principle of Least Authority (PoLA)]], which is necessary for users
 to be able to sensibly trust their computing systems in this modern
 age.
 To be sure, we need authentication when it is important to know that a
 certain entity "said a particular thing", but we need to know that
 this is not the same as knowing whether a particular entity "can do a
 certain thing".
 Mixing up authentication with authorization is how we get ACLs,
 and ACLs have serious problems.
 For instance, consider that Solitaire (Solitaire!) can steal all your
 passwords, cryptolocker your hard drive, or send email to your friends
 and co-workers as if it were you.
 Why on earth can Solitaire do this?
 All the authority it needs is to be able to get inputs from your
 keyboard and mouse when it has focus, draw to its window, and maybe
 read/write to a single score file.
 But Solitaire, and every other one of the thousands of programs on
 your computer, has the full authority to betray you, because it has
 the full authority to do everything you can... it /runs as you/.
 And that's not even to mention that ACLs are subject to the same
 confused deputy problems as discussed in the previous section.
 In this paper we'll lay out how ocaps can accomplish some amazing
 things that ACLs could never safely do... because [[http://waterken.sourceforge.net/aclsdont/current.pdf][ACLs Don't]].
 *** Content-centric filtering
 *** Reputation scoring