Hi, Sent from my iPhone
> On Jun 23, 2015, at 2:32 AM, Randy Presuhn <[email protected]> > wrote: > > Hi - > >> From: "Black, David" <[email protected]> >> Sent: Jun 22, 2015 5:06 PM >> To: Randy Presuhn <[email protected]>, Kathleen Moriarty >> <[email protected]> >> Cc: "[email protected]" >> <[email protected]>, >> "[email protected]" <[email protected]>, >> "[email protected]" <[email protected]>, The IESG <[email protected]>, >> "[email protected]" <[email protected]>, >> "[email protected]" >> <[email protected]> >> 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. This is not clear in the draft. If you make this clear, you put the problem out-of-scope and you might be providing helpful guidance to someone implementing with less experience than you. This is a non-blocking comment, so I'll leave it to the Responsible AD. Thanks, Kathleen > 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 [email protected] https://www.ietf.org/mailman/listinfo/opsawg
