Re: [PATCH v2 1/1] mm/madvise: replace ptrace attach requirement for process_madvise

On Tue 12-01-21 09:51:24, Suren Baghdasaryan wrote:

On Tue, Jan 12, 2021 at 9:45 AM Oleg Nesterov [off-list ref] wrote:

quoted

On 01/12, Michal Hocko wrote:

quoted

On Mon 11-01-21 09:06:22, Suren Baghdasaryan wrote:

quoted

What we want is the ability for one process to influence another process
in order to optimize performance across the entire system while leaving
the security boundary intact.
Replace PTRACE_MODE_ATTACH with a combination of PTRACE_MODE_READ
and CAP_SYS_NICE. PTRACE_MODE_READ to prevent leaking ASLR metadata
and CAP_SYS_NICE for influencing process performance.

I have to say that ptrace modes are rather obscure to me. So I cannot
really judge whether MODE_READ is sufficient. My understanding has
always been that this is requred to RO access to the address space. But
this operation clearly has a visible side effect. Do we have any actual
documentation for the existing modes?

I would be really curious to hear from Jann and Oleg (now Cced).

Can't comment, sorry. I never understood these security checks and never tried.
IIUC only selinux/etc can treat ATTACH/READ differently and I have no idea what
is the difference.

I haven't seen a written explanation on ptrace modes but when I
consulted Jann his explanation was:

PTRACE_MODE_READ means you can inspect metadata about processes with
the specified domain, across UID boundaries.
PTRACE_MODE_ATTACH means you can fully impersonate processes with the
specified domain, across UID boundaries.

Maybe this would be a good start to document expectations. Some more
practical examples where the difference is visible would be great as
well.

He did agree that in this case PTRACE_MODE_ATTACH seems too
restrictive (we do not try to gain full control or impersonate a
process) and PTRACE_MODE_READ is a better choice.

All that being said, I am not against the changed behavior but I do not
feel competent to give an ack.
-- 
Michal Hocko
SUSE Labs