Hi Randy,
> I still don't see how monitoring a not-necessarily-
> trusted VM is in any way different from monitoring any other
> not-necessarily-trusted resource.
IMHO, it's not, but that does not appear to be the source of the concern.
Here's an attempt to explain what I think is going on based on the AgentX
example:
> If one uses AgentX as the implementation technology, the protocol
> provides the subagent no means of access to other information known
> to the master agent.
As I understand the emails the concern wrt AgentX would be:
If AgentX is used between:
a) an SNMP engine plus master agent in a VM; and
b) a sub-agent in the hypervisor,
then a malicious VM (that isn't supposed to be using AgentX) could
use AgentX to try to get into the hypervisor at least to access the
data in this MIB, and possibly for other nefarious purposes.
The secdir reviewer's original comment was:
> I would also mention the specific problem of software running in a virtual
> machine and accessing the hypervisor's variables. This is an attack vector
> that is somewhat specific to this MIB. It cannot be mitigated by network
> firewalls.
That would be a consideration if AgentX was running over some sort of
hypervisor syscall interface that could not be interposed on by a firewall.
In that scenario, some sort of access controls on that syscall interface
would be a good idea.
OTOH, if one forced the AgentX access into the hypervisor to be via network
traffic, then a firewall (e.g., a software firewall on the same hypervisor),
could provide some mitigation.
Thanks,
--David
> -----Original Message-----
> From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Randy Presuhn
> Sent: Monday, June 22, 2015 5:13 PM
> To: Randy Presuhn; Kathleen Moriarty
> Cc: draft-ietf-opsawg-vmm-mib.sheph...@ietf.org; draft-ietf-opsawg-vmm-
> m...@ietf.org; opsawg-cha...@ietf.org; The IESG; opsawg@ietf.org; draft-ietf-
> opsawg-vmm-mib...@ietf.org
> Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-
> vmm-mib-03: (with COMMENT)
>
> Hi -
>
> ARRGH! I apologize for sending a blast of HTML gobbledygook.
> Here's what I intended to say:
>
> Sorry, I don't mean to be dense, but I can't provide text to
> explain this because this rationale doesn't make any sense to
> me at all. I still don't see how monitoring a not-necessarily-
> trusted VM is in any way different from monitoring any other
> not-necessarily-trusted resource. Let me explain why this
> makes no sense to me.
>
> There are about two-and-a-half strategies for connecting MIB
> module instrumentation to SNMP engines:
>
> (1) build the instrumentation into the same process as the
> SNMP engine. Straightforward, but becomes a software
> configuration management nightmare.
>
> (2) use a mechanism such as AgentX to handle the chit-chat
> between the master agent (home to the SNMP engine) and
> subagents
>
> (a) instrumentation can be built directly into the resources,
> implying a certain level of trust that the subagent will
> respond truthfully to get/set, etc.
>
> (b) instrumentation can be built into processes which in turn
> monitor the resources by other means. This is useful
> when, for example, one does not have control of the
> source code for the resource.
>
> 2(b) would IMO be the obvious preferred choice for implementing
> this MIB module.
>
> If one uses AgentX as the implementation technology, the protocol
> provides the subagent no means of access to other information known
> to the master agent. A malicious subagent (one which impersonates
> another) is conceivable, but even a malicious subagent doesn't gain
> access to existing management information of the subagent it is
> impersonating - it only sees subsequent configuration requests
> and what it can glean from index values present in get/getnext/bulk
> requests.
>
> None of this is specific to management of VMs.
>
> If someone uses some homebrew mechanism in place of AgentX,
> all bets are off until there's been an analysis of that
> mechanism. Again, however, this is true whether VMs are in
> the picture or not.
>
> Randy
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
