Re: [qubes-users] Thoughts about installed software
However I would not use the "move to VM" command like this, as I experienced those requests getting lost One time files were actually deleted, since that time I always use copy instead of move. Sounds troubling. Do you remember the last Qubes release version where you experienced this kind of data loss? [...][...] qvm-move-to-vm *should* be safe since R3.1 (unless the destination VM was debian-7 based, which had an old glibc without syncfs() support). Rusty 3.1 - but I dont remember src & dest types My thoughts are more about continuing the attack to other QubesVMs or even other systems by means of installed Software like a VNC client. But I only ever allow the ports I require to be used at that time. I do have one area that is set up as a complete, but they can only talk to each other, nothing else. So if you configure Qubes correctly, including the VMs, it will be very difficult to actually attack other VMs in the way I think you may be thinking it's easy? Good point, Drew. The problem is reduced significantly if you reduce the firewall exceptions to a minimum. -- 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/17c46299-307c-4f0e-e04a-d62e6baee4d7%40digitrace.de. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Thoughts about installed software
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Jeremy! > In Qubes 3.0, I noticed that source files for the "move to VM" > command would be deleted even if the move failed due to > insufficient disk space in the destination VM. (It goes without > saying that this is a Very Bad Thing.) That was fixed in R3.1: https://github.com/QubesOS/qubes-issues/issues/1355 > I'm not sure if this is still the case in newer releases of Qubes. I don't think it is. There's also another commit somewhere to call syncfs() after copying. So qvm-move-to-vm *should* be safe since R3.1 (unless the destination VM was debian-7 based, which had an old glibc without syncfs() support). Rusty -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJYAJr5XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0 NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfMj4P/0g3dif0bYm1fYO3E3Cs+zQC GtsFZX6As/7XL+RliVDK0GB7c9XuB0ycaXCbcnu3uNNhknm76wEkxkAe3Gq4dxPC t/NDwTQY0oSzlOxYrJ8jAqWUWSfe4buSecV+u5vC2iKO0UrGe8YIEZvM2+YhpsQT FOdKSNUvw4MJqy9xmjeYLtH6wtWzJyEN2B9n+yVScpTaA1MBO5WnmTu3pts1WmjT iUVHNr84Qzf/rcZnZIfTYThH+HSA8gJgN/RAeOE9ghzyEzcKkrznPWyMSuaW8SmO FW+djKx6lTOcJKg50BJHH/aSwrJxnIfIa1MtoLseMPEsDf+UHcAY6ASKRROt+7pn v9ORB/uB/uERBigik1yd9bAivauqqLbi8Dj7hBwc4XteEikvVUXAsOsEJl7lmaC1 I7Wzb8YXxvEAyJFINXItK5ZJT1x0D/5m+07oKD5oBf8aNY8CFHTEPUUQFmTQLOId XZg/pBhIOpmIsx3z+Zk3+VJCIz7tzR9BpRCAvN8FOZPs5HEG4Hu914Eb01ErwDE3 keM5Bu1mW/HsGcAvnXBGLfQ6MtFFmdNoqbS5Jrj2cv0q/9yGPmf44u4NqTNbQiAu mlqKx+8mx6H5/EBagZKNxVmFqUy+ShpsIhro9VlHaCoNF21ttjOr8/B4zaPb2igx 9SChvvIPXA5HKfR4FK5H =Bj5/ -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/5b71cd9a-d072-5c8c-d891-3ac641591a9b%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Thoughts about installed software
Rusty Bird: > Hi Robert, > >> However I would not use the "move to VM" command like this, as I >> experienced those requests getting lost One time files were >> actually deleted, since that time I always use copy instead of >> move. > > Sounds troubling. Do you remember the last Qubes release version > where you experienced this kind of data loss? > > Rusty In Qubes 3.0, I noticed that source files for the "move to VM" command would be deleted even if the move failed due to insufficient disk space in the destination VM. (It goes without saying that this is a Very Bad Thing.) I'm not sure if this is still the case in newer releases of Qubes. Cheers, -Jeremy -- 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/6ba93f84-206a-303e-e608-262b10a79f97%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Thoughts about installed software
Template VM Hierachy? Was still some topic (and would meet the user logic to design more foundation TVM's and higher specific TVM's on top of them)... https://groups.google.com/forum/#!searchin/qubes-users/vm$20hierachy%7Csort:relevance/qubes-users/iLJjTTQqgrw/-0OG1jrZPgAJ -- 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/9d6a4088-c81c-455f-a610-ae9c7647110f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Thoughts about installed software
Hello, how I found out, if the minimal Templates D8 or F22 will contain only "exploit proof" applications, which support all ASLR - against code injection - like the browsers? Or if not, how can I build an ASLR D8 template for Qubes? Kind Regards -- 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/f29d890a-6d35-4388-a535-c7dd45e2a245%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Thoughts about installed software
Hello, sounds quite interessting :-) How would be a encrypted software-database. Inside are all compressed folders, pathes and files and if you run some app, it will payed in this DVMs? Nice would be, if the protocols and logs get played back inside this database. And they are also compressed and enrypted. In the end you have an database, which maintain all the running coding, configurations and security-logs (So AppArmor can be used to see the good or bad behaviors). Kind Regards -- 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/200f40ab-d468-4257-9643-6bd5d048698c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Thoughts about installed software
On 10/12/2016 02:22 PM, Robert Mittendorf wrote: Am 10/12/2016 um 04:00 PM schrieb 7v5w7go9ub0o: On 10/11/2016 09:30 AM, Robert Mittendorf wrote: Software that you don't need is a security risk as it imposes additional attack surface - we all know that. Besides exploits those tools might cause additional threat (e.G. RDP- VNC-, SSH-Clients) So you better do not install non-universal software* in a template VM. *software that is not needed in every VM which is based on that template So where to put non-universal software? - user-space: allows malware to persist easily, because of persistent write rights. And does not allow usage of standard repositories - other (cloned) TemplateVM: You need to make sure that you keep all templates up-to-date for security reasons, you need much more storage space and cause more ssd aging Interesting!! Since r2.x, I've run each of my user apps in individual, dedicated, dynamically-configured DispVMs; using scripts that: start up a new DispVM, copies the application-specific files from the vault into the DispVM; runs the application, copies any updated data (data only) back from the DVM to the folder in the vault; discards the DVM. Of course the vault remains offline, and programs are never invoked within the vault; it is used exclusively to store data that is accessed safely in dispvms. If a DVM becomes compromised or corrupted I simply dispose of the DispVM and start anew. No worries about quiet infections of appvm user files, as only updated data (in most cases txt files) is retained from the DispVM back to the vault. After your OP, it dawns on me that one could devise similar scripts to start up a "barebones" DVM, dynamically modify it to be a dedicated application DVM by copying both the application files AND the necessary system (app) files into that DVM. Run the app; copy any updated data (data only) back into the vault, and discard the DVM. (This is trivial with some apps; e.g. keepassx; but could be involved with big complicated apps) This would keep the DispVMs smaller, and as you point out, with fewer attack surfaces. This would require two AppVMs: a "barebones" DVM (As per Rudd-O's "minimal" point, I'll likely use the Qubes default with Firefox system and FF "user" files installed), and a second AppVM containing and maintaining the system and user application files - it would be brought online only for the purpose of package manager updating. I plan on testing/configuring this way with r4.x. Thank You for the OP. Interesting idea. However I would not use the "move to VM" command like this, as I experienced those requests getting lost One time files were actually deleted, since that time I always use copy instead of move. This is a problem with Linux (package based setup, dependency hell) - in Windows you can run most Tools from their folder which you can place anywhere you like. They may create files in other places (like the registry), but they mostly run on a system they are copied to. Depending on how you copy malware still might be able to persist. I think about a browser extension, for example. Robert Dang! Right you are - I miss-wrote! I do indeed copy; e.g.: qvm-run -q --pass-io vault 'tar -c -f - keepass' | qvm-run --pass-io $x 'tar -x -f -' (where $x is the newly-created DispVM.) So I'll add an additional, similar command that would copy the system executable (e.g. keepassx) to the DVM, and instead of executing an installed app - which I do now: qvm-run -q $x 'keepassx /home/user/keepass/keepass.kdb' & I'd start executing a recently-copied app; e.g. something like (./ may not be needed): qvm-run -q $x './home/user/keepass/keepassx /home/user/keepass/keepass.kdb' & Don't know how much this will save me, as I don't have a lot of "stuff" installed, but it should reduce DVM size and attack surface(at the acceptable cost of dynamically creating DVMs before executions). In terms of browser extensions, I think they *ARE* an issue, and I routinely copy only places.sqlite back to the vault; the rest of the DVM is discarded. IF I do want to update extensions, then I'll start the FF DVM, update extensions, ublock, etc.; copy the whole shebang back to the vault; and then shutdown - without exposing FF to anything else. -- 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/eb54e356-fb48-a64c-e6dc-dd8d0146841b%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Thoughts about installed software
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Robert, > However I would not use the "move to VM" command like this, as I > experienced those requests getting lost One time files were > actually deleted, since that time I always use copy instead of > move. Sounds troubling. Do you remember the last Qubes release version where you experienced this kind of data loss? Rusty -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJX/kvQXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0 NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfZA0P/0vw2dBijUk6vZtmWgsGzL/B 3l+H7KcVXu7zPzjEMwQAdufC0gn2JG8NVWH7HHe6ru42iME07JNww1RoOvwImq4h /u8DojH7PYeO88TlmCquH9J9nxF7W6+LC0nEtsTAbEF0dxUUfHFL9MyOKGoU/nq+ JU78lKBfFstUCtcqib1J0ENAsRbY6oPj+XaAqkOGvX9uTqWPslUmncEstn4KXzIy M8b86Vql3WJ0fJgYdVxrLzuFgbMHUIjk4vfv2dNGwQHaDYXA25wM9jdV9FbED0mk pL6VTMwRHA5SCnXaTjHRJzS7+x/vOEGhNiwkyR5bpXiaHrxer3MmszC+oIgXuiXC yWthLHJ/fqrZjSjClrLYlQbCiD5gz6tWsul8KSzAGh56vMVsfXghHs4QIcNv61xp tfnQg4ESBtHLc3+LuDQRax6kkJVMCwX4s1KQQ3v6t8os7w/HBIBdkVHWkRBVKywu 8d/L2meN76DYyTsopjN5EfVOQ+/53dbTiUf+FTsl2ENM0yb6D8FcdgPm44XP9iE/ 5eiWcKazFvFYs9wOxXrs+Ej8aw6WW5mBTeoRoC+jSxTmA4nPoTAjHT6aSwwnCTvM MMtWk68WPbHic4ISDLl8X3OJCUjD6Yiar6Q5DoWWfwVGQZek/EVs/LwoCRhkSMn6 4E8tGXUwqvA9ADx9k/cL =tp0q -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/40b2c885-364c-766f-6bff-c0505d20626a%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Thoughts about installed software
Am 10/12/2016 um 04:00 PM schrieb 7v5w7go9ub0o: On 10/11/2016 09:30 AM, Robert Mittendorf wrote: Software that you don't need is a security risk as it imposes additional attack surface - we all know that. Besides exploits those tools might cause additional threat (e.G. RDP- VNC-, SSH-Clients) So you better do not install non-universal software* in a template VM. *software that is not needed in every VM which is based on that template So where to put non-universal software? - user-space: allows malware to persist easily, because of persistent write rights. And does not allow usage of standard repositories - other (cloned) TemplateVM: You need to make sure that you keep all templates up-to-date for security reasons, you need much more storage space and cause more ssd aging Interesting!! Since r2.x, I've run each of my user apps in individual, dedicated, dynamically-configured DispVMs; using scripts that: start up a new DispVM, copies the application-specific files from the vault into the DispVM; runs the application, copies any updated data (data only) back from the DVM to the folder in the vault; discards the DVM. Of course the vault remains offline, and programs are never invoked within the vault; it is used exclusively to store data that is accessed safely in dispvms. If a DVM becomes compromised or corrupted I simply dispose of the DispVM and start anew. No worries about quiet infections of appvm user files, as only updated data (in most cases txt files) is retained from the DispVM back to the vault. After your OP, it dawns on me that one could devise similar scripts to start up a "barebones" DVM, dynamically modify it to be a dedicated application DVM by copying both the application files AND the necessary system (app) files into that DVM. Run the app; copy any updated data (data only) back into the vault, and discard the DVM. (This is trivial with some apps; e.g. keepassx; but could be involved with big complicated apps) This would keep the DispVMs smaller, and as you point out, with fewer attack surfaces. This would require two AppVMs: a "barebones" DVM (As per Rudd-O's "minimal" point, I'll likely use the Qubes default with Firefox system and FF "user" files installed), and a second AppVM containing and maintaining the system and user application files - it would be brought online only for the purpose of package manager updating. I plan on testing/configuring this way with r4.x. Thank You for the OP. Interesting idea. However I would not use the "move to VM" command like this, as I experienced those requests getting lost One time files were actually deleted, since that time I always use copy instead of move. This is a problem with Linux (package based setup, dependency hell) - in Windows you can run most Tools from their folder which you can place anywhere you like. They may create files in other places (like the registry), but they mostly run on a system they are copied to. Depending on how you copy malware still might be able to persist. I think about a browser extension, for example. Robert -- 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/d5a4c26b-0d78-dbbd-3a2e-6b26d0ee97fa%40digitrace.de. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Thoughts about installed software
On 10/11/2016 09:30 AM, Robert Mittendorf wrote: Software that you don't need is a security risk as it imposes additional attack surface - we all know that. Besides exploits those tools might cause additional threat (e.G. RDP- VNC-, SSH-Clients) So you better do not install non-universal software* in a template VM. *software that is not needed in every VM which is based on that template So where to put non-universal software? - user-space: allows malware to persist easily, because of persistent write rights. And does not allow usage of standard repositories - other (cloned) TemplateVM: You need to make sure that you keep all templates up-to-date for security reasons, you need much more storage space and cause more ssd aging Interesting!! Since r2.x, I've run each of my user apps in individual, dedicated, dynamically-configured DispVMs; using scripts that: start up a new DispVM, copies the application-specific files from the vault into the DispVM; runs the application, copies any updated data (data only) back from the DVM to the folder in the vault; discards the DVM. Of course the vault remains offline, and programs are never invoked within the vault; it is used exclusively to store data that is accessed safely in dispvms. If a DVM becomes compromised or corrupted I simply dispose of the DispVM and start anew. No worries about quiet infections of appvm user files, as only updated data (in most cases txt files) is retained from the DispVM back to the vault. After your OP, it dawns on me that one could devise similar scripts to start up a "barebones" DVM, dynamically modify it to be a dedicated application DVM by copying both the application files AND the necessary system (app) files into that DVM. Run the app; copy any updated data (data only) back into the vault, and discard the DVM. (This is trivial with some apps; e.g. keepassx; but could be involved with big complicated apps) This would keep the DispVMs smaller, and as you point out, with fewer attack surfaces. This would require two AppVMs: a "barebones" DVM (As per Rudd-O's "minimal" point, I'll likely use the Qubes default with Firefox system and FF "user" files installed), and a second AppVM containing and maintaining the system and user application files - it would be brought online only for the purpose of package manager updating. I plan on testing/configuring this way with r4.x. Thank You for the OP. -- 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/84df6c4b-4849-a3ae-fa55-8bd62c79f7c4%40gmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Thoughts about installed software
Software that you don't need is a security risk as it imposes additional attack surface - we all know that. Besides exploits those tools might cause additional threat (e.G. RDP- VNC-, SSH-Clients) So you better do not install non-universal software* in a template VM. *software that is not needed in every VM which is based on that template So where to put non-universal software? - user-space: allows malware to persist easily, because of persistent write rights. And does not allow usage of standard repositories - other (cloned) TemplateVM: You need to make sure that you keep all templates up-to-date for security reasons, you need much more storage space and cause more ssd aging So what about a multi-level template system. That way you can keep at least most software up-to-date with a single update process. This would need a delta-filesystem instead of the current image=directory approach i think. I don't know whether Xen has such capabilities?! Robert -- 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/c7962f0f-9a05-2f81-9390-ce3a7bfb87ee%40digitrace.de. For more options, visit https://groups.google.com/d/optout.
