Unable to match embedded NULLs in unix bind rule for abstract sockets

Bug #1413410 reported by Jamie Strandboge
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
AppArmor
Fix Released
High
John Johansen
2.9
In Progress
High
Unassigned
Snappy
Invalid
High
Unassigned
apparmor (Ubuntu)
Fix Released
High
Unassigned

Bug Description

On Ubuntu 14.10, I had this in my logs:
Jan 21 16:32:30 localhost kernel: [24900.927939] audit: type=1400 audit(1421879550.441:534): apparmor="DENIED" operation="bind" profile="/usr/lib/firefox/firefox{,*[^s][^h]}" pid=12356 comm="plugin-containe" family="unix" sock_type="dgram" protocol=0 requested_mask="bind" denied_mask="bind" addr="@676F6F676C652D6E61636C2D6F316431323335362D3339310000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"

$ aa-decode 676F6F676C652D6E61636C2D6F316431323335362D3339310000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Decoded: google-nacl-o1d12356-391

$ aa-decode 676F6F676C652D6E61636C2D6
Decoded: google-nacl-`

So I tried the following:
unix bind type=dgram addr=@google-nacl*,
unix bind type=dgram addr="@google-nacl*",
unix bind type=dgram addr=@676F6F676C652D6E61636C2D6*,
unix bind type=dgram addr="@676F6F676C652D6E61636C2D6*",
unix bind type=dgram addr=@google-nacl*\\000*,
unix bind type=dgram addr=@google-nacl*[0-9a-zA-Z]\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000{,\\000,\\000\\000},

but none of them match. The best I could do was:
unix bind type=dgram,

This is likely going to be important for snappy since snappy will have the concept of different coordinating snaps interacting via abstract sockets. What is interesting is that this seems to work ok for some things, eg:
./lightdm: unix (bind, listen) type=stream addr="@/com/ubuntu/upstart-session/**",
./lightdm: unix (bind, listen) type=stream addr="@/tmp/dbus-*",
./lightdm: unix (bind, listen) type=stream addr="@/tmp/.ICE-unix/[0-9]*",
./lightdm: unix (bind, listen) type=stream addr="@/dbus-vfs-daemon/*",
./lightdm: unix (bind, listen) type=stream addr="@guest*",

Is this something in how firefox is setting up the socket?

To reproduce, enable the firefox profile, start firefox and try to attend a google hangout.

Changed in apparmor (Ubuntu):
importance: Undecided → High
tags: added: aa-kernel aa-parser
description: updated
description: updated
description: updated
Revision history for this message
John Johansen (jjohansen) wrote :
Download full text (4.2 KiB)

So first off something is wrong with the decode
   google-nacl-o1d12356-391

does not contain any characters that would cause encoding to happen. Doing a manual decode verifies that the issue is the trailing 0s.

The question still remains if this is a bug in apparmor grabbing the abstract names length, or if the application is really specifying all those null characters as part of the name.

So to the match patterns
> unix bind type=dgram addr=@google-nacl*,
> unix bind type=dgram addr="@google-nacl*",
Looking at the match generation * will not match \000 which will cause this to fail. This should be considered a bug since \000 is a valid character in abstract socket names

> unix bind type=dgram addr=@676F6F676C652D6E61636C2D6*,
> unix bind type=dgram addr="@676F6F676C652D6E61636C2D6*",
these are just incorrect apparmor rules don't support the hex encoding, this is something audit does when it encounters characters out of its printable alphanum range.

> unix bind type=dgram addr=@google-nacl*\\000*,
this won't work, perhaps you where thinking of regular re instead of apparmor's extended globbing?

> unix bind type=dgram addr=@google-nacl*[0-9a-zA-Z]\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000{,\\000,\\000\\000},

this is closer but still will not work

The follow rule should match the number of trailing null characters exactly, the audit encoding is hex so each two 0s is character which is mapped to \x00 below. Basically I copied and pasted the trailing 0s and insert \x every 2 00s. Currently there is no way to pattern match the trailing 0s and they must be provided in the exact number. An alternation can be used to vary the number but its is different than the alternation above.

unix bind type=dgram addr="@google-nacl*\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"

To vary the count of trailing nulls that are accepted we can use an alternation, however apparmor embedded alternation support can not handle a nesting level of 83, so the follow expression should but won't work until native parsing of aare is implemented
unix bind type=dgram addr="@google-nacl*{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00{\x00,},},},},},},},},},},},},},},...

Read more...

summary: - Unable to match unix bind rule
+ Unable to match embedded NULLs in unix bind rule for abstract sockets
Changed in apparmor:
assignee: nobody → John Johansen (jjohansen)
Changed in snappy-ubuntu:
assignee: nobody → Jamie Strandboge (jdstrand)
importance: Undecided → High
Changed in apparmor:
importance: Undecided → High
status: New → In Progress
Changed in snappy-ubuntu:
status: New → Triaged
status: Triaged → Confirmed
Changed in apparmor (Ubuntu):
status: New → Confirmed
Revision history for this message
John Johansen (jjohansen) wrote :

So I have verified that firefox is doing the bind call with a 110 byte long addrlen

[pid 1020] bind(18, {sa_family=AF_LOCAL, sun_path=@"google-nacl-o1d1020-1"}, 110) = -1 EACCES (Permission denied)

so the trailing 0s being reported by the apparmor audit message are correct

So this breaks down to 3 userspace bugs

  wrong handling of \x00 by the compiler
  wrong handling of the * and ** globs for abstract socket names
  limited nesting depth for alternations (though this is minor and not really needed for this bug if globbing is fixed)

Revision history for this message
Steve Beattie (sbeattie) wrote :

This did not get addressed in the 2.9.2 release, moving to the 2.9.3 milestone.

Michael Terry (mterry)
affects: snappy-ubuntu → snappy
Revision history for this message
John Johansen (jjohansen) wrote :

The commits that fix these issues are in apparmor 2.10

r2867 - wrong handling of \x00 by the compiler
r2866 - wrong handling of the * and ** globs for abstract socket names

In adddition
in 2.9 contains r2248 - which allows a fixed alternation depth by setting the define MAX_ALT_DEPTH, this could be increased to a value larger the 110 max byte length of the abstract socket.

Steve Beattie (sbeattie)
Changed in apparmor:
milestone: none → 2.10
status: In Progress → Fix Committed
Revision history for this message
Steve Beattie (sbeattie) wrote :

AppArmor 2.10 has been released: https://launchpad.net/apparmor/2.10/2.10

Changed in apparmor:
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apparmor - 2.10-0ubuntu2

---------------
apparmor (2.10-0ubuntu2) wily; urgency=medium

  * debian/patches/aa-status-dont_require_python3-apparmor.patch:
    make aa-status(8) work even when python3-apparmor is not installed,
    otherwise dh_apparmor postinst snippets can fail (LP: #1480492)
  * debian/control: make apparmor-utils depend on the same package
    version of python3-apparmor

 -- Steve Beattie <email address hidden> Fri, 31 Jul 2015 16:35:03 -0700

Changed in apparmor (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Leo Arias (elopio) wrote :

Hey Jamie, I'm not sure how this affects snappy, and I'm not sure how to reproduce it in a snappy system.
I see that a fix was released to apparmor. Is there something messing in the snappy side?

Changed in snappy:
status: Confirmed → Incomplete
Revision history for this message
Ian Johnson (anonymouse67) wrote :

Jamie, is this still an issue? I'm inclined to close this since the apparmor bug seems to have been released a long time ago.

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

We released UC16/xenial with a new enough apparmor (which was also backported to trusty) so we can mark the snapd task as Invalid, which I did just now.

Changed in snappy:
assignee: Jamie Strandboge (jdstrand) → nobody
status: Incomplete → Invalid
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.