Re: Documenting ptrace access mode checking

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Eric,

On 06/23/2016 09:04 PM, Eric W. Biederman wrote:
"Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx> writes:

Hi Eric,

On 06/21/2016 09:55 PM, Eric W. Biederman wrote:
Hmm.

When I gave this level of detail about the user namespace permission
checks you gave me some flack, because it was not particularly
comprehensible to the end users.  I think you deserve the same feedback.

How do we say this in a way that does not describes a useful way to
think about it.  I read this and I know a lot of what is going on and my
mind goes numb.

How about something like this:

   If the callers uid and gid are the same as a processes uids and gids
   and the processes is configured to allow core dumps (aka it was never
   setuid or setgid) then the caller is allowed to ptrace a process.

   Otherwise the caller must have CAP_SYS_PTRACE.

   Linux security modules impose additional restrictions.

   For consistency access to various process attributes are guarded with
   the same security checks as the ptrace system call itself.  As they are
   all methods to get information about a process.

We certainly need something that gives a high level view so people
reading the man page can know what to expect.   If you get down into the
weeds we run the danger of people beginning to think they can depend
upon bugs in the implementation.

Thanks for the feedback, but I think more detail is required than you
suggest. (And I added all of that detail somewhat reluctantly.)
See my other replies for my rationale.

What I saw badly missing from your description is not the level of
detail but bring things into a form that ordinary mortals can
understand.

For an explanation to be clear I think we very much need the high level
overview first.  Then we can expand that description with the very
detailed view.

I very much think we need to describe things in such a way that people
understand the principles behind the permission checks, and not just
have the documentation echo the code, so that people can know what weird
things LSMs like yama are likely to do, and how these checks are likely
to evolve in the future.

So, I completely agree with you, and I agree that this could be better.
At first, I understood your meaning to be that I should avoid all of the
detail, and just limit the man page to some very high level text as
you proposed. So, I think it's worth prefixing the details with some
attempt at a high-level picture. How about this as an introductory
paragraph:

       Various parts of the kernel-user-space API (not just  ptrace(2)
       operations),  require  so-called  "ptrace  access mode" checks,
       whose outcome determines whether an operation is permitted (or,
       in  a  few cases, causes a "read" operation to return sanitized
       data).  These checks are performed in cases where  one  process
       can  inspect sensitive information about, or in some cases mod‐
       ify the state of, another process.  The  checks  are  based  on
       factors  such  as  the  credentials and capabilities of the two
       processes, whether or not the "target" process is dumpable, and
       the  results  of checks performed by any enabled Linux Security
       Module (LSM)—for example, SELinux, Yama, or  Smack—and  by  the
       commoncap LSM (which is always invoked).

?

Because one thing is clear to me.  The evolution of these details is
clearly not done, and will continue to change in the future.

Maybe people will even write man page patches when that happens :-).

Cheers,

Michael


--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux