[pcp] [RFC] PCP authentication and access control proposal (draft v1)

[Mark Goodwin]

Throwing this out for discussion, in-line replies welcome :)

Authentication
     Use public/private key authentication, much like ssh. This can be
     (but does not have to be) passwordless. Keys are generated by
     ssh-keygen(1). We authenticate key holders, not named users.

     The existing client-pmcd connection handshake would be augmented
     to authenticate the user's secret private key (from ~/.pcp/id_rsa
     or wherever, and /etc/ssh/ssh_host_rsa_key for daemons) against
     persistent authorized public keys stored on remote hosts running
     pmcd. Additional per-client state (i.e. the public key) would be
     maintained as part of the pmcd ClientInfo array.

     Authentication failure would result in pmNewContext() returning
     PM_ERR_PERMISSION for the first connection attempt to the requested
     host. Successful authentication should prevail for the life of the
     PMAPI context. Other PMAPI calls such as pmReconnectContext()
     should require re-authentication.

     For secure trusted environments, we probably need to be able to
     turn off authentication and access control entirely (keep the
     status-quo as an option, perhaps even the default).

Access Control - Management
     Having the access control configuration accessible as PCP metrics
     will make it easy for authenticated admins to manage and query the
     current access control configuration and policies on a particular
     server, using existing PCP client tools.

     Keys could be installed manually but would be more easily managed
     with a pmstore to (say) pmcd.control.security.<operation>, with the
     instance name(s) specifying the metrics (or pmns subtree) to which
     access control for <operation> is to be applied. Here, <operation>
     could be "fetch" or "store" or "search", whatever we want. E.g.

	pmstore -h somewhere.com -i hinv,pmcd.control \
           pmcd.control.security.fetch "<keystring>"

     would grant fetch access for an authenticated holder of the <keystring>
     key to all the metrics below both hinv and pmcd.control in the pmns
     maintained by pmcd on the host somewhere.com. (note: an alternative to
     <operation> that uses Unix style permission semantics is discussed below).

     Keep authorized public keys below $PCP_VAR_DIR/config/pmcd/security
     on the pmcd server side. These are persistent. The suggested format
     is one file containing authorized public keys for each pmns path to which
     access control is required. The special file "root" would contain the
     authorized public keys for the administrators of this scheme (granting
     access to the entire namespace). Other files in this directory would
     contain authorized keys for access to individual metrics or pmns subtrees.

     I would expect secure authenticated access for selected users (and
     host daemons - pmlogger, pmie, etc) to the entire namespace would be
     sufficient and commonly used in many environments.

Access Control - Enforcement
     Access control is enforced by pmcd - each authenticated user's public
     key is maintained in pmcd's ClientInfo array, and used to check access
     rights by searching the pmcd.control.security database for matching
     authorized keys. If this fails, you get appropriate -EPERM error
     handling for various PMAPI operations.

     Access to PCP archives created by pmlogger (and local context access)
     are not really enforceable with this scheme - they must rely on the
     host filesystem access control mechanisms.

     Not sure if we'd want to push enforcement out to individual PMDAs instead
     of being pmcd centric - seems inherently less secure, but might offer
     desirable flexibility.

     This scheme can co-exist with the existing ip-mask based client host access
     control mechanisms - no need to rip it out.

Access Control - Operations
     We'd need to figure out appropriate semantics for whatever PMAPI operations
     we require access control for.

     Maybe unix semantics could work here: "rwx" for fetch/store/search, and
     combinations (search is for pmns traversal). Once authenticated, "access
     is denied unless allowed" seems a sensible starting point. With unix
     semantics, the above example to allow fetch and search (but not store)
     access for the <keystring> holder would be:
	pmstore -h somewhere.com -i hinv,pmcd.control \
           pmcd.control.security "r-x <keystring>"

     "store" access to pmcd.control.security itself would be needed to administer
     access control permissions for others - I guess this could be a single
     point of failure if the admin's private key were to escape :)

     Needs discussion.

Encryption
     None of this is secure unless we also have encryption over the wire, at
     least during the authentication handshake.

     Over-the-wire PCP PDU encryption should use the ssl API, see ssl(3) for
     introductory details. This would involve a bit of libpcp surgery at the
     transport/socket layer and might be messy if we have to stuff around with
     certificates, etc. .. needs discussion.

-- Mark