RE: Updating the MIB security guidelines

[Randy Presuhn <rpresuhn@dorothy.bmc.com>]

Hi -

> Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15583D8B3@nl0006exch001u.nl.lucent.com>
> From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
> To: Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>
> Cc: mibs@ops.ietf.org
> Subject: RE: Updating the MIB security guidelines
> Date: Tue, 31 Dec 2002 12:27:49 +0100
...
> > And even valus of not-accessible index objects can be retrieved by
> > reading some column and unpacking the index...
> > 
> I understand that, but that is implicit if you get access to 
> an accessible column.
>
> Are you saying that we should add something about this?

I think the point is that in some cases, even knowledge of the
existence of a row can be sensitive information.  For example,
consider a table indexed by user id.  In such a case, that
MIB's security considerations section should probably have
words to the effect that in some environments, the user names
are themselves sensitive, and that consequently, even though
the other information in the table might not of itself be
sensitive, access to the table might need to be restricted.

> I guess one could limit access to a specific column to exlcude
> some indices and not others.... 
> Oh well... that is where I find VACM went overboard (mea culpa,
> I am co-author/editor).
...

I think the fine-grained access control is actually one of
the things we did right in VACM.  Any of the alternatives
considered would require a master agent to have knowledge of
MIB structure, requiring a huge increase in complexity.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  SJC-1.3141
 randy_presuhn@bmc.com  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------