'signal peer=@{profile_name},' does not work as expected when in a profile using a regex match as a name

Bug #1317555 reported by Tyler Hicks
24
This bug affects 4 people
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=@{profile_name},' rule in the base abstraction. It does not work as expected when @{profile_name} contains a regex match. If an application confined with a profile that uses a regex match as the name attempts to signal itself, the signal is denied.

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/{kill,sleep} {
  #include <abstractions/base>
  file,
}

profile test {
  #include <abstractions/base>
  file,
}
EOF
$ sudo apparmor_parser -r profile

# Run the test under /tmp/test/{kill,sleep} confinement
# 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(1399560667.038:720): apparmor="DENIED" operation="signal" profile="/tmp/test/{kill,sleep}" pid=31474 comm="kill" requested_mask="send" denied_mask="send" signal=usr1 peer="/tmp/test/{kill,sleep}"
type=AVC msg=audit(1399560667.038:720): apparmor="DENIED" operation="signal" profile="/tmp/test/{kill,sleep}" pid=31474 comm="kill" requested_mask="receive" denied_mask="receive" signal=usr1 peer="/tmp/test/{kill,sleep}"

# 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

Tags: aa-parser
Tyler Hicks (tyhicks)
Changed in apparmor (Ubuntu):
status: New → Triaged
importance: Undecided → High
Revision history for this message
Kees Cook (kees) wrote :

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.

Revision history for this message
Tyler Hicks (tyhicks) wrote :

John says that the bug is in the parser:

11:18 < jjohansen> tyhicks: so the problem is the profile name vs. the expression
11:20 < tyhicks> I'm not following
11:20 < jjohansen> the profile name when a regex is used is the literal string
11:20 < jjohansen> /{a,b} { }
11:20 < jjohansen> is equiv to
11:20 < jjohansen> profile "/{a,b}" /{a,b} { }
11:20 < jjohansen> it is NOT the executable name
11:21 < jjohansen> so what we are laying down for @{profile_name} is actually wrong
11:22 < jjohansen> the encoding by the dfa is correct, but we are asking to do the wrong thing
11:23 < jjohansen> it should be matching the expression /\{a,b\}
11:23 < jjohansen> err make that encoding a match for that expression

Revision history for this message
Tyler Hicks (tyhicks) wrote :

Here's a patch for the automated parser tests that can be used to verify the fix for this bug.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Is this bug actually 'High' priority? It seems more like medium or possibly low.

Changed in apparmor:
importance: High → Medium
Changed in apparmor (Ubuntu):
importance: High → Medium
tags: added: aa-parser
Revision history for this message
Kees Cook (kees) wrote :
Revision history for this message
Christian Boltz (cboltz) wrote :

Just to make sure this doesn't get lost/overlooked:

> # Oddly, comm="kill" is in both denials, despite the denials being for send and receive masks

Revision history for this message
John Johansen (jjohansen) wrote :

not really, comm= added by the audit subsystem and is set by the thread the check is being done in, in kernel context. Both the send and receive check are being done in the same place so comm= will not change. We are not in control of this so there is little we can do about it.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.