You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@casbin.apache.org by "Eh2406 (via GitHub)" <gi...@apache.org> on 2026/09/28 20:44:24 UTC
[I] rejected mutation still authorizes grants [casbin-rs]
Eh2406 opened a new issue, #426:
URL: https://github.com/apache/casbin-rs/issues/426
Hi,
I am Co-Lead of the Rust Cargo Team and was recently hired by the Rust Foundation to help triage AI discovered bugs. This bug was found with AI, namely scrutineer and Fable. Except where specifically labeled this report was written by me. I am posting this as a public issue as I have not received a response to our attempts to reach out on https://security.apache.org/report-code/, by email, and on your discord.
From the AI:
> ## Summary
>
> Phantom role grants from rejected grouping mutations. With the default `incremental` feature enabled, the internal grouping-policy mutators replay role-link additions and removals even when the model reports that the requested mutation was rejected. This creates authorization state that disagrees with the policy table, adapter, watcher events, cache invalidation, and the API's returned result.
>
> ## Impact
>
> An authenticated lower-privileged user who can reach an application-provided policy-mutation route can create a live, unlisted role grant by submitting a batch containing one duplicate rule and one new attacker-controlled rule. The same class of mismatch can silently revoke another user's live role link while the corresponding policy row remains visible. The phantom state affects enforcement until `load_policy()` or a process restart rebuilds role links.
>
> ## Proof of concept
>
> Create an integration test using the repository's RBAC example model and policy, then run it with the default features:
>
> ```rust
> use casbin::prelude::*;
>
> #[tokio::test]
> async fn phantom_role_grant() {
> let mut enforcer = Enforcer::new(
> "examples/rbac_model.conf",
> "examples/rbac_policy.csv",
> )
> .await
> .unwrap();
>
> assert!(!enforcer.enforce(("mallory", "data2", "read")).unwrap());
>
> let changed = enforcer
> .add_grouping_policies(vec![
> vec!["alice".into(), "data2_admin".into()],
> vec!["mallory".into(), "data2_admin".into()],
> ])
> .await
> .unwrap();
>
> assert!(!changed);
> assert!(!enforcer
> .get_grouping_policy()
> .iter()
> .any(|rule| rule[0] == "mallory"));
> assert!(enforcer.enforce(("mallory", "data2", "read")).unwrap());
> }
> ```
>
> ```console
> cargo test --features logging,explain --test poc_internal_api -- --nocapture --test-threads=1 poc_phantom_grant_batch_add
> ```
>
> The verified run returned `false` from `add_grouping_policies`, showed no `mallory` rule in `get_grouping_policy()`, and nevertheless changed `enforce(("mallory", "data2", "read"))` from `false` to `true`. If you rerun the test with `--no-default-features` made the final assertion fail, isolating the defect to incremental role-link replay.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@casbin.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@casbin.apache.org
For additional commands, e-mail: commits-help@casbin.apache.org
Re: [I] rejected mutation still authorizes grants [casbin-rs]
Posted by "hsluoyz (via GitHub)" <gi...@apache.org>.
hsluoyz commented on issue #426:
URL: https://github.com/apache/casbin-rs/issues/426#issuecomment-6082788015
fixed in: https://github.com/apache/casbin-rs/commit/ec23250c21a3e30cf1c7c863bbdf1c9b0e21ca98
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@casbin.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@casbin.apache.org
For additional commands, e-mail: commits-help@casbin.apache.org
Re: [I] rejected mutation still authorizes grants [casbin-rs]
Posted by "hsluoyz (via GitHub)" <gi...@apache.org>.
hsluoyz closed issue #426: rejected mutation still authorizes grants
URL: https://github.com/apache/casbin-rs/issues/426
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@casbin.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@casbin.apache.org
For additional commands, e-mail: commits-help@casbin.apache.org
Re: [I] rejected mutation still authorizes grants [casbin-rs]
Posted by "Eh2406 (via GitHub)" <gi...@apache.org>.
Eh2406 commented on issue #426:
URL: https://github.com/apache/casbin-rs/issues/426#issuecomment-5878409285
I have a separate finding that I think has the same root cause.
> ## Summary
>
> Batch role revocation can leave revoked roles authorizing. A self-referential grouping row is ignored when links are added but rejected when links are deleted. During an incremental batch revocation, that error occurs after policy rows have been removed and aborts unlinking later rules, leaving the policy model and role graph inconsistent.
>
> ## Impact
>
> An authenticated, lower-privileged user who can create or edit grouping policies can plant an inert self-referential row. If an administrator later includes that row before a real grant in a batch revocation and the application does not reload the complete policy after the error, the later role remains active even though its policy row is gone; retries no-op, so a revoked administrative role can continue authorizing access.
>
> ## Proof of concept
>
> Using the crate's shipped RBAC model and policy, add a self-referential grouping row and then revoke it before a real role assignment in one batch:
>
> ```rust
> #[tokio::test]
> async fn batch_revocation_leaves_role_active() {
> use casbin::prelude::*;
>
> let mut enforcer = Enforcer::new(
> "examples/rbac_model.conf",
> "examples/rbac_policy.csv",
> )
> .await
> .unwrap();
>
> enforcer
> .add_grouping_policy(vec!["mallory".into(), "mallory".into()])
> .await
> .unwrap();
>
> let result = enforcer
> .remove_grouping_policies(vec![
> vec!["mallory".into(), "mallory".into()],
> vec!["alice".into(), "data2_admin".into()],
> ])
> .await;
>
> println!("remove_grouping_policies -> {result:?}");
> println!("g = {:?}", enforcer.get_grouping_policy());
> println!("roles = {:?}", enforcer.get_roles_for_user("alice", None));
> println!(
> "allowed = {:?}",
> enforcer.enforce(("alice", "data2", "read"))
> );
> }
> ```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@casbin.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@casbin.apache.org
For additional commands, e-mail: commits-help@casbin.apache.org