[apparmor] [profile] netstat(8): problems with '-p', '-program' option. Solved?

[daniel curtis]

Hello

Last year, running 12.04 LTS Release, I noticed some problems with
netstat(8) utility. It turned out, that the 'p' option is responsible for
many DENIED entries in log files etc. [1] This option "show the PID and
name of the program to which each socket belongs".

However, Mr John Johansen stated, that this is probably a kernel bug [2]. To
monitor this problem, I've created a bug report on Launchpad [3]. Mr Steve
Beattie reproduced this issue also. He wrote, that; "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."

(NOTE: Using/converting "capability sys_ptrace" without "deny", does not
work for me on 16.04 LTS. There are many DENIED entries in log files: same
as below.)

Because 12.04 LTS Relase is in EoL state now, I installed 16.04 LTS version
and checked this issue once again. And this problem still occurs. Running
netstat(8) with, for example, these options: 'talpn' produced many DENIED
entries in log files:

[ 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"

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

And many, many more. I've tried to add this rule: "ptrace (trace)
peer=@{profile_name}," and load a "new" profile to the kernel with
apparmor_parser utility(8) but with no luck. And something interesting
happened. I've decided to add "deny ptrace," rule and reload netstat(8)
profile once again. Here is a log entry:

[ 4713.703343] audit: type=1400 audit(1494266957.842:3148):
apparmor="DENIED" operation="capable" profile="/bin/netstat" pid=4267
comm="netstat" capability=19  capname="sys_ptrace"

Interesting. There was not DENIED entries mentioned earlier. Now, I've
decided to try these two rules together and it seems to work; there is no
DENIED entry in log files anymore etc. And these rules are:

deny capability sys_ptrace,
deny ptrace,

After reload profile and run e.g.: "netstat -talpn" command, log files are
clean of all previously DENIED entries.

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

What do you think about this? Is it OK? Can these two rules be used
together in netstat(8) profile? What is your opinions? Does that make any
sense?

Thanks, best regards.
_____________________

[1] https://lists.ubuntu.com/archives/apparmor/2016-December/010317.html
[2] https://lists.ubuntu.com/archives/apparmor/2016-December/010319.html
[3] https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1653347
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20170508/89d968d4/attachment-0001.html>