----- Original Message -----
> > > [...]
> > > security concerns dictate that every pmda that handles stores needs to
> > > be audited & ACL machinery applied.
> >
> > If you like, sure, but I know most/all of the store metrics and none are
> > of particular concern to me off the top of my head. So, let us know how
> > your audit goes - any issues there are independent of this effort though
> > (iow, via pmcd & existing clients, not new to pmwebd).
>
> Placing the burden of proof of security on someone other than the
> person loosening security is not appropriate.
You're asserting this pmcd/PMDA access "loosening" is needed, but I do
not think that's necessary (rather, we need to tackle holes in pmwebd
functionalily).
> 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.
IOW, this is a pmwebd (lack of) security problem, not a pmcd/PMDAs issue
as you seem to be thinking. It's fixable though.
Perhaps it will help to think about existing pmwebd issues from this POV:
I wonder also about pmwebd exposing "local:" to unauthenticated clients,
and whether that hole needs to be filled (even for read-only access).
[ analogous issue to http://oss.sgi.com/bugzilla/show_bug.cgi?id=1101 ]
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).
Likewise for local-context connections via pmwebd - I wonder if we should
be restricting access to those already.
I see several calls to MHD_basic_auth_get_username_password in pmwebd,
but not sure these two cases (unix: / local-context) are covered, it'd
appear not from a code inspection - can you confirm? Perhaps we need
something like the -A option to pmdaproc(1) for pmwebd to enable those
two context styles without access control on the "pcp" user account?
(and default to not allowing access (401?), like pmdaproc does)
> 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 kind of thing, and documenting that pmwebd relies on putting Apache in
front of it to provide security, does beg the question as to whether using
store in such environments is going to be an issue (given the expectations
that are being set for pmwebd already via the docs, IOW). Anyway ... it's
looking like we need to start improving all these things, just as was done
for pmcd.
cheers.
--
Nathan
|