As I have discussed in the post below, it looks like every external access such as apps are granted full permissions.
I think this is problematic as an app can be compromised and then a malicious actor or program can cause huge harm.
Perhaps it is possible to design Nextcloud in a way so that apps get permissions on what is necessary for them to have access to. It’s thinkable as well that an admin could be able to select options on what additional permissions he wants to grant. Or that the admin or user is prompted for specific access the app inquires once or permanently. This is how it works in Android, specifically with GrapheneOS.
I moved it to the development section. Not sure if that is doable today, since the script are all running php with the same user permissions, they can directly access files and databse even behind the back of the NC interfaces.
As tflidd said, the question is the attack vector.
Any app you install into the server is going to have full access. That would be for example the bookmark app. There is no point in denying this. This is the way the complete architecture works and changing this would mean an immense burden as everything would need to be redone in the ecosystem. Also, most probably, the performance would be impacted by such a change.
This is different than e.g. in Android where each app is in its dedicated sandbox in some sense. The OS can dictate the API calls the app is allowed to carry out. For NC apps such a sandbox would mean you would have to stop the PHP core from any direct access. This is not possible and would only allow to protect against malicious or buggy code. Instead that would mean to implement a complete operating system (this is one of the core features of an OS).
So the question is: Why do you want that? (Read: What is the attack vector you want to be protected against?)
Are you concerned that the bookmark app has a bug and by accident accesses the files in some way?
Is it the floccus browser app that might be a security issue as it knows a token that could allow for file access if extracted in some way?
Are we talking about the (REST-based) interface between these two?
Are you fearing a ill-intended user using the floccus browser app’s token to hack into the NC server? Or using a trojan to hijack the session token?
Each point has its individual motivation and counter-measures. However, there is no single shoot-and-forget solution with security. Otherwise is is not security but obscurity.
Once, you defined your use-case, we can think of solutions. Before that, it is a too large fied to discuss in a single thread here.
but rather if this NC design is deemed to be reasonably secure or not.
As NC may host highly sensitive data, its security level should mirror this.
I think it is security fundamentals for permissions to be restricted to what is necessary which seems not to be the case here.
I was wondering if security was audited and it looks like one of Nextclouds customers had one carried out “for the code base they use”. I can’t download the report as my email address is not accepted for not being a “business email address”. So I don’t know the results and if the apps issue discussed here was part of it.
What you can do, use one setup for data storage with a limited amount of apps enabled. Then for additional apps that you trust a bit less, you can run on a separate setup that has no access to the first one.
The problem is, that you have to trust all the apps. We don’t know if or how apps are reviewed, and from other projects there have been infiltration of code to known packages. And especially for apps, there is often a lack of contributors …
I believe the original issue is restricting external access, though, right? So, you have to trust the apps that you install, but ideally there could be more config options for app tokens used by external apps. A workaround here is to have a separate account just for the bookmarks app for example. But in general, nothing is stopping anyone from submitting a Pull request that updates the auth token code to add app scopes to tokens.
