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
|