Re: [qubes-users] How to share data between 2 Qubes installations via USB in a sensible way?
On Monday, June 27, 2016 at 7:22:26 PM UTC+2, David Hobach wrote: > (qvm-block can mount files from one VM to > another) If this is true, why is it not a massive security issue? -- 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/8c900a29-bc58-4ac0-b7f5-1687c016fd7c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] How to share data between 2 Qubes installations via USB in a sensible way?
On 06/27/2016 07:22 PM, David Hobach wrote: On 06/19/2016 01:12 PM, Chris Laprise wrote: On 06/19/2016 05:25 AM, David Hobach wrote: I wonder whether there's any sensible (= relatively secure) way of sharing data between 2 Qubes installations via a single USB pen drive or hard disk? What are you using or do you have any thoughts? [...] I think I identified the probably optimal solution: In short you can use some less known qvm-block tricks to mount files from one VM to another and thus force all FS & USB attacks to happen inside your USB VM. In long: Run a service in dom0: 1. Every 3s check whether a specific USB drive was attached to the USB VM (vendor & product ID match); if yes: 2. Mount it and iterate over the folders found there (--> USB driver & filesystem parsing attacks only affect the usb VM) 3. If a folder found there matches a name of a list of VMs defined in the script and that VM is started, mount the luks file in the folder to that VM using qvm-block (qvm-block can mount files from one VM to another), if it's not already mounted. 4. Each of these luks files can only be decrypted by the respective VM via a key file that only that VM has. From dom0 we can locate that file and do the necessary decrypt & mount operations as well. The service should also provide a state in dom0 for other services to indicate for which VMs it is currently active and can be active. So assuming qvm-block is reasonably secure, only attacking the luks implementation would still work to compromise VMs, but that's pretty much it from my point of view. Plus the attacker might have to destroy data he'd like to extract in order to get the attack done. Attached a sample implementation for anyone interested. Use it at your own risk! Kind Regards David -- 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/18f5517b-927f-7fa4-59a1-502a9d5d6862%40hackingthe.net. For more options, visit https://groups.google.com/d/optout. #!/bin/bash # # author: David Hobach # version: 1.0 / 04.09.2016 # # See usage. # # For testing you can use losetup devices. #errorOut [message] function errorOut { >&2 echo "ERROR: $1" >&2 echo "Aborting..." exit 1 } #infoNoNewLine [message] [optional: 1 = also log] function infoNoNewline { echo -n "INFO: $1" [ -n "$2" ] && [ $2 -eq 1 ] && log "$1" } #info [message] [optional: 1 = also log] function info { infoNoNewline "$1" "$2" echo "" } #log [message] function log { #in Qubes use journalctl|grep "$SCRIPT_NAME" to find related logs logger "${SCRIPT_NAME}: $1" } function reloadPid { PID=$([ -f "$PID_FILE" ] && cat "$PID_FILE") } ## start: config variables # #name & directory of this script (hopefully...) SCRIPT_DIR="$(dirname "$(readlink -f "${BASH_SOURCE[0]}")")" SCRIPT_NAME="$(basename "$0")" SCRIPT="$SCRIPT_DIR/$SCRIPT_NAME" #full path to the default config file & load it DEFAULT_CONFIG="${SCRIPT}_default.conf" source "$DEFAULT_CONFIG" [ $? -ne 0 ] && errorOut "Failed to load the default config from ${DEFAULT_CONFIG}." #full path to the custom config file & load it, if it exists #the custom config is meant to be used to override variables from the default config CUSTOM_CONFIG="${SCRIPT}_custom.conf" if [ -f "$CUSTOM_CONFIG" ] ; then source "$CUSTOM_CONFIG" [ $? -ne 0 ] && errorOut "Failed to load the custom config from ${CUSTOM_CONFIG}." else errorOut "No custom configuration file found at ${CUSTOM_CONFIG}. You'll probably at least want to specify the VMs you'd like to use with qusb there." fi #path to the PID file to use by this script PID_FILE="${SCRIPT_DIR}/${SCRIPT_NAME}.pid" #PID of the currently running service PID= reloadPid #the qvm-run command with necessary parameters #NOTE: qvm-run will always make dom0 wait during the execution of the script in the client VM! QVM_RUN="qvm-run -p -u root" #timeout for error notifications to the user in ms (( NOTIFY_ERROR_TIMEOUT_MS = $NOTIFY_ERROR_TIMEOUT * 1000 )) ## end: config variables # #joinArray [delimiter] [all array elements expanded] function joinArray { local d=$1; shift; echo -n "$1"; shift; printf "%s" "${@/#/$d}"; } function usage { echo "$SCRIPT_NAME start|stop|restart|status|mountAll|umountAll|setupDrive [partition]|setupDriveData|mountAllToSingle [target VM] [target VM: key file base path] [target VM: decrypted data path]|help" echo "" echo "$SCRIPT_NAME is a small service which runs in dom0 and attempts to provide a secure way of sharing data between two Qubes installations (each with multiple VMs) via a single USB drive. The service is configured via global variables in this script." echo "" echo "
Re: [qubes-users] How to share data between 2 Qubes installations via USB in a sensible way?
On 06/19/2016 01:12 PM, Chris Laprise wrote: On 06/19/2016 05:25 AM, David Hobach wrote: I wonder whether there's any sensible (= relatively secure) way of sharing data between 2 Qubes installations via a single USB pen drive or hard disk? What are you using or do you have any thoughts? [...] I think I identified the probably optimal solution: In short you can use some less known qvm-block tricks to mount files from one VM to another and thus force all FS & USB attacks to happen inside your USB VM. In long: Run a service in dom0: 1. Every 3s check whether a specific USB drive was attached to the USB VM (vendor & product ID match); if yes: 2. Mount it and iterate over the folders found there (--> USB driver & filesystem parsing attacks only affect the usb VM) 3. If a folder found there matches a name of a list of VMs defined in the script and that VM is started, mount the luks file in the folder to that VM using qvm-block (qvm-block can mount files from one VM to another), if it's not already mounted. 4. Each of these luks files can only be decrypted by the respective VM via a key file that only that VM has. From dom0 we can locate that file and do the necessary decrypt & mount operations as well. The service should also provide a state in dom0 for other services to indicate for which VMs it is currently active and can be active. So assuming qvm-block is reasonably secure, only attacking the luks implementation would still work to compromise VMs, but that's pretty much it from my point of view. Plus the attacker might have to destroy data he'd like to extract in order to get the attack done. -- 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/edb3ab52-cc97-26ed-1bc4-f2ce54d2db79%40hackingthe.net. For more options, visit https://groups.google.com/d/optout. smime.p7s Description: S/MIME Cryptographic Signature
Re: [qubes-users] How to share data between 2 Qubes installations via USB in a sensible way?
On 06/19/2016 05:25 AM, David Hobach wrote: I wonder whether there's any sensible (= relatively secure) way of sharing data between 2 Qubes installations via a single USB pen drive or hard disk? What are you using or do you have any thoughts? [...] Probably I did understand what you are trying to achieve, but when I had to copy data between two Qubes installations made a backup of the first installation on a NAS and restored it on the second installation, changing the name of conflicting VMs before restore. Everything really easy and fast. This is the method I personally use. It's essentially a system "migration" as described here: https://www.qubes-os.org/doc/backup-restore/#tocAnchor-1-1-4 That's indeed a good solution for rare accesses - especially from a security point of view (From what I see the USB drive does not need to be trusted as it can be mounted in some untrusted AppVM and the encryption is done in dom0.). I'm just not so sure if it's good for day-to-day use wrt to speed. So if I want to modify one file on my USB drive, I have to restore the entire backup (maybe 10GB or so), edit the file and then do a backup again? So it would take 15min to edit a single file I guess? Ideally I'd like to plug the USB drive in my machine and see the files dedicated for VM_A inside that VM immediately (same for the other VMs). Then I'd edit, maybe umount and then unplug the USB drive again. Maybe I'm a little picky about speed, but I know that once users have to use secure solutions that are slow, they'll go for totally insecure ones that are fast. So I prefer to see people going to pretty secure ones that are fast. Thanks for the suggestion though - I hadn't considered it so far as I'm not using the original Qubes backup solution (once again for speed reasons - and yes, it adds 1-2 potential attack vectors). Try this automount solution - https://groups.google.com/d/msgid/qubes-users/20160607202924.GD1593%40mail-itl If you are sharing between to similar vms (even if they're on different systems) you can format the volume in vm with LUKS and specify a keyfile in each vm using crypttab. No need to have dom0 format or decrypt the volume. Chris -- 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/57667E11.3060004%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] How to share data between 2 Qubes installations via USB in a sensible way?
I wonder whether there's any sensible (= relatively secure) way of sharing data between 2 Qubes installations via a single USB pen drive or hard disk? What are you using or do you have any thoughts? [...] Probably I did understand what you are trying to achieve, but when I had to copy data between two Qubes installations made a backup of the first installation on a NAS and restored it on the second installation, changing the name of conflicting VMs before restore. Everything really easy and fast. This is the method I personally use. It's essentially a system "migration" as described here: https://www.qubes-os.org/doc/backup-restore/#tocAnchor-1-1-4 That's indeed a good solution for rare accesses - especially from a security point of view (From what I see the USB drive does not need to be trusted as it can be mounted in some untrusted AppVM and the encryption is done in dom0.). I'm just not so sure if it's good for day-to-day use wrt to speed. So if I want to modify one file on my USB drive, I have to restore the entire backup (maybe 10GB or so), edit the file and then do a backup again? So it would take 15min to edit a single file I guess? Ideally I'd like to plug the USB drive in my machine and see the files dedicated for VM_A inside that VM immediately (same for the other VMs). Then I'd edit, maybe umount and then unplug the USB drive again. Maybe I'm a little picky about speed, but I know that once users have to use secure solutions that are slow, they'll go for totally insecure ones that are fast. So I prefer to see people going to pretty secure ones that are fast. Thanks for the suggestion though - I hadn't considered it so far as I'm not using the original Qubes backup solution (once again for speed reasons - and yes, it adds 1-2 potential attack vectors). -- 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/57666506.8020002%40hackingthe.net. For more options, visit https://groups.google.com/d/optout. smime.p7s Description: S/MIME Cryptographic Signature
Re: [qubes-users] How to share data between 2 Qubes installations via USB in a sensible way?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2016-06-17 12:32, Franz wrote: > On Fri, Jun 17, 2016 at 1:52 PM, David Hobach > wrote: > >> Dear users, >> >> I wonder whether there's any sensible (= relatively secure) way >> of sharing data between 2 Qubes installations via a single USB >> pen drive or hard disk? >> >> What are you using or do you have any thoughts? >> >> [...] >> > Probably I did understand what you are trying to achieve, but > when I had to copy data between two Qubes installations made a > backup of the first installation on a NAS and restored it on the > second installation, changing the name of conflicting VMs before > restore. Everything really easy and fast. > This is the method I personally use. It's essentially a system "migration" as described here: https://www.qubes-os.org/doc/backup-restore/#tocAnchor-1-1-4 - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJXZOC+AAoJENtN07w5UDAwVIEP/jqTHcqYorkFVS/Y60A5s57P EYQgnkIq3DYRZ7teJLCdKRjqROFcmBnLEjjn7TwRLePG0c0W38vawgHB/RNj+AAK uLd0x4NF4oeUJeo3ts9nxLVTsTB/qcoSXE9ameWX+SWblyC1ivqStAn02Ayt/e4Z 4iDhjfr2Dm5Abgp4SySUNFYfs4F1Ov/7R1YQSHqT43gOPfOOHtpmpXcRgMZhRi6V nfRwLAaAYRrcvTI4AkYU1USEyTttvTeZE6vo0Zxhut8KNo6DNN8oUjbOqyfNs//K eQY6jZaQoGcnToUAwbOK48ebISYM0se3a7O1sWsmNmqBmt+FhKe+bI+3z+dR/HB4 crrFWvMSguh1FZcibdbvr6BxMueHZzBX0gNDy62Xd1CMK3wFHLuS2lWxPNM3RJSo KfQA2Hq9fcc6DJhq1aI+LQi6BJNcSiKHJaufLRltWfzyFY3kKOcJHieaS3affOsa vrYLr8cACuMpt0USflORo1mVYMVTxcO3IJT4z1xIRhFYtCqS7SZuk83DD0qoIbnU 3GLqSnpO/8EToNr6qoV5KwhgD9DKG1G7n0RIobGF+8RCerRLhY0j5aaRdo1IUW/8 NnaexunD9zW2NtHo5kDBwmeUEaXJ66ici9iOj7EfJMGSaE5dwrVfsGxIyLtHYf1h YXAc7g6t8CcFYe/z5MWs =O21o -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/f92279ab-798b-94cc-f38c-fb6669194bde%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] How to share data between 2 Qubes installations via USB in a sensible way?
On Fri, Jun 17, 2016 at 1:52 PM, David Hobach wrote: > Dear users, > > I wonder whether there's any sensible (= relatively secure) way of sharing > data between 2 Qubes installations via a single USB pen drive or hard disk? > > What are you using or do you have any thoughts? > > Of course I assume that both installations have multiple VMs for which you > want to share data (i.e. Qubes_A has VM_1, VM_2, VM_3, ... and Qubes_B has > VM_1*, VM_2*, VM_3* and you want to share data as follows: VM_1 -> VM_1*, > VM_2 -> VM_2* and so on). The single VM solution is obviously directly > supported by Qubes. > > I also consider having one USB drive per VM not practical. > > Kind Regards > David > > -- > > My proposal: > > 0. for each client VM you'll need a subfolder on that USB drive with a > dmcrypt container inside > 1. Attach the USB drive to some usbshare VM ("server" VM) & mount it there > 2. Run a ssh server in the usbshare VM, accessible for all client VMs > 3. in your client VMs use e.g. sshfs to access the respective dmcrypt > container and decrypt it using a key local to the respective client VM > > Mitigated attacks: > - USB driver attacks would be executed in the usbshare VM which doesn't > have access to any sensible data (all encrypted) --> USB drive does not > need to be trusted > - no VM can access another one's data without successfully compromising > the other VM or breaking the dmcrypt crypto > - other OSes cannot read the data and cannot modify it without being > noticed (integrity needs to be checked by the deployed crypto algorithms) > > Possible attacks: > - ssh exploits (clients can try to attack the usbshare VM, the usbshare VM > might try to attack the client VMs via ssh vulnerabilities) > > > Feedback welcome! > > Probably I did understand what you are trying to achieve, but when I had to copy data between two Qubes installations made a backup of the first installation on a NAS and restored it on the second installation, changing the name of conflicting VMs before restore. Everything really easy and fast. > -- > 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/57642AC5.4070100%40hackingthe.net > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CAPzH-qBD_%2BcS_d-tpBJPb5WBzBwf6eC_iCyU0OOGPC3oGFb%3DmA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] How to share data between 2 Qubes installations via USB in a sensible way?
Dear users, I wonder whether there's any sensible (= relatively secure) way of sharing data between 2 Qubes installations via a single USB pen drive or hard disk? What are you using or do you have any thoughts? Of course I assume that both installations have multiple VMs for which you want to share data (i.e. Qubes_A has VM_1, VM_2, VM_3, ... and Qubes_B has VM_1*, VM_2*, VM_3* and you want to share data as follows: VM_1 -> VM_1*, VM_2 -> VM_2* and so on). The single VM solution is obviously directly supported by Qubes. I also consider having one USB drive per VM not practical. Kind Regards David -- My proposal: 0. for each client VM you'll need a subfolder on that USB drive with a dmcrypt container inside 1. Attach the USB drive to some usbshare VM ("server" VM) & mount it there 2. Run a ssh server in the usbshare VM, accessible for all client VMs 3. in your client VMs use e.g. sshfs to access the respective dmcrypt container and decrypt it using a key local to the respective client VM Mitigated attacks: - USB driver attacks would be executed in the usbshare VM which doesn't have access to any sensible data (all encrypted) --> USB drive does not need to be trusted - no VM can access another one's data without successfully compromising the other VM or breaking the dmcrypt crypto - other OSes cannot read the data and cannot modify it without being noticed (integrity needs to be checked by the deployed crypto algorithms) Possible attacks: - ssh exploits (clients can try to attack the usbshare VM, the usbshare VM might try to attack the client VMs via ssh vulnerabilities) Feedback welcome! -- 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/57642AC5.4070100%40hackingthe.net. For more options, visit https://groups.google.com/d/optout. smime.p7s Description: S/MIME Cryptographic Signature