localhost_frssoft
/
ocappub
mirror of https://gitlab.com/spritely/ocappub.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

instances and ACLs

This commit is contained in:
Christopher Lemmer Webber 2019-07-18 16:37:33 -04:00
parent affeb7885f
commit 15fc950a42
No known key found for this signature in database
GPG Key ID: 4BC025925FF8F4D3
1 changed files with 151 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

151
README.org
View File

@ -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