Question re: Origin Based Security Model (FEP-fe34)
-
We also got the same type of vulnerability reports. Good that you bring it up, because I wasnt aware of the FEP.
To answer your question we can look at it the other way. Imagine we implement a way to federate admin/moderator status and then check it for every incoming mod action. First of all we get problems with older platforms which dont implement this feature yet, it means all their mod actions will be rejected and we end up with spam. Or we add a way to bypass the check, then the whole security feature becomes pointless.
Even if we assume that all platforms correctly federate the admin/mod status, there would still be problems. Federation is not perfect, sometimes things get lost. Or someone gets appointed as admin and immediately removes some spam. At this point the admin status is not federated yet (if its part of the user profile and only updated every 24h). Then again valid mod actions are rejected and we end up with spam that is not deleted.
On the other hand, whats exactly is the exploit here? Some platform lets a normal user (no admin/mod rights) send Update or Delete activites for another user on the same instance. That is clearly not our problem, but its a problem of the remote platform which allows such actions. Besides it cannot affect users from other instances so the impact would be very limited.
Overall, adding such stricter checks would create more problems than it solves.
-
R relay@relay.an.exchange shared this topic
-
Well, yeah, that's why I linked what T&S is doing here to fix the moderator use case. At present I don't know of anyone sending cross-actor delete/update actions, so we'd be adding capability with the
moderatedBy -
Well, yeah, that's why I linked what T&S is doing here to fix the moderator use case. At present I don't know of anyone sending cross-actor delete/update actions, so we'd be adding capability with the
moderatedBy@thisismissem hmm, I believe Lemmy and Piefed send cross actor Deletes, but they might be Announces by the group actor.
They (and I) don't use
moderatedBybut rather the group actor'sattributedToJust want to make sure you're aware of that existing prior art.
-
@thisismissem hmm, I believe Lemmy and Piefed send cross actor Deletes, but they might be Announces by the group actor.
They (and I) don't use
moderatedBybut rather the group actor'sattributedToJust want to make sure you're aware of that existing prior art.
@nutomic@lemmy.ml @rimu@piefed.social @bent0_b0x@norden.social — do y'all send
Deleteactivities with the moderator actor?(Announce wrapping aside.)
-
@nutomic@lemmy.ml @rimu@piefed.social @bent0_b0x@norden.social — do y'all send
Deleteactivities with the moderator actor?(Announce wrapping aside.)
Yes.
This is easy in FEP 1b12-land because each community has a list of moderators so receiving instances know who to allow.
Getting a list of instance admins requires calling the Lemmy API, unfortunately. So PieFed has a cron job that does that once per day for all instances. Admins rarely change.
-
Yes.
This is easy in FEP 1b12-land because each community has a list of moderators so receiving instances know who to allow.
Getting a list of instance admins requires calling the Lemmy API, unfortunately. So PieFed has a cron job that does that once per day for all instances. Admins rarely change.
> @rimu@piefed.social said:
>
> Getting a list of instance admins requires calling the Lemmy API, unfortunately.Wait, why don't we write a mini FEP to extend this?
attributedToon the instance/application actor? -
> @rimu@piefed.social said:
>
> Getting a list of instance admins requires calling the Lemmy API, unfortunately.Wait, why don't we write a mini FEP to extend this?
attributedToon the instance/application actor?That sounds fine to me.
On communities the moderators are just an array of strings which are the activitypub actor IDs of the mods. I think NodeBB has an array of actor objects though?
Anyway whatever it is, consistency with how the communities do it would be nice.
-
That sounds fine to me.
On communities the moderators are just an array of strings which are the activitypub actor IDs of the mods. I think NodeBB has an array of actor objects though?
Anyway whatever it is, consistency with how the communities do it would be nice.
> @rimu@piefed.social said:
>
> I think NodeBB has an array of actor objects thoughIs this causing problems for you? I can send just the IDs instead.
-
> @rimu@piefed.social said:
>
> I think NodeBB has an array of actor objects thoughIs this causing problems for you? I can send just the IDs instead.
It's fine, I've already adjusted the code at my end. I don't know about Lemmy though.
-
Yes.
This is easy in FEP 1b12-land because each community has a list of moderators so receiving instances know who to allow.
Getting a list of instance admins requires calling the Lemmy API, unfortunately. So PieFed has a cron job that does that once per day for all instances. Admins rarely change.
Lemmy doesnt even federate admin status in any way, instead we trust that actions which are coming from the same instance as the community or post are valid. So essentially origin-based security model.
-
It's fine, I've already adjusted the code at my end. I don't know about Lemmy though.
Looks like this, only IDs: https://github.com/LemmyNet/lemmy/blob/main/crates/apub/apub/assets/lemmy/collections/group_moderators.json
-
Looks like this, only IDs: https://github.com/LemmyNet/lemmy/blob/main/crates/apub/apub/assets/lemmy/collections/group_moderators.json
Right, that's the "Group Moderation" section of FEP 1b12, right?
It may be a good idea to extend this concept to the instance/application actor as well. There's no urgent need to implement and consume, but it would be fairly simple thing to serve on our respective softwares I think.
-
Right, that's the "Group Moderation" section of FEP 1b12, right?
It may be a good idea to extend this concept to the instance/application actor as well. There's no urgent need to implement and consume, but it would be fairly simple thing to serve on our respective softwares I think.
Yes exactly that FEP. Federating admin status would make sense for informational purposes, but rejecting mod actions based on that could cause problems as I mentioned in my previous comment.
-
Yes exactly that FEP. Federating admin status would make sense for informational purposes, but rejecting mod actions based on that could cause problems as I mentioned in my previous comment.
> @nutomic@lemmy.ml said:
>
> but rejecting mod actions based on that could cause problems as I mentioned in my previous comment.So to confirm then, you serve the moderator collection but you don't use it to determine whether an actor is able to modify/delete content on that instance, is that right?
Curious to know what those problems are.
-
> @nutomic@lemmy.ml said:
>
> but rejecting mod actions based on that could cause problems as I mentioned in my previous comment.So to confirm then, you serve the moderator collection but you don't use it to determine whether an actor is able to modify/delete content on that instance, is that right?
Curious to know what those problems are.
We use the moderator collection. But if that fails we check if the mod is from the same instance as the community or the post/comment being removed. If thats true we also allow the action.
