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
>
>
>
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
