Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT)

From: Randy Presuhn <[email-masked]>
Date: Mon, 22 Jun 2015 17:32:28 -0700 (GMT-07:00)

Hi -

>From: "Black, David" <[email-masked]>
>Sent: Jun 22, 2015 5:06 PM
>To: Randy Presuhn <[email-masked]>, Kathleen Moriarty <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
>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

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 23 Jun 2015 07:10:57 +0200

Hi,

Sent from my iPhone

> On Jun 23, 2015, at 2:32 AM, Randy Presuhn <[email-masked]> wrote:
> 
> Hi -
> 
> 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