Does the instance actor have special privileges?
-
Just something I noticed while testing non-public posts... when I try to message @[email protected], sharkey tries to grab the
inReplyTo, but it attempts to do so with the instance actor, which obviously doesn't have access to the chat.Feels like a Sharkey bug, but I also noticed this behaviour when I tried to use @[email protected]'s activitypub.academy... using the search bar (and the explorer) caused the request to be made with the instance actor.
So now I'm not even sure what to think.
-
@julian @jdp23 @crepels Using the "instance actor" as a proxy is a common practice because a lot of softwares don't want to leak who exactly is making the request.
This, combined with the fact that anyone with control of the server running on a given domain can technically do whatever they want with keys, is a strong reason why access control tends to be origin-based instead of actor-based.
-
silverpillreplied to julian on last edited by [email protected]
@julian @crepels @jdp23 @jdp23 It is not special, but it has same origin as person-actor. If you accept origin-based security model, there is little practical difference, and you can grant access to an instance actor or to any other actor on that server.
-
@[email protected] @[email protected] hmm, I don't think I like that for this use case.
Especially within the context of limited visibility objects that are scoped to specific users, allowing just anybody from the same origin to access that object seems like a security violation.
I can see the case for allowing the instance actor access to it, but even then it gives me pause.
cc @[email protected] for her thoughts.
-
I'd feel safer if Sharkey, et al. were to attempt the request with the instance actor (to preserve privacy), but failing that, make the request with the expected user id.
@[email protected] I'm assuming there's precedent for proxying the request for privacy, but the tradeoff doesn't add up for me.
-
@julian
I'd feel safer if Sharkey, et al. were to attempt the request with the instance actor (to preserve privacy), but failing that, make the request with the expected user id.
That is what Hubzilla does... -
Emelia 👸🏻replied to julian on last edited by [email protected]
@julian @silverpill @trwnh I think instance-actor based fetching only really makes sense for public objects?
AP does indeed rely on a same-origin security model though, afaik, because they didn't wanna get into ACLs (which solid eventuality ended up with two of: WebACL and ACP)
-
@thisismissem @julian @silverpill @trwnh I believe that Mastodon implemented this for privacy reasons, but I honestly think using the users actual actor here would be preferable. How else do you establish visibility?
-
@thisismissem @julian @silverpill @trwnh it feels like one of those things where a poorly thought out privacy feature creates a functionality problem to me
-
@julian @silverpill @thisismissem @trwnh anyway given everyone does authorisation based upon exact actor match (the only really reasonable approach) I think the only reasonable approach is to use the authenticated user for fetches so they can see the posts they’re supposed to be able to
-
@julian @trwnh @thisismissem Server operators can read all private messages. Strict ID check is not completely useless, because it might prevent leaks in case of a software bug, but it doesn't provide any additional security guarantees
-
@[email protected] said in Does the instance actor have special privileges?:
Strict ID check is not completely useless, because it might prevent leaks in case of a software bug, but it doesn't provide any additional security guarantees
I soft disagree, because the instance actor being a admin-level "server operator" actor is — by my understanding — a convention, not a requirement. In those cases, you could run head-first into a gotcha that exposes something you did not want exposed.
I treat the resolved actor via HTTP signature to be like an API token, it's basically a fancy password! I like to operate on the principle of least privilege, and so that's why I'm raising a flag about this at all. It's very likely I could be ignorant of established best practices regarding the instance actor.
-
infinite love ⴳreplied to Erin 💽✨ @38C3 on last edited by
@erincandescent @julian @thisismissem @silverpill WWW-Authenticate + Authorization?
-
infinite love ⴳreplied to Erin 💽✨ @38C3 on last edited by
@erincandescent @julian @thisismissem @silverpill Mastodon I think considered the idea of trying first with the instance proxy key and then if that failed try again with your key.
This makes it better from a usability perspective but the security qualities are just as lacking as before. The server could theoretically try with any/every user’s key. You end up having to put a lot of trust in the server anyway, so you fall back to having origin-based security anyway…
-
@silverpill @thisismissem @julian Yeah, it raises the bar very slightly to say that instead of any key on a domain, you need to use a specific key id on the domain. But it could be the same key material, and that wouldn’t even hurt security meaningfully.
-
@[email protected] I opened the issue in the Sharkey repo and received a response that is along the lines of what was discussed here:
For privacy, Sharkey (and all other Misskey forks) fetch unknown posts using the instance.actor account. This works for public posts, but breaks for followers-only / direct messages.
...
Any "simple" fix would allow remote instances to de-anonymize local users, which is the same vulnerability that Mastodon has had for years.Which is fair. I was thinking that one could simply assume that the recipients of the received object would be an identical set of subset of
inReplyTo, but that is not a guarantee at all! -
> treat the resolved actor via HTTP signature to be like an API token, it's basically a fancy password!
yup, exactly. imagine if we used out-of-band bearer tokens. same principle. same with DPoP. the keys are all custodial in most cases. any “security” comes from the bidirectional link between actor and key (and it’s not much, but it’s barely enough to establish an identity at all)
-
End of the day we're talking about machines talking to other machines. I can see potential privacy concerns, but it seems like it would be hard to utilise as a malicious actor... but I've no opsec expertise.
@[email protected] @[email protected] @[email protected] @[email protected]
-
@julian @silverpill @erincandescent @thisismissem Security-wise all bets are off if you want to establish anything other than “the signature claims to be from this key, and the key claims to be owned by this actor, and the actor links back to the same key, so we can assume the actor’s controller is the signing party”
note that i said “actor’s controller” and not just “actor”. this is an important distinction. just like web keys are custodial, web actors are custodial too
-
Erin 💽✨ @38C3replied to infinite love ⴳ on last edited by@trwnh @julian @silverpill @thisismissem fundamentally trust lies in the server here; if you're not using LD signatures (and maybe even then?) I'm pretty sure you'd actually be fine to use one public key for every user
But what matters is the authorisation identity, not so much the key itself; in the fully general case it is impossible for a server to know everyone who should have access to a third party object (b/c BTo/BCC + implementation defined features), so when a user explicitly requests a resource then the server should use their identity
