this post was submitted on 01 Dec 2023

80 points (98.8% liked)

Selfhosted

40006 readers

591 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.

Resources:

selfh.st Newsletter and index of selfhosted software and apps
awesome-selfhosted software
awesome-sysadmin resources
Self-Hosted Podcast from Jupiter Broadcasting

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago

MODERATORS

HybridSarcasm@lemmy.world

HybridSarcasm@lemmy.hybridsarcasm.xyz

Disclosure of sensitive credentials and configuration in containerized deployments - ownCloud (owncloud.com)

submitted 11 months ago by Anonymouse@lemmy.world to c/selfhosted@lemmy.world

29 comments fedilink hide all child comments

I haven't seen this posted yet here, but anybody self-hosting OwnCloud in a containerized environment may be exposing sensitive environment variables to the public internet. There may be other implications as well.

all 30 comments

sorted by: hot top controversial new old

[–] astraeus@programming.dev 11 points 11 months ago

OwnCloud? More like PwnCloud

[–] possiblylinux127@lemmy.zip 9 points 11 months ago (1 children)

Nextcloud is the right answer

[–] COASTER1921@lemmy.ml 1 points 11 months ago (3 children)

Any tips for speeding it up? Loading can be painfully slow at times. I was reading that it may be the database (I use MariaDB which in theory shouldn't limit it with 32gb RAM and an R7 1700x).

[–] TechAdmin@lemmy.world 3 points 11 months ago (1 children)

Is MariaDB on spinning disk or ssd?

I initially set up Nextcloud with MariaDB on spinning disk but it was slow even completely empty. I moved that container to ssd & performance was a lot better. The web UI may still have some slow loading parts but I can't say for sure since rarely use it. Caldav+carddav+Nextcloud client are how I usually interact with it.

[–] COASTER1921@lemmy.ml 1 points 11 months ago

NVME only. I suspect caching just isn't enabled based on previous comment. If it's not by default then I didn't change it.

[–] ShortN0te@lemmy.ml 2 points 11 months ago

Implement redis. Like shown here: ( you can ignore most stuff there) https://github.com/nextcloud/all-in-one/blob/main/manual-install/latest.yml

[–] possiblylinux127@lemmy.zip 1 points 11 months ago (1 children)

What are you using for your reverse proxy? Make sure you have caching

[–] COASTER1921@lemmy.ml 1 points 11 months ago (1 children)

I reverse proxy over tailscale to a VPS because I have double NAT... The connection to the VPS is direct with wireguard at least, no relay node. Adds ~30ms latency. But even when I connect direct locally it's not substantially faster.

I'll check my config.php for caching. I don't recall adding anything for it so if it's not on by default then that's a likely reason. Thanks!

[–] possiblylinux127@lemmy.zip 1 points 11 months ago

Yeah for my instance I remember I had to do a few performance optimizations. Also make sure you are up to date because nextcloud has gotten performance upgrades.

[–] deepdive@lemmy.world 7 points 11 months ago (1 children)

That's way exposing your home services to the internet is a bad idea. Accessing it through a secure tunnel is the way to go.

Also, they already "fixed" the docker image with an update, something todo with phpinfo...

[–] i_am_not_a_robot@discuss.tchncs.de -1 points 11 months ago

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: https://nvd.nist.gov/vuln/detail/CVE-2002-1725

[–] Decronym@lemmy.decronym.xyz 1 points 11 months ago* (last edited 11 months ago)

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:

Fewer Letters	More Letters
IP	Internet Protocol
NAT	Network Address Translation
VPN	Virtual Private Network
VPS	Virtual Private Server (opposed to shared hosting)
k8s	Kubernetes container management package

5 acronyms in this thread; the most compressed thread commented on today has 11 acronyms.

[Thread #330 for this sub, first seen 3rd Dec 2023, 04:05] [FAQ] [Full list] [Contact] [Source code]

[+] TCB13@lemmy.world -12 points 11 months ago (2 children)

"Docker is safer" sure.

[–] sudneo@lemmy.world 14 points 11 months ago (3 children)

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.

[–] Anonymouse@lemmy.world 4 points 11 months ago (1 children)

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.

[–] sudneo@lemmy.world 5 points 11 months ago

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.

[–] inspxtr@lemmy.world 4 points 11 months ago (3 children)

what are the other alternatives to ENV that are more preferred in terms of security?

[–] synestine@sh.itjust.works 7 points 11 months ago (1 children)

A named volume for the config directory for one.

[–] sphericth0r@kbin.social 1 points 11 months ago* (last edited 11 months ago)

That's just as insecure lol, env vars are far better

[–] sudneo@lemmy.world 4 points 11 months ago

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).

[–] sphericth0r@kbin.social 2 points 11 months ago (1 children)

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

[–] sudneo@lemmy.world 2 points 11 months ago

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.

[–] TCB13@lemmy.world -3 points 11 months ago (1 children)

No, but it only happens because this tech exists in the first place and things got way more cumbersome and way overcomplicated than they should be.

[–] sudneo@lemmy.world 2 points 11 months ago (1 children)

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.

[–] TCB13@lemmy.world 0 points 11 months ago (1 children)

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.

[–] sudneo@lemmy.world 1 points 11 months ago (1 children)

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...

[–] TCB13@lemmy.world 0 points 11 months ago

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.

[–] possiblylinux127@lemmy.zip 8 points 11 months ago

If you do it right, possibly.