Subject: snmpconf Issue #17: security questions

From: Wes Hardaker <[email-masked]>
Date: 02 Apr 2001 15:59:43 -0700

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

---

From: Steve Waldbusser <[email-masked]>
Date: Tue, 03 Apr 2001 02:25:59 -0700

Wes,

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

Regards,
Steve

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

---

From: Steve Waldbusser <[email-masked]>
Date: Tue, 03 Apr 2001 20:58:40 -0700

> with their authority, gaining no authority.

I was wrong regarding the expression and event mibs - you can use 
VACM to protect against a third party modifying the operation.

Steve

---

From: David Partain <[email-masked]>
Date: Fri, 20 Apr 2001 18:15:49 +0200

Greetings,

http://www.snmp.com/snmpconf/mailing-list/msg00661.html has the 
thread in question.

There have been two messages thus far.  That is simply not enough 
to make any judgement on so-called "consensus".  So... I'm going
to give my viewpoint.  Other voices welcome.

*chair hat off, technoweeníe hat on*
 
 I personally believe that it's going to be very difficult to do
 better than the DISMAN folks have done and am inclined to leave
 the security model as it is (since that seems to be what DISMAN
 decided - Juergen?  Randy?).

 There may be reason to wordsmith to some degree, but operating
 under the credentials of the last writer seems to be the right
 thing to do given what I know now.

Wes wrote:
> 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.

That's not what happens.  Who _wrote_ the code and who _writes_
the code into the code tables are two entirely separate issues.

> Even worse, who wrote
> (updated) the "last segment" of the code even though all the
> other segment was someone else.

Keep in mind, of course, that the code tables are protected by
the VACM.  So, if you only want joe to write to the table, you
can do that.  If you set it up so that both joe and mary are
allowed to write, then you'd better be sure joe and mary know
what they're doing.  I see the VACM as the solution to what
you're describing.

So, I believe we have it right - or the best we can do - already.

With kind regards,

--
David Partain                  [email-masked]
Ericsson Radio Systems AB      Tel:    +46 13 28 41 44
Research and Innovation        Fax:    +46 13 28 75 67
P.O. Box 1248
SE-581 12  Linköping, Sweden

---

From: Wes Hardaker <[email-masked]>
Date: 30 Apr 2001 13:48:53 -0700

>>>>> On Fri, 20 Apr 2001 18:15:49 +0200, David Partain <[email-masked]> said:

(Sorry for the delay.)

David> I personally believe that it's going to be very difficult to do
David> better than the DISMAN folks have done and am inclined to leave
David> the security model as it is (since that seems to be what DISMAN
David> decided - Juergen?  Randy?).

I think that's also the case and we don't have a whole lot of choice
here with respect to implementing something at all.

>> be determined by who wrote the code.

David> That's not what happens.  Who _wrote_ the code and who _writes_
David> the code into the code tables are two entirely separate issues.

Sorry, that's true and you can assume that I mean "wrote" the row, not
the code.

>> Even worse, who wrote (updated) the "last segment" of the code even
>> though all the other segment was someone else.

David> Keep in mind, of course, that the code tables are protected by
David> the VACM.

Yep.  It's more a complexity issue.  Consider 2 segments of code,
originally written by a low-level system administrator that had
read-only access to the MIB tree.  Lets say a system administrator
with full access privileges notes that the first code segment has a
bug in it, and fixes it.  He may not have looked at the second segment
to ensure that it wasn't performing an illegal set.  The operations of
the entire code set are now executed at the full-privileged level now.

In general, I simply disagree that the access control should be
associated with the "last SET" to the row when that column may be
updated frequently.  It makes it a pain for administrators sharing
tasks to ensure that things execute with a "standard" permission set,
since one administrator making any changes to the code affect how the
code operates.  I'm much more likely to want the code to run as
"demonuser" with a restricted set of access control but give myself
(with full permissions) write access to the code segments.

The "last SET to some particular activation column" makes much more
sense to me, which is how the DISMAN MIBs operate.

David> So, if you only want joe to write to the table, you can do
David> that.  If you set it up so that both joe and mary are allowed
David> to write, then you'd better be sure joe and mary know what
David> they're doing.  I see the VACM as the solution to what you're
David> describing.

I'm not trying to imply otherwise.  It *can* be handled correctly
using the current definition.  I just think it could be a lot more
clear-cut if done a different way and less confusing.

David> So, I believe we have it right - or the best we can do - already.

It'll work, as I mentioned.  It's just not optimal, IMHO.

-- 
Wes Hardaker
NAI Labs
Network Associates