I reproduced this on ubuntu 26.04 (7.0.0-29-generic) with a minimal test
case (a small spread test using a MSG_FASTOPEN client, see
https://bugs.launchpad.net/apparmor/+bug/2163740).
Separately from what JJ reported on Mattermost (that the test needs the
right to create the socket), I found that the "deny network (connect),"
rule breaks the "network (create)" rule.
With a profile like:
profile t flags=(attach_disconnected) {
file,
network (create) ip=127.0.0.1,
}
socket creation succeeds. But adding a connect-deny rule:
profile t flags=(attach_disconnected) {
file,
network (create) ip=127.0.0.1,
deny network (connect) ip=127.0.0.1,
}
makes socket creation fail with:
apparmor="DENIED" operation="create" class="net" profile="t"
family="inet" sock_type="stream" protocol=0 requested="create"
denied="create"
This happens with every variant I tried:
- unconditional allow: "network (create)," + "deny network (connect)," ->
create denied
- full family allow: "network inet stream," + "deny network (connect)," ->
create denied
- with "abi <kernel>,": create is allowed but then "bind" is denied instead,
even though "network (bind) ip=127.0.0.1," is present
It reproduces with both the distro apparmor_parser 5.0.2 and the in-tree
parser, so it doesn't look like a parser regression -- the deny rule
seems to poison the compiled policy so that other, explicitly allowed
network operations get denied too.
--
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
