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

[John Johansen]

On 05/08/2017 11:53 AM, daniel curtis wrote:
> 
> Hello
> 
Hi daniel sorry for the delay in replying

> 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".
> 
yep

> 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."
> 
it is, it should work but would depend on the kernel, there is nothing you can do for the 12.04 kernel except use a kernel with the patch


> (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.)
> 
yes, 16.04 picked up addition controls on ptrace so capability sys_ptrace will not be sufficient. Specifically you will need ptrace rules, and might need the capability. Specifically you will need the capability when the trace crosses a uid/cred boundary causing the kernel to do a capability check. ptraces to tasks with the same uid will just require the ptrace rule. Unfortunately these policy rules are not compatible with the version of apparmor in 12.04, unless you update 12.04 to a new apparmor userspace that can support them.

Since 12.04 is no longer supported, new userspace/kernels are not going to be released, it is possible we could build some that would work in a ppa if it is really important but I recommend moving onto a newer release

> 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,
> 

yep, this is what you need. Though I will note you might want something a little different due to the reason for many of these ptrace permission requests. Unfortunately the kernel devs decided to re-use the ptrace check to determine if an application can access several files in /proc/
see
http://wiki.apparmor.net/index.php/TechnicalDo_Proc_and_ptrace#List_of_.2Fproc_files_checking_ptrace_access

and apparmor can not distinguish these requests from true ptrace requests (there is no association to the proc filesystem or distinction of which request it is when the request is passed to the LSM and hence apparmor). Denying all these requests can result in the netstat tool not functioning correctly as it can not gather all the information it needs. I would do some comparisons of its output for your uses cases between
  deny ptrace,
and
  allow ptrace,

now I don't recommend putting
  allow ptrace,

in your profile but it might be acceptable to do

  allow ptrace read,

or if you know the peers it should be limited to
  allow ptrace read peer=some_peer_expr,

using read will block the ptrace request to just reading info, and not allow the full ptrace which allows modifying a task.

Ideally we would have finer grained control, and there are a few things we can yet add, but we are limited but the interfaces the kernel supplies

> 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?
> 
Hopefully I have fully answered your questions above

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