On Mon, May 16, 2011 at 07:32:07PM +1000, Mark Goodwin wrote:
> Throwing this out for discussion, in-line replies welcome :)
Here they are...
First of all, there are really two distinct but related parts that we want
to address...
1) authentication - that is, establishing the identity of the client
2) authorization - deciding whether or not an authenticated client has
access to a resource
> 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.
Hrm...I'm a bit torn on this. I do like the idea, but at the same time I
do not want to manage *another* set of keys. Lots of folks use Kerberos
or LDAP for authentication, it'd be nice to let them use their existing
infrastructure.
Any reason we couldn't/shouldn't use existing authentication frameworks?
For example, SASL. It supports username/password schemes, kerberos, etc.
> 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.
Sounds good irrespective of the actual authentication/authorization
mechanism.
> 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).
Agreed.
> 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.
...
I like this idea.
...
> 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>"
Currently, there is "rw" with the host-mask scheme... I like this search
extension.
> 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.
Hrm... Any thoughts about making ssl optional/negotiated ala IMAP?
http://en.wikipedia.org/wiki/STARTTLS
Of course, if encryption is optional, there should be pmcd/pcp-client config
to refuse non-ssl connections.
Jeff.
--
All parts should go together without forcing. You must remember that the
parts you are reassembling were disassembled by you. Therefore, if you
can’t get them together again, there must be a reason. By all means, do not
use a hammer.
— IBM Manual, 1925
|