[apparmor] aa-unconfined, netstat(8) profile: plenty of DENIED messages; repeated "target=*" value.

[daniel curtis]

Hi

Continuing my first message about netstat(8) profile [1] - here, on this
mailing list - and many "target=*" entries, I would like to write another
one example of a problem with netstat(8) and probably: "-p" option along
with "capability sys_ptrace" etc.

Today, I've noticed a pretty strange thing. During checking profile status
with, for example, "ps aux -Z | grep -v unconfined" and "grep -L unconfined
/proc/*/attr/current" commands, everything was okay. But when I used
"aa-unconfined" utility, there was not an output at all.

So I've checked log files and both: /var/log/kern.log and /var/log/syslog
files contains exactly the same entries:

Feb 28 19:37:40 t4 kernel: [17794.190290] type=1400
audit(1488307060.421:49): apparmor="DENIED" operation="ptrace" parent=4186
profile="/bin/netstat" pid=4189 comm="netstat" target=B00280F4B00280F40301

Feb 28 19:37:40 t4 kernel: [17794.190309] type=1400
audit(1488307060.421:50): apparmor="DENIED" operation="ptrace" parent=4186
profile="/bin/netstat" pid=4189 comm="netstat" target=B00280F4B00280F40301

Feb 28 19:37:40 t4 kernel: [17794.190317] type=1400
audit(1488307060.421:51): apparmor="DENIED" operation="ptrace" parent=4186
profile="/bin/netstat" pid=4189 comm="netstat" target=B00280F4B00280F40301

Feb 28 19:37:40 t4 kernel: [17794.190326] type=1400
audit(1488307060.421:52): apparmor="DENIED" operation="ptrace" parent=4186
profile="/bin/netstat" pid=4189 comm="netstat" target=B00280F4B00280F40301

Feb 28 19:37:40 t4 kernel: [17794.190333] type=1400
audit(1488307060.421:53): apparmor="DENIED" operation="ptrace" parent=4186
profile="/bin/netstat" pid=4189 comm="netstat" target=B00280F4B00280F40301

Feb 28 19:37:40 t4 kernel: [17794.190341] type=1400
audit(1488307060.421:54): apparmor="DENIED" operation="ptrace" parent=4186
profile="/bin/netstat" pid=4189 comm="netstat" target=B00280F4B00280F40301

Feb 28 19:37:40 t4 kernel: [17794.190349] type=1400
audit(1488307060.421:55): apparmor="DENIED" operation="ptrace" parent=4186
profile="/bin/netstat" pid=4189 comm="netstat" target=B00280F4B00280F40301

Feb 28 19:37:40 t4 kernel: [17794.190357] type=1400
audit(1488307060.421:56): apparmor="DENIED" operation="ptrace" parent=4186
profile="/bin/netstat" pid=4189 comm="netstat" target=B00280F4B00280F40301

Feb 28 19:37:40 t4 kernel: [17794.190364] type=1400
audit(1488307060.421:57): apparmor="DENIED" operation="ptrace" parent=4186
profile="/bin/netstat" pid=4189 comm="netstat" target=B00280F4B00280F40301

Feb 28 19:37:40 t4 kernel: [17794.190372] type=1400
audit(1488307060.421:58): apparmor="DENIED" operation="ptrace" parent=4186
profile="/bin/netstat" pid=4189 comm="netstat" target=B00280F4B00280F40301

Anyway, according to an official AppArmor wiki, "aa-unconfined" uses
"netstat -nlp" command output to find programs accepting connections,
right? So it seems to be related with an issue mentioned above and in whole
thread.

By the way; the only one modifications to the netstat(8) profile, which I
made was: remove an "owner" prefix and use rules for both protocols - for
example - tcp/udp, tcp6/udp6 and raw/raw6 (placed in "@{PROC}/*/net/") etc.
Even if I'm not using IPv6, after removing these rules from a profile,
AppArmor filled log files with "DENIED" messages about it, so I had to use
them once again.

There is also a bug report, which I've created to address the whole things
with "target=*" entries and so on. Here it's:

https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1653347

AppArmor wiki page, which I've used: "AppArmor Monitoring" and 1.3
subsection: "Information on running processes". Used profile:

https://github.com/Harvie/AppArmor-Profiles/blob/master/bin.netstat

Best regards.
_____________
1. https://lists.ubuntu.com/archives/apparmor/2016-December/010317.html
1a. https://lists.ubuntu.com/archives/apparmor/2016-December/010326.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20170228/8f298d02/attachment.html>