Nobody cares about your home services unless they can use them to send spam or mine bitcoin. Owncloud is a funny name because it seems to imply it’s for personal use: your own cloud. I didn’t know until I found myself in one, but apparently a lot of schools use Owncloud.
phpinfo is just a bad idea. It’s a built in facility that dumps everything without knowing whether it’s sensitive or not, right into the current page, making it trivial to add this vulnerability to your own application or library that an unsuspecting developer will include into their application. There’s not even a single security warning in the documentation. Here’s practically the same problem from 21 years ago: nvd.nist.gov/vuln/detail/CVE-2002-1725
You need to keep up that was so last year. The new hottnes is switching back to owncloud because it is so light weight. But now i am guessing the new new hotness is switch from owncloud to Nextcloud.
You’ll find a lot of pessimistic people here because there are few unicorns when a commercial company buying an open source project didn’t go badly for the open source people. Most of the time after a sell-out the projects ends up under highly restrictive licensing, features behind paywalls, and many other problems making it a shadow of its former self.
The most notable recent examples I can think of is IBM buys Red Hat buys CentOS, and that ended with forks as AlmaLinux and Rocky Linux. Oracle buys MySQL ended up forked as MariaDB. Businesses love to push their commercial offerings on open source products, and it’s not always in the form of plain old support agreements (like the people behind AlmaLinux). Often (this is common especially in databases) they’ll tax features like SSO, backups, or literally simple the privilege of having stable software. Projects like CentOS and VyOS don’t have stable OSS versions, and soooo many databases will put LDAP/Kerberos behind the commercial product, charging monthly or yearly operating costs.
Even GitHub (which to be clear was closed source to begin with, but is a haven for F/OSS so I’ll give it an honorable mention here) started showing Microsoft-isms after M$ bought the platform.
Fair, but I would point out that OwnCloud kinda already went that direction years ago. There’s already a very limited free version and a fully featured enterprise version. So it’s not like we’re losing something that the community built here.
I would have used Owncloud Infinite Scale but the fact you can’t use your own existing files makes it a complete non-starter for me. I don’t want my files locked behind Decomposed FS.
Unless I’ve read things wrong, which is entirely possible.
Hmm. I guess that works, too. I'm just a nerd and really like Free Software. Almost exclusively use it. My phone runs a custom ROM with just a few unfree apps and without Google services, all my computers run Linux. Even the internet router does, and my IoT smart sockets run Tasmota or ESPHome. I like the 4 freedoms and the culture behind it. I participate and regularly contribute. All of that is mostly personal preference. I guess I could as well live comfortably with using Google Drive, but I choose not to. Source-available software would allow me to look at the code, something proprietary software doesn't allow. But that's pretty much it. I often can't remix and share it as I like. I don't have the freedom to decide to use it as it pleases me. And depending on the exact license, I can't even invite my friends and family to use the services I set up...
It's just the line I draw. And with the software I really rely on and use daily, I'm pretty strict. Either it provides me with the Four Essential Freedoms of Free Software as lined out by RMS in the eighties, or I don't volunteer to use it. I have no issues though with other people making different choices.
That’s indeed confusing. The wording linked below suggests the eula is for packages distributed by owncloud. so to my understanding the source itself and any third party packages don’t need to care about it.
Apache isn't a copyleft license. I guess they (and everyone) can just copy or compile it, make it a derivative work and say it's now non-free and terms and conditions apply.
I mean the GitHub repo has a license file which says it's Apache 2.0. And 3h) of the EULA says it doesn't apply to open source components. So it kinda doesn't apply to itself. I think you're right, it's Free Software after all and them saying "Some builds [...]" means it's the binaries distributed by them. IANAL and it kinda contradicts the Apache license which explicitly states I am allowed to redistribute copies both modified and not modified and both in object and source form. I'm not sure why they do it and if there are components missing in the GitHub repo.
The only thing that makes this case worse in docker is that more info is in ENV variables. The vulnerability has nothing to do with containers though, and using ENV variables to provide sensitive data is in general a bad decision, since they can be leaked to any process with /proc access.
Unfortunately, ENV is still a common way which people use to pass data to applications inside containers, but it is not in any way a requirement imposed by the tech.
Absolutely not. Many applications used ENV variables for sensitive stuff even before. Let’s remember that the vulnerability here is being able to execute phpinfo remotely.
Containerization can do good for security, in general.
This is just a bad practice that was popularized by CI/CD solutions and later on by containers. I’m not saying containers aren’t good for security, what I’m saying is that they’re misused and abused and that images shouldn’t even be a thing. Isolation is great, blindingly trusting images made by someone and/or having people that don’t have any basic knowledge of security nor infrastructure suddenly being able to deploy complex solutions with a click ends up in situations like this.
OK, but how do you solve the problem? Trusting an image is not so different than downloading a random deb and installing it, which maybe configures a systemd unit as well. If not containers you still have to run the application somehow.
Ultimately my point is that containers allow you to do things securely, exactly like other tools. You don’t even have to trust the image, you can build your own. In fact, almost every tool I add to my lab, I end up opening a PR for a hardened image and a tighter helm chart.
In any case, I would not expose such application outside of a VPN, which is a blanket security practice that most selhosters should do for most of their services…
My point was that “random deb” and/or “random web application” are way less likely to come with unsafe default ENV based configuration files and usually go with the config files securely stored in system directories with the proper permissions enforced during installation or simple .php config files that won’t get exposed and that will require the user to configure in a proper way (like WordPress does by providing wp-config-sample.php but not the final wp-config.php file required to run it). Those are the solutions people used before the containerization hype and things were just fine.
My second point: containers “lowered the bar”, allowing for almost anyone to be able to deploy complex solutions and this was / is bound to be a disaster. No matter how safe Docker and others become we can’t just expect people who know almost nothing about computers and networking to be able to safely deploy things. Even the ones that know a lot, like developers, sometimes use Docker to deploy things they wouldn’t be able to deploy otherwise and fall to the pitfalls of not understanding networking and computer security.
In any case, I would not expose such application outside of a VPN, which is a blanket security practice that most selhosters should do for most of their services…
Well, me too, however I understand that some people might want to expose it publicly because they might want to access their instances from public or work machines where they can’t install a VPN. For those cases I would recommend 2FA and only allowing specific IP addresses or ranges access to the thing - the office static IP, their ISP or eventually only the user’s country.
It's probably best to look at what the devops industry is embracing, environment variables are as secure as any of the alternatives but poor implementations will always introduce attack vectors. Secret management stores require you to authenticate, which requires you to store the credential for it somewhere - no matter what there's no way to secure an insecure implementation of secrets access
They are not as secure, because there are less controls for ENV variables. Anybody in the same PID namespaces can cat /proc/PID/environ and read them. For files (say, config file) you can use mount namespaces and the regular file permissions to restrict access.
Of course you can mess up a secret implementation, but a chmod’d 600 file from another user requires some sort of arbitrary read vulnerability or privilege escalation (assuming another application on the same host is compromised, for example). If you get low-privileged access to the host, chances are you can dump the ENV for all processes.
Security-wise, ENV variables are worse compared to just a mounted config file, for example.
In general, a mounted file would be better, because it is easier to restrict access to filesystem objects both via permissions and namespacing. Also it is more future proof, as the actual ideal solution is to use secret managers like Vault (which are overkill for many hobbyist), which can render secrets to files (or to ENV, but same security issue applies here).
I’m using Kubernetes and many of the apps that I use require environment variables to pass secrets. Another option is the pod definition, which is viewable by anybody with read privileges to K8s. Secrets are great to secure it on the K8s side, but the application either needs to read the secret from a file or you build your own helm chart with a shell front end to create app config files on the fly. I’m sure there are other options, but there’s no “one size fits all” type solution.
The real issue here is that the app is happy to expose it’s environment variables with no consideration given to the fact that it may contain data that can be misused by bad actors. It’s security 101 to not expose any more than the user needs to see which is why stack dumps are disabled on production implementations.
The problem is in fact in the applications. If these support loading secrets from a file, then the problem does not exist. Even with the weak secrets implementation in kubernetes, it is still far better than ENV variables.
The disappointing thing is that in many “selfhost” apps, often the credentials to specify are either db credentials or some sort of initial password, which could totally be read from file or be generated randomly at first run.
I agree that the issue is information disclosure, but the problem is that ENV variables are stored in memory, are accessible to many other processes on the same system, etc. They are just not a good way to store sensitive information.
Seafile is not FOSS, as I understand it. But I tried it anyway, since I also found Nextcloud bloated.
In the end I went back to the purest strategy of all: peer-to-peer. My files are synced between devices over the local network using ssh, rsync and unison and never touch an internet server.
I wanted to spin up OCIS but for some reason ran in to difficulties with the Docker container. I forget what the issues were, but I already had a solid Nextcloud instance running so I didn’t dig very hard. Would like to revisit it some day.
However, since then Owncloud has been bought out, causing some worry.
Oh never mind, I saw this finding announcement for 6M and assumed it was the same company. Looks like they have many corporate investors…doesn’t inspire too much confidence.
Although they are still using the Apache 2 license and you can see they are very active in github. It does look like it’s a good FOSS project from the surface.
I used nextcloud for a year or so, but found the web GUI/apps slow, bloated and sometimes way to buggy ! Switch to owncloud for the simplicity of only having a cloud system without to much bloat.
I just read through the seafile documentation and yeah this is also not going to happen. Maybe I should switch to a simple webdav server…
How was it setup? Make sure you are using a good SQL backend or else it will be slow.
Its also received a bunch of live recently so it may be worth another look. I would be very careful trusting seafile as it sounds like a locked down proprietary solution
What’s up with Owncloud? Why did devs leave for Nextcloud? And what happened to prevent that from happening again?
I too dislike that Nextcloud is in PHP, but if Owncloud went closed-source, then opened it up again (not saying that’s the story here), who’s to say it won’t happen again? Putting my eggs in that basket might seem quite dangerous as I don’t want my server to suddenly stop working and sit behind a paywall or something because management decided they want to make a quick euro.
I don’t remember all the details. They never went closed source, there was a difference in opinion between primary devs on the direction the project should take.
Its possible that was related to corporate funding but I don’t know that.
Regardless it was a fork where some devs stayed with owncloud and most went with NextCloud. I moved to NextCloud at this time as well.
OwnCloud now seems to have the resources to completely rewrite it from the ground up which seems like a great thing.
If the devs have a disagreement again then the code can just be forked again AFAIK just like any other open source project.
I’ve been running OC10 for a while now and have hit a few bumps here and there. I didn’t realize OCIS is available as a self hosted thing. Since first reading this thread a while ago I’ve been working on getting it running. Using docker I manage to get it to open to a blank blue page where I’m supposed to be able to log in but the form doesn’t show up no matter what browser I use. I may look into it again in the future…
I mean software that’s actively being developed can’t be called DOA. Even if it’s garbage now (and I don’t know if it is) doesn’t mean it can’t become useful at a future date.
Its not like a TV show where once released it can never be changed.
owncloud.com
Top