kernel-packages team mailing list archive

[Kamal Mostafa <kamal@xxxxxxxxxxxxx>]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-xenial

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1465724

Title:
  net_admin apparmor denial when using Go

Status in Snappy:
  In Progress
Status in linux package in Ubuntu:
  Incomplete
Status in linux source package in Xenial:
  Fix Committed

Bug description:
  SRU Justification:

  Impact: A noisy AppArmor denial is reported to the system logs when a
  go program is run as a privileged user. The denial is non-fatal and is
  simply the result of the proc net systctl code determining what
  permissions a new inode should have. This noisy denial has a high
  potential to confuse snap packagers because they may think that their
  application is not working under Snappy confinement. It has a high
  potential to confuse Snappy users because they may think that the
  snaps running on their system are malicious.

  Fix: The fix was authored by Tyler Hicks and acked by Serge Hallyn. It
  creates a new ns_capable() function that calls into the LSM hooks with
  the noaudit flag set so that the LSM doesn't generate a denial if the
  application under confinement is missing the CAP_NET_ADMIN capability

  Testcase:
    # Load a test AppArmor profile
    $ echo "profile test { file, }" | sudo apparmor_parser -rq
    # Read a proc net sysctl file as root under confinement:
    $ sudo aa-exec -p test -- cat /proc/sys/net/core/somaxconn
    128
    # Manually inspect /var/log/syslog (or, if auditd is running, /var/log/audit/audit.log) to verify that the following denial is *NOT* present:
    # audit: type=1400 audit(1462575670.000:29): apparmor="DENIED" operation="capable" profile="test" pid=1161 comm="cat" capability=12  capname="net_admin"

  Original report:

  Somewhere in the following code, this denial gets thrown. It's
  difficult to tell where because the report of the denial seems to be
  asynchronous, as it comes interspersed with all the other debug
  information being printed to stdout.

  http://bazaar.launchpad.net/~rick-rickspencer3/+junk/go-
  uploader/view/head:/main.go

  Jun 16 14:21:51 localhost kernel: [ 7488.856306] audit: type=1400
  audit(1434464511.427:41): apparmor="DENIED" operation="capable"
  profile="go-uploader.sideload_go-uploader_0.3" pid=1493 comm="go-
  uploader" capability=12  capname="net_admin"

  I can fix it by adding capability net_admin to
  /var/lib/apparmor/profiles/click_go-uploader.sideload_go-uploader_0.3
  and rerunning apparmor_parser

To manage notifications about this bug go to:
https://bugs.launchpad.net/snappy/+bug/1465724/+subscriptions