Re: Separating different ecryptfs mounts

["Christian Stüble" <stueble@sirrix.com>]

Hi Tyler,

thanks for your answer. I hope you have not misunderstood my question (you 
describe copying a file from plain1 to plain2, right?): When an encrypted file 
(from directory raw1) is copied into directory raw2,
I want that it is not decrypted from the view of plain2.

That is, I want that key1 is only used to decrypt files to be readable at 
plain1 and key2 is only used to decrypt files for plain2.

I have the setup described already but I noticed that a file copied from
raw1 to raw2 (or vice versa) is accessible in plain1 and plain2 although
the ecryptfs mount assigns only one key fro each overlay.

I assume that the reason for this behavior (which is what a normal user would 
expect) is, that both mounts access the same keyring and thus have access to
all keys. Is that correct? My hope is that it is possible to restrict the use 
of the keys to individual ecryptfs mounts.

My expectation (not verified yet) is that the behavior I need can be realized
by doing the mounts with two different users, but I hope that there is a 
better solution.

Best regards,
Chris

Am Mittwoch, 24. September 2014, 09:06:12 schrieb Tyler Hicks:
> On 2014-09-24 10:50:57, Christian Stüble wrote:
> > Hi,
> > 
> > is it possible with ecryptfs to have two different ecryptfs mounts, e.g.,
> > 
> > plain1 -> raw1
> > plain2 -> raw2
> > 
> > using two different openssl keys, and to ensure that each key is _only_
> > used by its own mount? That is, I want to prevent that files copied
> > between
> > raw1 and raw2 are automatically decrypted.
> 
> Everything above is doable except for the last part. Copying files
> between two eCryptfs mount points will result in the file being
> decrypted when copied out of the first mount and re-encrypted when copied
> into the second mount point.
> 
> > To my understanding of the IBM paper about ecryptfs, it should be possible
> > to set a policy defining which mount is allowed to use which key, but I
> > could not find any documentation about it.
> 
> The policy feature described in the IBM paper was future thinking. It
> has never been implemented and there are no near term plans to implement
> it. I would be willing to accept patches that implement the feature.
> 
> Tyler
> 
> > When it is possible, can you explain or point me to some docs describing
> > how I can do this?
> > 
> > Thanks,
> > Chris
> > 
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe ecryptfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Sirrix AG security technologies - http://www.sirrix.com
Dipl.-Inform. Christian Stüble  eMail: stueble@sirrix.com
Tel +49(681) 959 86-111    Fax +49(681) 959 86-511

Vorstand: Ammar Alkassar (Vors.), Christian Stüble, Markus Bernhammer
Vorsitzender des Aufsichtsrates: Harald Stöber
Sitz der Gesellschaft: Homburg/Saar, HRB 3857 Amtsgericht Saarbrücken
This message may contain confidential and/or privileged information. If you
are not the addressee, you must not use, copy, disclose or take any action
based on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail and
delete this message.