Re: [pcp] pmcd security proposals

[Nathan Scott <nathans@xxxxxxxxxx>]

Hi Frank,

On 12 March 2012 10:51, Frank Ch. Eigler <fche@xxxxxxxxxx> wrote:

...
The first issue is relatively straightforward: encrypt the
conversations.  The main choice is between tunnelling the pcp protocol
via some other tool such as ssh/stunnel/s_client, vs. linking directly
to a crypto library such as openssl or mozilla nss:

Like Chandana, I was curious about Windows ... but I think either of those

crypto libraries should be OK (from just a quick check, although a more in-

depth check would be good before choosing one - to be sure it will work for

all platforms natively).

Option #1 may be a reasonable quick hack.
Option #2 is probably a better long-term approach, say using NSS.

Having used tunnels to access pcp, I can vouch for the level of pain for

the end user ... option 2 is far, far better.

We should pay some attention to how this functionality would be enabled;

I'm assuming it wouldn't be mandated for everyone.  Some extension to

the host specification might be the go - perhaps pcp://host:port and then

pcps://host:port for a secure connection?  Most (all?) clients will already

be using pmParseHostSpec and pmParseMetricSpec, so the affected

source should be easy to find.  The data structures those routines return

would need to be extended I guess.

So it seems like this aspect almost "just works" already.  One bit
that's missing is the ability for local unprivileged users to offer up
their own PMDA processes for merging into the systemwide pmcd data
stream.  Perhaps we just need another setuid-pmcd wrapper akin to

Thinking about this some more since the meeting, and I'm wondering if

this is really needed? ... I've never come across a need for this to date,

have always been in the situation where the people doing system-level

performance analysis have the ability to change how pmcd is configured

(either directly or indirectly, via puppet or something along those lines).

The risk in allowing these unprivileged metric additions would be that we

allow shared libraries and daemons to be executed on someone else's

behalf, which might open a can of worms wrt how much that code can be

trusted.

OTOH, agents like pmdammv, which allows arbitrary user processes to

extend the set of values on the fly might be a better model (unless I'm

missing something wrt your requirements here), where there is a strict

interface between instrumented code and the agent, and the agent just

interprets the data from the client in a read-only fashion.

The last includes access control for PMDAs.  There is already some
host-level ACL logic built into pmcd.conf, but one needs a concept of
user identity to control access to individual metric hierarchies:

- for the linux proc pmda, expose proc[PID] metrics only to the users
 that own those processes: ie. subset the instance domain; and
 to expose sensitive system-wide metrics only to selected users
- control store/fetch permissions per-metric/per-user

Credentials could be automagically transferred to pmcd for connections
across unix sockets (SCM_CREDENTIALS), or if invoked via ssh/stdio.
For crossing the network, something more substantial is needed.  I
would suggest not inventing our own userid/password database widgetry,

*nod* 

 

but relying on something like SASL.  Some new PDU_AUTH packets would
have to be designed to carry the authentication data (possibly
multiple rounds).

Yep, sounds OK.

 

Once a userid credential acquired for a pmcd client, it'd go into the
pmcd ClientInfo, and share it with PMDAs to allow them enforce
finer-grained access controls.

Additionally, we could put some enforcement logic into pmcd (so that
the agents don't need to do it), for example expressed within
pmcd.conf via a new section

The other way to make it easy/consistent for agents to enforce would be

to make libpcp_pmda interfaces available.  Upside is its opt-in for the

agents and no pmcd changes, downside is that admins might want to set

permissions for existing metrics too (i.e. for agents that don't want to opt

in to understanding security extensions).  I think I prefer the pmcd.conf

way, but maybe others have strong opinions.

 

[acl]
forbid user : metric.name fetch, store;
forbid * : metric3.name list; (?)
allow *@host : metric2.name fetch;

I can imagine some cases where a user should not be allowed to know

whether a metric exists at all (i.e. namespace level permissions, a bit

like directory permissions I suppose).  So, may need a third permission

mode (fetch, store, lookup)?

It would be kind of handy to keep all permissions information in the one

place, now that I think about it, so perhaps this should not be visible to

the agents after all.

 

Additionally, we could allow remote admins to upload acl bits, like
Mark's proposed scheme, or coarser "store pmcd.acl LINE" operations
or "store pmcd.acl.load_file FILENAME" operations.

Not a big fan of either of those ... starting to sound a bit overly complex

(we'd then have to work out how to integrate a single ACL change into a

larger set, rather than just a total re-evaluation of all ACLs).  In the latter

case, we'd have to work out how to get the file named FILENAME to a

possibly remote host as well.

I think I'm starting to lean toward just keeping all this information in one

place (pmcd.conf) if thats feasible - it'd be alongside the existing host-based

mechanism too, and sighup can be used to get pmcd to reevaluate all of

the permissions at once (already supported for host-based, and we should

keep doing that).

cheers.

--

Nathan