Hi,

I think you have some misconceptions here - the main one being why people tend to use Qubes OS: Segregation of data to application-specific domains, i.e. impact of a domain compromise is limited.

Your idea however makes your Qubes installation vulnerable to:
- Any attacks originating from that OS ("files should still be accessible/decryption from other Operating systems"). - Nfs-based attacks (basically all your AppVMs using nfs will be vulnerable to all nfs vulnerabilities - and there have been quite a few in the past).
- encfs based attacks which people can even find on wikipedia.

If you don't want to add another idea to the security circus, I'd reconsider either using Qubes OS, your other OS or your architecture. The invisible things blog articles should be a good point to start with.

KR
David

On 10/15/2017 11:01 AM, '[799]' via qubes-users wrote:
Hello,

I'd like to add, that I know that EncFS seems to have some issues, mentioned 
here for example:
https://defuse.ca/audits/encfs.htm
While this report is from 2014 and a new version has been issued it seems that 
encfs 2.x (which should provide better security) is still on its way - if it 
will come at all.

Unfortunately encfs is the only solution which is cross-platform, if someone is 
using a Linux only environment, the encryption layer could be replaced with 
other solutions:
https://www.cryfs.org/comparison

As such the subject should not be...

"Idea for (resonable secure) cloud-storage usage with Qubes"

... but ...

"Idea for (a slightly more secure) cloud-storage usage with Qubes"

[799]

PS: sorry for Top-Posting ;-)
I have a typo in my initial post, replace my-untrusted with my-work (where I 
unmount the encfs uencrypted directory)

-------- Original-Nachricht --------
An 15. Okt. 2017, 01:54, [799] schrieb:

Hello,
I thought about how to work with cloud storage under Qubes OS and I'd like to 
share my idea with you, to provide feedback.
I have already build a prototype that works "reasonable" well, but I am far 
away from being a security professional, as such I'd like to hear your opion about it.
Assumptions:
You are using cloud storage like Microsoft OneDrive and you would like to do so 
under Qubes in a more secure way.
Goals:
- all files within onedrive should be encrypted
- files should still be accessible/decryption from other Operating systems
- decrypted data storage and cloud storage access should be separated into two 
AppVMs
- different AppVMs should have access to data in the cloud storage, but it's 
impossible for an AppVM to read the data which should be read by other AppVMs 
(meaning you have the option to create individuall encrypted directories)
- solution should be easy to use and relying on scripts to provide good 
automation and a good tradeoff between security and user experience.

Idea:
In order to reach the goals, the idea is to work with two AppVMs:
1. "Access+Transfer AppVM" this VM will access the cloud storage provider, 
provide synchronisation and will always see encrypted data
2. "Storage-AppVM" this VM will receive the encrypted files from the 
Access+Transfer AppVM and store the files. It will also work as a data-hub to provide 
access to data to your other AppVMs which you use to manipulate the data within this VM.

As such we have separated:
- Access & Transfer of data from cloud storage provider
- Local data storage
- Data manipulation

Solution Design:
[Access+Transfer AppVM]
Template: fedora-25-minimal
Additional packages:
- OneDrive Freeclient 
([https://github.com/skilion/onedrive)](https://github.com/skilion/onedrive)
- sudo dnf -y install nfsutils
Will be configured to mount a NFS-share from the Storage AppVM and to access 
OneDrive to synchronize the files
Data will be downloaded and storad in the mounted NFS-Share of the Storage AppVM

[Storage App-VM]
Template: fedora-25-minimal
Additional packages:
- sudo dnf -y nfs-utils encfs
This machine has been setup as a NFS Server.
The /etc/exports file and also the iptables Firewall of this AppVM has been 
setup, so that the [Access+Transfer AppVM] kann access a certain location.
Within this location all files ENCFS-encrypted.
As such the Access+Transfer AppVM but also the Cloud Storage provider will only 
see encrypted files.
Additional AppVMs can also mount the main NFS Share/directory.
Those AppVMs can access certain subfolders and mount them via ENCFS to get the 
unecrypted data.
So the ENCFS decryption are done in those AppVMs.
You could setup various subfolders within your Onedrive directory and each 
folder could be encrypted within the different AppVMs.
Example:
onedrive\photos --> NFS Share to --> my-photo-appvm
onedrive\work --> NFS Share to --> my-work-appvm
onedrive\media --> NFS Share to --> my multimedia-appvm

Let's look at one AppVM (example my-work-appvm = 10.137.2.25 // storage-appvm = 
10.137.2.20)
On sys-firewall there is a rule, so that the work-appvm can access the 
storage-appvm:
[user@sys-firewall ~]$ sudo iptables -I FORWARD 2 -s 10.137.2.25 -d 10.137.2.20 
-j ACCEPT

On the storage appvm:
[user@my-storage ~]$ sudo iptables -I INPUT 5 -i eth0 -s 10.137.2.25 -d 
10.137.2.20 -j ACCEPT
The NFS Exports file:
[...]
# 10.137.2.15 = Access+Transfer AppVM
/var/nfs 10.137.2.15(rw,sync,no_subtree_check)
# 10.137.2.25 = Work AppVM
/var/nfs/work 10.137.2.25(rw,sync,no_subtree_check)
[...]

In the Work AppVM you are mounting the NFS Share from the Storage AppVM:
sudo mount 10.137.2.20:/var/nfs/work /mnt/onedrive-work.encfs

In Order to access the files, the NFS share is encfs-mounted:
encfs /mnt/onedrive-work.encfs ~/work

the unencrypted files can be accessed in ~/work.
If saved they will be encfs-encrypted and stored to NFS share of the Storage 
AppVM.
The Storage AppVM is connected to the Access-Transfer-AppVM which will 
recognize that an (encrypted) file has changed and will upload it to Onedrive.

As you can guess, you can use different AppVMs, which access different 
subfolders with different ENCFS-Keys.
For additional security you can also choose to shutdown the Access+Transfer 
AppVM and disable the NFS Server in the Storage AppVM if you don't need access 
to the files.

Script to start the NFS Server from dom0
#!/bin/bash
qvm-run my-storage 'xterm -e "sudo systemctl start nfs"'
sleep 2

Scripts to unencrypt the data in an AppVM from dom0:
#!/bin/bash
qvm-run my-work 'xterm -e "encfs /mnt/onedrive-work.encfs ~/work"'

Script to unmount the unencrypted share in an AppVM:
#!/bin/bash
qvm-run my-untrusted 'xterm -e "fusermount -u ~/work"'

I have already a working prototype, regarding the NFS server and ENCFS-part and 
will now add the onedrive part.

What's your opinion about this approach (I hope I could make clear what the 
idea is) - am I opening to much attack possibilities because I need to have NFS 
server running between the AppVMs? Keep in mind, that I am only sharing one 
directory, which is encrypted and only the AppVM knows how to decrypt the data.
So even if the Storage AppVM gets compromissed, the data should be encrypted 
(and therof protected).

The password entry within the AppVM to open of the ENCFS-encrypted data could 
be simplified by using something like a yubikey + short password.

Interested to get your feedback.

[799]



Hello,

I'd like to add, that I know that EncFS seems to have some issues, mentioned here for example:
https://defuse.ca/audits/encfs.htm
While this report is from 2014 and a new version has been issued it seems that encfs 2.x (which should provide better security) is still on its way - if it will come at all.

Unfortunately encfs is the only solution which is cross-platform, if someone is using a Linux only environment, the encryption layer could be replaced with other solutions:
https://www.cryfs.org/comparison

As such the subject should not be...

"Idea for (resonable secure) cloud-storage usage with Qubes"

... but ...

"Idea for (a slightly more secure) cloud-storage usage with Qubes"

[799]

PS: sorry for Top-Posting ;-)
I have a typo in my initial post, replace my-untrusted with my-work (where I unmount the encfs uencrypted directory)

-------- Original-Nachricht --------
An 15. Okt. 2017, 01:54, [799] schrieb:


    Hello,
    I thought about how to work with cloud storage under Qubes OS and
    I'd like to share my idea with you, to provide feedback.
    I have already build a prototype that works "reasonable" well, but I
    am far away from being a security professional, as such I'd like to
    hear your opion about it.
    Assumptions:
    You are using cloud storage like Microsoft OneDrive and you would
    like to do so under Qubes in a more secure way.
    Goals:
    - all files within onedrive should be encrypted
    - files should still be accessible/decryption from other Operating
    systems
    - decrypted data storage and cloud storage access should be
    separated into two AppVMs
    - different AppVMs should have access to data in the cloud storage,
    but it's impossible for an AppVM to read the data which should be
    read by other AppVMs (meaning you have the option to create
    individuall encrypted directories)
    - solution should be easy to use and relying on scripts to provide
    good automation and a good tradeoff between security and user
    experience.

    Idea:
    In order to reach the goals, the idea is to work with two AppVMs:
    1. "Access+Transfer AppVM" this VM will access the cloud storage
    provider, provide synchronisation and will always see encrypted data
    2. "Storage-AppVM" this VM will receive the encrypted files from the
    Access+Transfer AppVM and store the files. It will also work as a
    data-hub to provide access to data to your other AppVMs which you
    use to manipulate the data within this VM.

    As such we have separated:
    - Access & Transfer of data from cloud storage provider
    - Local data storage
    - Data manipulation

    Solution Design:
    [Access+Transfer AppVM]
    Template: fedora-25-minimal
    Additional packages:
    - OneDrive Freeclient (https://github.com/skilion/onedrive)
    <https://github.com/skilion/onedrive>
    - sudo dnf -y install nfsutils
    Will be configured to mount a NFS-share from the Storage AppVM and
    to access OneDrive to synchronize the files
    Data will be downloaded and storad in the mounted NFS-Share of the
    Storage AppVM

    [Storage App-VM]
    Template: fedora-25-minimal
    Additional packages:
    - sudo dnf -y nfs-utils encfs
    This machine has been setup as a NFS Server.
    The /etc/exports file and also the iptables Firewall of this AppVM
    has been setup, so that the [Access+Transfer AppVM] kann access a
    certain location.
    Within this location all files ENCFS-encrypted.
    As such the Access+Transfer AppVM but also the Cloud Storage
    provider will only see encrypted files.
    Additional AppVMs can also mount the main NFS Share/directory.
    Those AppVMs can access certain subfolders and mount them via ENCFS
    to get the unecrypted data.
    So the ENCFS decryption are done in those AppVMs.
    You could setup various subfolders within your Onedrive directory
    and each folder could be encrypted within the different AppVMs.
    Example:
    onedrive\photos --> NFS Share to --> my-photo-appvm
    onedrive\work --> NFS Share to --> my-work-appvm
    onedrive\media --> NFS Share to --> my multimedia-appvm

    Let's look at one AppVM (example my-work-appvm = 10.137.2.25 //
    storage-appvm = 10.137.2.20)
    On sys-firewall there is a rule, so that the work-appvm can access
    the storage-appvm:
    [user@sys-firewall ~]$ sudo iptables -I FORWARD 2 -s 10.137.2.25 -d
    10.137.2.20 -j ACCEPT

    On the storage appvm:
    [user@my-storage ~]$ sudo iptables -I INPUT 5 -i eth0 -s 10.137.2.25
    -d 10.137.2.20 -j ACCEPT
    The NFS Exports file:
    [...]
    # 10.137.2.15 = Access+Transfer AppVM
    /var/nfs 10.137.2.15(rw,sync,no_subtree_check)
    # 10.137.2.25 = Work AppVM
    /var/nfs/work 10.137.2.25(rw,sync,no_subtree_check)
    [...]

    In the Work AppVM you are mounting the NFS Share from the Storage AppVM:
    sudo mount 10.137.2.20:/var/nfs/work /mnt/onedrive-work.encfs

    In Order to access the files, the NFS share is encfs-mounted:
    encfs /mnt/onedrive-work.encfs ~/work

    the unencrypted files can be accessed in ~/work.
    If saved they will be encfs-encrypted and stored to NFS share of the
    Storage AppVM.
    The Storage AppVM is connected to the Access-Transfer-AppVM which
    will recognize that an (encrypted) file has changed and will upload
    it to Onedrive.

    As you can guess, you can use different AppVMs, which access
    different subfolders with different ENCFS-Keys.
    For additional security you can also choose to shutdown the
    Access+Transfer AppVM and disable the NFS Server in the Storage
    AppVM if you don't need access to the files.

    Script to start the NFS Server from dom0
    #!/bin/bash
    qvm-run my-storage 'xterm -e "sudo systemctl start nfs"'
    sleep 2

    Scripts to unencrypt the data in an AppVM from dom0:
    #!/bin/bash
    qvm-run my-work 'xterm -e "encfs /mnt/onedrive-work.encfs ~/work"'

    Script to unmount the unencrypted share in an AppVM:
    #!/bin/bash
    qvm-run my-untrusted 'xterm -e "fusermount -u ~/work"'

    I have already a working prototype, regarding the NFS server and
    ENCFS-part and will now add the onedrive part.

    What's your opinion about this approach (I hope I could make clear
    what the idea is) - am I opening to much attack possibilities
    because I need to have NFS server running between the AppVMs? Keep
    in mind, that I am only sharing one directory, which is encrypted
    and only the AppVM knows how to decrypt the data.
    So even if the Storage AppVM gets compromissed, the data should be
    encrypted (and therof protected).

    The password entry within the AppVM to open of the ENCFS-encrypted
    data could be simplified by using something like a yubikey + short
    password.

    Interested to get your feedback.

    [799]

-- 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
    <mailto:qubes-users+unsubscr...@googlegroups.com>.
    To post to this group, send email to qubes-users@googlegroups.com
    <mailto:qubes-users@googlegroups.com>.
    To view this discussion on the web visit
    
https://groups.google.com/d/msgid/qubes-users/1AEzAuelWDrVQsdrIbOmPhwI9QwoloMGiX6VcHatwcwHduke7sU-hDiyWwer2ffDpftxICtSWgAMAfUtd4kSus2RzA1v1DSUMOkwdLzkDkE%3D%40protonmail.com
    
<https://groups.google.com/d/msgid/qubes-users/1AEzAuelWDrVQsdrIbOmPhwI9QwoloMGiX6VcHatwcwHduke7sU-hDiyWwer2ffDpftxICtSWgAMAfUtd4kSus2RzA1v1DSUMOkwdLzkDkE%3D%40protonmail.com?utm_medium=email&utm_source=footer>.
    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/36f3a195-7647-942b-5e6d-f94f11585e5a%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to