Communication Profiles for Nextcloud and all of it's Apps

[uwedisch]

How to use GitHub

• Please use the 👍 reaction to show that you are interested into the same feature.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Is your feature request related to a problem? Please describe. Yes, it's a hard job to prevent a possible supply chain attack that could take place via Nextcloud and it's apps.

Starting at the blog post Protecting Against Supply Chain Attacks by Profiling Suppliers I found that Nextcloud and it's apps have a communication profile that is really complex. Currently I write that down from own memory and I'm possibly missing some details here. But I like to describe the more genaral problem. For example updates for apps are taken from various GitHub accounts that are not controlled from Nextcloud itself. I also found, that the weather feature of the dashboard is using a network of weather forecast servers and if you like to profile Nextcloud as a supplier (see the above article) within a given infrastructure someone has a hard job: source code has to be consulted and many testing has to be done to setup restrictive firewall rules.

Describe the solution you'd like I'd like to have a clear communication profile for Nextcloud and all of it's functionality and apps like described within the above article:

Nextcloud expected traffic IP in range of AS NS domains

In the case of code sourced from GitHub the exact URI part including username and project is needed to profile the vendor because malware is also hosted on GitHub.

Describe alternatives you've considered Reading source code and monitoring network communication of Nextcloud and it's apps to get some sort of communication profile to have the vendor Nextcloud profiled.

Additional context Understanding the issue of the above article is helpful in understanding the issue of this feature request.

[szaimen]

Hi there, are you maybe looking for something like this? https://github.com/nextcloud/server/issues/21566

[szaimen]

Related https://github.com/nextcloud/appstore/issues/1512

[uwedisch]

Hi there, are you maybe looking for something like this? nextcloud/server#21566

No, not that.

Each plugin crator must ship this communication profile with it's own app that someone else can verify if the app is doing intended communication or if the app was a victim of a supply-chain attack. Also Nextcloud as whole software should do that, that anyone has possivility that Nextcloud was a victim of a supply-chain attack or not.

[uwedisch]

@szaimen : do you have read the article mentioned above? This article descibes all that have to be done and why.

https://www.domaintools.com/resources/blog/protecting-against-supply-chain-attacks-by-profiling-suppliers

[ghost]

This issue has been automatically marked as stale because it has not had recent activity and seems to be missing some essential information. It will be closed if no further activity occurs. Thank you for your contributions.

[uwedisch]

Hello @szaimen and at all who are involved in Nextcloud, my request is about an essential basic functionality that is missing in Nextcloud, not about an optional add-on. it's basic knowledge to know what a program is doing. And profiling communication is knowing communication habits.

[uwedisch]

@szaimen, what kind of info is missing?

[szaimen]

cc @nextcloud/security is this feasible?

[nickvergessen]

Releases installed via the appstore are signed with a key unique to the app author. Nextcloud will fail to install packages which are not signed correctly. Signatures are stored in the appstore so not manipulatable via github. To further strengthen the security we started to move release files to another org, so people can not replace packages which then yields an error on install attempt.

Nextcloud packages itself are signed as well and signatures are hosted on download.nextcloud.com

[uwedisch]

Releases installed via the appstore are signed with a key unique to the app author. Nextcloud will fail to install packages which are not signed correctly. Signatures are stored in the appstore so not manipulatable via github. To further strengthen the security we started to move release files to another org, so people can not replace packages which then yields an error on install attempt.

Nextcloud packages itself are signed as well and signatures are hosted on download.nextcloud.com

Unfortunately, there was absolutely no understanding of what supplier profiling is all about.It is not about Nextcloud signing any packets, but about the communication behavior, that this is specified by Nextcloud and that it becomes traceable for the operator of a Nextcloud instance whether the Nextcloud instance in question behaves as specified.

It is a shame to simply close incidents if you have not understood them. And if the issue is understood, then it should be possible to admit that a complete redesign of Nextcloud is necessary.

[Spartachetto]

@nickvergessen I am not sure that a complete redesign of Nextcloud is necessary , yet reading the link i find this phrase: "In a perfect world, we could ask each vendor in our supply chain what is to be expected of their software and receive a firewall rule set we could plug directly into appliances we already have in place on our networks".

I guess that this would mean that every part of Nextcloud (apps included) should have a standardised way to expose the information of all the external services it communicates with. I guess that this would mean that the maps app should say something like "I communicate with Openstreetmap.org for the tiles, with Nominatim for reverse geocoding and with ... for the route calculation". Another app could expose the weather services it uses for the meteo, and yet another one could inform about the origin of the nice fonts it downloads on the fly. An admin should have the possibility to find and read all these info in a single place.

@uwedisch could confirm if my understanding is correct. If so, it could help to secure a Nextcloud installation by detecting communications with services not in the list previously described. Sounds useful....

[uwedisch]

@uwedisch could confirm if my understanding is correct. If so, it could help to secure a Nextcloud installation by detecting communications with services not in the list previously described. Sounds useful....

Yes, this is that what is needed, but using NS domain is the first part, the second would be adding information about IP ranges AS.

Don't forget to think of updates communication. Using GitHub as a source for updates won't be good because many malware is hosted on GitHub too. Updates of all apps must be wihtin the IP range AS und NS domain of Nextcloud for example.

[Mannshoch]

Do I assume it right, that this Idea is going into a way like android handles Apps or Flatpack control access on Desktop? I would assume that Nextcloud has to check all plugins and not accept scripts that contain certain php commands e.g. that try to download files. That way, a Nextcloud function has to be used, so Nextcloud could control accessing external resources and Users/admins may could block or allow on request certain connection?

[uwedisch]

Yes, it's about external resoureces to be used. Not only for updates. This also should apply for runtime data of apps, for example the apps for weather or geo location.

[Mannshoch]

I think that's an important request. Nextcloud is growing huge and that attract bad guys. Not solve this issue would not only be irresponsible, but even highly negligent!

[uwedisch]

I fully agree.