Pith. sign in

REVIEW 4 major objections 6 minor 1 cited by

Quantifying Azure RBAC Wildcard Overreach

T0 review · 4 major / 6 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Belshazaar computes exact effective permission sets for Azure RBAC wildcards and shows that about half of all actions can be extended across resource providers by non-obvious wildcard placements.

desk verdict The compiler is real; the 50% headline is a lower-bound measurement from a genetic algorithm that the abstract overstates, and the grammar's fidelity to Azure's actual wildcard matching is unvalidated. read the letter →

arxiv 2506.10755 v3 pith:SQ3CDYV6 submitted 2025-06-12 cs.CR

Christophe Parisel This is my paper · ORCID
classification cs.CR
keywords AzureRBACwildcardpermissionseffectivepermissionsetcontext-freegrammarultrametricdistanceleastprivilegebloatpolicyanalysis
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper tries to establish that Azure RBAC wildcard permission patterns can be precisely expanded rather than guessed at, and that doing so reveals systematic overreach: about half of Azure actions can be paired with non-obvious wildcards that reach across resource providers. If this is right, security teams can replace dangerous wildcards with explicit permission lists, quantify how much a wildcard over-approximates, and catch privilege bloat before deployment. The argument is carried by a grammar of Azure action syntax and a tree-based distance metric that measures how far a wildcard's expansions spread.

What carries the argument

The central object is a context-free grammar over three tokens: TEXT, SLASH, and WILDCARD, whose production rules define valid Azure action strings with at most one wildcard and a final segment restricted to read, action, write, delete, or a wildcard. The compiler turns each wildcard pattern into a normalized regular expression, so a wildcard denotes a regular language over the action catalog; subtracting the expanded NotActions languages from the expanded Action language yields the effective permission set. Overreach is measured by an ultrametric distance $d(u,v)=\mathrm{depth}(\mathrm{LCA}(u,v))$ on the tree whose levels are providers, subproviders, resource types, and action verbs, with the diameter of a permission set defined as the minimum distance between any two distinct actions in it; smaller diameters mean the wildcard's expansions spread across distant parts of the hierarchy. A genetic algorithm searches wildcard placements for the smallest diameters, producing a lower-bound estimate of how many actions admit cross-provider reach.

What would settle it

Select custom Azure role definitions containing wildcards that violate the model's restrictions—repeated slashes, repeated dots, multiple wildcards, or a final segment outside the allowed verbs—and call Azure's APIs to list the operations each role actually grants; compare that list with Belshazaar's expansion of the same pattern, and any mismatch would show that the claimed exact computation does not hold for real Azure permissions.

Watch

Extended reading notes

Core claim

The paper claims that every Azure RBAC wildcard expression is a sentence in a context-free grammar, and that compiling that grammar yields the exact set of concrete actions the wildcard matches. Given an Action and its NotActions, the effective permission set is computed as $P_{\mathrm{eff}}(A,N)=L(A)\setminus\bigcup_{j=1}^{m}L(n_j)$, where $L$ expands each pattern against the full catalog of 15,481 Azure actions. Applied to that catalog, the expansion shows that roughly half of all actions can be paired by non-obvious wildcards whose matched operations lie in different resource providers (ultrametric diameter 1), while under 3% of wildcard pairs remain within a tightly scoped, least-privilege range (diameter 3 or higher). The paper concludes that wildcards, especially infix wildcards allowed in custom roles, create substantial privilege bloat, and that the exact enumeration of effective permissions makes wildcard removal a feasible, semantics-preserving step.

Load-bearing premise

Everything rests on the grammar and preprocessing rules exactly matching Azure's real wildcard expansion: the model allows at most one wildcard per action, requires the last segment to be read, action, write, delete, or a wildcard, and ignores repeated slashes and repeated dots that Azure in fact permits; if Azure's runtime matching differs in any of these ways, the computed effective permission sets and the 50% cross-provider figure describe the model, not actual Azure permissions.

Editorial extensions

If this is right

  • Any single-wildcard Azure action, together with its NotActions, can be replaced by the explicit list of operations it actually grants, making least-privilege review a mechanical step.
  • Custom roles that place wildcards at infix positions can grant operations spanning multiple resource providers while looking narrowly scoped, and the diameter metric exposes exactly those cases.
  • Because the median expansion diameter is about 1, most non-obvious wildcards are near-maximally spread, and fewer than 3% of wildcard pairs keep permissions within a single least-privilege scope.
  • Wildcards can silently grow when Microsoft adds new actions to a provider, and a compiler that re-expands against an updated catalog lets administrators detect that growth.
  • The same expansion machinery can be embedded in policy-authoring or continuous-monitoring pipelines to flag over-privileged roles before deployment.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If Azure's runtime matching permits repeated slashes, repeated dots, or multiple wildcards in ways the grammar excludes, the true expansion sets are at least as large as those reported, so the 50% cross-provider figure is a lower bound rather than a ceiling.
  • A direct validation would compare Belshazaar's expansions, for sampled custom roles, against the operations returned by Azure's role definition APIs; the paper does not report such a comparison.
  • The ultrametric diameter could be combined with the number of granted actions or the sensitivity of the resource providers involved to produce a risk ranking, a step the paper leaves implicit.
  • The same grammar-and-diameter recipe should transfer to other cloud IAM systems once their action syntaxes are formalized; the paper lists multi-cloud extension as future work, not as a demonstrated result.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper introduces Belshazaar, a two-stage framework for Azure RBAC wildcard analysis. The first stage formalizes Azure action syntax as a context-free grammar and implements a compiler that expands wildcard patterns into explicit action lists using Microsoft's official catalog of 15,481 actions. The second stage defines an ultrametric distance over the hierarchical action namespace and uses the minimum pairwise distance (diameter) of an expanded permission set as a measure of semantic overreach. A genetic algorithm searches for wildcard placements with small diameters; the paper reports that about 50% of catalog actions admit a cross-resource-provider wildcard reach, and that effective permission sets are computable. The paper claims exactness for the expansion and proposes the tool as a way to detect and remediate privilege bloat in Azure roles.

Significance. If the central claims hold, Belshazaar would be a useful contribution to cloud IAM analysis, filling a gap in tooling for Azure RBAC compared with AWS-oriented tools such as Zelkova, Cedar, and IAM Lens. The paper's strengths are its explicit formal grammar, the machine-checked parsing of the full 15,481-action catalog, the open-source implementation with a public data dump of diameters, and the a priori definition of the ultrametric metric with no fitted parameters. The empirical finding, if properly qualified as a lower-bound existence result, is interesting and actionable for security practitioners. However, the exactness claim and the interpretation of the 50% statistic require substantial qualification before the results can be accepted as describing actual Azure behavior.

major comments (4)
  1. [§4.2.1 and footnote 1] The paper's central claim that Belshazaar computes the exact effective permission set for any Azure RBAC wildcard specification (Abstract, §2.2, §8) is not supported by the grammar as defined. Preprocessing rules 3 and 5 restrict inputs to at most one wildcard per action and force the last segment to be read, action, write, delete, or a wildcard, and footnote 1 excludes repeated slashes and repeated dots that Azure permits. No evidence is provided that these restrictions match Azure's runtime wildcard semantics. Because every effective permission set and the subsequent statistics are outputs of this grammar, the exactness claim should either be validated against Azure's authorization engine or explicitly qualified as exact with respect to the modeled grammar.
  2. [§6.3.2 and §6.3.3] The headline statistic that about 50% of actions admit a cross-resource-provider reach is produced by a genetic algorithm explicitly optimized to minimize ultrametric diameter. The paper acknowledges this yields a lower-bound estimate in §6.3.2, but the abstract and §6.3.3 phrase the result as 'about 50%' without consistently carrying the lower-bound qualification. Furthermore, the statement 'about half of all pairs are cross Resource Provider' refers to the GA-generated population of wildcards, not to a measured distribution over wildcards actually used in Azure deployments. The claim should be restated as: for at least roughly 50% of catalog actions, there exists a grammar-valid wildcard whose expansion has diameter 1.
  3. [§4.2.3] The grammar-completeness validation parses all 15,481 explicit, wildcard-free actions, which only demonstrates that the grammar accepts the catalog. It does not test that the compiler's wildcard expansion semantics match Azure's runtime matching behavior. The examples in §4.2.3 (prefix, suffix, infix, and complete wildcards) are illustrative but are not a differential test against Azure's authorization engine. Without such validation, the reverse-engineered wildcard semantics remain a hypothesis, and the exactness claim in §8 is overstrong.
  4. [§5.3] The definition of Diam(P) as min_{u≠v} d(u,v) is clear, but the accompanying interpretation is stated incorrectly: 'Large diameter (small distance between pair of actions) indicates tightly scoped permissions' contradicts the definition, because a large minimum distance corresponds to large pairwise distances, not small ones. This should be corrected so that readers understand that small diameters (e.g., 1) indicate cross-provider overreach and large diameters indicate tightly scoped permissions.
minor comments (6)
  1. [Throughout] There are several typographical errors: 'Substracting' in §5.1, 'exponantial' in §5.2, 'aactions' in the contribution list in §2.2, and 'actions grammar' in §2.2. These should be corrected.
  2. [Figure 1] Figure 1 is referenced in §6.3.3 but no figure appears in the text; please provide the figure or remove the reference.
  3. [Tables 2 and 3] Some entries in Tables 2 and 3 are malformed or contain line breaks within action names (e.g., 'Microsoft.A VS/*/action' and 'Microsoft.ApiCenter/services /apis/...'). Please reformat the tables for readability.
  4. [§3.1] The statement 'All segments are optional' is inconsistent with the grammar, which requires at least one segment, and with preprocessing rule 6 that ignores standalone '*'. Please clarify the segment optionality.
  5. [§4.1] The token definition for WILDCARD is shown as r'\ *'; this appears to be a formatting artifact for r'\*'. Please verify the displayed code.
  6. [§5.2] The distance model treats dots as segment delimiters, while the grammar's TEXT token includes dots as ordinary characters. The relationship between the grammar's segmentation and the ultrametric tree's segmentation should be stated explicitly to avoid confusion.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the grammar, expansion engine, and ultrametric metric are defined a priori against the external Azure action catalog; the 50% figure is an empirical output of that expansion, and the sole self-citation is non-load-bearing.

full rationale

I walked the paper's derivation chain and found no step in which a 'prediction' or 'first-principles result' is equivalent to its inputs by construction. The grammar in Section 4.2 is offered as a reverse-engineered model of Azure action syntax, and the expansion L(w) is defined against the external 15,481-action catalog in Section 5.1; the compiler's effective permission sets are computed by enumerating catalog matches, not by fitting to the headline statistics. The ultrametric distance and diameter (Sections 5.2-5.3) are defined a priori from the hierarchical namespace, and the identification of diameter 1 with cross-Resource-Provider reach follows from the definition of LCA depth; however, whether about 50% of actions admit such a wildcard is an empirical property of the catalog strings and the genetic-algorithm search, not an input to the metric. The only self-citation is to the author's prior ultrametric work [8], which the paper explicitly distinguishes by using a linear rather than an exponential ultrametric and does not invoke to justify the grammar, the expansion, or the prevalence claim. The admitted simplifications (footnote 1: repeated slashes/dots excluded; Section 4.2.1 rules 3 and 5: at most one wildcard and a restricted final segment) mean the 'exact effective permissions for any Azure wildcard' claim may not hold against Azure's real matcher, but that is a correctness or validation gap, not circularity: the paper's outputs are not forced by its inputs through definition, and no fitted parameter is renamed as a prediction. The absence of an external check of wildcard expansion against Azure's runtime engine is a substantive limitation, but it does not make the derivation circular.

Assumptions & free parameters 5 free parameters · 5 assumptions · 0 invented entities

The framework depends on five hand-chosen search and modeling parameters, plus several domain assumptions about Azure's action catalog and wildcard semantics. The empirical percentages in the abstract should be read as lower bounds under these choices, not as measured frequencies.

free parameters (5)
  • Genetic algorithm population size = 40
    Section 6.3.2 fixes 40 individuals per original action. This choice bounds the search space and directly affects which extreme wildcard patterns are found.
  • Genetic algorithm generations = 10
    Section 6.3.2 runs 10 generations. More generations could find additional diameter-1 patterns and raise the 50% estimate.
  • Fitness weight on diameter = 1000
    Fitness f(D,x)=1000*D-x in Section 6.3.2. The 1000 multiplier makes diameter dominate the selection, so the ranking and the reported extreme pairs depend on this hand-chosen scale.
  • Minimum wildcard offset after provider dot = 3 characters
    Section 6.3.1 forbids wildcards starting within 3 characters after the provider dot. This excludes patterns like Microsoft.O*ions and defines what counts as a non-obvious wildcard.
  • Ultrametric depth convention = root=0, providers=1
    Section 5.2 assigns integer depths starting at the root. Diameter values and the 50% threshold depend on this leveling choice; a different convention would shift all distances.
assumptions (5)
  • domain assumption The 15,481-entry action catalog from 'az provider operation list' is a complete representation of the Azure action universe.
    Section 6.3 treats this snapshot as U for all expansions and statistics. Any missing action would make effective permission sets incomplete and the 50% figure a lower bound.
  • domain assumption Azure's runtime wildcard matching matches the grammar's regex semantics, including wildcards spanning one or more segments and infix wildcards matching across dots.
    Section 4.2.2 and 4.2.3 assert this based on a small number of tests. If Azure treats '*' differently, every expansion is wrong.
  • ad hoc to paper Repeated slashes and repeated dots in action strings can be ignored.
    Section 4.2.1 states Azure permits these patterns but the model excludes them 'for simplicity'. This explicitly limits grammar completeness.
  • domain assumption The last segment of an action must be read, action, write, delete, or a wildcard.
    Preprocessing rule 5 in Section 4.2.1. If Azure permits other verb segments, the grammar rejects valid actions.
  • ad hoc to paper The ultrametric min-diameter is a meaningful proxy for security overreach.
    Section 5.3 defines Diam(P) as the minimum pairwise distance and interprets low values as over-approximation without validating against operational impact; Section 7 concedes the tool is syntactic only.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Quantifying Azure RBAC Wildcard Overreach." pith.science (2026). https://pith.science/paper/SQ3CDYV6

@misc{pith2026250610755,
  author       = {Pith},
  title        = {Pith review of: Quantifying Azure RBAC Wildcard Overreach},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/SQ3CDYV6}},
  note         = {Machine review of arXiv:2506.10755}
}
read the original abstract

Azure RBAC leverages wildcard permissions to simplify policy authoring, but this abstraction often obscures the actual set of allowed operations and undermines least-privilege guarantees. We introduce Belshazaar, a two-stage framework that targets both the effective permission set problem and the evaluation of wildcards permissions spread. First, we formalize Azure action syntax via a context free grammar and implement a compiler that expands any wildcard into its explicit action set. Second, we define an ultrametric diameter metric to quantify semantic overreach in wildcard scenarios. Applied to Microsoft s official catalog of 15481 actions, Belshazaar reveals that about 50 percent of actions admit a cross Resource Provider reach when associated with non obvious wildcards, and that effective permissions sets are effectively computable. These findings demonstrate that wildcard patterns can introduce substantial privilege bloat, and that our approach offers a scalable, semantics driven path toward tighter, least-privilege RBAC policies in Azure environments.

Figures

Figures reproduced from arXiv: 2506.10755 by the authors.

Figure 1
Figure 1. Distribution of Diameters 6.3.4 Wide-ranging wildcards Tables 2 and 3 provide a small excerpt of extreme pairs generated by wildcards expansion [PITH_FULL_IMAGE:figures/full_fig_p008_1.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Overprivilege Analysis of Security Policies in Serverless Cloud Applications

    cs.CR 2026-07 conditional novelty 7.0 of 10

    47.7% of 789 real AWS Lambda applications are overprivileged, with 99.65% aggregate privilege-reduction potential and wildcards inflating excess by ~274×.

Reference graph

Works this paper leans on

13 extracted references · 12 canonical work pages · cited by 1 Pith paper

  1. [8]

    Christophe Parisel, Scoring Azure permissions with metric spaces https://arxiv.org/abs/2504.13747

    arXiv

  2. [1]

    J. H. Saltzer and M. D. Schroeder, ”The protection of information in computer systems,” Proceedings of IEEE , vol. 63, no. 9, pp. 1278-1308, 1975

    work page 1975

  3. [2]

    R. S. Sandhu, E. J. Coyne, H. L. Feinstein, and C. E. Youman, ”Role-based access control models,” Computer, vol. 29, no. 2, pp. 38-47, 1996

    work page 1996

  4. [3]

    N. Li, J. C. Mitchell, and W. H. Winsborough, ”Design of a role-based trust-management framework,” Proceedings IEEE Symposium on Security and Privacy , pp. 114-130, 2002

    work page 2002

  5. [4]

    Fisler, S

    K. Fisler, S. Krishnamurthi, L. A. Meyerovich, and M. C. Tschantz, ”Verification and change-impact analysis of access- control policies,” Proceedings International Conference on Software Engineering , pp. 196-205, 2005

    work page 2005

  6. [5]

    Jackson, Software Abstractions: Logic, Language, and Analysis

    D. Jackson, Software Abstractions: Logic, Language, and Analysis . MIT Press, 2012

    work page 2012

  7. [6]

    Hopcroft, R

    J. Hopcroft, R. Motwani, and J. Ullman, Introduction to Automata Theory, Languages, and Computation, 3rd ed. Pearson, 2006

    work page 2006

  8. [7]

    Christophe Parisel, A dump of all Azure action diameters as of June 06, 2025 https://github.com/ labyrinthinesecurity/silhouette/blob/2.1/formal/azureDiameters.txt

    work page 2025

Show all 13 references
  1. [9]

    PLY (PYthon Lex-Yacc), https://ply.readthedocs.io/en/latest/

  2. [10]

    How AWS uses automated reasoning to help you achieve security at scale, https://aws.amazon.com/blogs/ security/protect-sensitive-data-in-the-cloud-with-automated-reasoning-zelkova/

  3. [11]

    Cedar, a policy language and evaluation engine, https://github.com/cedar-policy

  4. [12]

    David Kerber, IAM Lens, https://github.com/cloud-copilot/iam-lens

  5. [13]

    /" + p[3] segment : TEXT p[0] = re.escape(p[1]) | WILDCARD p[0] =

    Christophe Parisel, Belshazaar, an Azure RBAC actions compiler, https://github.com/ labyrinthinesecurity/silhouette/blob/2.1/formal/README.md 10 Appendix Production rules Belshazaar’s production rules build a normalized Python regex. pattern : segment_list p[0] = p[1] segment_...

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.