scoperunner tries to access /proc/*/attr/current, denied by apparmor

Bug #1367264 reported by Scott Sweeny on 2014-09-09
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
apparmor-easyprof-ubuntu (Ubuntu)
Low
Jamie Strandboge

Bug Description

While testing an aggregator scope I encountered some "leaf" scopes which were not returning results. Checking syslog I found some strange apparmor denials where the scope runner was trying to access /proc/*/attr/current/.

Sep 8 11:22:10 ubuntu-phablet kernel: [ 1172.643613] type=1400 audit(1410189730.887:130): apparmor="D
ENIED" operation="open" profile="com.canonical.REDACTED_0.5" name="/proc/4637/attr/current" pid=4
637 comm="scoperunner" requested_mask="r" denied_mask="r" fsuid=32011 ouid=32011
...
Sep 8 11:22:11 ubuntu-phablet kernel: [ 1172.792552] type=1400 audit(1410189731.037:134): apparmor="D
ENIED" operation="open" profile="com.canonical.scopes.REDACTED_1.02" name="/proc/4675/attr/current" pid
=4675 comm="scoperunner" requested_mask="r" denied_mask="r" fsuid=32011 ouid=32011

I can find nothing in the code for the leaf scopes that tries to make these accesses.

Michi Henning (michihenning) wrote :

I strongly suspect that the apparmor entries are normal. During start-up, the scopes run time calls aa_getcon() to figure out whether a scope is confined or not. I suspect that this is what's causing these denials. In other words, they are most likely normal and unrelated to your problem.

Jamie, I don't know how aa_getcon() is implemented. Would you expect to see failures from /proc/<uid>/attr/current? I know that reading that file returns the current profile, so I suspect aa_getcon() reads the /proc entry behind the scenes?

Scott, if your leaf scopes don't return results, I strongly suspect that something else isn't right, but I'm pretty sure that apparmor denials have nothing to do with this.

Jamie Strandboge (jdstrand) wrote :

aa_getcon() does use /proc/<pid>/attr/current. The problem is, we can't allow apps to access this file because we cannot currently limit the pid to self. Ie, this is what we want:
  @{PROC}/self/attr/current r,

but this is what we must use now:
  @{PROC}/[0-9]*/attr/current r,

Therefore, if we allowed that ^, an app could easily enumerate what apps are installed on the device, which constitutes an information disclosure issue. That said, I can happily silence the denial with:
  deny @{PROC}/[0-9]*/attr/current r,

if the scopes runner can handle this well. Note, I'm pretty sure we pointed you at aa_getcon(), however we didn't expect it to be run from within a confined scope process.

affects: unity-scopes-api → unity-scopes-api (Ubuntu)
Michi Henning (michihenning) wrote :

Thanks for the comments Jamie. We call aa_getcon() to figure out whether we are running confined or not:

    // Find out whether we are confined. aa_getcon() returns -1 in that case.
    char* con = nullptr;
    char* mode;
    int rc = aa_getcon(&con, &mode);
    // Only con (not mode) must be deallocated
    free(con);
    confinement_type = rc == -1 ? "leaf-net" : "unconfined";

If you want to silence the denial in the logs, that's cool with me. We just rely on aa_getcon() returning -1 if we are confined. So, as long as the return value doesn't change, I'm good with silencing it (but I don't have a problem with the log entry per se either).

affects: unity-scopes-api (Ubuntu) → apparmor-easyprof-ubuntu (Ubuntu)
Changed in apparmor-easyprof-ubuntu (Ubuntu):
status: New → In Progress
assignee: nobody → Jamie Strandboge (jdstrand)
importance: Undecided → Low
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apparmor-easyprof-ubuntu - 1.2.23

---------------
apparmor-easyprof-ubuntu (1.2.23) utopic; urgency=medium

  * ubuntu-scope-network:
    - don't needlessly escape '-' in zmq access rule
    - silence @{PROC}/[0-9]*/attr/current denial since the scopes runner uses
      aa_getcon() and the denial is noisy (LP: #1367264)
  * ubuntu-webapp: explicitly deny noisy denial to dbus bind on
    org.freedesktop.Application
  * debian/apparmor-easyprof-ubuntu.postinst: update the cached .md5sums file
    on upgrade to avoid running on install and then again on first boot after
    upgrade. This change only affects apt upgrades and not system-image
    upgrades since system-image upgrades always use the existing .md5sums if
    they exist (see /etc/system-image/writable-paths).
 -- Jamie Strandboge <email address hidden> Wed, 10 Sep 2014 08:54:28 -0500

Changed in apparmor-easyprof-ubuntu (Ubuntu):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers