Separating different ecryptfs mounts

Separating different ecryptfs mounts

[Christian Stüble]

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. 

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. 

When it is possible, can you explain or point me to some docs describing how I 
can do this?

Thanks,
Chris

Re: Separating different ecryptfs mounts

[Tyler Hicks]

[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Separating different ecryptfs mounts

[Christian Stüble]

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.

Re: Separating different ecryptfs mounts

[Tyler Hicks]

[-- Attachment #1: Type: text/plain, Size: 4796 bytes --]

On 2014-09-24 16:20:54, Christian Stüble wrote:
> 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 did misunderstand your question. Sorry about that.

Note that you shouldn't modify files/directories underneath eCryptfs
mounts. eCryptfs may have cached something (dentries, inodes, file
contents, etc.) that will not be updated when you directly change the
lower files/directories.

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

This is the correct behavior. The mount wide encryption key that you set
up a mount time isn't telling eCryptfs that it should only use that key
for the mount. Instead, it is telling eCryptfs what key should be used
when creating new files in the mount.

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

Yes, that is correct.

> My hope is that it is possible to restrict the use of the keys to
> individual ecryptfs mounts.

That is not possible with the current ecryptfs-utils and ecryptfs kernel
module.

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

Different users should work. I understand that isn't an ideal solution
but I don't recall anyone ever asking for the functionality you're
describing.

The type of change that I'd be willing to accept in order to meet your
requirements would be one where an additional mount option
(ecryptfs_keyring ?) can be given to limit the kernel keyring searches
to a specific kernel keyring. It would also require changes to the utils
to insert the mount key into the specified keyring instead of the user
session keyring.

Would that meet your requirements?

Tyler

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Separating different ecryptfs mounts

[Christian Stüble]

Hi Tyler,
hi List

we did some more tests to find out whether there are other alternatives than 
adding another option and we found some interesting behavior I do not 
understand:

When mounting the example scenario given below:

	plain1 -> raw1
	plain2 -> raw2

as normal Linux user using sudo and passphrase-based encryption I get the 
result as required:

1) The user can write/read files to/from plain1
2) The user can write/read files to/from plain2
3) Files exchanged between raw1 and raw2 cannot be read.
4) The root, however, can read files exchanged between raw1 and raw2

It this an intended behavior? It seems that ecryptfs only uses the keys 
directly assigned to the mount for decryption for normal users, but all
keys for the root user.

However, if I do the same setup (sudo etc.) using the openssl module,

1) A normal user cannot even write files into plain1 or plain2. I get
a "socket not connected" error.
2) Root can write/read files into plain1/plain1

Here, it seems that ecryptfs only allows users to use keys of its own keyring?

The bahavior of the ecrypfs mount based on passwords would be ok for us, but 
we would need it in combination with asymmetric encryption. Do you have an 
idea why these two backends behave differently?

Best regards,
Chris


Am Mittwoch, 24. September 2014, 09:51:03 schrieb Tyler Hicks:
> On 2014-09-24 16:20:54, Christian Stüble wrote:
> > 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 did misunderstand your question. Sorry about that.
> 
> Note that you shouldn't modify files/directories underneath eCryptfs
> mounts. eCryptfs may have cached something (dentries, inodes, file
> contents, etc.) that will not be updated when you directly change the
> lower files/directories.
> 
> > 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.
> 
> This is the correct behavior. The mount wide encryption key that you set
> up a mount time isn't telling eCryptfs that it should only use that key
> for the mount. Instead, it is telling eCryptfs what key should be used
> when creating new files in the mount.
> 
> > 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?
> 
> Yes, that is correct.
> 
> > My hope is that it is possible to restrict the use of the keys to
> > individual ecryptfs mounts.
> 
> That is not possible with the current ecryptfs-utils and ecryptfs kernel
> module.
> 
> > 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.
> 
> Different users should work. I understand that isn't an ideal solution
> but I don't recall anyone ever asking for the functionality you're
> describing.
> 
> The type of change that I'd be willing to accept in order to meet your
> requirements would be one where an additional mount option
> (ecryptfs_keyring ?) can be given to limit the kernel keyring searches
> to a specific kernel keyring. It would also require changes to the utils
> to insert the mount key into the specified keyring instead of the user
> session keyring.
> 
> Would that meet your requirements?
> 
> Tyler
> 
> > 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.

Re: Separating different ecryptfs mounts

[Christian Stüble]

Hello,

I had an error in my configuration, see below:

Am Donnerstag, 25. September 2014, 10:10:58 schrieb Christian Stüble:
> Hi Tyler,
> hi List
> 
> we did some more tests to find out whether there are other alternatives than
> adding another option and we found some interesting behavior I do not
> understand:
> 
> When mounting the example scenario given below:
> 
> 	plain1 -> raw1
> 	plain2 -> raw2
> 
> as normal Linux user using sudo and passphrase-based encryption I get the
> result as required:
> 
> 1) The user can write/read files to/from plain1
> 2) The user can write/read files to/from plain2
> 3) Files exchanged between raw1 and raw2 cannot be read.
> 4) The root, however, can read files exchanged between raw1 and raw2
> 
> It this an intended behavior? It seems that ecryptfs only uses the keys
> directly assigned to the mount for decryption for normal users, but all
> keys for the root user.
This behavior is still unclear to me.

> 
> However, if I do the same setup (sudo etc.) using the openssl module,
> 
> 1) A normal user cannot even write files into plain1 or plain2. I get
> a "socket not connected" error.
> 2) Root can write/read files into plain1/plain1
I just noticed that the difference is that ecryptfsd has to run as the user 
who accesses the ecryptfs file system. It is possible to run multiple 
ecryptfsd in parallel (one for each user)?

Best regards,
Chris


> 
> Here, it seems that ecryptfs only allows users to use keys of its own
> keyring?
> 
> The bahavior of the ecrypfs mount based on passwords would be ok for us, but
> we would need it in combination with asymmetric encryption. Do you have an
> idea why these two backends behave differently?
> 
> Best regards,
> Chris
> 
> Am Mittwoch, 24. September 2014, 09:51:03 schrieb Tyler Hicks:
> > On 2014-09-24 16:20:54, Christian Stüble wrote:
> > > 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 did misunderstand your question. Sorry about that.
> > 
> > Note that you shouldn't modify files/directories underneath eCryptfs
> > mounts. eCryptfs may have cached something (dentries, inodes, file
> > contents, etc.) that will not be updated when you directly change the
> > lower files/directories.
> > 
> > > 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.
> > 
> > This is the correct behavior. The mount wide encryption key that you set
> > up a mount time isn't telling eCryptfs that it should only use that key
> > for the mount. Instead, it is telling eCryptfs what key should be used
> > when creating new files in the mount.
> > 
> > > 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?
> > 
> > Yes, that is correct.
> > 
> > > My hope is that it is possible to restrict the use of the keys to
> > > individual ecryptfs mounts.
> > 
> > That is not possible with the current ecryptfs-utils and ecryptfs kernel
> > module.
> > 
> > > 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.
> > 
> > Different users should work. I understand that isn't an ideal solution
> > but I don't recall anyone ever asking for the functionality you're
> > describing.
> > 
> > The type of change that I'd be willing to accept in order to meet your
> > requirements would be one where an additional mount option
> > (ecryptfs_keyring ?) can be given to limit the kernel keyring searches
> > to a specific kernel keyring. It would also require changes to the utils
> > to insert the mount key into the specified keyring instead of the user
> > session keyring.
> > 
> > Would that meet your requirements?
> > 
> > Tyler
> > 
> > > 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.

Re: Separating different ecryptfs mounts

[Tyler Hicks]

[-- Attachment #1: Type: text/plain, Size: 8963 bytes --]

My apologies for the long delay.

On 2014-09-25 10:48:23, Christian Stüble wrote:
> Hello,
> 
> I had an error in my configuration, see below:
> 
> Am Donnerstag, 25. September 2014, 10:10:58 schrieb Christian Stüble:
> > Hi Tyler,
> > hi List
> > 
> > we did some more tests to find out whether there are other alternatives than
> > adding another option and we found some interesting behavior I do not
> > understand:
> > 
> > When mounting the example scenario given below:
> > 
> > 	plain1 -> raw1
> > 	plain2 -> raw2
> > 
> > as normal Linux user using sudo and passphrase-based encryption I get the
> > result as required:
> > 
> > 1) The user can write/read files to/from plain1
> > 2) The user can write/read files to/from plain2
> > 3) Files exchanged between raw1 and raw2 cannot be read.
> > 4) The root, however, can read files exchanged between raw1 and raw2
> > 
> > It this an intended behavior? It seems that ecryptfs only uses the keys
> > directly assigned to the mount for decryption for normal users, but all
> > keys for the root user.
> This behavior is still unclear to me.

I can't reproduce this behavior. I can move the files between the lower
mount points and read the files out of each upper mount point.

As I mentioned before, directly modifying the lower mount point while eCryptfs
is mounted is not supported and may result in data loss. You should unmount the
eCryptfs layer before modifying the lower mount point.

One thing to check is that you have both mount keys in each session:

$ keyctl show
Session Keyring
 965589071 --alswrv   1000  1000  keyring: _ses
 155596823 --alswrv   1000 65534   \_ keyring: _uid.1000
 589053956 --alswrv   1000  1000       \_ user: 253ca7e88811d184
 760940678 --alswrv   1000  1000       \_ user: 72c0078c0eaa7eec

Different distributions use the kernel keyring and the pam_keyinit PAM module
differently. eCryptfs searches the user session keyring. You'll only be able to
read files created under mounts whose key(s) are in the current user session
keyring. Doing things like opening a new SSH session may result in a new user
session keyring, depending on how your system is configured.

> 
> > 
> > However, if I do the same setup (sudo etc.) using the openssl module,
> > 
> > 1) A normal user cannot even write files into plain1 or plain2. I get
> > a "socket not connected" error.
> > 2) Root can write/read files into plain1/plain1
> I just noticed that the difference is that ecryptfsd has to run as the user 
> who accesses the ecryptfs file system. It is possible to run multiple 
> ecryptfsd in parallel (one for each user)?

Yes. ecryptfsd was designed with the thought that each user would run their own
daemon.

Tyler

> 
> Best regards,
> Chris
> 
> 
> > 
> > Here, it seems that ecryptfs only allows users to use keys of its own
> > keyring?
> > 
> > The bahavior of the ecrypfs mount based on passwords would be ok for us, but
> > we would need it in combination with asymmetric encryption. Do you have an
> > idea why these two backends behave differently?
> > 
> > Best regards,
> > Chris
> > 
> > Am Mittwoch, 24. September 2014, 09:51:03 schrieb Tyler Hicks:
> > > On 2014-09-24 16:20:54, Christian Stüble wrote:
> > > > 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 did misunderstand your question. Sorry about that.
> > > 
> > > Note that you shouldn't modify files/directories underneath eCryptfs
> > > mounts. eCryptfs may have cached something (dentries, inodes, file
> > > contents, etc.) that will not be updated when you directly change the
> > > lower files/directories.
> > > 
> > > > 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.
> > > 
> > > This is the correct behavior. The mount wide encryption key that you set
> > > up a mount time isn't telling eCryptfs that it should only use that key
> > > for the mount. Instead, it is telling eCryptfs what key should be used
> > > when creating new files in the mount.
> > > 
> > > > 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?
> > > 
> > > Yes, that is correct.
> > > 
> > > > My hope is that it is possible to restrict the use of the keys to
> > > > individual ecryptfs mounts.
> > > 
> > > That is not possible with the current ecryptfs-utils and ecryptfs kernel
> > > module.
> > > 
> > > > 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.
> > > 
> > > Different users should work. I understand that isn't an ideal solution
> > > but I don't recall anyone ever asking for the functionality you're
> > > describing.
> > > 
> > > The type of change that I'd be willing to accept in order to meet your
> > > requirements would be one where an additional mount option
> > > (ecryptfs_keyring ?) can be given to limit the kernel keyring searches
> > > to a specific kernel keyring. It would also require changes to the utils
> > > to insert the mount key into the specified keyring instead of the user
> > > session keyring.
> > > 
> > > Would that meet your requirements?
> > > 
> > > Tyler
> > > 
> > > > 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.
> 
> --
> 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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

AW: Separating different ecryptfs mounts

[Anna Fischer]

> Betreff: Re: Separating different ecryptfs mounts
> 
> My apologies for the long delay.
> 
> On 2014-09-25 10:48:23, Christian Stüble wrote:
> > Hello,
> >
> > I had an error in my configuration, see below:
> >
> > Am Donnerstag, 25. September 2014, 10:10:58 schrieb Christian Stüble:
> > > Hi Tyler,
> > > hi List
> > >
> > > we did some more tests to find out whether there are other 
> > > alternatives than adding another option and we found some 
> > > interesting behavior I do not
> > > understand:
> > >
> > > When mounting the example scenario given below:
> > >
> > > 	plain1 -> raw1
> > > 	plain2 -> raw2
> > >
> > > as normal Linux user using sudo and passphrase-based encryption I 
> > > get the result as required:
> > >
> > > 1) The user can write/read files to/from plain1
> > > 2) The user can write/read files to/from plain2
> > > 3) Files exchanged between raw1 and raw2 cannot be read.
> > > 4) The root, however, can read files exchanged between raw1 and 
> > > raw2
> > >
> > > It this an intended behavior? It seems that ecryptfs only uses the 
> > > keys directly assigned to the mount for decryption for normal 
> > > users, but all keys for the root user.
> > This behavior is still unclear to me.
> 
> I can't reproduce this behavior. I can move the files between the 
> lower mount points and read the files out of each upper mount point.
> 
> As I mentioned before, directly modifying the lower mount point while 
> eCryptfs is mounted is not supported and may result in data loss. You 
> should unmount the eCryptfs layer before modifying the lower mount point.
> 
> One thing to check is that you have both mount keys in each session:
> 
> $ keyctl show
> Session Keyring
>  965589071 --alswrv   1000  1000  keyring: _ses
>  155596823 --alswrv   1000 65534   \_ keyring: _uid.1000
>  589053956 --alswrv   1000  1000       \_ user: 253ca7e88811d184
>  760940678 --alswrv   1000  1000       \_ user: 72c0078c0eaa7eec
> 
> Different distributions use the kernel keyring and the pam_keyinit PAM 
> module differently. eCryptfs searches the user session keyring. You'll 
> only be able to read files created under mounts whose key(s) are in 
> the current user session keyring. Doing things like opening a new SSH 
> session may result in a new user session keyring, depending on how your system is configured.

Hi Tyler,

I have a question related to the use case Chris is describing. I have seen that at kernel-level, there is an additional mount option "ecryptfs_mount_auth_tok_only" which forces ecryptfs to only use the keys specified by 'ecryptfs_sig' and 'ecryptfs_fnek_sig' for *decryption* of files (as I understand it is by default only used for encryption of newly created files under the given mount point). 

Can you clarify the (implementation) state of that option? I thought that is a potential way to restrict what keys are used for individual mount points?

Thanks for your help,
Anna