Developer of ActivityPub-based micro-blogging and content subscription platform Mitra. I help maintain the FEP repository and write my own FEPs too. Currently working on ActivityPub Next.
Developer of ActivityPub-based micro-blogging and content subscription platform Mitra. I help maintain the FEP repository and write my own FEPs too. Currently working on ActivityPub Next.
Co-Founder (NodeBB) | Husband 🤷♂️ and Dad 🙉 to three | Rock Climber 🧗♂️ | Foodie 🥙 | Conductor 🎵 | Saxophonist 🎷 ✅ Small teams craft better code. 🇨🇦 Made in Canada 🗨️ Federating NodeBB with funding from NLNet ♥️🇪🇺
FEP-baf5: Administrator Collection
Co-Founder (NodeBB) | Husband 🤷♂️ and Dad 🙉 to three | Rock Climber 🧗♂️ | Foodie 🥙 | Conductor 🎵 | Saxophonist 🎷 ✅ Small teams craft better code. 🇨🇦 Made in Canada 🗨️ Federating NodeBB with funding from NLNet ♥️🇪🇺
Question re: Origin Based Security Model (FEP-fe34)
I received a security vulnerability report regarding NodeBB’s handling of Update and Delete activities.
tl;dr
NodeBB implementes FEP fe34, and treats Update and Delete activities as valid if the activity’s actor and the object’s attributedTo differ but the origins are identical. e.g. @alice@example.org is allowed to federate Delete(Note) on @bob@example.org’s Note. The origin-based security model allows for moderator-style actions (third-party post editing and deletions) in the absence of explicit moderator claims. The reporter disagrees that this should be allowed.
Are they right? […]
I responded that FEP fe34 allows for this behaviour because we do not have ready access to an instance’s admin or moderator list. By conducting same-origin checks and allowing Update and Delete through for same-origin (but different identifier), we allow for moderators to federate their actions across instances.
Their response:
I respectfully disagree that FEP-fe34 permits this behavior. Below are direct quotes from the specification that contradict your assessment.
ActivityPub spec (quoted in FEP-fe34 Rationale, Section 7.3 Update Activity):
▎ “The receiving server MUST take care to be sure that the Update is authorized to modify its object. At minimum, this may be done by ensuring that the Update and its object are of same origin.”
Note: “at minimum” means same-origin is the floor, not the ceiling. Authorization must still be verified.
- FEP-fe34 — Authorization > Ownership:
▎ “The actor that creates an object MUST be its owner.”
▎ “The owner of an object is permitted to modify and delete it.”
▎ “Update and Delete activities, and objects indicated by their object property are expected to have the same owner.”
“Same owner” means the same specific actor — not any actor on the same domain.
I responded back with the following:
“The actor that creates an object MUST be its owner.”
Correct, the creator must be an owner, no impersonation allowed.
“The owner of an object is permitted to modify and delete it.”
A strict reading of this does not preclude the ability of a same-origin moderator to modify and delete the object. This is my argument.
“Update and Delete activities, and objects indicated by their object property are expected to have the same owner.”
Again, “expected to” does not rise to the level of MUST.
I agree out of principle that the security implications exist, but if you follow through with the exploit, it requires a non-compliant server to allow users to publish Update and Delete for other users on the same instance, and even then the exposure is limited to users of that origin only (e.g. your server cannot arbitrarily delete my posts). This is the foundation of the Origin-based security model.
So we are at an impasse as to whether my strict reading of the FEP is adherent to the spirit of the FEP itself. Here’s where you come in… do you agree with me, or the reporter?
Directly tagging @silverpill@mitra.social (as FEP author), @trwnh@mastodon.social and @evan@cosocial.ca (both subject matter experts) for their thoughts.
LAUTI is your open source community calendar and offers you a non-commercial independent organizing platform. Invite friends, groups and places and let them fill the site with their events. Use it for independent calenders for cities or regions, for political and cultural events, demonstrations, activism, special interest communities and everything else you can imagine. Maintained by @klasse_methode With support from @NGIZero and @nlnet
Developer of ActivityPub-based micro-blogging and content subscription platform Mitra. I help maintain the FEP repository and write my own FEPs too. Currently working on ActivityPub Next.
FEP-8b32 (Object Integrity Proofs) is getting updated: https://codeberg.org/fediverse/fep/pulls/839
I added two new requirements:
- Objects identified using fragment IDs SHOULD NOT have integrity proofs. It is enough to secure the top-level document.
- Verifiers SHOULD ignore proofs that use unsupported algorithms and verification methods. This requirement provides forward compatibility, which is important because sooner or later we will need to use different algorithms.
Welcome social coder, To this self benefit center, Where we earn #socialweb. Concept is simple.. Bring something of value, Others make it grow, You self-benefit, Our synergies flow.. Commons 💕 unite! Participate in our channels, Reach out, embrace others, Follow passions and dreams, #Dreamwalk bright future, To realize them.. Invest in #SX now! Gift one 🪙 of #humanity, Earn 🪙🪙 cts of #freedom.. 💃🕺 #peopleverse shall rise! CC BY-NC-SA, Humane tech community.
~ Kissed by a rose on the grey ~ Warrior / struggling / to remain / consequential (In my Raspberry Heaven〜)
Developer of ActivityPub-based micro-blogging and content subscription platform Mitra. I help maintain the FEP repository and write my own FEPs too. Currently working on ActivityPub Next.
You've seen all posts