Subject: [Netconf] Comments on draft-ietf-netconf-access-control-02

From: Charlie Kaufman <[email-masked]>
Date: Mon, 21 Mar 2011 06:31:33 +0000

I was recently reminded that I am listed as security advisor to the netconf group and that there is an access control document that should be reviewed by a security advisor. I probably shouldn't be security advisor to this group, and that might get corrected through other channels.

An important role of a security advisor is to try to keep a group out of trouble in the sense of having someone from the security space come in and disrupt things at the last minute. That mostly involves not stepping on certain land mines along the way. I don't believe this document is likely to generate such excitement (though you can never know for sure). Here are some thoughts based in part on my experience in security and in part on what I've seen blow up in IETF. I apologize for reviewing what I see now is the previous version, but I doubt much has changed that would affect my comments.

Access control is always messy. Authentication can be based on cryptographic algorithms and can be correct or have subtle bugs, and people "enjoy" spending time debating arcane details around key sizes, approved algorithms, and which of two equivalent variations is "better". Access control, on the other hand, is a matter of figuring out how to be able to express all the things you need to be able to express without making the statements so large that no one can ever check them. Section 2 says "It should be easy to do simple things and hard to do complex things, instead of hard to do everything". The usual statement of that is that it should be easy to do simple things and possible to do complex things. But in access control, nothing is ever simple. What you really want is for it to be easy to do the things people most frequently want to do and possible to do anything important.

It's really a question of the scope of declarations. The "simplest" access control model would be for each item and each operation on that item, a list of the users permitted to perform that operation on that item is listed. It's simple, but it's not easy because the volume of activity you would have to go through to state a complete policy would be infeasible. The trick to a good access control model is correctly anticipating the groups of things administrators are going to want to apply the same rules to and the groups of users that administrators are going to want to give the same rights to.

I don't understand the full range of things NETCONF is likely to be used for to say whether what's proposed here is a good model, but let me point out some things that make me uneasy:

Section 2.2 para 4: "Default access control policy needs to be as secure as possible". There is a constant debate over whether the default access control policy should be the most locked down configuration anyone would possibly want or the policy people are most likely to want. This item seems to be talking more about bootstrap situations: what should the policy be when you take a new device out of the box and plug it in. Usually there is no safe way to take a new device out of the box and safely put it on an open network and configure it from there. That's because at that point, the device can't distinguish a good guy from a bad guy. Usually, it's necessary to do some minimal configuration through some local (non-network) interface before putting the device on the network or taking advantage of some special purpose hack like printing a factory password on the bottom of the device. Resetting to factory settings usually requires some physical access.

Section 2.3 para 3: "YANG modules should be designed so that different access levels for input parameters to protocol operations is not required". This is saying that the permission to do something should be determined by the operation and the object and not by any parameters. It sounds obvious, but it actually constrains how operations are defined. It means that you can't have a "generic" operation on an object that based on a parameter might be a read or a write. It means that if there is a normal range of values for a configuration parameter, it's not possible to require a higher level of authority to set a value to outside the normal range than to set it within the normal range. If the operations that you have already defined follow this pattern, and you don't anticipate new operations that break the pattern, making such a restriction simplifies the access control model. But it's not free.

Section 2.4 para 5: "The non-volatile startup configuration needs to be loaded into the running configuration without applying any access control rules". The is a "restore factory settings" operation, which must be possible even if the running configuration is arbitrarily broken in ways that would prevent such an operation, but it is still a highly privileged operation... doing this would require some sort of physical device override and depending on what else is going on might require alarms, real time delays, or something else to make sure it is not part of an attack.

Section 2.4.2 "Data nodes to which the client does not have 'read' access ... are silently omitted from the <rpc-reply> message." You need to decide whether this is done for convenience or for security. It says that if you try to read a group of values and you don't have permission to read some of them, those values are not returned. This can be a convenience measure because you don't need to interrupt the return of a list with an error saying the permission is denied. Or it can be a security measure in that you can't learn of the existence of parameters unless you have permission to read them. If you try to delete such an item, do you get a different error depending on whether it exists or not? (i.e. access denied vs. named object not found). It also can have bad side effects as noted at the end of section 2.4.4: if you do a backup by reading everything, but some stuff is left out because you did not have permission to read it, it would be good to get notified at backup time that your backup has failed rather than discovering it at recovery time when the objects you did not have permission to read are not restored.

In section 2.4.3, by giving permissions on the base objects rather than on the procedures that manipulate them, you lose some capabilities you might want. For example, if you wanted to allow someone to move quotas around between objects they controlled but not increase the total quotas of all of his objects, you could write a "macro" procedure to do that. But if the permissions are enforced on all of the base objects independently, you could not give out such "reshuffle" permissions.

The use of the term "superuser" might turn out to be a land mine, in that there are lots of people who have gotten into lots of different kinds of trouble with such a feature, and calling it that is calling their attention to it. Ideally, a system would be designed so that under normal circumstances all administrators - even the most powerful ones - are configured to have the permissions they need. You still need a mechanism for overriding those permissions to deal with the case of misconfiguration where no one is authorized to perform some needed operation. You might be better off calling that an "emergency recovery user" rather than superuser, clearly carrying the implication that it is not for routine use. (That's just a word to the wise... in all probability you can use the term superuser and no one will complain).

In section 3.2.5, there is discussion of a global on/off switch for certain categories of access control rule enforcement. It doesn't say whether when access control is "off" whether all actions are allowed or whether all are denied. I suspect from context that all are allowed. Clearly these are extremely dangerous settings; I would guess they exist for some sort of emergency recovery situation. I don't understand why there are four categories... if you're going to throw security to the wind because the nuclear plant is melting down and you want to allow anyone in the world to try to fix it, that would argue for one big switch not four. It's also questionable whether you want the feature at all. It would be equivalent to making all users superusers (er... emergency recovery users). A global switch that turned off all ability to remotely change configuration settings regardless of credentials presented might make sense, but that didn't appear to be what was being called for.

In section 3.3.1: "There is no requirement to enforce access control rules before or while the non-volatile configuration data is processed and loaded into the running configuration". I hope that doesn't mean what it looks like to me. You certainly don't want to say that while configuration data is being loaded from a non-volatile store that anyone can in parallel make any changes they want without access controls being applied. To the contrary, I would expect you would want to lock out all other changes during the load process. Restoring an old non-volatile configuration is an example of an operation you might want someone to be able to do even if they don't have permission to update all of the entries in the configuration independently.

The document does not seem to deal with things that are "read-only data" where it makes no sense to try to modify it over the network because it is computed by the system as a reflection of the system's state. Someone might be configured with permission to update such data, but an update wouldn't work. You should say whether you want to model that as an access control failure or have the update silently ignored, or whatever. An example might be the case where you've done a complete backup of configuration state. When trying to restore it, the read-only values can't be restored. What is the system supposed to do?

Section 3.4.3 there are labels for "secure" and "very-secure". Reading the text, it would appear that "very-secure" really means that reading the data is security sensitive (as opposed to secure, where only updating it is sensitive). That's probably going to confuse people. You might consider read-secure. Of for the pair "read-sensitive" and "write-sensitive".

In the construction of "groups", there are really two kinds of groups: there are groups of people, where you want to give all members of the group the same permissions. These groups might naturally be defined by a more global authentication system, where when someone authenticates you find out not just who they are but get a list of groups they belong to. Alternately, you might define the groups locally. The second kind of group is constructed to fill the need that is often called a "role" in the access control community. That is for the case where there are some things on the server where you always want to control access to them in the same way. To do that, you would always define the group locally, and you would specify what users and externally defined groups are members of this locally defined group.

For example, you might create an "administrators" group and a "performance monitors" group locally and give those groups the appropriate access to ranges of resources. The intent would be that you would never update the policy concerning which of these groups had access to which resources, but you would change the membership in the groups. You would not want such groups defined remotely because someone would be unlikely to be an administrator everywhere. The set of administrators for each instance of the system would be different.

The ability to have group memberships defined either internally or externally is already allowed by the spec; you might want to make it explicit.

Good luck with this.

	--Charlie

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Mon, 21 Mar 2011 09:50:45 +0100

Thanks Charlie.

I trust that the editors/authors of the document will come back with a reaction.

And other WG participantsm, Please chime in with your own viewponts/opinions/comments.

Bert

On 3/21/11 7:31 AM, Charlie Kaufman wrote:
> Section 2.4.2 "Data nodes to which the client does not have 'read' access ... are silently omitted from the<rpc-reply>  message." You need to decide whether this is done for convenience or for security. It says that if you try to read a group of values and you don't have permission to read some of them, those values are not returned. This can be a convenience measure because you don't need to interrupt the return of a list with an error saying the permission is denied. Or it can be a security measure in that you can't learn of the existence of parameters unless you have permission to read them. If you try to delete such an item, do you get a different error depending on whether it exists or not? (i.e. access denied vs. named object not found). It also can have bad side effects as noted at the end of section 2.4.4: if you do a backup by reading everything, but some stuff is left out because you did not have permission to read it, it would be good to get notified at backup time that your backup has failed rather than discovering it at recovery time when the objects you did not have permission to read are not restored.
>

---

From: Andy Bierman <[email-masked]>
Date: Sun, 27 Mar 2011 05:31:11 -0700

On 03/20/2011 11:31 PM, Charlie Kaufman wrote:

Hi,

thanks for your review... comments inline.

> I was recently reminded that I am listed as security advisor to the netconf group and that there is an access control document that should be reviewed by a security advisor. I probably shouldn't
> be security advisor to this group, and that might get corrected through other channels.
>
> An important role of a security advisor is to try to keep a group out of trouble in the sense of having someone from the security space come in and disrupt things at the last minute. That mostly
> involves not stepping on certain land mines along the way. I don't believe this document is likely to generate such excitement (though you can never know for sure). Here are some thoughts based in
> part on my experience in security and in part on what I've seen blow up in IETF. I apologize for reviewing what I see now is the previous version, but I doubt much has changed that would affect my
> comments.

agreed -- most of the changes from -02 to -03 are editorial, such as RFC2119 cleanup.

>
> Access control is always messy. Authentication can be based on cryptographic algorithms and can be correct or have subtle bugs, and people "enjoy" spending time debating arcane details around key
> sizes, approved algorithms, and which of two equivalent variations is "better". Access control, on the other hand, is a matter of figuring out how to be able to express all the things you need to
> be able to express without making the statements so large that no one can ever check them. Section 2 says "It should be easy to do simple things and hard to do complex things, instead of hard to
> do everything". The usual statement of that is that it should be easy to do simple things and possible to do complex things. But in access control, nothing is ever simple. What you really want is
> for it to be easy to do the things people most frequently want to do and possible to do anything important.

I will fix the cliche in the text.
YANG is a fairly powerful data modeling language.
It is much easier to model powerful ACLs and we are optimizing for the most common use cases.

>
> It's really a question of the scope of declarations. The "simplest" access control model would be for each item and each operation on that item, a list of the users permitted to perform that
> operation on that item is listed. It's simple, but it's not easy because the volume of activity you would have to go through to state a complete policy would be infeasible. The trick to a good
> access control model is correctly anticipating the groups of things administrators are going to want to apply the same rules to and the groups of users that administrators are going to want to
> give the same rights to.
>

I think the NETCONF WG members understand NETCONF and what aspects of the protocol need access control.
It is debatable how fine-grained the control needs to be, but the access control enforcement points are fairly well understood.

>
> Section 2.2 para 4: "Default access control policy needs to be as secure as possible". There is a constant debate over whether the default access control policy should be the most locked down
> configuration anyone would possibly want or the policy people are most likely to want. This item seems to be talking more about bootstrap situations: what should the policy be when you take a new
> device out of the box and plug it in. Usually there is no safe way to take a new device out of the box and safely put it on an open network and configure it from there. That's because at that
> point, the device can't distinguish a good guy from a bad guy. Usually, it's necessary to do some minimal configuration through some local (non-network) interface before putting the device on the
> network or taking advantage of some special purpose hack like printing a factory password on the bottom of the device. Resetting to factory settings usually requires some physical access.

Requiring a human to physically visit and manipulate every managed device does not really scale well.
It may be fine for a SOHO deployment but maybe not much else.

The default access control can be more sophisticated if the data model schema contains meta-information
about the security sensitivity of particular objects.

The operational problem is the need to provide reasonable default access control instead
of requiring explicit rules for every possible operation or conceptual datastore object.

>
> Section 2.3 para 3: "YANG modules should be designed so that different access levels for input parameters to protocol operations is not required". This is saying that the permission to do
> something should be determined by the operation and the object and not by any parameters. It sounds obvious, but it actually constrains how operations are defined. It means that you can't have a
> "generic" operation on an object that based on a parameter might be a read or a write. It means that if there is a normal range of values for a configuration parameter, it's not possible to
> require a higher level of authority to set a value to outside the normal range than to set it within the normal range. If the operations that you have already defined follow this pattern, and you
> don't anticipate new operations that break the pattern, making such a restriction simplifies the access control model. But it's not free.

NACM is not designed that way.  It is layered.
That means that no matter what operation is used (nc:edit-config or acme:edit) that access to the conceptual
datastore is protected (i.e., data-rules).

For 'actions', such as acme:reset, that do not access the conceptual datastore, there is only course-grained
control, as you point out.  That does mean that generic commands (e.g., acme:action op='reset-all-hardware'
or acme:action op='change-my-terminal-line-length') would be a bad design which could not be easily controlled
with NACM rules.  Not even VACM allows a user to set ifAdminStatus to the value 'up' but not the value 'down'.
This is a WG decision that fine-grained access is not needed at the parameter value level.
Operationally, all input parameters to an RPC are part of that RPC.  It may make sense to
say a user is not allowed to provide some of the operation parameters, but this fine-grained access
is only provided on the conceptual datastore layer.

>
> Section 2.4 para 5: "The non-volatile startup configuration needs to be loaded into the running configuration without applying any access control rules". The is a "restore factory settings"
> operation, which must be possible even if the running configuration is arbitrarily broken in ways that would prevent such an operation, but it is still a highly privileged operation... doing this
> would require some sort of physical device override and depending on what else is going on might require alarms, real time delays, or something else to make sure it is not part of an attack.
>

We will try to clean up the terminology.
This text is meant to apply to the boot initialization phase of the device, before
it is active and accepting NETCONF (or any user) sessions.

> Section 2.4.2 "Data nodes to which the client does not have 'read' access ... are silently omitted from the<rpc-reply>  message." You need to decide whether this is done for convenience or for
> security. It says that if you try to read a group of values and you don't have permission to read some of them, those values are not returned. This can be a convenience measure because you don't
> need to interrupt the return of a list with an error saying the permission is denied. Or it can be a security measure in that you can't learn of the existence of parameters unless you have
> permission to read them. If you try to delete such an item, do you get a different error depending on whether it exists or not? (i.e. access denied vs. named object not found). It also can have
> bad side effects as noted at the end of section 2.4.4: if you do a backup by reading everything, but some stuff is left out because you did not have permission to read it, it would be good to get
> notified at backup time that your backup has failed rather than discovering it at recovery time when the objects you did not have permission to read are not restored.
>

This behavior is needed to make NETCONF filtering usable.
This is also how SNMP works.  If you get-next into a restricted node,
the operation does not fail -- it continues on to the next node the user is allowed to read.

If NETCONF subtree or XPath filters needed to be constructed so they never matched a node
that the user is not authorized to read, then not only would filtering be almost impossible
to use, the user would need to be aware of all the data s/he is not allowed to access.
This seems the opposite of what one would want, both from a security and operational POV.

> In section 2.4.3, by giving permissions on the base objects rather than on the procedures that manipulate them, you lose some capabilities you might want. For example, if you wanted to allow
> someone to move quotas around between objects they controlled but not increase the total quotas of all of his objects, you could write a "macro" procedure to do that. But if the permissions are
> enforced on all of the base objects independently, you could not give out such "reshuffle" permissions.

We have a CRUDX permissions model.  This allows fine-grained control over the NETCONF 'operation' attribute
used within nc:edit-config.  There is no super-fine-grained control over the YANG 'insert' attributes.
I do not understand the use-case you are describing.  NACM does not allow control over inserting
an entry at the end of a list vs, the middle, vs. just changing the order (insert X after Y,
where X already exists == move operation).

>
> The use of the term "superuser" might turn out to be a land mine, in that there are lots of people who have gotten into lots of different kinds of trouble with such a feature, and calling it that
> is calling their attention to it. Ideally, a system would be designed so that under normal circumstances all administrators - even the most powerful ones - are configured to have the permissions
> they need. You still need a mechanism for overriding those permissions to deal with the case of misconfiguration where no one is authorized to perform some needed operation. You might be better
> off calling that an "emergency recovery user" rather than superuser, clearly carrying the implication that it is not for routine use. (That's just a word to the wise... in all probability you can
> use the term superuser and no one will complain).

I agree.  Perhaps we can come up with some word smithing that will say the device MAY have mechanisms
which allow the emergency recovery to be possible.  IMO, this has always been a weakness of the IETF.
This policy mandates that every device will have a non-standard (i.e. different) mechanism to
deal with the initial state and 'locked-out' state.  OK for SOHO, but does not scale beyond that.

>
> In section 3.2.5, there is discussion of a global on/off switch for certain categories of access control rule enforcement. It doesn't say whether when access control is "off" whether all actions
> are allowed or whether all are denied. I suspect from context that all are allowed. Clearly these are extremely dangerous settings; I would guess they exist for some sort of emergency recovery
> situation. I don't understand why there are four categories... if you're going to throw security to the wind because the nuclear plant is melting down and you want to allow anyone in the world to
> try to fix it, that would argue for one big switch not four. It's also questionable whether you want the feature at all. It would be equivalent to making all users superusers (er... emergency
> recovery users). A global switch that turned off all ability to remotely change configuration settings regardless of credentials presented might make sense, but that didn't appear to be what was
> being called for.

This is one detail that was cleaned up in -03.

There are not 4 switches that do the same thing.
There is a global on/off switch (AFAIK, many real solutions such as firewalls and SELinux
have such a switch).

Then there are 3 switches to control the default action when no rule is found for
a requested operation type (read, write, exec).  An operator can decide how to treat
each of these request types.  Setting them all to 'deny' would be the most secure.

The on/off switch is needed to allow a simple way to check if access control is
getting in the way (temporarily disable it), rather than requiring the operator
to delete all NACM configuration and add it back later.

>
> In section 3.3.1: "There is no requirement to enforce access control rules before or while the non-volatile configuration data is processed and loaded into the running configuration". I hope that
> doesn't mean what it looks like to me. You certainly don't want to say that while configuration data is being loaded from a non-volatile store that anyone can in parallel make any changes they
> want without access controls being applied. To the contrary, I would expect you would want to lock out all other changes during the load process. Restoring an old non-volatile configuration is an
> example of an operation you might want someone to be able to do even if they don't have permission to update all of the entries in the configuration independently.
>

We will try to fix the text so it is clear this only applies to the device initialization phase,
before the server is accepting user sessions of any kind.

> The document does not seem to deal with things that are "read-only data" where it makes no sense to try to modify it over the network because it is computed by the system as a reflection of the
> system's state. Someone might be configured with permission to update such data, but an update wouldn't work. You should say whether you want to model that as an access control failure or have the
> update silently ignored, or whatever. An example might be the case where you've done a complete backup of configuration state. When trying to restore it, the read-only values can't be restored.
> What is the system supposed to do?

NETCONF/YANG does not currently support the concept of read-only configuration (i.e., not writable
by any user, only writable by the server).  We are hoping new work (TBD) will address the complexity
of configuration that is never writable by a user (e.g., you cannot add or delete physical interfaces).
Currently, the server would just return an access-denied error for such as case.

I do not understand the use-case of the system not being able to provide these read-only configuration parameters.
By definition, the server knows its own factory default settings.  Anything else is a bug in the vendor code.

>
> Section 3.4.3 there are labels for "secure" and "very-secure". Reading the text, it would appear that "very-secure" really means that reading the data is security sensitive (as opposed to secure,
> where only updating it is sensitive). That's probably going to confuse people. You might consider read-secure. Of for the pair "read-sensitive" and "write-sensitive".
>

I'm not a fan of debating terminology for very long.
We will try to come to agreement (if the WG agrees these terms need changing.
I agree with you that these terms are too generic now and probably need to be more specific.
The terms 'secure' and 'very-secure' have no real semantics at all, but they are easy to remember.

> In the construction of "groups", there are really two kinds of groups: there are groups of people, where you want to give all members of the group the same permissions. These groups might
> naturally be defined by a more global authentication system, where when someone authenticates you find out not just who they are but get a list of groups they belong to. Alternately, you might
> define the groups locally. The second kind of group is constructed to fill the need that is often called a "role" in the access control community. That is for the case where there are some things
> on the server where you always want to control access to them in the same way. To do that, you would always define the group locally, and you would specify what users and externally defined groups
> are members of this locally defined group.

Again, more terminology.
Let's say I want to configure the servers by application, because I know I want
particular NMS applications deployed.  What does the "FooApp" role mean vs. the "BarApp" role?
IMO, groups are more generic, but this term has less baggage than the term 'role'.
What role is "admin-group-in-chicago' vs. 'admin-group-in-new-york'?

>
> For example, you might create an "administrators" group and a "performance monitors" group locally and give those groups the appropriate access to ranges of resources. The intent would be that you
> would never update the policy concerning which of these groups had access to which resources, but you would change the membership in the groups. You would not want such groups defined remotely
> because someone would be unlikely to be an administrator everywhere. The set of administrators for each instance of the system would be different.
>

These are the easy use cases.

> The ability to have group memberships defined either internally or externally is already allowed by the spec; you might want to make it explicit.

OK -- we will look at the text and try to determine what needs to be changed.
Perhaps the text about radius support is not clear enough, or made vague intentionally.

> Good luck with this.

thanks, we'll need it.

> --Charlie

Andy

---

From: Charlie Kaufman <[email-masked]>
Date: Mon, 28 Mar 2011 17:59:59 +0000

Attempting to clarify a couple of points of confusion... (none of this requires a response).

	--Charlie

>
> Section 2.2 para 4: "Default access control policy needs to be as 
> secure as possible".
>
You responded to a much more complex issue than the simple one I was raising. The statement above is a common one made in the security community without thinking about its implications. Choosing a default policy is a trade-off between security and convenience. The most convenient default is the policy that the most administrators will want... it minimizes the number of settings they need to change. The most secure default denies everything and forces virtually all administrators to change it. I was just questioning whether that was really what you wanted.

It's also possible I misinterpreted what you meant by the statement above.

>> In section 2.4.3, by giving permissions on the base objects rather 
>> than on the procedures that manipulate them, you lose some 
>> capabilities you might want. For example, if you wanted to allow
>> someone to move quotas around between objects they controlled
>>but not increase the total quotas of all of his objects, you could write
>>a "macro" procedure to do that. But if the permissions are enforced
>>on all of the base objects independently, you could not give out such
>>"reshuffle" permissions.

>We have a CRUDX permissions model.  This allows fine-grained control
>over the NETCONF 'operation' attribute used within nc:edit-config. 
>There is no super-fine-grained control over the YANG 'insert' attributes.
>I do not understand the use-case you are describing.  NACM does not
>allow control over inserting an entry at the end of a list vs, the middle,
>vs. just changing the order (insert X after Y, where X already exists ==
>move operation).

You misinterpreted my comment. By "moving" a quota, I meant increasing the numeric value of one attribute while simultaneously decreasing the numeric of another (related) attribute. There are cases where you want to give someone permission to make such changes but you don't want to give them permission to change the sum. (It's possible such scenarios never come up in the context of NETCONF). An access control model that could specifically enable such a thing would be intolerably complex, so what many systems do instead is to give 'eXecute' permission on some procedure, where the procedure has the ability to change attributes that the user would not be able to change directly. (Think 'setuid' programs). My reading of your access control model seemed to rule out such procedures (because it seemed to say that the user needed the appropriate permissions on all base objects that operations touched). That's OK if it's a conscious choice. I just wanted to verify that it was.

>> The document does not seem to deal with things that are "read-only 
>> data" where it makes no sense to try to modify it over the network 
>> because it is computed by the system as a reflection of the system's state.
>>Someone might be configured with permission to update such data, but
>>an update wouldn't work. You should say whether you want to model that
>>as an access control failure or have the update silently ignored, or whatever.
>>An example might be the case where you've done a complete backup of
>>configuration state. When trying to restore it, the read-only values can't
>>be restored.
>>
>NETCONF/YANG does not currently support the concept of read-only
>configuration (i.e., not writable by any user, only writable by the server). 
>We are hoping new work (TBD) will address the complexity of configuration
>that is never writable by a user (e.g., you cannot add or delete physical
>interfaces).
>I do not understand the use-case of the system not being able to provide
>these read-only configuration parameters. By definition, the server knows its
>own factory default settings.  Anything else is a bug in the vendor code.

The case I'm worried about is where someone tries to do a backup and restore of system state. Reading the system state works fine, but when they try to restore it they get access-denied failures for all the items which are read-only. Just as for the case of pretending that data does not exist if the user does not have permission to read it, it might be convenient if there were some way to ignore requests to update data if the user does not have permission to update it. For data that is essentially static (like number of ports), the update request might be ignored only if the data he was attempting to write matched what was already there. But for statistical data (like number of xyzzy operations performed since bootload), some other technique might be useful.

	--Charlie