Subject: Re: VACM and DISMAN

From: Randy Presuhn <[email-masked]>
Date: Mon, 6 Jul 1998 17:15:20 -0700 (PDT)

Hi- 

> Date: Mon, 6 Jul 1998 20:03:46 +0200
> From: Juergen Schoenwaelder <[email-masked]>
> To: [email-masked]
> CC: [email-masked], [email-masked]
> Subject: Re: VACM and DISMAN
> References:  <[email-masked]>
> 
> 
> >>>>> 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.
...

It seems like the other appropach you outlined makes more
sense, where the administrator defines for each user a set of
<user>_in_<role> securityNames with the supporting USM entries and
vacmSecurityToGroupEntries.  In this case, one would only need <role>
groups and avoid excessive duplication of subtree information.  The 
downside is that the command generator would have to be explicit about
the role in which the user is acting, and the security administrator
would need to be aware of those roles.  This is probably not a bad thing.

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

---

From: Uri Blumenthal <[email-masked]>
Date: Mon, 20 Jul 1998 22:24:43 -0400 (EDT)

> would need to be aware of those roles.  This is probably not a bad thing.

1. "Role-based" authorization models usually have separate [independent]
   policies for roles known AND for users known. Each decision is made
   based on what the CONJUNCTION of the User and Role permissions are.

   For example:

	A role "operator" has access rights X. A role "netadmin" has
	access rights Y. A user "randy" has general access rights Z. 
	So when a request comes from "randy-in_role-operator", the
	access rights to check it against will be what is included
	in the set "X AND Z". Whatever is not included in BOTH will
	automatically be forbidden.

   The main reason for role-based models is to be able to modify roles
   independently from principals and vs. versa.  It is NOT easy to
   design and administer a good role-based access control model.

2. It usually is a very bad idea to allow the receiving entity to guess
   what role to apply, especially so if the guessing algorithm is "go
   for the mightiest access". Those who know me, have already figured
   out that I'm tempted to use a much stronger word than just "bad".

3. Sometimes when people say "role-based", what they really mean is:

	We want to have just a few access control policies, like
	"any operator can do X, any netadmin can do Y and any
	superuser can do Z", but we want to maintain a detailed
	log of who-did-what, including name-and-serial-number.

	So the "principal" ID goes into the log, but the access 
	control is decided using the "role" rather than the 
	"principal".

In any case, the request MUST carry the "role" or the "group" tag
in it, for anything role-based to make any sense at all.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>