A bunch of security questions and some requests
Gremious opened this issue · 14 comments
Hello again o/
I'm considering maybe having a lil, short-lived, public/ volume open to, well, the public, mostly for my friends to go over e.g. Discord size limits. However, should a malicious party stumble upon it, I'd like to be secure. Now, all the other volumes I have are locked behind accounts, so I'm quite happy with them e.g. generating thumbnails and the like, so even -s is not really nice for my day-to-day use.
Now, it might just be reasonable to instead give all my friends an account, or set a global password in nginx, so I'm considering doing that instead.
However, that still leads me to the question: If I wanted a fully publicly available folder, is that just a bad idea, period, or are there any things I could be doing to reasonably secure myself, while not restricting myself, i.e. ether only liming a) anon accounts, or b) on a per-volume basis?
Could copyparty implement some existing security features, like no-readme and no-thumb, but scoped, e.g. files uploaded to this specific volume should be marked, and will never generate thumbnails for anyone? (or an accs permission to generate thumbnails in the same vein) (though perhaps easier, maybe just generate an empty/"safe" thumbnail)
On that note, do folders with only G: * permissions still generate thumbnails?
Basically, perhaps going over some of the global security flags and seeing if any of them make sense per volume would be nice and worth doing. In an ideal world, the worst an anon user should be able to do it fill up the whole space with racism.png rather than exploit ffmpeg/<script>'s/symlinks, and I'd like to have the nice privileges still available to use for myself/trusted friends.
though maybe ppl should just avoid public folders entirely accessible by anons in the first place idk.
More sidebits:
-
I checked the logs, I don't believe copyparty logs uploader IPs? It'd be nice to see the client IP right next to the uploaded file name. If some anon gets in my site and decided to be an unfunny guy and flood my shared folder with unfriendly images, I'd rather like to be able to just check the logs and block that IP in nginx or w/e.
-
It would be nice to have a global option to set the default ban timer, so that I can set it to forever. Anybody who tries to to bruteforce a password or hits 50 404's in 60min is no friend of mine, and I'd rather not have to deal with them in 24 hour hours ether. And on that note, does copyparty log bans + ip, so that I can also just ban them in nginx generally? If they're malicious on copyparty, I don't want them on any of my services.
Thanks ❤️
o/
Now, it might just be reasonable to instead give all my friends an account, or set a global password in nginx, so I'm considering doing that instead.
Yeah, this is probably the best option -- having an entirely public read-write folder is really scary; primarily because someone will start uploading illegal stuff sooner or later... Pillow is battle-hardened enough that I wouldn't be too worried about the security aspects really.
Most servers I know of do one of the following:
- one shared account for everyone that should be allowed to upload; anonymous users get read-only
- anonymous uploads are OK, but the folder is invisible unless you're logged in to a specific account
The approach with a shared account for all your friends would probably be pretty comfy in your case -- for convenience, you could link them to https://your.box/public/?pw=supersecret so they automatically log in with that password whenever they access that link.
If I wanted a fully publicly available folder, is that just a bad idea, period, or are there any things I could be doing to reasonably secure myself, while not restricting myself, i.e. ether only liming a) anon accounts, or b) on a per-volume basis?
if we start with the simpler case, and say you don't intend to allow anonymous uploads to the folder, then this should be perfectly fine as-is! The demo server does just that without any further precautions, and I know of a handful others with similar setups.
Just one thing you should keep in mind, is to make sure the folder does not have any symlinks which point outside the folder and into unintended locations. Copyparty can help with this, using --xvol (volflag xvol) which ensures that all files are directly shared through an accessible copyparty volume. This is optional and default-disabled, since there are usecases where this is actually intended (sharing /home/you/Downloads/ISOs by linking it from /srv/pub/ for instance).
And you may want --force-js and --no-robots which together helps prevent google from indexing the server :>
But say that anonymous uploads would be permitted --
Could copyparty implement some existing security features, like no-readme and no-thumb, but scoped, e.g. files uploaded to this specific volume should be marked, and will never generate thumbnails for anyone?
Interesting idea! But I'm not sure -- I can't really think of a sure-fire way to permanently tag a file as "dirty", and prevent thumbnailing / FFmpeg-parsing if it were to be moved into a "safe" volume... Might be possible with xattrs, or alternate streams, so it would be very os specific and probably have fairly poor performance unfortunately.
So to prevent FFmpeg from running on potentially malicious files, it's best to set volflags d2t and dthumb to disable metadata parsing, and don't allow anyone to move files out of those volumes.
The most important security-related features are currently available as volflags; --no-thumb / dthumb, --xvol / xvol, --xdev / xdev, and volflag d2t are the ones I can think of, but --
Basically, perhaps going over some of the global security flags and seeing if any of them make sense per volume would be nice and worth doing.
Good call, I'll do another pass later :>
Although I'm noticing that --no-dot-mv, --no-dot-ren, --no-logues, --no-readme are global-only... so that's a bit of an oversight! but that said, now that READMEs and prologues/epilogues are sandboxed inside an unpriviled iframe anyways, this is less of an issue than it used to be. The worst possible outcome of a malicious README/logue should be purely visual, instead of being able to run malicious code, as used to be the case.
On that note, do folders with only G: * permissions still generate thumbnails?
Good question... I think you can coerce it into doing that, but ran out of time to check :-P but yeah it probably shouldn't
EDIT: nope! you need full read-access to make or retrieve thumbnails 👍
I don't believe copyparty logs uploader IPs?
It does! Both the uploader IP and upload time is stored into .hist/up2k.db directly inside the volume root, and can be viewed using party journal. But come to think of it, it would make a lot of sense to have these visible in the browser as well, if you're logged in with an admin account or something... Although due to the database design they would probably not be searchable.
It would be nice to have a global option to set the default ban timer, so that I can set it to forever.
This is kind of possible, using --ban-pw 9,60,99999999 for instance. Unless I'm misunderstanding!
And on that note, does copyparty log bans + ip, so that I can also just ban them in nginx generally?
Not except from mentioning it briefly in the log file -- I think the most common approach to this would be using fail2ban to monitor the log file, and pick up the IP and globally ban it that way. But it would be awesome to have an eventhook for this, so you could define exactly what should be done in a python script for instance. Thanks for the idea, I'll add that!
One thing you could do in general, to help prevent against undiscovered/unpatched security flaws (in either copyparty itself, or pillow/ffmpeg, or python) is using prisonparty -- this will put copyparty inside a chroot, which physically limits the access to unintended parts of your filesystem, preventing malware from seeing anything outside of the folders that copyparty itself is intended to access.
Lots of good points btw, I'll keep mulling this over and see if I can think of more :>
for convenience, you could link them to https://your.box/public/?pw=supersecret so they automatically log in with that password
Something like this is exactly what I was hoping for, thank you! I've considered having a shared account that only has access to this one small, more secured folder, but the convenience of being able to share a link was the only thing stopping me. With that, it sounds like a perfectly good solution c:
it's best to set volflags d2t and dthumb to disable metadata parsing [per volume]
Ahh, I was looking for exactly that and I did not find it myself - thanks!
Both the uploader IP and upload time is stored into .hist/up2k.db directly inside the volume root, and can be viewed using party journal
Thank you! Though I do agree that this should be a bit more acessible, and admin log and some event hooks so that I can notify myself sounds like a really nice idea c:
This is kind of possible, using --ban-pw 9,60,99999999 for instance.
Are ban-404 and ban-pw the only ways in which copyparty bans?
Also another thing I noticed, the readme says:
the directory-listing embed is sandboxed (so any malicious scripts can't do any damage) but the markdown editor is not
Does this mean that somebody could hide a bad<script> in the Readme and it'll looks perfectly fine, but then if I press edit on it I could explode?
Outside of that, thank you once again for taking the time, really appreciate it!
Are
ban-404andban-pwthe only ways in which copyparty bans?
Yup, at least for now :>
Does this mean that somebody could hide a bad <script> in the Readme and it'll looks perfectly fine, but then if I press edit on it I could explode?
Yeah... I'm not sure what's the best approach to make this safer -- and it's not just markdown files, but HTML ones as well.
I wonder if it would be worth it to add a new volflag to specify that any dynamic content in a given volume is not to be trusted by default. If that is enabled, then anyone clicking an html-file or a readme-file in the browser UI would get a message popup asking whether you want to view it as plaintext or properly rendered. And anyone accessing the URL of such a file directly would get the plaintext one by default, unless they add ?DANGER_DONT_CLICK... or something like that?
If that were to be added, it should probably not be auto-enabled for all volumes where anonymous uploading is permitted, since it changes fundamental behavior like that -- but on the other hand it would be another thing you'd have to remember to add, if you want the extra security it adds... At least it could be a warning that gets printed on startup if it looks like something you might have intended to add.
Outside of that, thank you once again for taking the time, really appreciate it!
No problem at all, and likewise! Feedback like this is how the best improvements happen after all 👍 👍
I wonder if it would be worth it to add a new volflag to specify that any dynamic content in a given volume is not to be trusted by default. [...] anyone clicking an html-file or a readme-file in the browser UI would get a message popup asking whether you want to view it as plaintext or properly rendered.
I like that!
Idk if it's helpful or any better/easier than copyparty rendering the plaintext file, but just as a though, at least for html files, you could also always redirect to the raw view-source:https://... url (i.e. trust browser).
And anyone accessing the URL of such a file directly would get the plaintext one by default, unless they add ?DANGER_DONT_CLICK...?
I think it's fine if you mark a volume as "secure" and are now no longer able to render the <script>s in said volume, at all, forever. Or anything else. Like, that's the idea of disabling dynamic content like that, having a url flag that you can hide in a shortlink which circumvents said security doesn't sound too good to me.
Debatable, Idk if it's inconvenient?; but I would not mind the volflag always displaying plaintext files for said volume, period, no prompts or anything. Like, this type of security is for publicly facing folders usually, not the right target of user to care to make a pretty welcome.html in the public/ folder? I guess the only downside is that I can't add a welcome.html for other to see. But with e.g dthumb, folder.jpg doesn't render ether, and it's like, yeah...security. idk if there's much you can do about it.
it would be another thing you'd have to remember to add, if you want the extra security it adds...
The only reason I even know to add xvol/no-thumb/etc., is because I thought "this is a publicly available location, I should check what security settings are available" and then I checked the security section of the docs and it listed them.
I don't think this is necessarily any different, imo you can absolutely get away with just adding another bullet point to the Security section, and then mentioning here and there throughout the docs - "Hey btw pls check out #security if you have publicly facing things !!"
Great points :> totally didn't think of shortlinks! yep, much better to force it entirely.
I think I'll keep the readme-preview enabled even if the disable-flag is set though, since the sandbox makes it safe to do that, and because being able to add an explanation on how to use the uploader and such is a very common usecase for that :>
I think I'll keep the readme-preview enabled even if the disable-flag is set though, since the sandbox makes it safe to do that
Absolutely, that would be really nice, thanks c:
All of the functionality discussed in this issue have been implemented in recent commits so I'll go ahead and close this. But it's still open for comments of course 👍
it would make a lot of sense to have these visible in the browser as well, if you're logged in with an admin account or something...
Heya, quick question....I can't find it...
Where are the IPs, is it a cool place somewhere in the admin panel I am blinding out on, or ?
Also, you said "admin account", and the docs mention I can use "the [reload cfg] button in the control-panel (if logged in as admin)". What is an admin account, what makes a copyparty account an admin one?
The account definition in the config is just
[accounts]
name: passwordnothing special? Who decides who is admin and can reload the config? (and maybe see IPs or whatever, if that's what I'm missing)
Ah right -- it works like the other permissions (rwmd...), so it goes in the accs: section, so for example:
[global]
p: 8086, 3939 # listen on ports 8086 and 3939
e2dsa # enable file indexing and filesystem scanning
e2ts # and enable multimedia indexing
[accounts]
friend: letmein
joe: hunter2
[/pub]
/mnt/nas/pub
accs:
rw: friend
rwmda: joe
flags:
nohtml...however it currenty requires -e2t to work, since it reuses the tags API to send the IP's to the browser, so the d2t volflag will disable it. Ahem, bit of an oversight :p
I'll get it fixed for the next version :>
Should look like this when it works:
Oooh,
Yeah I understood that this was a user permission but:
- I was in grid mode, so I was looking around the admin panel for a log button of some kind, didn't realize it'd be a details view tab;
- The folder I was testing did in fact have
d2tas well;
All seems good now, thank you a lot! c:
This actually leaves me with a small question, re: the docs:
click the [reload cfg] button in the control-panel when logged in as admin
Who's an admin for the purposes of reloading my config? Any accounts I've created?
Who's an admin for the purposes of reloading my config? Any accounts I've created?
Currently that is anyone who has read-write in the volume, as this was the actual "admin" permission from way back when -- and looks like the name was never updated.
Probably a good idea to make this exclusive to people with the (actual) admin permission, now that that's a thing 👍
in the volume
but...the control/admin panel isn't in a volume, it's in the home (?) page? It's just copyparty.com/?h, and the "reload cfg" button there doesn't look any connected to a particular volume? Is it anyone with rw permission on root volume or something?
Small crucial typo there -- meant to say any volume!
The idea was something along the lines of "if someone has readwrite somewhere, then they're trustworthy enough".
Worst case, I guess you could DoS by hammering the rescan button, preventing new uploads from going through, so I'll swap it out to check for the admin permission instead :>
Yea okay, thank you, that was the bit I was missing!
And yeah someone spamming the button was my concern, so admin check is appreciated c: