Re: [qubes-users] Special (Secure) Browser Frontend for Qubes?!
> Does your proposal really harden agains a real threat, or is it > something that should be done only because it could be done? > > Btw, thank you for taking the time to write us your proposal and > replying to our e-mails. Well honestly "proposal" is probably too much credit for the time I spent on it so far and I mainly wanted to probe for the idea more. I think I am going to write a true proposal that can actually be reviewed and your input definitely helps to guide that effort, which is also why I asked that question in the first place. And I am not actually sure I will address a threat model, since it doesn't really do more than you can do manually. It is really more about regaining the convenience while maximizing the additional privacy and security Qubes OS technically provides, you see... But I agree that it is required to be much more specific and clear but I can't do that so quickly in a mail, so I will take this conversation and address the issues raised in a more structured manner ^^. Thanks & Cheers -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4c300108-99c2-46db-b68d-981ce97cea1b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Special (Secure) Browser Frontend for Qubes?!
Hi Simon, > several AppVMs, each one dedicated to a different activity, or as I > prefer to refer it myself: to different sensitivity levels. See my reply to Alex, maybe that explains why this is exactly what I was talking about ;). > - You may have a dedicated Firefox instance still having the infamous > Flash plugin installed when you need to access some websites requiring Yes but this could and would be all included in this dom0 browser interface. > - Use (X)KeePass in a separated, isolated and dedicated AppVM. I suggest > you to create a "Web" or "Firefox" group, and then create a different I am using UNIX pass, but it has the same flaw. If you copy passwords this way they won't automatically get purged from the AppVM, which under the assumption that any AppVM is completely compromised at all times, is not much of a big deal, but still it would be nicer if the password was cleared or even better never copied to the clipboard... Which is why my idea would be to host Mozilla Sync Service in each AppVM and the let the dom0 browser fill this Sync Server with the passwords belonging to the corresponding identity... > website: you will *not* open this link in the same AppVM but instead > copy/paste it in your "Random surf" AppVM. Would this site be malicious Yes but people WILL click the link. It's not a sane assumption to make. Besides it is incredibly annoying to operate this way. I am not some prime target of the NSA ^^, and I doubt many of the people using qubes will be... So you want to be safe, but you still want the convenience... The right way is to block the link, unless it refers to a white-listed domain for this identity. Or even better, pipe it back to dom0 and open it in a new tab & AppVM under the right identity... (this kind of integration is what I am proposing) > password database is to first hack the forum, and use it as a pivot to > then be able to hack your computer and get access to your file system. How he does it is basically immaterial to me as I assume that all AppVMs are evil all the time. The point is to separate them properly so only one identity gets compromised. I want to add that it is generally unlikely that a disposable AppVM with the right configuration will actually be compromised, but it helps to assume them to be to get a better picture of the impact it would have and to minimize that impact. > (https://addons.mozilla.org/en-US/firefox/addon/secure-login/) so > Firefox does not dumbly automatically fill any password field without Yes this looks good. > like uMatrix or NoScript which allow to better control third-party Thanks for uMatrix, I didn't know that one. But yes this is pretty much what I imagined also to happen, just in dom0 (which is more trustworthy to me), not in an AppVM. > It *may* be possible to implement a way to handle different AppVM in > different tabs instead of different windows, but I'm not sure to see any > real advantage of this. The advantage is the same as going back to IE6 times when each tab was its own window and having windows with several tabs in addition to this madness. I don't see how you can not see the advantage of having all browser tabs over all AppVMs organized in a dom0 browser interface as tabs in comparison to having tons of floating windows with sub-tabs each ;). > instance, personally I set it to not display reduced windows in the > Alt-Tab menu, so I can focus on the window I am currently working with. I don't think any of those suggestions really helps with the problem. All in all I think Qubes OS in general lacks a good UI for what it is doing, but I also understand that you have to start somewhere. But in the end the way Qubes does AppVM and identity management at the moment is truly terrible, but it works. All I want to do is to come up with a plan to improve it ^^. > be useful to have them volatile on a day-to-day basis, and turn them > non-volatile only to update Firefox's modules or save a change in its I think the Mozilla Sync Server could be of help here... > To be honest I did never investigated this, I'm not sure what the > concrete threats there are. Are you so sure that your AppVM doesn't have an unique fingerprint that potentially could be exposed via a malicious website, browser extension or the browser? In that case, even using the same base template for disposable VMs could be a privacy disaster (I am not sure Qubes OS has taken any steps, like maybe "Tails", to actually mitigate fingerprinting in disposable VMs) On top of that have you ever tried to use Panopticlick? Even tails gets more or less uniquely fingerprinted primarily via the non-standard browser window size when it is maximized and also because it seems to apply some uncommon browser settings that maybe only tail users have... > UUID you really should just use the same UUID as a lot of other people That requires you to know the UUID, also UUID was more a token for
Re: [qubes-users] Special (Secure) Browser Frontend for Qubes?!
> And that's why you can use many appVMs in the first place. You share the But that is not the point. First of all, unless your life depends on it, it will be very unlikely that you are actually paying enough attention to where you use which identity. A click on the wrong link can already screw it up because then site X read the tracking data placed on site Y and site X shouldn't know about what you were doing with Y... So you need some sort of white-listing to technically prevent those mistakes. Yes this can be done in different AppVMs and that is exactly what I am proposing here. It's about making what you describe much more convenient without a single drawback in security. > There's little actual reason to use a hard-separate identity for each > and every web service you visit; first because they don't usually talk > to one another (i.e. amazon does not ask facebook for your info, nor > does this happen the other way around) Um, that is a bold statement, do you have any data to back that up? Maybe Amazon indeed doesn't talk to Facebook (yet), but no one is stopping them either. Facebook definitely has an interest to read your Amazon visits because this way they can link your true identity to your fake profile... for instance. > are, in fact, the very same entity (fb and whatsapp, gmail and youtube). True, and for those you will want to use the same identity (it get's complicated quite quickly which is why I am proposing to aid the user with this chore). > Third because you usually want to present a "brand" identity of yourself > around the web. Think of your personal blog or github account presented > on your linkedin profile: this is a reinforcement of your "brand" > identity, so you would like to share the connection between your github > and your linkedin identities. Maybe, but here we have the same issue again. I have other things in my head than trying to remember which sites shares what data with whom and which idenity I have to use where and which AppVM to start for it, it's just insane... This needs to be much simpler. > And that's actually the point why I'm replying to your e-mail; this is > an idea as bad as it gets. The main reason why dom0 does not have > networking, and should not have, is to prevent exposing data on *all* of > the VM at once. As a side effect of this, the less software there is on > dom0 the better. I think you entirely misunderstand my proposal or maybe I wasn't clear enough. My proposed "dom0" browser has no network at all. In fact, it can't do anything you couldn't do manually already. The point is to automate it. This dom0 browser frontend will know which identity belongs to which domain and which AppVM should be used for each identity and what your passwords & cookies were. It also feeds this data to each AppVm on startup so they can completely be disposable... The "real" browsers still run in AppVMs. > TL;DR: first, do you really actually need to separate each and every > identity you use? second, once you realize that many identities can > co-exist (and indeed, sometimes you would like this to happen) do you What do you mean by "co-exist"? If I use them at the same time in the same browser/VM I might as well just use one single identity because there is no way to know if either of them wasn't compromised or linked in ways I didn't want. I don't see how identities can co-exist (I am also not talking about sign-in data, I am talking about fake "me"'s, fake people so to speak who consume services to protect the real identity; I simply see no use case of why you ever want to share identities within the same AppVM or browser/site). > really need that many isolated VMs? third, why would you need to move > this complexity in dom0? Because dom0 is the only place where this can meaningfully exist. Think of it as a different way of organizing the AppVM windows (not in the XCFE panel's, but instead as real tabs in a dom0 browser) and a lot of infrastructure code to help you with identity management. Cheers -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1f43fe6b-39dc-4898-ba5b-b066c4e1be84%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Special (Secure) Browser Frontend for Qubes?!
Hi, I am using Qubes daily for a while now. One thing I think is really missing is some sort of identity management. This is most visible when browsing. You shop something on Amazon, then go to check some Facebook updates and look at WhatsApp. Then you browse Hacker News click on this link and that link, end up on Wikileaks by accident then look at which club to visit in the evening... Yes this is shit. But convenience often wins over security/privacy. Not only do you have to assume that all sites you visit within the same VM knows everything you did in there, but also you have to assume they know all the passwords for all the other sites you visit there and basically have full control over that VM. If you don't assume that, then why are you using Qubes in the first place... I think what would solve this dilemma is a custom dom0 browser layer. The way this can work is as follows: * Each identity consists of white-listed domains and HTTPS certificates (like amazon plus all its garbage), bookmarks, history, it's own password & auto-fill store and basically everything else like it's own cookies and the works. * Trying to visit a non-white-listed website will simply not work without switching identities properly or using a special disposable identity * Two identities are never used on the same VM * You always use a new VM for each tab (there is potential for optimization, like sharing a VM per identity as long as this identity has at least one tab still open) * Each VM is disposable (no home file system sharing) and get's the corresponding identity auto-copied on boot (only the essentials for Firefox) * The browser gets installed after launch, so no kind of tracking can take place here via installation UUIDs etc. So the core feature of this dom0 browser is basically identity management and the usual tab-based browser gui with history, settings, etc. But in contrast to what we have now, this dom0 browser will also manage the VMs that run the actual browsers and blit their page view into its dom0 tab. Is there anything like that under development? Or how would you solve this issue? Cheers -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/22581429-6e04--a8db-e287d122765b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes on a dedicated server
Am Freitag, 30. September 2016 15:05:31 UTC+2 schrieb Patrick Schleizer: > Does anyone ever try this? > > Did it work? Any experiences? Why would it not work? But the question is rather why use Qubes OS? If it's a dedicated server, you should look into XenServer, which basically can be thought of a Qubes-Server OS ;) and is widely deployed in data centers across the world. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/010cb2bb-73e7-483a-8cad-425dcb42767e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Switching from UEFI to BIOS after installation...
Hmm yeah with that I managed to boot through BIOS mode, unfortunately the VMs don’t start (randomly, different ones fail on each boot attempt). So basically something seems to go wrong. The disks get decrypted and I can login with the manager etc. but the system is more or less a complete failure ^^. When I go back and boot in UEFI mode, everything works just fine… This seems kinda odd xD. On 25/09/16 23:27, "Marek Marczykowski-Górecki"wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Sep 25, 2016 at 02:22:49PM -0700, mara.kuens...@gmail.com wrote: > Hi, > > I just discovered that AEM needs a BIOS boot. > Is there a way to install grub into the MBR of an USB drive after Qubes was already installed in UEFI mode? If so... How? Like any other Linux distribution or does Qubes need something special? > > I would want to avoid re-installing Qubes if possible. Just installing grub2 package and calling grub2-install should be enough. At least in theory... - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJX6EEvAAoJENuP0xzK19cshs0H/3YSRCfl4eTGRiZaYgor1cOb lLfywbI5WMlJnICZkvpj5cwd3Ar1MxfEAHkWv+yvqPq9YH+80yxYPv3QyyrMsA8t IfwWJXLFc0Av5L3wkO5CN7BrKdLlbQf4J/LAb/QEWpbTKz9odLxoXLPkuNOKgm3/ r5yWbkQOisGuHiK66ao6Hdn1pCCthLub1+4dA/vtSzai/37rv5LFOU1TbwLktd+J JmglqpA5WUNqmgX2QtzILWTOhdeHPb0CepGv61x58g2SP4OqOVUKs6cqETZkjLCc 0BX8haa/D8/gWoFjU3/+Af4xKBWom8uWJG7H0dBee7e6pbUqtigYoQGGWixeeFc= =QEHr -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/BCDEB0A1-CE53-477C-B439-E101059087BA%40gmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Switching from UEFI to BIOS after installation...
Hi, I just discovered that AEM needs a BIOS boot. Is there a way to install grub into the MBR of an USB drive after Qubes was already installed in UEFI mode? If so... How? Like any other Linux distribution or does Qubes need something special? I would want to avoid re-installing Qubes if possible. Thanks! -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/9bc6c0b8-bc24-4b1b-b39b-26bae14004d1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Encfs + Dropbox: How to keep your cloud files secure?!
Am Sonntag, 18. September 2016 04:52:52 UTC+2 schrieb rac...@gmail.com: > > So for me, EncFS seems the way to go > > I looked into using EncFS with Dropbox, but from what reading I did it seemed > that EncFS was (1) old and not well maintained and (2) insecure whenever an > attacker can see more than one version of the same file (that is, see the > same file before and after a modification). Version 1.8 supposedly fixed some > of the issues but this issue about being able to learn about a file's > contents when it changes remains (as far as I can tell from reading around). > Since Dropbox can always see files before and after modification (that's kind > of the point of it), EncFS seems like an insecure choice to use with Dropbox. > > So I'm still looking for a good solution for encrypting a single folder that > will be synced. > > Of course, Dropbox itself would be considered a security risk by many who are > interested in Qubes. Myself, I'd put up with it if I could localize it to a > dedicated AppVM. Okay I have now installed Qubes OS on my work PC which also supports VT-d :), so I had a chance to look into this more deeply. I see that EncFS is old and maybe not fully secure. Unfortunately there don't seem to be good alternatives. Also the vulnerability primarily focuses on manipulation, not decryption. Since I only push to Dropbox, but dont fetch anything, this is unlikely to be a problem. Also the data I am pushing is not that important. It's personal but I am not a dissendent or something, so I don't "really" have anything to hide. I don't think EncFS is a security hole, unless some state sponsored actor really takes a liking to you... They would also need to have access to dropbox in the first place, which isn't easy. I actually trust Dropbox enough that I don't believe they will go trough the trouble of breaking my EncFS encryption ^^. Like... What for? I doubt I am on any NSA list yet... Well on the list you get on for googling Snowden and downloading Qubes OS, okay, but that's probably a list with millions of entries ;). I tried the block-device approach, it doesn't work. Dropbox can sync only the "changed" blocks, yes, but for that it needs to scan the entire 200 GB file for changed blocks which is a freaking nightmare, power-consumption wise... So my current setup is: 1) Dropbox VM: Runs dropbox and keeps a local copy of 200 GB EncFS files (only encrypted) 2) Vault VM: No internet connection. Has a plaintext copy of the 200GB EncFS files. Now I just mount the Vault VM's loopback device with the encrypted EncFS files inside the dropbox VM and issue an rsync command to update the dropbox VM's local copy. Then dropbox will updated the changed files... Not exactly as smooth as I expected but I guess that's the price you have to pay for maximum security ;) -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5558f917-8de4-4442-907d-3c7cef41f6fc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Encfs + Dropbox: How to keep your cloud files secure?!
Am Freitag, 16. September 2016 20:11:48 UTC+2 schrieb Chris Laprise: > On 09/16/2016 09:58 AM, mara.kuens...@gmail.com wrote: > > Am Freitag, 16. September 2016 09:52:40 UTC+2 schrieb Drew White: > >> If they can get access, whether encrypted or not, it means it's insecure. > >> > >> Encryption just takes time to break. > >> > >> If you have encrypted files, encrypted with a STRONG password THEN a 2048 > >> bit cypher, THEN it will probably take about 6 months to decypher it and > >> get the data out. > > I think you need to educate yourself a bit on the topic of encryption. > > Encryption is secure if you use it correctly. Too secure actually, it's > > much more straightforward to simply torture the information out of > > someone... > > > > And unless there is a backdoor in AES-256 (which why ideally you would > > always use a combination of several ciphers), it is technically and > > theoretically unbreakable if you used a 256-bit random key. It's much more > > likely that someone will social engineer his way to the data. Matters are > > entirely different with current public key algorithms, which may very well > > be broken via quantum computers, so I wouldn't bet my money on that > > horse... On the other hand those are not the algorithms you use for backup > > anyway. > > Ssh may add some security against things like MITM attacks, but you have > to trust who you're connecting to as well. From a Qubes standpoint it > matters because the non-crypto parts add a bit more complexity, and > adding rsync adds substantially more. SSHFS is probably more complex and > attackable than both of those together. That, along with TCP/IP itself, > is attack surface. > > The way you're describing it makes it seem like any successful attack on > one of those components in the dropbox vm could be repeated against the > encfs vm. I think most Qubes users would consider that too risky for > handling sensitive info, or interfacing with highly trusted vms. It also > means you need to keep extra copies on your drive. > > What I described involves no extra copies, and if the dropbox vm becomes > compromised then there is very little it can do to attack your other vms > that are using the data. Ssh between the dropbox vm and dropbox is still > a good idea in this case, and you might even want to use SSHFS or > whatever else would allow you to map disk images in that vm. The dropbox > vm could be considered 'red' and your client vms (which encrypt and use > the data as mounted disk image) could be 'blue' or whatever. I think > this is worth a try because its more secure and probably less complex > than what you're suggesting. > > Of course, with Qubes its up to the user to weigh the risks and make the > decicions. Good luck... > > Chris I don't disagree with you... But your approach has several usability downsides. Although I am reconsidering this, since in the end I might be able to live with a "once per hour" dropbox sync which would open many doors for options like the ones you described. Thanks :) I will think about it and try it out. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e7d495ec-116c-4079-bc54-2266d7c4f286%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Encfs + Dropbox: How to keep your cloud files secure?!
Am Freitag, 16. September 2016 09:27:26 UTC+2 schrieb Raphael Susewind: > IMHO the safest option is indeed to use a split-dm kind of approach, as > suggested before: create a loopback file in the dropbox VM, expose this > via qvm-block to your working VM where you then do all the encryption > (using standard LUKS) and can either mount the thing right there or - > for extra security - expose to yet another VM, again using qvm-block: > > dropbox VM: loopback file -> /dev/loop0 -> exposed with qvm-block to > crypto VM: /dev/xvdX -> dm-crypt -> /dev/mapper/plain -> exposed to > work VM: /dev/xvdX -> mounted somewhere and used as usual... > > The only caveat is how Dropbox behaves if you have a file in it that > serves as backdrop for a loopback device - any thoughts on this? > > Raphael I dont have any references at hand, but back then when I decided to go with EncFS, I also looked at the block-device method. IIRC, Dropbox theoretically does handle giant files very well (actually it's pretty irrelevant what you store), but there were problems with syncing obviously (try accessing this device on multiple machines) and also with write-through and general integrity. It just had a lot of quirky corner cases and while EncFS + Dropbox isn't perfect for syncing either, it has worked flawlessly for over two years now (with daily use)... So for me, EncFS seems the way to go, unless you unmount the file system and flush it before activating dropbox but that is kinda unstable from a human error perspective... -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5be67da3-dc2f-49ae-be29-14263c81a1cb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Encfs + Dropbox: How to keep your cloud files secure?!
Am Freitag, 16. September 2016 09:52:40 UTC+2 schrieb Drew White: > If they can get access, whether encrypted or not, it means it's insecure. > > Encryption just takes time to break. > > If you have encrypted files, encrypted with a STRONG password THEN a 2048 bit > cypher, THEN it will probably take about 6 months to decypher it and get the > data out. I think you need to educate yourself a bit on the topic of encryption. Encryption is secure if you use it correctly. Too secure actually, it's much more straightforward to simply torture the information out of someone... And unless there is a backdoor in AES-256 (which why ideally you would always use a combination of several ciphers), it is technically and theoretically unbreakable if you used a 256-bit random key. It's much more likely that someone will social engineer his way to the data. Matters are entirely different with current public key algorithms, which may very well be broken via quantum computers, so I wouldn't bet my money on that horse... On the other hand those are not the algorithms you use for backup anyway. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/43d896a3-aee4-40ef-ae98-fff3e522c798%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Encfs + Dropbox: How to keep your cloud files secure?!
PS: SSH alone is of course not very ideal, because this could mean I am running rsync of the dropbox qube. Instead I could use SSHFS to mount the dropbox qube's folder in encfs and then use the rsync of the encfs qube to sync the files via SSHFS. This is like super indirect, but probably safer?! -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/6cd48d49-5ce5-49ee-9fae-66ed81290cc8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Encfs + Dropbox: How to keep your cloud files secure?!
> > Hi, > > > > I just installed Qubes OS and I feel its freakin awesome! > > > > I am trying to set it up the way I want and one thing on my list is having > > a dropbox vm that provides simply just the cloud storage... I would like to > > run the actual encryption on a different qube because I dont at all trust > > dropbox. > > > > How would I setup a qube that runs dropbox and exposes its filesystem > > securely to another qube that runs encfs which in turn can then be used to > > safely store & view cloud files via qubes OS standard file sharing > > capabilities?! > > > > My idea was to run NFS on dropbox qube and connect to NFS with the encfs > > qube, but that's in several unfortunate. > > > > 1) I don't trust NFS > > 2) NFS is unreliable in combination with EncFS > > > > > > I want to get rid of the network connection... > > > > How would you solve this? > > > > Thanks a bunch! > > > > The operative word here is 'expose'... There is probably no secure way > to share something as complex as a filesystem, which is why Qubes has no > built-in file sharing capabilities. > > You could use qvm-copy-to-vm or the equivalent in the context menu of > the file browser... but that copies whole files between vms. > > You could also create one disk image per vm on dropbox, and somehow set > them up as loopback devices in the dropbox vm. This allows you to > 'share' data to client vms as disk blocks using qvm-block, which is far > less risky than sharing filesystems. You would also have to encrypt the > disk images in each client vm to make this truly secure. > > Chris What do you think about this: Encfs-Qube contains plaintext & encrypted files and has a cron job that runs like every hour. This job will SSH into dropbox-qube and run Rsync to project all the changes onto the dropbox-qube (but ignores all the changes inside dropbox, which would also be nice in case dropbox deletes everything or modifies encrypted files etc.) Dropbox-Qube just contains the public SSH key and see only encrypted files... Is SSH + Rsync reasonably safe? Or do I have to assume an attacker could easily break into the encfs domain once he compromises dropbox? Remember that Rsync will not promote any changes in the dropbox domain back to the encfs domain... It will discard all the changes inside dropbox instead. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/6b1267b3-9295-4104-9d73-89e3b072667c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Encfs + Dropbox: How to keep your cloud files secure?!
@Chris Thanks I will think about this block-level approach. @Drew I don't agree... Storing encrypted files on dropbox IS secure in the sense that nobody in the world will be able to decrypt them (as long as the encryption step is not exposed to the dropbox process, which might be compromised). Of course dropbox can delete all your files instantly, but that is another matter. I use dropbox as cloud backup and if they delete everything it doesn't really matter, unless I lose all my own backups at the same time. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/6a05a5f4-beba-40ed-be49-ad484ed8deaf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Encfs + Dropbox: How to keep your cloud files secure?!
Hi, I just installed Qubes OS and I feel its freakin awesome! I am trying to set it up the way I want and one thing on my list is having a dropbox vm that provides simply just the cloud storage... I would like to run the actual encryption on a different qube because I dont at all trust dropbox. How would I setup a qube that runs dropbox and exposes its filesystem securely to another qube that runs encfs which in turn can then be used to safely store & view cloud files via qubes OS standard file sharing capabilities?! My idea was to run NFS on dropbox qube and connect to NFS with the encfs qube, but that's in several unfortunate. 1) I don't trust NFS 2) NFS is unreliable in combination with EncFS I want to get rid of the network connection... How would you solve this? Thanks a bunch! -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7a5fc95d-8fe8-4c00-8e53-94ae4d660456%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.