Hi -
Following on from last week's meetings, here are a couple of sketchy
thoughts about how we can improve pcp security. Recall that there
were several different desires:
- wire level security
- non-root pmcd / pmda operation
- access control for pmdas
This is a slightly different take from Mark's from last year:
See http://oss.sgi.com/pipermail/pcp/2011-May/001769.html
------------------------
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:
ssh or stunnel or s_client:
+ offloads maximum security functionality
+ no changes to PDUs
+ full licensing / process-boundary independence
+ needs least client-side code
o needs local IP forwarding
(ie: pcp app@client: pmapi->localhost:####
ssh-tunnel@client: localhost:####->server:44321
pmcd@server: ->server:44321
or
pcp app@client: pmapi->localhost:####
stunnel@client: localhost:####->server:####
stunnel@server: server:####->server:44321
pmcd@server: ->server:44321)
o or else needs stdio based bidirectional-pipe pcpd transport
akin to pcpd<->pipe-pmda's
(ie: pcp app@client: pmapi <-> ssh
sshd@server: sshd <-> pmcd
or
pcp app@client: pmapi <-> stunnel to server:####
stunnel@server: server:#### <-> pmcd)
- requires more admin setup (ssh keys / certificates / xinetd)
- more process context switches, more kernel hops
- requires tunnel-subprocess control logic in pmapi
nss or openssl:
+ maximum self-sufficiency, performance
+ best certified crypto implementation (if mozilla nss)
o nss or openssl license mingling is fine with PCP's GPLv2+
- requires new tcp port, unless able to reuse via STARTTLS-ish
message, perhaps based on a new PDU_CREDS tuple
- requires much more pmcd/pmapi code, with e.g. funny-looking
mozilla FU_NctIons
- requires only small admin setup (certificate database mgmt)
Option #1 may be a reasonable quick hack.
Option #2 is probably a better long-term approach, say using NSS.
Converting the socket code en masse to the NSPR vs. #ifdef NSS'ing for
a parallel implementation would be a question of taste - and
acceptance of NSPR/NSS as a general prerequisite for PCP.
See also:
src/libpcp/src/connect.c, pdu.c.,
http://www.mozilla.org/projects/security/pki/nss/
http://www.mozilla.org/projects/nspr/
------------------------
The second issue is non-root operation of PMCD and PMDAs. It's clear
that the status quo (pmcd running as root) is undesirable and in some
venues unacceptable. One may envison the network-facing server as
evolving toward an unprivileged proxy, connecting to a motley crew (or
crue?) of PMDA processes running under distinct userids, and perhaps a
few dso PMDAs that require no privilege.
If the various PMDAs are all long-running processes, there appears to
be little complication: just add them to pmcd.conf. PMDAs that need
to be run as root would do so (via some initscript), including the
linux proc-scraper one. A "pipe" variant agent configuration in
pmcd.conf could be used to start on-the-fly agents under other userid,
with some setuid wrapper.
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
crontab(1) that adds peruser namespaces & pmdas to the configuration
file, something like:
user.foo random(?) pipe-setuid foo /path/to/foo/bin/pmda
Another solution would be to have such users to run their
own-privilege pmcd's, listening on their own port numbers (or stdio),
own config files, etc., isolated from the central pmcd. The central
pmcd/pmdas would have to protect their local comm sockets from such
interlopers.
------------------------
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,
but relying on something like SASL. Some new PDU_AUTH packets would
have to be designed to carry the authentication data (possibly
multiple rounds).
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
[acl]
forbid user : metric.name fetch, store;
forbid * : metric3.name list; (?)
allow *@host : metric2.name fetch;
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.
------------------------
Thanks for reading.
Please let me know to what extent all this makes sense.
- FChE
|