'signal peer=@{profile_name},' does not work as expected when in a profile using a regex match as a name
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
AppArmor |
Triaged
|
Medium
|
Unassigned | ||
apparmor (Ubuntu) |
Triaged
|
Medium
|
Unassigned |
Bug Description
Kees Cook reported signal mediation issues stemming from the 'signal peer=@{
Here's a simple reproducer:
# Set up the test environment
$ mkdir /tmp/test
$ cd /tmp/test
$ cp -a /bin/kill .
$ cp -a /bin/sleep .
# Run the unconfined test to verify that it works (it does)
$ /tmp/test/sleep 30s &
[2] 31464
$ /tmp/test/kill -USR1 $!
[2]+ User defined signal 1 /tmp/test/sleep 30s
# Create and load the AppArmor profile
$ cat << EOF > profile
#include <tunables/global>
/tmp/test/
#include <abstractions/base>
file,
}
profile test {
#include <abstractions/base>
file,
}
EOF
$ sudo apparmor_parser -r profile
# Run the test under /tmp/test/
# Note that this will not work, likely due to the regex in the profile name
$ /tmp/test/sleep 30s &
[1] 31473
$ /tmp/test/kill -USR1 $!
# Look at the new denials
# Oddly, comm="kill" is in both denials, despite the denials being for send and receive masks
type=AVC msg=audit(
type=AVC msg=audit(
# Run the test once more under the "test" profile (it succeeds)
$ aa-exec -p test -- /tmp/test/sleep 30s &
[1] 31476
$ aa-exec -p test -- /tmp/test/kill -USR1 $!
[1]+ User defined signal 1 aa-exec -p test -- /tmp/test/sleep 30s
Changed in apparmor (Ubuntu): | |
status: | New → Triaged |
importance: | Undecided → High |
Changed in apparmor: | |
importance: | High → Medium |
Changed in apparmor (Ubuntu): | |
importance: | High → Medium |
tags: | added: aa-parser |
Thanks for helping debug this! Similarly, using the extended profile name and executable path definition style:
profile test /tmp/test/ {kill,sleep} {
...
works too, without need for aa-exec -p. With that work-around, I'm able to get my profile running happily again.