Hi -
> [...]
> > (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.
We're not talking about hypothetical configurations where someone
turns off the normal security settings, but about defaults. So yes.
> [...]
> > (d) vector will need to use non-anonymous connections
>
> Depends on the server side configuration, so no - this is not mandatory.
So yes, by default.
> > (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 [...]
So for the particular hypothetical part of vector that relies on
pmstore - the part we are actually talking about, yes.
> > 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.
So, yes, "work remotely" only in less-secure non-default configurations.
Perhaps it will help to simplify. Please spell out the your proposed
out-of-the-box local & remote capabilities of pmstore-based
pcp/pmwebd/vector or pcp-atop functionality. Any changes needed to
the current ACL's, or authentication non-setup?
> > IMHO, we should instead improve the wire protocol [...]
>
> Like I said (and I wont be repeating it again, again) this is a massive
> undertaking
Maybe. Would you like someone to scope it out?
> we'd end up with a special-case solution for containers. [...]
Not necessarily.
> [...] So, to be clear, it sounds like you are confirming pmwebd has
> indeed re-opened the information exposure issue from CVE-2012-3419
> [...]
What? No. That CVE was about (a) core pmcd (b) giving information
about every single system process (c) to every client. In this case
we have (a) optional pmwebd (b) only for its own uid (c) only to those
clients that are permitted to create local connections. (While
pmwebd, like pmproxy, lacks detailed outgoing ACL facilities - see
PR941 - it can limit context creation via -h/-N, and can run under any
old uid.)
> > [...] 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
You are confusing things. You seem to think that absence of a formal
CVE-labeled "vulnerability" bug makes a service suitable for direct
connection to a hostile network. That is simply not the case. There
are countless network services that have design limitations that make
them unsuitable for direct hostile contact. For better or worse, pmcd
is one of these.
> I know of many sites using internet-facing PCP daemons, so please be
> specific with any issues you know of...
Please post some IP addresses. But if any of those are filtered by
firewalls, ACLs, etc., then pmcd is not *directly* connected, so are
irrelevant to my point.
> > 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? [...]
There are multiple issues. That laudable commit from three years ago
made one particular problem -better-. pmcd now only hangs for a few
seconds after a hostile client sends a few bytes of data instead of
indefinitely. A few hundred of those hostiles, and legitimate packets
won't get through. Or a hostile client can make a large request, drop
response packets, and hang pmcd during the reply. Or hostile clients
busy-loop polling metrics that take nontrival amounts of time,
starving the system or crashing pmdas. (Future pmda auto-restart will
help a bit.)
Most of these particular cases come from pmcd's singlethreadedness and
trivial state machine. They are obvious by inspection. There are
probably other problems (e.g., binary wire protocols are notoriously
difficult to robustly decode) that would take more focused effort to
find.
> and, wow, honestly? you've thought this inadequate for over 3 years
> and did nothing about it? [...]
Suggestions to multithread pmcd or improve the state machine were
treated as ridiculous and impossibly complicated.
And maybe it is. The point is that such limitations can be OK and
nothing to be ashamed of. One can live with them in a low-hostility
network. But it is ignorant or dishonest to claim that pmwebd's man
page's forthright description of the exact same situation is somehow a
"horror story", or that it should disqualify one from discussing a
separate security topic.
- FChE
|