| 2015-06-16 15:24:26 |
Rick Spencer |
bug |
|
|
added bug |
| 2015-08-25 14:37:11 |
Michael Vogt |
snappy: status |
New |
Incomplete |
|
| 2015-08-26 18:48:28 |
Jamie Strandboge |
snappy: status |
Incomplete |
Confirmed |
|
| 2015-08-26 18:48:32 |
Jamie Strandboge |
snappy: importance |
Undecided |
High |
|
| 2016-04-29 01:28:28 |
Tyler Hicks |
snappy: assignee |
|
Tyler Hicks (tyhicks) |
|
| 2016-04-29 01:28:30 |
Tyler Hicks |
snappy: status |
Confirmed |
In Progress |
|
| 2016-05-31 22:43:26 |
Tyler Hicks |
description |
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 |
SRU Justification:
Impact: A noisy AppArmor denial is reported to the system logs when a go is ran 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 |
|
| 2016-05-31 23:07:28 |
Tyler Hicks |
description |
SRU Justification:
Impact: A noisy AppArmor denial is reported to the system logs when a go is ran 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 |
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 |
|
| 2016-06-06 21:06:04 |
Kamal Mostafa |
bug task added |
|
linux (Ubuntu) |
|
| 2016-06-06 21:06:17 |
Kamal Mostafa |
nominated for series |
|
Ubuntu Xenial |
|
| 2016-06-06 21:06:17 |
Kamal Mostafa |
bug task added |
|
linux (Ubuntu Xenial) |
|
| 2016-06-06 21:06:29 |
Kamal Mostafa |
linux (Ubuntu Xenial): status |
New |
Fix Committed |
|
| 2016-06-06 21:30:14 |
Brad Figg |
linux (Ubuntu): status |
New |
Incomplete |
|
| 2016-06-14 14:21:21 |
Kamal Mostafa |
tags |
|
verification-needed-xenial |
|
| 2016-06-15 07:39:07 |
Tyler Hicks |
tags |
verification-needed-xenial |
verification-done-xenial |
|
| 2016-06-15 08:26:16 |
Launchpad Janitor |
linux (Ubuntu): status |
Incomplete |
Fix Released |
|
| 2016-06-15 08:26:16 |
Launchpad Janitor |
cve linked |
|
2016-4482 |
|
| 2016-06-15 08:26:16 |
Launchpad Janitor |
cve linked |
|
2016-4569 |
|
| 2016-06-15 08:26:16 |
Launchpad Janitor |
cve linked |
|
2016-4578 |
|
| 2016-06-15 08:26:16 |
Launchpad Janitor |
cve linked |
|
2016-4951 |
|
| 2016-06-27 18:27:24 |
Launchpad Janitor |
linux (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2016-08-23 23:20:06 |
Tyler Hicks |
snappy: status |
In Progress |
Fix Released |
|
