Subject: RE: VACM and DISMAN

From: Pete Lynch <[email-masked]>
Date: Mon, 6 Jul 1998 09:28:29 +0100

Can't the user/group identity stuff be done at the client:
- leave VACM as it is. Have your client establish one user ID for each user or group
- maintain the membership records at the client
- try to access view under user id alone
- try to access view under each group id in turn
- cache "best" result for remainder of "management session" or until you feel the world may have changed

That achieves the end result for the time being without changing SNMPv3. 

The user/group mapping may be done completely independently (for example, in an LDAP directory), reducing
the complexity of security administration.

That said, given that the performance penalty only really exists when a user is a member of 
many groups, and is thus capable of being worked around. I would be comfortable with changing the spec.

Pete

-----Original Message-----
From:	Juergen Schoenwaelder [SMTP:[email-masked]]
Sent:	Friday, July 03, 1998 14:38
To:	[email-masked]; [email-masked]
Subject:	VACM and DISMAN

I am trying to find `good' VACM configurations for the Script MIB. And
it turns out that this is more complex than I thought. What I would
like to have for the Script MIB is what people usually call "role
based access control" (RBAC):

  A user (a snmpSecurityName in RFC 2271 speak) maps to one of more
  roles he has (e.g. routing administrator, web service manager, data
  collector) and each role has associated "transactions" that can be
  called in order to fulfill the tasks for a given role. Transactions
  are either SNMP operations (in case of traditional agents) or more
  complex management functions implemented via scripts.

It would be cool if VACM could be configured so that we get something
pretty similar to the RBAC model described above. In an ideal world,
the security administrator would configure VACM so that it is pretty
easy to assign user "joe" the role of a "routing administrator and
data collector" and user "lara" the role of a "web service manager and
data collector".

I started to look deeper into VACM and I finally realized that VACM is
not ideal with regard to the RBAC model described above:

1) At first glance, it looks like if the VACM group can be used to
   describe roles. However, a given user (identified by securityName
   and securityModel) can only be in a single group, which makes it
   impossible to assign multiple "roles" to a user. This means that in
   the example above, I have to create a group "routing administrator
   and data collector" and another group "web service manager and data
   collector". An alternative would be to give the principals "joe"
   and "lara" two snmpSecurityNames and tell them that they are
   responsible to select the right name for a given task.

2) Having to define lots of groups would not be that bad if one could
   at least share common view tree family definitions. However, VACM
   does not allow to do that. So, in the example, I would have to
   duplicate the tree family entries needed to be a data collector for
   the groups "routing administrator and data collector" and "web
   service manager and data collector", which does not look very
   attractive.

   Things get really worse if you have a DISMAN environment and you
   want to give users their own "sandboxes" where they can install
   scripts of expressions to be evalutated. You either end up doing a
   one-to-one mapping between securityNames and VACM groups (thus
   rendering VACM groups useless and duplicating entries in the tree
   family table) or you hand out another securityName which is used to
   select the private "sandbox".

Please let me know if I have just overlooked something in RFC 2275. If
my interpretation of RFC 2275 is correct, I would argue that VACM
might work pretty well to protect small agents without many control
objects. But VACM has a pretty serious scalability problems for agents
where you need different but similar levels of access control of
multiple users, like the Script MIB.

Are there already fielded implementations of VACM? Are there any
experiences or guidelines how to use it without creating huge MIB
tables?
							Juergen

Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3283)

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 22 Jul 1998 09:22:41 -0700 (PDT)

Hi - 

Since there seems to be virtually no disman-specific content in this
thread, I suggest limiting its continuation to the [email-masked]
list.

 -----------------------------------------------------------------------
 Randy Presuhn           Email: [email-masked]      http://www.bmc.com     
 Voice: +1 408 616-3100  BMC Software, Inc.           965 Stewart Drive
 Fax:   +1 408 616-3101  Sunnyvale, California 94086  USA
 -----------------------------------------------------------------------
 In accordance with the BMC Communications Systems Use and Security
 Policy, I explicitly state that although my affiliation with BMC may be
 apparent, implied, or provided, my opinions are not necessarily those
 of BMC Software and that all external representations on behalf of
 BMC must first be cleared with a member of "the top management team."
 -----------------------------------------------------------------------