[profile] netstat(8): using '-p' option produces many ptrace-related DENIED entries in log files.

[daniel CURTIS]

Hi

In the last days, weeks I've noticed that running netstat(8) utility via sudo(8) is responsible for many entries in various log files, such as /var/log/kern.log or /var/log/syslog. I'm using this profile [1]. There are many DENIED messages but not related with, for example, lack of some rule etc. It looks this way; run i.e. `sudo netstat -talpn/tulpn` command and check log files - there are such entries:

* /var/log/kern.log file:

Nov 30 19:12:15 t4 kernel: [12380.946835] type=1400
audit(1480529535.149:812): apparmor="DENIED" operation="ptrace" parent=5014
profile="/bin/netstat" pid=5015 comm="netstat" target=B00280F4B00280F42701

Nov 30 19:12:15 t4 kernel: [12380.946850] type=1400
audit(1480529535.149:813): apparmor="DENIED" operation="ptrace" parent=5014
profile="/bin/netstat" pid=5015 comm="netstat" target=B00280F4B00280F42701

Nov 30 19:12:15 t4 kernel: [12380.946859] type=1400
audit(1480529535.149:814): apparmor="DENIED" operation="ptrace" parent=5014
profile="/bin/netstat" pid=5015 comm="netstat" target=B00280F4B00280F42701

Dec 6 15:27:11 t4 kernel: [ 816.591037] type=1400
audit(1481034431.811:45): apparmor="DENIED" operation="ptrace" parent=17598
profile="/bin/netstat" pid=17599 comm="netstat" target=B00280F4B00280F44B01

Dec 6 15:27:11 t4 kernel: [ 816.591069] type=1400
audit(1481034431.811:46): apparmor="DENIED" operation="ptrace" parent=17598
profile="/bin/netstat" pid=17599 comm="netstat" target=B00280F4B00280F44B01

Dec 6 15:27:11 t4 kernel: [ 816.591086] type=1400
audit(1481034431.811:47): apparmor="DENIED" operation="ptrace" parent=17598
profile="/bin/netstat" pid=17599 comm="netstat" target=B00280F4B00280F44B01

There are, of course, much more such entries - about 80. maybe more. As we can see the only one thing, which has changed, is "target=*" entry.

According to Mr Steve Beattie, who's reproduced above issue, "converting the 'deny capability sys_ptrace,' to allowing the sys_ptrace capability made the rejections go away, as well as allowed netstat's -p argument to work. Attempts to add a ptrace rule instead did not succeed."

Also, I've noticed that running netstat(8) as a normal user (without sudo(8) - just for a testing purposes), produced such entry in a log files:

[~]$ netstat -ta / -tunl
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
/proc/net/tcp: Permission denied

* /var/log/syslog file:

Dec 31 13:19:02 t4 kernel: [ 3734.255210] type=1400 audit(1483186742.483:604): apparmor="DENIED" operation="open" parent=3210 profile="/bin/netstat" name="/proc/3293/net/tcp" pid=3293 comm="netstat" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

As we can see, there is only one DENIED message, but this time netstat(8) was run without 'p' flag, which is responsible for above logs with many target=* entries. So, does netstat(8) profile needs also a rule related to DENIED /proc/*/net/tcp? Something like:

@{PROC}/[0-9]*/net/tcp r,

AppArmor ver: 2.7.102-0ubuntu3.10,
Description: Ubuntu 12.04.5 LTS,
Release: 12.04,
Kernel: 3.2.0-120.163-generic-pae (3.2.79).

Best regards.
______________
[1] https://github.com/Harvie/AppArmor-Profiles/blob/master/bin.netstat

[John Johansen (jjohansen)]

The denial messages like
  target=B00280F4B00280F

are caused by a kernel bug, in reporting the the profile name of the target of the ptrace.

In general ptrace operations are controlled by both capability and ptrace rules. This is because within the kernel ptrace calls in to the capability code, and hence the capability hook without the security system having context of the reasons (semantics) for the capability request. So you will need the capability rule.

Yes, netstat will also need a file rule like you described as it will walk parts of the proc filesystem as that is how it obtains information about the network connection.

[daniel CURTIS (anoda)]

Hi. It seems, that this "problem" is solved. After installing 16.04 LTS Release and doing some tests with various AppArmor rules etc., it turned out that these two rules fixed this issue;

deny capability sys_ptrace,
deny ptrace,

However, netstat(8) utility in 16.04 LTS Release used with '-p' option produced different log entries. For example:

[ 2272.884332] audit: type=1400 audit(1494264517.023:78): apparmor="DENIED"
operation="ptrace" profile="/bin/netstat" pid=3544 comm="netstat"
requested_mask="trace" denied_mask="trace" peer="unconfined"

And so on. More info can be found here: <https://lists.ubuntu.com/archives/apparmor/2017-May/010744.html> I hope, that this issue is really solved/fixed.

Best regards.