Re: [qubes-users] How to share data between 2 Qubes installations via USB in a sensible way?

[Salmiakki]

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?

[David Hobach]

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?

[Chris Laprise]

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?

[Andrew David Wong]

-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?

[Franz]

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.