Hi -
> > Change the default pmcd.conf [access] acl today.
>
> ... but if pmwebd is on same host as pmcd (normal situation) there's no
> need to loosen anything. So I wasn't thinking we'd be loosening this but
> rather that pmwebd would be required to have clients providing some kind
> of credentials (basic auth?) before it would do stores on their behalf.
> [...]
It sounds like you're thinking that:
(a) you don't want anonymous users to be able to connect to local: via pmwebd
(b) you want only local: to have pmStore access (the status quo, which is
already too open IMHO, without the audit)
(c) vector would like to use pmStore via pmwebd
ergo:
(d) vector will need to use non-anonymous connections
(e) pmwebd will need to support authentication out of the box, or else
(e.1) vector would not run out of the box
Given that we haven't figured out how to configure workable pmcd-level
authentication (sasl) out of the box, expecting pmwebd to do so is ...
optimistic.
But beyond that, it would strike me as sad if something as fun as this
flavour of container monitoring were only practical on the local host.
The hypothetical (?) pmStore-necessitating extensions to "pcp atop"
wouldn't work remotely.
... all because of an API choice that is nothing but an optimization,
when the apps could just use a per-container pmNewContext.
IMHO, we should instead improve the wire protocol to make
pmNewContexts (and pmDupContext - don't forget about that one) work
efficiently, i.e., do more & better fd/socket sharing rather than
less. Yes, some new PDUs. But the API stays cleaner, and runtime is
more efficient (no ping-pong of pmStore-switcheroo packets).
> That access re-opens the old information exposure issue from
> pmdaproc we keep running into, no? (pmwebd runs as "pcp"
> user... and "unix:" will auto-authenticate as that but web clients
> have not authenticated at all). [...]
(Don't get confused by the coincidence of the "pcp" userid pmwebd
normally runs under. Any other userid would get those same marginal
pmdaproc privileges, and pmStore (!), if connected through local:
transport.)
> > If you examine the SECURITY section of pmproxy(1), or pmcd(1) for that
> > matter, you might notice analogous "horror story" cautions about
> > encryption, admission control, etc. Or you would, if those tools
> > even had a SECURITY man page section. They do not.
>
> It's covered in PCPIntro(1) - there's certainly nothing there like "pmwebd
> is suitable for direct exposure to trusted networks only, due to several
> security limitations." though, like is found on pmwebd(1).
That is quite an ironic choice of quote. Those with network security
or sysadmin experience know well not to directly expose general
purpose daemons to hostile networks. I bet a survey would find
approximately zero exposed pmcd's on the Internet (never mind
pmproxy's), and for good reason.
There is a very high burden of robustness for software directly
connected to the public. PCP is not near to meeting that burden.
When a 1-line bash script can DoS pmcd for a problem that we've
discussed years ago and accepted ever since, no. It's not ready.
> That kind of thing, and documenting that pmwebd relies on putting
> Apache in front of it to provide security
Again a bit ironic choice. Apache turns out to be an excellent
frontend. It can apply an excellent mix of controls based on ACLs,
usage rates, and can superimpose authentication/authorization. pmwebd
can already blanket-lock some of its own capabilities (-N, -A, -R,
-G), but a web proxy can do so with a finer granularity, because it
can look into the messages in the URLs! Most of that impossible with
pmcd/etc. because of the unique wire protocol.
- FChE
|