# Shared encrypted partition

## Herring42

Hi,

I'm wanting to set up an encrypted loop partition on our server that can be accessed by multiple clients. Is this possible, and how should it be done?

e.g. either:

```

     Server                                                                        Client

Loop file

mounted crypt partition <------- Remote access by --------   nfs access

```

Or:

```

     Server                                                                        Client

Loop file         <------- Remote access by --------           nfs access

                                                                                  mounted crypt partition

```

Is there a better way?

----------

## Anarcho

It depends. Do they need simultaneous access? Then you won't come arround a network filesystem with a server side unencrypted filesystem (btw. which I'm using here).

----------

## cach0rr0

I may be missing something here...if it's already mounted, why would it be treated any differently than any other partition? 

Once it's mounted, the fact that it's encrypted should be invisible. 

Every volume on the machine I'm typing from is encrypted - it's also my file server (NFS)

I export as I would any other FS. 

```

[meat@gw Downloads]$ sudo mount |grep mapper

/dev/mapper/root on / type ext3 (rw)

/dev/mapper/share on /share type xfs (rw,nodev,logbufs=8)

/dev/mapper/kvm on /kvm type btrfs (rw)

/dev/mapper/btrfsvol on /tmp type btrfs (rw,noexec,nosuid,nodev,noatime,subvol=tmp)

/dev/mapper/btrfsvol on /usr type btrfs (rw,nodev,noatime,subvol=usr,compress)

/dev/mapper/btrfsvol on /var type btrfs (rw,noatime,subvol=var,compress)

/dev/mapper/btrfsvol on /opt type btrfs (rw,nosuid,noatime,subvol=opt)

/dev/mapper/btrfsvol on /home type btrfs (rw,nosuid,nodev,noatime,subvol=home,compress)

[meat@gw Downloads]$ sudo cat /etc/exports 

/share  x.x.x.x(rw,sync,no_subtree_check)

/share  x.x.x.y(rw,sync,no_subtree_check)

/share  x.x.x.z(rw,sync,no_subtree_check)

/share  x.x.y.x(rw,sync,no_subtree_check)

/share  x.x.y.y(rw,sync,no_subtree_check)

```

client fstab:

```

host.domain.tld:/share   /share  nfs             rw,defaults     0 0

```

If you were wanting multiple users to be able to mount it, however, that's a different story. In that case methinks you'd have to add each user's key.

(I apologize in advance if I'm missing something, and telling you something you already know!)

----------

## Herring42

That solution would require the encrypted partition to be mounted at all times, whereas I was after something that was unlocked only when the client accessed the partition (for access, possibly read mount).

i.e. the partition was locked to the access of that user, and unavailable to mr hacker that has compromised another account on the server (or indeed another client...)

----------

## cach0rr0

 *Herring42 wrote:*   

> That solution would require the encrypted partition to be mounted at all times, whereas I was after something that was unlocked only when the client accessed the partition (for access, possibly read mount).
> 
> i.e. the partition was locked to the access of that user, and unavailable to mr hacker that has compromised another account on the server (or indeed another client...)

 

ok, that makes more sense. And I have zero ideas there - a compromised account with access (unless it's an interactive process such as entering a passphrase in order to mount it) will be treated just as any other with access. 

Only way I can think of to mitigate the risk is just that, rather than reading unlock from a file, require user input so that even if you compromise an account, the attacker still needs to know the pass to access the crypt volume 

No idea how to do that. Hope I didn't waste too much reading time!

----------

## chithanh

Probably using an ecryptfs based solution would be the way to go. That way the server could not see any unencrypted data, so any compromised account or client would not affect the other users.

----------

## Herring42

Ahh! Yes, that looks like what I'm after. Thank you.

Ok, now to look for a HowTo, and write one if I can't find it!

Cheers, I'll report back.

----------

