[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

snmpconf Issue #17: security questions

The MIB text currently states:

  When executing this action, if SNMP requests are made to the local
  system, access to objects is under the security credentials of the the
  requester who modified the most recently modified pmPolicyCodeEntry
  associated with either the pmPolicyFilter value or pmPolicyAction
  value. In other words, modification of any part of a policy's filter
  or action will change the credentials stored for the policy.

And the issue states:

  Should we consider adding an OwnerString?


1) leave as is.  I don't think this is a good option.  First off, who
   is the code is going to be run as shouldn't be determined by who
   wrote the code.  Even worse, who wrote (updated) the "last segment"
   of the code even though all the other segment was someone else.

2) Provide a "securityName" to be used in a separate column (this is
   NOT an on owner string and shouldn't be confused with such.
   Ownership of an object to modify it is not necessarily related to
   actions taken when an object's is run, though they probably will be
   99% of the time).  However, if you use a securityName then you
   should also have a securityModel, as the current ACM available
   (VACM) uses these two to begin the decision process of whether an
   operation is allowed or not (see vacmSecurityToGroupTable).
   + Listed explicitly in the row.
   - Presumes that a securityModel and securityName are all that is
     needed (which may be a problem if a VACM replacement needs more
     in the future).
   - yet more columns

3) Whoever last modified the pmPolicyEntry row definition is who the
   filter/action should be run as.  Similar to #1, but changes where
   the authentication comes from.  Most importantly, only one row is
   used to make this decision (as opposed to the code table with
   multiple segments involved).
   - Isn't listed explicitly and is misleading. 

4) The security credentials of the entity that made pmPolicyEntry row
   definition "active" would be used.  This is similar to how the
   DISMAN-EVENT-MIB implements things.
   + Allows changing it by making it not-in-service then active again.
   - Isn't listed explicitly and is misleading. 
   - impossible to implement within the AgentX IETF subagent protocol,
     but there are other issues with that protocol already (no SETs
     allowed from subagent to master).

I'd shoot for #2 if the choice is up to me (ie, no one responds to
this saying otherwise) though would be happy with #4 as well.

I'll write needed text for any decision reached on this list I'm happy
with ;-)

Wes Hardaker
NAI Labs
Network Associates