Subject: VACM and DISMAN

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 3 Jul 1998 15:38:02 +0200

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: Uri Blumenthal <[email-masked]>
Date: Fri, 3 Jul 1998 14:22:16 -0400 (EDT)

> based access control" (RBAC):

IMHO, VACM was not designed to accomodate it.

One *can* use it that way by modifying the "match" criteria.

>    impossible to assign multiple "roles" to a user.

If a principal can be a member of more than one group, the main
obstacle is how to choose which group to use for access control
decisions?

>    This means that in
>    collector". 

Whch is no big deal, except how would you convey which group to use?

>    An alternative would be to give the principals "joe"

It works now, but it is ugly.

> objects.

Partially disagree. VACM was to protect small agents with limited
resources, but not necessarily few control objects...

What is needed is some way to deal with one-principal-in-many-groups
issue. Do you add a group or a role to the PDU? Do you modify the
matching algorithm (if so - how)?
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 4 Jul 1998 19:56:42 +0200

>>>>> Uri Blumenthal writes:

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

Uri> If a principal can be a member of more than one group, the main
Uri> obstacle is how to choose which group to use for access control
Uri> decisions?

Depends on the semantics you use. For DISMAN, something similar to the
UNIX model would be suitable where the access rigths are actually the
union of the access rights for each group. You simply loop over all
the groups for a given <securityName, securityModel> pair and you
return "access allowed" as soon as you got a positive match. If the
loop completes without a match, you return "access denied".

This is only an example. You can define more complicated functions.
It is all a matter of what the semantics should be of being in
multiple groups.

>> 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".

Uri> Whch is no big deal, except how would you convey which group to
Uri> use?

You are right that a strict RBAC model would need to convey the role.
I am not saying that we have to have a strict RBAC model. I am saying
that a reasonable and scalable VACM configuration for the DISMAN
Script MIB does not seem to be possible without creating several
snmpSecurityNames for a user and lots of repeated entries in the view
family tables.

Sure, VACM can be modified to solve that problem. The SNMPv3 WG has to
decide what to do. But you can be sure that I will be back when people
want to gather operational experiences.
							Juergen

---

From: Keith McCloghrie <[email-masked]>
Date: Sun, 5 Jul 1998 15:34:15 -0700 (PDT)

> loop completes without a match, you return "access denied".

This loop will have a performance impact.  It's already the case that a
GetNext can take a significant amount of processing due to
access-control checking; your loop has a multiplicative effect on
that.  An implementation could pre-compute the tree for each user, but
that could require a significant amount of memory.

> It is all a matter of what the semantics should be of being in
 
I understand it was only an example.  Hopefully, there's another example
which has a lesser performance impact.

Keith.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Jul 1998 10:33:40 +0200

>>>>> Keith McCloghrie writes:

Keith> This loop will have a performance impact.  It's already the
Keith> case that a GetNext can take a significant amount of processing
Keith> due to access-control checking; your loop has a multiplicative
Keith> effect on that.  An implementation could pre-compute the tree
Keith> for each user, but that could require a significant amount of
Keith> memory.

I disaggree that allowiong a user to be a member in multiple groups
has a multiplicative effect on the getnext/getbulk performance.

VACM currently requires the security administrator to configure the
pre-computed trees for all group combinations. This means lots of VACM
tree family entries while the time to do access control checking
(which is essentially the number of discarded getnexts/getbulks) will
be roughly the same.

The performance penalty is a function of the access control rules in
place. It is IMHO only marginally influenced by the scheme you use to
describe the access control rules.
							Juergen

---

From: Keith McCloghrie <[email-masked]>
Date: Mon, 6 Jul 1998 10:17:59 -0700 (PDT)

> has a multiplicative effect on the getnext/getbulk performance.

As I understood your proposal, each iteration of the "loop" that you
proposed was to test a particular group's access privileges, so that
the number of times around the loop is the number of groups that a
user is in, i.e., denying an access for a user in N groups is N times
as much checking as denying a user in one group.  That's what I meant
by multiplicative.  This is independent of GetNext/GetBulk.  However,
N times a larger number is a larger absolute/more noticeable increase,
and so it's GetNext performance which appears to suffer most. 

Did I misunderstand ?

> describe the access control rules.

Right, putting users in multiple groups has performance implications, 
which is the point I was trying to make in my original message.

Keith.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Jul 1998 20:03:46 +0200

>>>>> Keith McCloghrie writes:

Keith> As I understood your proposal, each iteration of the "loop"
Keith> that you proposed was to test a particular group's access
Keith> privileges, so that the number of times around the loop is the
Keith> number of groups that a user is in, i.e., denying an access for
Keith> a user in N groups is N times as much checking as denying a
Keith> user in one group.  That's what I meant by multiplicative.
Keith> This is independent of GetNext/GetBulk.  However, N times a
Keith> larger number is a larger absolute/more noticeable increase,
Keith> and so it's GetNext performance which appears to suffer most.

You are right that a user in N groups requires to repeat the check N
times in the worst case. So you will have N * M checks in the worst
case if the average number of subtrees defined for each group is M.

However, I argue that without having this feature, people will be
forced to create VACM configurations with N * M subtree definitions
for a given user since you can not share definitions. So you will gain
nothing in the isAccessAllowed() function (you still need to do N * M
tests in the worst case) but you will pay be a high price in terms of
the total number of VACM MIB entries needed and the complexity a
security administrator has to deal with.

I would also expect that the number of discarded method function calls
during GetNext processing defines the performance bottleneck and not
the number of access control rules you have to check. (The later one
is a tight loop while the method function calls very likely include
costly interactions with a hardware device or a subagent.) And the
number of discarded method function calls depends on how simple or
complex the access control configuration is and how intelligent the
agent is to skip method function calls that are known to be out of
scope with regard to the access control rules.
							Juergen