- ownCloud is a PHP application with quite a few third-party modules of varying quality. Looking at the security history of Wordpress, it's not hard to imagine what's going to happen.
- The maximum bug bounty for ownCloud is 500 USD. I think my data easily exceeds that.
- From what I've heard, security fixes are provided to enterprise customers first, so if you're lucky your adversary is one of them and knows about vulnerabilities way ahead of you.
To their credit, ownCloud openly publishes security advisories for every vulnerability, but I still think it's architecturally designed to fail.
Exposing this to the internet is probably a bad idea. If you just need storage, you probably should just use dumb storage. If you need project management stuff and care about privacy, maybe look at https://protonet.info/ or something along those lines. Also https://www.boxcryptor.com is really nice - the Dropbox desktop client does proper cert pinning (ownCloud doesn't) at least.
Other than that, storage connected to a raspi via USB will probably yield rather bad transfer speeds?
So an open source product with active and transparent security patching with a bug bounty isn't good enough?
Yet you want to offer two closed-source alternatives. I am not defending Owncloud's record, I'm attacking your logic. A low-effort all-in-one groupware and private doc cloud (Google Apps replacement) is an awesome thing - if Owncloud could make deploying an email server as simple as the rest of its toolset, they will have hit the home run.
And sandstorm.io - still waiting on internal user stores.
The entire premise of self-hosting is SELF hosting. Internal network, no operational, day-to-day necessity for Internet connectivity post-install.
If I install such a product, it's because I want total control over my data and the terms by which I access it. Being forced to use Google/Github/email as auth goes against that.
Especially considering, unlike those proprietary products, our open source product and the engineers we pay to work on it are under constant and public scrutiny thanks to availability of the source.
Honestly, I think you should not even consider trusting a proprietary product with your most important private data. There's no guarantee it isn't full of back doors and you can't audit the code or pay somebody to do it - some companies would even sue you if you try (see the Oracle debacle some weeks ago).
I don't agree with him, I just understand his point. Actually, I wouldn't really trust either product at this point - there have been too many vulnerabilities in OwnCloud for my taste, but buying a proprietary application is not an alternative either for my personal use.
- extensibility - you can adapt other apps, open source or commercial, to run on sandstorm. As far as I'm aware you can even upload them to the hosted version.
- security seems to be taken good care of by pragmatic and experienced people.
- the fact that I can pay a small amount monthly for it depending on my storage and computing needs, making sure incentives are aligned (although last time I checked I think Sandstorm hadn't even started the billing machine I think.)
Furthermore it seems to be completely, real, free software, -I ran the OS version at a maching at home for months before oasis became available to me, and I haven't noticed any juicy parts missing or filed under "Enterprise only". The only difference between the versions seems to be the storage and compute resources available. (OK, the billing system doesn't seem to be in the Open Source version, but that is OK to me. : )
Kenton, thanks for all of the work you and your contributors do on sandstorm.io; I have referred this project to many people wanting to get their feet wet "running a server" as a way to do something without instantly cutting yourself. Have you considered writing a how-to article on replicating ownCloud-like functionality within Sandstorm using apps? It might be a good first step, and I believe that it has the possibility to help people move onto (what I personally believe is) a superior platform.
The biggest things I see ownCloud still having a huge advantage on is contacts and calendars, nobody's ported or written good apps for Sandstorm to do that yet.
There's an awesome file storage app called Davros though, that's actually compatible with the ownCloud desktop client for file syncing!
AFAIK sandstorm self hosting only works on 64bit x86 machines and there's certain files I don't want hosted outside my own walls. The various ARMs are great for that use case, any future plans on supporting ARM?
Otherwise sandstorm looks pretty great overall. I always appreciate a focus on security :)
The primary problem with supporting ARM is that Sandstorm apps run native binaries. So in order to support ARM, every single Sandstorm app would need to be able to also be recompiled for ARM, or you end up fragmenting the ecosystem.
I'm also not sure how many board PCs like a Raspberry Pi or what have you would handle Sandstorm well performance-wise, though I do think there's some 64-bit board PCs you can get now to try it on.
Curious, why the scripts to install a simple series of binaries? If you packaged it natively then all the stuff you're doing with both GPG and install.sh simplifies dramatically from 2k lines of bash. With added benefit of pushing out security updates or releases becomes pretty simple.
- There is sadly no universal package manager on Linux.
- A lot of that 2k-line bash script is implementing an interactive setup that configures your server, optionally claims a hostname and obtains SSL certificates, etc. A package manager wouldn't replace any of that.
- Sandstorm's auto-updater will automatically update your server within 24 hours of any release. That's actually pretty hard to achieve with package managers. Most are not designed to auto-run in a cron job. Worse, many distros have long release cycles (6 months, 2 years, etc.) during which they only accept bugfixes.
- Most package managers don't verify PGP signatures back to the upstream author, but rather to the distro maintainer (which in Debian's case is any one of thousands of people). It's debatable which is preferable, but note in any case that it's a very different property from what our installer implements.
- Sandstorm self-containerizes in its own corner of the filesystem, basically avoiding any dependency on the rest of your system other than the kernel. This strategy works well for us -- it relieves us from having to test on every distro separately, and it avoids messing up the user's system -- but it probably wouldn't meet the guidelines required to get a package into a distro. So we'd still have to distribute our packages direct from our own server, or do a _lot_ more work.
With all that said, when Sandstorm stabilizes more we do plan to figure out a way to let people "apt-get install sandstorm", since a lot of people are more comfortable with this.
Unfortunately probably not any time soon, for the same reason as ARM: Sandstorm app packages include binaries built for x86-64. We'll need a lot of tooling to make it easy for developers to package for multiple architectures. :/
Sandstorm works decently on mobile browsers, they do test it. But how well different Sandstorm apps work on mobile depends on those apps.
It's also possible to use native apps that sync to Sandstorm. My Tiny Tiny RSS instance on Sandstorm I can access through a native Android app, for instance.
At present, apps can implement HTTP and WebDAV APIs but not SFTP nor SMB. In the future we plan to generalize things so that apps could potentially implement any protocol, but we want to be careful to do it in a way that lets us keep our strong security guarantees.
"Please look at this commit so you know how you can hack us", sounds certainly like a much better idea ;-)
> Security history at Wordpress
When was there a single very grave vulnerability within the core of Wordpress? Mostly plugins are the root of all evil there.
(besides the nasty XSS one in Jetpack, which was caused by a static HTML file)
> - From what I've heard, security fixes are provided to enterprise customers first, so if you're lucky your adversary is one of them and knows about vulnerabilities way ahead of you.
This is wrong. Until now there has not been a single moment where customers did receive patches in advance. The only difference being is that they see the advisories earlier, but at this moment patches are already available for all.
> maximum bug bounty is $500
For the record we receiced until now 340 reports by over 150 individuals and until now only 1 vulnerability within the server has been pointed out.
(Full Path Disclosure of the ownCloud root folder such as "/var/www")
> If you need project management stuff and care about privacy, maybe look at https://protonet.info/ or something along those lines
> "Please look at this commit so you know how you can hack us", sounds certainly like a much better idea ;-)
I think that'd be better than a deceptive commit message, yes. ;-)
IMO, security-related changes should clearly be marked as such - if you don't want to have them publicly, you can keep it on a private branch for the time being.
> When was there a single very grave vulnerability within the core of Wordpress? Mostly plugins are the root of all evil there.
The same (plugins) probably applies to ownCloud, still that doesn't make it better. I personally think that embracing PHP's low entry barrier [1] is the wrong approach and I'd rather see a security-driven design.
> This is wrong. Until now there has not been a single moment where customers did receive patches in advance. The only difference being is that they see the advisories earlier, but at this moment patches are already available for all.
Thanks for the clarification - very sorry for the FUD. I got this info at a conference from one of your enterprise customers not-so-technical management guys, who is apparently misinformed.
> For the record we receiced until now 340 reports by over 150 individuals and until now only 1 vulnerability within the server has been pointed out. (Full Path Disclosure of the ownCloud root folder such as "/var/www")
My argument was that the market price of vulnerability is more or less a metric for security strength [2], and 500 USD doesn't seem to be much. If we presume that the value of a critical ownCloud exploit exceeds 500 USD, your bounty program provides very little incentive to search for or report critical vulnerabilities and you'd only get low-quality reports (which seems to be the case).
> What makes you thinl they are more secure?
I think that ownCloud has a big problem with automated vulnerability scanning and the security properties of managed appliances are generally superior. I unfortunately can't edit my original post anymore, but I should have added that running ownCloud behind a VPN is a very good idea as well.
So, if we ignore all lower and medium severity ones we're basically only left with CVE-2015-2213 which requires authentication. Also XSS is barely something one can blame PHP for. That's pretty low number.
For the record: ownCloud protects you against XSS using Content-Security-Policy.
This is an arbitrary wishfulness. I'm not even sure why you're debating Wordpress vulnerabilities -- if your point is that PHP is a secure application development environment, then even if WP was riddled with 9.0 severity exploits, it shouldn't matter. It seems to me that by correlating your product's security with WP's, solely because they are both PHP apps, is conceding the ponit.
The one column at the link with that has "medium" and "low" values is "complexity" which means CVSS's "access complexity". So having many rows like this means there are many vulnerabilities that are easy to exploit!
Also CVE-2015-2213 is marked as NOT requiring authentication (along with about 7 other straight remote code execution CVEs).
> The one column at the link with that has "medium" and "low" values is "complexity" which means CVSS's "access complexity". So it means there are many vulnerabilities that are easy to exploit.
I'm aware of that, I have a ton of CVE entries filed myself. I was referring to the score (https://nvd.nist.gov/cvss.cfm), anything below 7.0 is not deemed "high".
> Also CVE-2015-2213 is marked as NOT requiring authentication (along with about 7 other straight remote code execution CVEs).
CVE entries are often terribly done wrong if they are not provided by the vendor (which is what ownCloud does).
See https://core.trac.wordpress.org/changeset/33555 for the patch for CVE-2015-2213. As you can see this is within the function "wp_untrash_post_comments" which is called by "wp_untrash_post" which only accepts user-input from the Wordpress admin panel.
> I don't really get why one wants to trust ownCloud with private files
Because
1. You get to host and control the data, and have 100% access to the code managing that data. You don't have to trust anyone else for anything.
2. The chances of somebody attacking you (a small target) vs somebody attacking a big centralized service is fairly small.
I'm not saying I believe Owncloud to be 100% secure (it being a semi-shoddy PHP application and all), but there are reasons someone may want to trust it over centralized, US-hosted and NSA-friendly online services.
No. 2 is not right. For fingerprintable service with known exploits, dragnet type attacks are very common. If the GP is right about OwnCloud having a poorly written code base then you have a very high chance of getting hacked unless you can stay on top of updates, which is unlikely for most people.
If your data is important enough that it needs to stay on self hosted machine, you should look at commercial solutions. Otherwise use dropbox/gdrive/s3 with self encrypted files.
We're a large project (often an order of magnitude larger than others trying something similar) and a company behind it with many large enterprise customers, which explains of course why we have good, transparent processes and dedicated security people.
None of that has to lead to good code as a rule, I admit that. And there sure is lots of less than perfect code in ownCloud. But I don't think it is fair to just claim it is any more shoddy than any competitor without any evidence of that.
I am not claiming that owncloud is shoddy, I am just refuting the claim that somehow hosting your own server makes you a smaller target and somehow safer.
Every code base eventually has security problems, sometime a big as heartbleed. If you are Amazon, you get a preferential disclosure and patches before it is publicly revealed. If you are John Doe, you better hope that you read the cve as soon as it's published and that you can patch the server right then.
That is why we publish updates with fixes 2 weeks before we publish CVE's. If a would-be-hacker follows CVE's, all users who updated in the last 2 weeks are safe.
On top of that, while we prepare updates mostly in public in github we only release the security-related fixes the moment we release the update.
So a would-be-hacker would have to look through the source code of the update to identify security fixes, and then he/she can hack ownCloud instances. (Lukas should check this, btw, I'm only 75% sure about this)
There is nothing we, or anybody working on any product can do about users not updating, though we do give warnings, offer packages which makes updating easier and do all we can to use security hardening to limit the damage security problems can do.
It is true that hosting your own server doesn't make you safer from targeted attacks. If you follow our security recommendations, you'll be quite OK, though, and there are tricks like using a special port and port knocking and what-not to improve security even more.
But this is no different to any other self-hosting tech.
Yeah, a public cloud can do better - they don't publish any source. They also have, almost by default, a back door to the NSA so that's like saying "let's give up on trying to build a roof because if you do, it could have a leak".
BTW if your ownCloud just presents a login screen to others, I mean, how often can somebody break in through that with automated means? Not 'never' I suppose but it should be rare...
But, for many users, security is complicated and us making it easy to run ownCloud includes that. You won't find many competitors with such extensive documentation, nor automatic security setup tips and warnings in the ownCloud admin interface.
Second, this is a matter of focus. For home and small server users, ease of use trumps perfect security, that is a simple risk model assumption: your security has to be good enough, not perfect. Better than others and all that.
For enterprise users, however, security IS paramount and ownCloud lends itself for that. We get security audits by the financial institutions and others which run ownCloud and have extensive security hardening and best practices in place. Of course, these enterprise users don't use the many 'random' community apps, which is where the vast majority of security issues can be expected. I think that, for enterprise usage, you'll find that ownCloud security practice belongs to the best. And that is in no small part thanks to the awesome that is Lukas Reschke.
For home and small server users, ease of use trumps perfect security, that is a simple risk model assumption: your security has to be good enough, not perfect. Better than others and all that.
As someone else points out in a neighbouring thread, OwnCloud is generally less secure than any of the large services, because of automated vulnerability scanning. If an OwnCloud user updates their server days or even hours to late, it can be game over and your data is on the street. It does not matter if the attacked service is OwnCloud or some other service with enough privileges.
This does not mean that open source and/or decentralized services are at a disadvantage, but you have to make the right security choices. The storage service[1] should never see unencrypted data - encryption at rest is not good enough. For instance, Bittorrent Sync provides this with their encrypted read-only keys. A cloud peer with such a key never sees unencrypted folder data. The only thing you lose when a cloud peer is hacked is a node in the swarm, but it'll never result in visibility of plain-text (unless you subvert AES-128). One SyncThing developer is currently also working on similar functionality for SyncThing.
For this reason, I would never recommend OwnCloud to anyone outside a large company that has the capacity to do continuous security auditing and monitoring, unless you apply client-side encryption (but then you could use Dropbox et al. as well if privacy is the primary consideration).
[1] I know that OwnCloud does more than just storage.
Self hosting does have this issue in general, yes. It is a bit harder to get at security vulnerabilities in ownCloud as was initially portrayed in the thread you mention (we publish CVE's 2 weeks after updates have hit the net, and these updates contain unmarked security updates).
Client side encryption is a great solution but you lose out on most of the benefits of the cloud.
Honestly, I don't know. I haven't seen any of such attacks but of course, with about 3 million users, ownCloud isn't a HUGE target. I just don't like the idea of giving up on self hosting ;-)
I also wonder how successful such automated scanning attacks are against a simple login screen. Esp compared with the fact that on the big services people routinely call the helpdesk and manage to get passwords reset and all that so they get into accounts. That won't happen with your private ownCloud...
> We will create a self-hosted device with Western Digital hardware and ownCloud software, to be made available for on-line purchase in early 2016. In preparation for this we’re looking for people who want to help us lower the barrier to self hosting and help turn this dream into reality.
Maybe I'm being cynical, but the way the first paragraph is worded seems a bit odd. Is the goal of this project to act like free R & D for ways to deploy this or make it compartmentalized? It seems like it. Why would you send 10 developer units out, require proposals, etc.? No compensation is offered -- just a devkit.
> This is where you come in! We’re looking for concrete proposals and offers for help. Can you build a disk image which boots up and allows a laptop to find it over the local network? Can you create a setup optimized for performance on the Pi? Can you write a simple web interface to finish configuring the Pi or to check how it is running? Develop a backup tool? We’re looking for creativity here!
Fantastic, that sounds a lot like crowdsourcing your product development.
> Sometime in February or March you can expect ownCloud and Western Digital Labs to release a goodie – and you will be there with a big thank-you in the manual!
A thank-you in the manual. My goodness!
> This is a project of the ownCloud community, not ownCloud, Inc.
But who's going to be shipping the final product, with the fixes that someone makes, and gets the thank-you in the manual? The ownCloud community?
so, on your last point: yes. As in - WD will ship the hardware, and the software comes from volunteers - or not at all.
IF this turns out successful (as in, the first batch of devices has great software and sells out in 2 weeks so a second, much bigger batch is made) we'll talk to WD about sharing some of their profit with the community. Until then, there is only costs for all involved and we're not asking for financial donations to cover that. Isn't that cool?
People are somewhat missing the point with the security discussion: the target use case is almost certainly the "home NAS" box, such as the WD "My Cloud" they already sell. You put it entirely inside your firewall and use it to stream media and so on.
Having an open-source version supported by WD is much better than having a random closed-source web UI on your NAS.
Yeah, I'm looking at the security discussion with interest and a lot of confusion.
I appreciate that security is important and those that give it up for connivence deserve neither... but I'm at a loss as to why some 'hacker' would go to the effort to sift through the type of content that is typically stored on the average NAS box. Like you said, family photos, birthday videos...
If you're a digital nomad / homeoffice user then yes, your livelyhood depends on something more secure - but that's not the userbase here.
I have rolled my own raspi/owncloud in the past but happily use the WD MyCloud to sync all the devices in my house.
> but I'm at a loss as to why some 'hacker' would go to the effort to sift through the type of content that is typically stored on the average NAS box. Like you said, family photos, birthday videos...
It's not 'some hacker' going through your stuff, it's an automated attack scheme. Your adversary may choose to do something CryptoLocker-like or more stealthy stuff that makes your NAS part of a botnet. Neither option is good.
As others pointed out, it is highly likely that the ownCloud instance ends up publicly accessible, because that's the primary way to access files from the outside.
Thank you. Out of curiosity, can you point me at a significant case cryptolockering of NAS data? I've read windows boxes being hit.
I have nothing on my WD MyCloud that isn't duplicated somewhere else (either it's a backup of google photos/videos, or dupe'd to a USB drive)
Again, a lock is the same as a HD failure to me. Both could happen with this setup. If the information is too valuable to fall prey to either circumstance then the system as implemented the wrong setup.
Now, a botnet is different. I assume one could not run off of the WD box and the Raspi/Owncloud base is too small to target. Unless you can point me at content that indicates otherwise?
> I have nothing on my WD MyCloud that isn't duplicated somewhere else (either it's a backup of google photos/videos, or dupe'd to a USB drive)
It sounds like it doesn't apply to your case, but a potential issue with Dropbox/ownCloud/Google Drive is that the master server can instruct all copy-holders to delete their copies. You should have off-site backups, but I suspect many people don't.
> I assume one could not run off of the WD box and the Raspi/Owncloud base is too small to target.
This is not really an issue - there are multiple router-based botnets as well. You can't really mine bitcoins, but there are tons of other stuff you can do, e.g. DDoS is usually not constrained by the processing power.
Everyone who's not living in a disused nuclear bunker has given up some security for convenience. We have to be a little realistic. But the threat is automated. The only sensible thing to do is keep it off the public-facing internet, and the average home NAT router will achieve that unless configured otherwise.
A home cloud that's accessible outside the home is an interesting promise, but as everyone has said is a risk.
I agree with sibling comment about the threat model being entirely automated, either botnetting or cryptolocker.
I wonder how successful such automated scanning attacks are against a simple login screen though. Does that really have much chance with a reasonably secure project? That then says "don't use self hosting, EVER, for ANYTHING. Get rid of the NAS, too...".
XSS/CSRF is often effective as well: bypass the login screen by using the existing session of a user who's visiting $BADSITE from the same browser as they used to login to their device.
Tragically, for the average nontechnical user, the risk of everything except state attacks and acquishutdowns is lower when using a cloud service than self-hosting.
I was about to ask if a Raspberry Pi 2 would be sufficient to run OwnCloud, but it looks like it's the hardware of choice—great!
Is there a way to run OwnCloud along with a typical system (really, an ssh server and a few utility programs) on the Pi? It's mentioned as an SD card image, but it would be nice to run it on top of a normal Raspbian or Arch installation.
Keep in mind the choice of using a raspberry Pi comes along with the compromises made in the design of the Pi.
For this specific use case, be aware that both network and USB bandwidth are limited.
This'd be great for a network backup drive, where something like Time Machine or cron/rsync are regularly-but-not-continuously writing to the drive, but it'd fall to it's knees pretty quickly if you use it to host a household's media library and you start trying to pull several HD video streams from it simultaneously.
Here's some good numbers - the onboard 10/100 ethernet can be upgraded with a 1GB USB3 adapter, but you still only get ~220Mb/sec, because you bump into the problem that the USB ports are only USB2, which is pretty much what limits the GB ethernet adaptor. And if you consume all the USB2 bus bandwidth for the network, there's then none left for the USB attached disk...
ArchLinux ARM has packages for OwnCloud. Unfortunately, the software itself is a PHP spaghetti monster from hell (is there any other kind?) that doesn't really scale.
Even worse, the RPi is extremely limited in I/O capabilities, with only a single USB2 hub shared between the 100Mbit ethernet and 4x USB2 connections (including your harddrive.) This means that any file transfer is limited to 10-11 MB/s in the best case... We can only hope that a RPi3 will with USB3 support will materialize before 2020.
I am running a RPi2 as a home server / NAS / VPN / seedbox, and it works - as long as you set your expectations right.
Finally, note that the RPi kernel stack is always slightly outdated due to out-of-tree patches. Most ARM SOCs suffer from this problem, and the RPi foundation is slowly taking steps to fix that after years of user pressure. However, I have decided to switch to a low-power x86 CPU with a fully open linux stack for my future home server needs, until ARM decides to fix their driver mess.
Well, having used and tried to fix OwnCloud, it IS spaghetti monster from hell that randomly calls out to bash/perl/etc. scripts and happily corrupts non-UTF8 filenames at times (e.g. if you're on a NAS that doesn't have locales setup the same way as the developres) and does other horrible things with data.
Seriously, that's fud. Ok, you're running a NAS so I bet you have hopelessly outdated software on there and it's a miracle anything runs on it, including ownCloud. We probably shouldn't go through so much trouble making it run on any platform we can make it run on.
But ownCloud doesn't use bash, doesn't use perl - it is all PHP, javascript, html and CSS. If your NAS build does weird stuff to work around the limitations of your NAS - well, that's one reason we're trying to build something new...
On the other hand, Facebook being built on PHP meant they eventually felt the need to dedicate significant engineering time into building their own PHP VM (HHVM) along with their own spin-off of the PHP language (Hack) to get it to work for them.
Yeah, and they could have switched to any language they wanted, but they stuck with PHP and created HHVM (they most likely run other languages as well).
They also felt the need to create other open source things you have had heard of, such as react.
It was only 4 years ago when creating HTML5 based hybrid mobile apps was "the biggest mistake Facebook ever made", and it was all about "native apps" for iOS and Android... Now React and React Native are "the new hotness"...
Upstream PHP has gained to about the same speed, and added many of the features (e.g. gradual strict typing and generators). I don't think Facebook would have made the same decision today.
Well, I don't know what your upload speed was - a normal ownCloud setup can saturate the link speed with large files, a bit less with small ones though the latest versions get very close.
Of course, if the link is slow, 180GB is going to take a while.
I run a number of web apps as separate docker containers, and use nginx as a frontend to force everything to HTTPS. Is there anything that these cloud products provide over and above what I have now?
yeah, but WD is in the business of selling hard drives and they look everywhere for ways of doing that. In this case, connected to a Raspberry Pi and such boards... We're happy to benefit by getting a cool, ownCloud branded device for our users ;-)
I sure hope that's not the configuration they RTM with, because they're going to have a lot of people upset about disk failure and data loss if they do.
I find this more than a bit ironic since WD was working with the NSA to insert backdoors into all of its hard drives, and the entire point of OwnCloud is supposedly privacy and escaping surveillance.
Can you provide a source? All the ones I can find (Der Spiegel's article on TAO, Kaspersky's "Equation Group" report) seem to claim that the NSA had found ways to reflash the firmware on the victim's machine to add backdoors, and had high-quality, robust patches to WD's firmware to add backdoors. But I can't track down a claim that WD shipped (knowingly or otherwise) malicious firmware, or that they knowingly provided unpatched firmware sources to the NSA.
Still an interesting point. Note that the software for this device will be fully developed in the open on Github and IF WD builds in a backdoor between us shipping the final image to them and them putting it on the devices before they go out to users, it will not be terribly hard to find out. Heck, ownCloud 9 will already verify its own code and warn if things are modified, maybe we can do something in the OS image which does some checks, too.
- "logging changes": https://github.com/owncloud/core/commit/eea96298951805dfc6eb... vs https://owncloud.org/security/advisory/?id=oc-sa-2014-020
- ownCloud is a PHP application with quite a few third-party modules of varying quality. Looking at the security history of Wordpress, it's not hard to imagine what's going to happen.
- The maximum bug bounty for ownCloud is 500 USD. I think my data easily exceeds that.
- From what I've heard, security fixes are provided to enterprise customers first, so if you're lucky your adversary is one of them and knows about vulnerabilities way ahead of you.
To their credit, ownCloud openly publishes security advisories for every vulnerability, but I still think it's architecturally designed to fail. Exposing this to the internet is probably a bad idea. If you just need storage, you probably should just use dumb storage. If you need project management stuff and care about privacy, maybe look at https://protonet.info/ or something along those lines. Also https://www.boxcryptor.com is really nice - the Dropbox desktop client does proper cert pinning (ownCloud doesn't) at least.
Other than that, storage connected to a raspi via USB will probably yield rather bad transfer speeds?