[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: snmpconf Issue #17: security questions


  The background behind the current design is that we needed a way to
delegate authority to scripts that preserved security by preserving the
integrity of the requested operation (in other words, don't allow a bad
guy to rewrite my script so that it says to reboot the router while it
continues to run with my authority).

The disman group has been down this road before and had perfected the
text that I re-used here regarding using the security credentials of the
requester. However, I believe the expression mib and event mib have a
security hole whereby the integrity of the operation is *not* preserved
because the nature of the operation can be changed after the credentials
have been stored. The PM MIBs rule regarding using the credentials of
the writer of the last-updated code segment avoids this problem because
any third party who attempts to modify my code changes the script to run
with their authority, gaining no authority.

That is why the who wrote the code *is* important in determining who it
should run as. The modification in your choice #3 would directly break
this security mechanism. Choice #2 would require us to create a new
ACL-list that maps "requester credentials" to the "credentials they're
allowed to use" - it has a fairly high cost and it may be a mistaken
idea security-wise*. Of course choice #4 would also allow authenticated
policies to be hijacked.

Unfortunately I didn't finish the job because there's still a security
hole left on my todo list: this one's a related race condition. Let's
say I have a script that I'm going to download in three code segments. I
download code segment 1. The bad guy replaces code segment 1 with code
that reboots the router before I finish downloading code segments 2 and
3. So the last writer is me, yet the code won't do as I intend because
integrity has been compromised.

2 potential solutions (please suggest others):
1) Dictate that the code segments are contiguous starting at zero and
cannot be modified once written (unless some reset happens at the policy
level). Use the credentials of the last writer.
2) Simply say that if more than one credential is used amongst all code
rows for this policy and all policyTable objects for this policy, then
the policy is disabled. This is my preference because it also ensures
integrity of the objects in the policy table itself which can also have
some security significance (particularly elementType, Group, Precedence,
Schedule and Parameters).


*Lets say I have medium authority and joe has high authority. If you
want to give me high authority it would be better to explicitly give me
high authority than to let me use joe's authority.

Wes Hardaker wrote:
> The MIB text currently states:
>   When executing this action, if SNMP requests are made to the local
>   system, access to objects is under the security credentials of the the
>   requester who modified the most recently modified pmPolicyCodeEntry
>   associated with either the pmPolicyFilter value or pmPolicyAction
>   value. In other words, modification of any part of a policy's filter
>   or action will change the credentials stored for the policy.
> And the issue states:
>   Should we consider adding an OwnerString?
> Choices:
> 1) leave as is.  I don't think this is a good option.  First off, who
>    is the code is going to be run as shouldn't be determined by who
>    wrote the code.  Even worse, who wrote (updated) the "last segment"
>    of the code even though all the other segment was someone else.
> 2) Provide a "securityName" to be used in a separate column (this is
>    NOT an on owner string and shouldn't be confused with such.
>    Ownership of an object to modify it is not necessarily related to
>    actions taken when an object's is run, though they probably will be
>    99% of the time).  However, if you use a securityName then you
>    should also have a securityModel, as the current ACM available
>    (VACM) uses these two to begin the decision process of whether an
>    operation is allowed or not (see vacmSecurityToGroupTable).
>    + Listed explicitly in the row.
>    - Presumes that a securityModel and securityName are all that is
>      needed (which may be a problem if a VACM replacement needs more
>      in the future).
>    - yet more columns
> 3) Whoever last modified the pmPolicyEntry row definition is who the
>    filter/action should be run as.  Similar to #1, but changes where
>    the authentication comes from.  Most importantly, only one row is
>    used to make this decision (as opposed to the code table with
>    multiple segments involved).
>    - Isn't listed explicitly and is misleading.
> 4) The security credentials of the entity that made pmPolicyEntry row
>    definition "active" would be used.  This is similar to how the
>    DISMAN-EVENT-MIB implements things.
>    + Allows changing it by making it not-in-service then active again.
>    - Isn't listed explicitly and is misleading.
>    - impossible to implement within the AgentX IETF subagent protocol,
>      but there are other issues with that protocol already (no SETs
>      allowed from subagent to master).
> I'd shoot for #2 if the choice is up to me (ie, no one responds to
> this saying otherwise) though would be happy with #4 as well.
> I'll write needed text for any decision reached on this list I'm happy
> with ;-)
> --
> Wes Hardaker
> NAI Labs
> Network Associates