pcp
[Top] [All Lists]

Re: pmlogconf including proc metrics?

To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Subject: Re: pmlogconf including proc metrics?
From: fche@xxxxxxxxxx (Frank Ch. Eigler)
Date: Fri, 19 Jul 2013 12:32:12 -0400
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <y0mob9yy61o.fsf@xxxxxxxx> (Frank Ch. Eigler's message of "Fri, 19 Jul 2013 10:32:03 -0400")
References: <51E91E01.6060602@xxxxxxxxxxxxxxxx> <y0mob9yy61o.fsf@xxxxxxxx>
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)
I wrote:

> [...]
> OTOH, with the authentication code now working, we should install the
> proc pmda by default (in a secure mode; in src/pmdas/linux_proc/contexts.c
> proc_ctx_access(), use uid/gid=nobody if ! CTX_USERID.

Actually, what we may need even more is some ownership-checking for in
src/pmdas/linux_proc/proc_pid.c's opening of /proc/%d/XXX files.  On
linux, they are generally wide-open so any local user can read a lot
of stats about others' processes.  We have some choices:

- for authenticated mode contexts, 
  ... let the remote pcp client access all that she could if logged in
      with the same credentials
  ... or to limit it to her own processes (via explicit stat()->st_uid
      comparisons & rejection)

- for unauthenticated contexts,
  ... let the remote pcp client addess all that an anonymous user
      ("pcp"/"nobody") could (which is IMO too much disclosure)
  ... or to limit it to the anonymous user's own processes via
      same stat()->st_uid as above; (probably still too much disclosure)
  ... or to limit it to no /proc/%d/XXX info at all   <<< my favorite

In either scenario, the setuid work currently done by linux_pmda would
be more of a belt & suspenders kind of measure rather than providing
the system confidentiality I'm talking about above.


- FChE

<Prev in Thread] Current Thread [Next in Thread>