Apologies for the delay, really didn't know how to respond to some of the
comments you made at the end there... but, lets try to keep moving things
forward anyway.
----- Original Message -----
> 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
This is an independent problem, but yes, that is absolutely required -
it is not exactly something I want, really, but it is going to have to
happen (e.g. for web access to some metrics, like proc.*).
Fortunately it seems that clients like Vector tend to use "localhost" by
default already, which is an inet connection, so we may just be able to
deprecate, hide behind options like pmdaproc(1) -A, and/or remove both
local: and local-context in pmwebd entirely, with few ill-effects.
> (b) you want only local: to have pmStore access
Eh? No. Its configurable, as always - users can choose ACLs appropriate
to their situation. Defaults should remain unchanged.
> (c) vector would like to use pmStore via pmwebd
+1
> (d) vector will need to use non-anonymous connections
Depends on the server side configuration, so no - this is not mandatory.
> (e) pmwebd will need to support authentication out of the box, or else
> (e.1) vector would not run out of the box
That's simply not the case. There may be parts of Vector inaccessible
without authenticating (which is *entirely appropriate* given the nature
of some metrics - as described in CVE-2012-3419), but it depends on the
end-user setup as to whether its needed at all.
> 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.
They will work remotely. As will _store in pmwebapi. Again its end-users
choice to allow/disallow access - "doesn't work" misrepresents the current
state of affairs.
> IMHO, we should instead improve the wire protocol [...]
Like I said (and I wont be repeating it again, again) this is a massive
undertaking and we'd end up with a special-case solution for containers.
We need both _store and a solution to the pmwebd authentication problem
anyway, so using store for containers is a good approach.
> > 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
So, to be clear, it sounds like you are confirming pmwebd has indeed
re-opened the information exposure issue from CVE-2012-3419 -- which
Mark, Ken, Florian and I worked very hard to close a few years back;
is that correct? (please answer with a clear yes or no, thanks - one
of the PCP maintainers will need to action fixing this in pmwebd in
the next release, if you're not going to take responsibility for it)
> [...] PCP is not near to meeting that burden.
There are no known vulnerabilities in PCP - the last set, from the
Red Hat security team were resolved as quickly as we possibly could
(for the record, none of that work was done by you IIRC) - and that
was very quickly indeed. Beyond that, this statement is just FUD,
and IMO very disrespectful to the people who have worked on security
flaws in the past.
I know of many sites using internet-facing PCP daemons, so please be
specific with any issues you know of...
> When a 1-line bash script can DoS pmcd for a problem that we've
> discussed years ago and accepted ever since, no.
What??? Could you please supply that script? - thanks. I'm going
to guess that you are referring to the issue/commit below - is that
correct? (and, wow, honestly? you've thought this inadequate for
over 3 years and did nothing about it? I ... wow ... I don't know
what to say. Other than, that kind of attitude is not welcome on
this project, sorry.)
commit 9ba85dca940de976176ce196fd5e3c4170936354
Author: Ken McDonell <kenj@xxxxxxxxxxx>
Date: Mon Aug 13 11:28:46 2012 +1000
Resolve event-driven programming flaw in pmcd
Fix an issue where a misbehaving client could prevent pmcd from
responding to other legitimate requests. Now uses a dead-hand
timer to ensure a client does not feed tiny pieces of PDUs into
pmcd, preventing service to genuine clients.
Original report and fixes reviewed by Florian Weimer of the Red Hat
Security team. Red Hat bugzilla bug #841706.
Security advisory CVE-2012-3421.
|