Security impact of URL support for <source> and <target> parameters about netopeer2 HOT 10 OPEN

I still think this is a significant issue. In my view trusting an external user to run copy-config is completely different with trusting this user to do any read / write as root (owner of netopeer2-server) on the local FS (at the moment one can even use "file:///" for both source and destination in single call, so one can copy / overwrite at will).

from netopeer2.

if ENABLE_URL=ON then one can enable / disable URLs only via model features

What do you mean, some new features? There is only one feature right now, url.

I have pushed a change for this, was more difficult than I thought and I still need to add support for older libcurl...

from netopeer2.

You are right and by default it all works as you described, every authenticated user can do this. I am not sure it is a real security problem, though, because it is up to you to configure authenticated users that you trust. If not, you can customize their access rights using NACM (you can forbid executing copy-config). Also, I do not really like any of your suggested solutions (disabling URL by default may be okay, actually) and the last one is impossible to implement (not every NETCONF user must correspond to a system user).

from netopeer2.

This sounds like a security issue because user foo that's connecting over NETCONF can create files in the local filesystem as root. That is a bug on its own, even if some custom config was needed to trigger this operation.

How is copy-config currently implemented? Does the user need a special NACM rule for that RPC? Is the NACM filtering (that would limit the scope of the content of the config payload that's copied to whatever is NACM-visible to the current user) in place?

Anyway, disabling the file: scheme sounds like a reasonable minimum to do. In fact, I suggest limiting the URLs to https: (and maybe http: as well if you think that having a cleartext, "insecure" upload/download is worth the convenience).

from netopeer2.

This sounds like a security issue because user foo that's connecting over NETCONF can create files in the local filesystem as root. That is a bug on its own, even if some custom config was needed to trigger this operation.

Well, like I said, the use foo may not even exist on the system, what should the owner then be?

Does the user need a special NACM rule for that RPC?

No.

Is the NACM filtering (that would limit the scope of the content of the config payload that's copied to whatever is NACM-visible to the current user) in place?

Yes.

Anyway, disabling the file: scheme sounds like a reasonable minimum to do.

I am not sure about this, why shouldn't the users be allowed to work (backup/load) with configurations stored on the system? I think there may be a use-case for this.

from netopeer2.

Okay, but a reasonable solution needs to be found. So what about adding a new compile-time variable ENABLE_URL_FILE that will be OFF by default, will that make everyone happy?

from netopeer2.

That sounds like a good pragmatic solution!

Down the road, ideally some kind of file path jail system or allow/deny lists that can be controlled via NACM might enable more safe use of the file URLs.

One more comment about ENABLE_URL itself. At the moment, if the server is compiled with ENABLE_URL=ON the server fails to start if the url feature is disabled from ietf-netconf. If ENABLE_URL=ON remains as default, then it would be worth considering if this logic should be changed, in the sense that:

• if ENABLE_URL=ON then one can enable / disable URLs only via model features
• if ENABLE_URL=OFF, the server does not start if the ietf-netconf url feature is enabled

from netopeer2.

a new compile-time variable ENABLE_URL_FILE that will be OFF by default, will that make everyone happy?

If it has some documentation which explains that in the context of a NETCONF server, this allows all authenticated users to overwrite arbitrary files as root, and therefore it has vast security implications, then OK, I'll be happy :). Bonus points if Netopeer2-server checks for this at build time as well and issues a warning about a config that's insecure.

from netopeer2.

if ENABLE_URL=ON then one can enable / disable URLs only via model features

What do you mean, some new features? There is only one feature right now, url.

Should have been singular, I was referring to the url feature in ietf-netconf.

from netopeer2.

Okay, is there any point to such a change? It was never the idea to manually change supported YANG features of ietf-netconf but rather let netopeer2 set them according to its compile-time options.

from netopeer2.