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 14:13:16 -0700 (GMT-07:00)

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

---

From: "Black, David" <[email-masked]>
Date: Tue, 23 Jun 2015 00:06:53 +0000

Hi Randy,

> I still don't see how monitoring a not-necessarily-
> 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:

> 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:[email-masked]] On Behalf Of Randy Presuhn
> Sent: Monday, June 22, 2015 5:13 PM
> To: Randy Presuhn; Kathleen Moriarty
> Cc: [email-masked]; draft-ietf-opsawg-vmm-
> [email-masked]; [email-masked]; The IESG; [email-masked]; draft-ietf-
> [email-masked]
> Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-
> vmm-mib-03: (with COMMENT)
> 
> Hi -
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: joel jaeggli <[email-masked]>
Date: Mon, 22 Jun 2015 22:14:02 -0700

> Hi Randy,

<snip>

> In that scenario, some sort of access controls on that syscall interface

that's consistent with the security considerations for agent-x

> could provide some mitigation.

I don't recall there inherently being a reason why agents couldn't use
TLS, or some other socket transport like websockets it's just a
tcp-stream wrapping agent-x pdus.