Follow-up with a byte-level comparison of the compiled policy produced
by both parser versions from the bug report (v5.0.0-beta1 vs v5.0.2
tags; ubuntu-specific patches may differ slightly, but the mechanism is
in the shared parser code).

Method: compiled the exact QRT profile from
tests/regression/apparmor/net_inet_tcp_fastopen.sh (gen_send_no_connect:
the inet + inet6 lines, the peer rules, the setopt rules and the two
"deny network (connect) ip=..." rules, with "abi <kernel>," as emitted
by prologue.inc) with both parsers, then walked the policy DFA the way
the kernel does for each socket operation (aa_profile_af_perm ->
aa_match_to_prot -> early_match -> aa_do_perms), using a small userspace
tool built on go-apparmor.

Results matrix (inet/stream, 127.0.0.1:8080):

                        create  bind  listen  accept
  beta1, with deny      DENIED  DENIED DENIED DENIED
  beta1, without deny   DENIED  DENIED DENIED DENIED
  5.0.2, with deny      DENIED  DENIED DENIED DENIED
  5.0.2, without deny   DENIED  ALLOWED ALLOWED ALLOWED

There are two independent parser-side problems visible in the compiled
policy, on top of the known test-profile issue (the profile never grants
"create" - create is DENIED in every row, matching the audit log in the
bug description):

1. beta1: the family+type prefix state never gets AA_CONT_MATCH for
conditional inet rules. The conditional DFA paths are present in the
compiled policy (walking them byte-by-byte reaches the expected accept
states, e.g. allow=0x208000 for the bind rule), but because the prefix
perms lack the cont-match bit (allow=0x8000, lock only), the kernel's
early_match treats the prefix as authoritative and denies every
conditional operation. Unconditional rules ("network inet stream,") work
fine, which is why the pre-existing net_inet tests passed - and this
test simply did not exist in 5.0.0~beta1 (per comment 4), so nothing
exercised this path in the Aug 1 cycle.

2. 5.0.2: the conditional rules work (the mandatory cont-match stub at
the prefix is present), but the "deny network (connect) ip=..." rules
strip AA_CONT_MATCH from the shared prefix state: the prefix goes from
allow=0x8008000 (lock+cont-match) without the deny rules to allow=0x8000
without it. With cont-match gone, early_match makes the prefix
authoritative for all operations, so the explicitly-allowed
bind/listen/accept/send rules become unreachable too - the deny poisons
the whole family, not just connect.

So even with "create" added to the test profile (the fix from comment
3), the deny rules as compiled by 5.0.2 would still break the test: the
listener's bind/listen/accept would be denied. The test fix needs to
land together with a parser fix for the deny/cont-match interaction.

(Separately, on the legacy net_allowed_af downgrade path,
update_compat_net() ORs the socket type mask into the deny mask for a
per-operation deny rule, wiping the whole family allow mask - a third,
distinct issue noted in my earlier comment, on a code path this test
does not hit.)

Happy to share the analysis tooling (go-apparmor network query support +
apparmor-insight "query network" CLI) if useful for verifying a fix.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2163740

Title:
  net_inet_tcp_fastopen from ubuntu_qrt_apparmor failed on Resolute

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/2163740/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to