Hi - >From: "Black, David" <david.bl...@emc.com> >Sent: Jun 22, 2015 5:06 PM >To: Randy Presuhn <randy_pres...@mindspring.com>, Kathleen Moriarty ><kathleen.moriarty.i...@gmail.com> >Cc: "draft-ietf-opsawg-vmm-mib...@ietf.org" ><draft-ietf-opsawg-vmm-mib...@ietf.org>, "draft-ietf-opsawg-vmm-...@ietf.org" ><draft-ietf-opsawg-vmm-...@ietf.org>, "opsawg-cha...@ietf.org" ><opsawg-cha...@ietf.org>, The IESG <i...@ietf.org>, "opsawg@ietf.org" ><opsawg@ietf.org>, "draft-ietf-opsawg-vmm-mib.sheph...@ietf.org" ><draft-ietf-opsawg-vmm-mib.sheph...@ietf.org> >Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on >draft-ietf-opsawg-vmm-mib-03: (with COMMENT) > >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.
No, Agentx provides no way for a subagent to access MIB data. The worst that a malicious subagent can do is to impersonate a legitimate subagent. >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. AgentX and the related protocols I'm aware of provide no mechanism for a subagent to access the master agent's variables. Providing such a mechanism could completely negate the value of VACM. If someone's homebrew interface allows this sort of wanton behaviour, that's their problem. We can't (and should try to) call out every conceivable ill-advised implementation strategy. >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. No. It would not provide any more protection than any other IPC mechanism might. AgentX and related mechanisms assume a degree of trust between the master and subagent. This is documented, for example, in the AgentX RFC. A consequence of this assumption is that the subagent code instrumenting a non-trusted resource should be implemented in a way that it is protected from misbehaviour by the resource; as a practical matter, this means in a separate subagent process, distinct from both the master agent and the stuff being managed. None of these concerns are the least specific to management of hypervisors / VMs, and are, as far as I know, widely understood among implementors of subagent technologies. Randy _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
