[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf General Functional Questions
I think I understand what you are asking for. If there were a way without
excessive violence to the system to cause the "user" to get an error if he
tried to change something that was under policy control without first
removing it, I would at least be sympathetic to the two step process.
But, if we make it a two step process without such coupling, what happens
is that the "user" makes a change, gets no error, and comes back later and
discovers it is gone. The "user" involved may well not be familiar with
the policy mechanisms (someone else takes care of that). He needs to make
the change. Forcing him to try to go through audit logs to figure out what
happened is not sensible, particularly since network management is NOT this
"user"s primary task. he is a network engineer trying to fix a customer
Whether this "user" is aware of the organizations desired policies is an
organizational issue, not a protocol issue. Making sure that there is
someway to tell that he has overriden the policy (the flag that can be
checked, and the logs to say who set the flag) is a protocol issue.
It may be that different organizations desire different behaviors in this
regard. Experience suggests to me however that the larger organizations
which most want policy also have folks who need to make changes without
significant hinderance. And adding more options to the behavior does not
seem like a good way out of this mess. That will just give our users more
ways to get confused.
Joel M. Halpern
At 12:23 PM 7/12/00 -0700, you wrote:
>All we're trying to do is make sure that when operators override a
>policy that they do so deliberately. Access control is not the
>right tool to accomplish this.
>If every operator has some more restrictive "root" priveleges and all
>objects require this new privelege, nothing has changed from an access
>control perspective and the same mistakes will be made.
>And administering fine-grained access control to restrict only those
>objects currently under policy control is a nightmare.
>Jon Saperia wrote:
> > on 07/06/2000 5:23 PM, Steve Waldbusser at email@example.com wrote:
> > > All I want is for the field engineer to have to do something special
> > > to override a policy. Shouldn't he at least know that he has done
> > > something significant? Wouldn't it be good if he was thus encouraged
> > > to think twice? Wouldn't it be good if he was encouraged to mention it
> > > to the network architect? ("hey, I needed to disable the blah policy
> > > on trunk 7 last night because it was interacting poorly with the
> > > backup circuit").
> > >
> > > My proposal is that he issue 2 commands rather than one. The first
> > > disables the policy on the interface and the second is a normal
> > > SNMP set that makes the change.
> > Steve, I am in agreement with your concern. I think we can accomplish this
> > without having to issue two commands though. You gave the example of not
> > running as 'root' to avoid making mistakes - most of us have learned that
> > lesson. My point is that the access/change of policy is an operational
> > policy (forgive the pun) decision. If a system is under policy control,
> > access to the MIB tree that contains everything except the policy objects,
> > should be quite restricted. The operator would then have to use the root
> > password to make the changes. This is analogous to 'su root' make all your
> > changes and exit. Your preference would be to have the person 'sudo change
> > 1', 'sudo change2' etc. In our case the equivalent of the sudo is to make
> > the explicit something special you suggest.