peer=unconfined in most cases is not meant to be any. It is just that
the policy could not distinguish between the different unconfined
processes.
Confined processes were still being blocked by the peer=unconfined rule.
--
You received this bug notification because you are a member of Ubuntu
Bug
I have noticed that a lot of AppArmor policies use peer=unconfined when
they meant *any* peer. I believe this is also the case for bug 2040483.
I see little difference in allowing "signal (receive) peer=unconfined,"
vs "signal (receive)," in abstractions/base, so I proposed
https://gitlab.com/appa
Hey Christian!
thanks a lot for your fast reaction on this report!
>In other words: this looks like normal and expected behaviour to me.
You'll need to add a rule
ok, that makes sense.
>Note that abstractions/base allows signal (receive) peer=unconfined, -
and "unconfined" does not match your p
> comm="apparmor_signal" requested_mask="receive" denied_mask="receive"
signal=kill peer="/home/ubuntu/apparmor_signal_test_wrap.sh"
So you get a denial for receiving a signal from
peer="/home/ubuntu/apparmor_signal_test_wrap.sh" - which is not
surprising because that peer has a profile:
> "/home
** Also affects: apparmor (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2077413
Title:
apparmor unconfined profile blocks signal sending
To mana
