On 05/17/2011 09:36 AM, Josef 'Jeff' Sipek wrote:
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
Thanks for the reply.
yeah ok s/enforcement/authorization/ in my original post
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.
wanted to keep it really simple, with minimal dependencies. Kerb/LDAP
are in wide use in many organizations, but they make me shiver a bit
due to the excess baggage charges.
Any reason we couldn't/shouldn't use existing authentication frameworks?
For example, SASL. It supports username/password schemes, kerberos, etc.
there's no technical reason we couldn't - e.g. libgsasl seems to be pretty
portable (even has a mingw port). I just think the ssh key approach is
the most simple, most portable and the easiest to manage.
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
by the looks of it, starttls might work to encapsulate the PCP protocol,
but I'm getting out of my comfort zone here ...
Of course, if encryption is optional, there should be pmcd/pcp-client config
to refuse non-ssl connections.
... perhaps you (Jeff) could draft a more complete ssl/tls proposal
than my half baked lasagne?
Cheers
-- Mark
|