| View previous topic :: View next topic |
| Author |
Message |
Herring42
Guru
Joined: 10 Mar 2004
Posts: 373
Location: Buckinghamshire
|
 Posted: Tue Jun 15, 2010 12:55 pm Post subject: Shared encrypted partition |
 |
|
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:
| Code: |
Server Client
Loop file
mounted crypt partition <------- Remote access by -------- nfs access
|
Or:
| Code: |
Server Client
Loop file <------- Remote access by -------- nfs access
mounted crypt partition
|
Is there a better way?
_________________
"The problem with quotes on the internet is that it is difficult
to determine whether or not they are genuine." -- Abraham Lincoln |
|
| Back to top |
|
 |
Anarcho
Advocate
Joined: 06 Jun 2004
Posts: 2970
Location: Germany
|
| Posted: Tue Jun 15, 2010 1:40 pm Post subject: |
|
|
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).
_________________
...it's only Rock'n'Roll, but I like it! |
|
| Back to top |
|
|
cach0rr0
Bodhisattva
Joined: 13 Nov 2008
Posts: 4123
Location: Houston, Republic of Texas
|
| Posted: Tue Jun 15, 2010 8:01 pm Post subject: |
|
|
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.
| Code: |
[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:
| Code: |
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!)
_________________
Lost configuring your system?
dump lspci -n here | see Pappy's guide | Link Stash |
|
| Back to top |
|
|
Herring42
Guru
Joined: 10 Mar 2004
Posts: 373
Location: Buckinghamshire
|
| Posted: Tue Jun 15, 2010 8:21 pm Post subject: |
|
|
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...)
_________________
"The problem with quotes on the internet is that it is difficult
to determine whether or not they are genuine." -- Abraham Lincoln |
|
| Back to top |
|
|
cach0rr0
Bodhisattva
Joined: 13 Nov 2008
Posts: 4123
Location: Houston, Republic of Texas
|
| Posted: Tue Jun 15, 2010 8:27 pm Post subject: |
|
|
| 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!
_________________
Lost configuring your system?
dump lspci -n here | see Pappy's guide | Link Stash |
|
| Back to top |
|
|
chithanh
Developer
Joined: 05 Aug 2006
Posts: 2158
Location: Berlin, Germany
|
| Posted: Wed Jun 16, 2010 1:22 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Herring42
Guru
Joined: 10 Mar 2004
Posts: 373
Location: Buckinghamshire
|
| Posted: Wed Jun 16, 2010 8:59 am Post subject: |
|
|
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.
_________________
"The problem with quotes on the internet is that it is difficult
to determine whether or not they are genuine." -- Abraham Lincoln |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
