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
For those reading this bug report, "net_admin" is used for the following (from man capabilities):
* interface configuration;
* administration of IP firewall, masquerading, and accounting;
* modify routing tables;
* bind to any address for transparent proxying;
* set type-of-service (TOS)
* clear driver statistics;
* set promiscuous mode;
* enabling multicasting;
* use setsockopt(2) to set the following socket options: SO_DEBUG, SO_MARK, SO_PRIORITY (for a priority outside the range 0 to 6), SO_RCVBUFFORCE, and SO_SNDBUFFORCE.
This is quite a set of privileges and our AppArmor policy is correctly denying the access.
I have a feeling this is a harmless denial related to setsockopt() by the "net/http" import and that go tries to do something with setsockopt and happily proceeds if it cannot.