ecryptfs-simple: KISS directory encryption

Xyne · 2012-05-29 19:46:30

Update: Warning

I have encounted problems with eCryptFS (independent of ecryptfs-simple) that have led to data loss. I can no longer recommend the use of eCryptFS. I will continue to maintain this package, but I strongly suggest that users switch to something else such as encfs.

If there are any ecryptfs enthusiasts who know how to recover from random input/output errors, please let me know and I may reconsider this stance.

Original Post

Project page: ecryptfs-simple

*edit: removed old usage example after major update*

If you have seen my most recent threads on the forum, you will be aware that I am currently setting up different encryption schemes on some systems. One of the issues that I encountered was with eCryptfs (related thread). Setting up eCryptfs either requires superuser privileges (both for ad-hoc mounting and for editing fstab), or you are forced to use hard-coded paths in the ecryptfs-utils package (~/.Private). Neither of these were acceptable.

Basically, I just want to be able to use eCryptfs the same way that I use EncFS: by selecting an arbitrary source directory and mountpoint. I found no easy way to do it so I wrote my own simple utility.

Enter ecryptfs-simple. It lets a regular user mount any encrypted directory on any other directory as long as the user has full access permissions on both. It also prevents mounting on top of mount points and unmounting non-eCryptfs mount points.

Last edited by Xyne (2013-09-24 20:07:50)

/dev/zero · 2012-05-29 22:07:16

Nice! I notice the help page has a typo, repeated a few times: ecrypts vs ecryptfs.

USAGE
  Mount a directory:
    [b]ecrypts[/b]-simple <directory> <mountpoint> [option1=value1,option2=value2,...]

  Unmount a directory:
    [b]ecrypts[/b]-simple <mountpoint>
# ... (and so forth.)

Also, it doesn't seem to deal elegantly with the case that an encrypted directory (say, .Private) has already been set up. I have to say again when remounting, 1. Use a passphrase, 1. Use AES, and so forth. Does there exist some way to replicate the effects of ecryptfs-mount-private, which doesn't re-ask the questions for a previously set up directory?

Xyne · 2012-05-29 22:15:39

Thanks, I've fixed the typo.

I'll try to figure out how ecryptfs-mount-private retrieves that data and port the functionality if I can. In the meantime, take a look at the example script on the project page. It's easy to adapt (or even convert to a .bashrc function) and it bypasses most of the dialogue.

anrxc · 2012-05-31 00:54:30

Nice, I get annoyed by the lack of abstraction in ecryptfs-utils and Ubuntu defaults being hard-coded.

Last edited by anrxc (2012-06-18 00:52:43)

Xyne · 2012-06-18 00:05:31

I've just release a major update. You can find the changelog on the homepage.

The main thing is that it should now save and reload options so that all you need to supply is the password (when using the automount option).

Xyne · 2012-06-24 22:17:35

*edit*
Removed last post as it was a bit of a rant.

Summary: The upstream codebase is a kludgy mess in motion and the last update broke my hooks. Given the quality of the code I have growing concerns about trusting eCryptfs with real data.
Update: ecryptfs-simple no longer uses hooks. I hope that the current implementation will remain stable (or only require minimal intervention with future updates).

Last edited by Xyne (2012-06-25 06:40:01)

kozaki · 2013-02-16 23:29:04

Xyne wrote:

Thanks, I've fixed the typo.
I'll try to figure out how ecryptfs-mount-private retrieves that data and port the functionality if I can. In the meantime, take a look at the example script on the project page. It's easy to adapt (or even convert to a .bashrc function) and it bypasses most of the dialogue.

Xyne please could you add a note on how to have ecryptfs-simple "deal elegantly with the case that an encrypted directory (say, .Private) has already been set up" as /dev/zero said? Just for clarity, e.g.

It will check that the real user has full permissions to both the directory and mountpoint for the requested operation

...means $HOME/Private needs to be 'drwx' (in place of 'dr-x' as per ecryptfs-setup-private), correct?

Also ecryptfs-simple "automount" option still requires the user to enter its own password when login? Here I mean for when login in via ssh or through root 'su - $USER'.

Xyne · 2013-02-20 12:49:57

I don't use the default .Private directory and I don't have time to set it up right now and look at how it stores its settings. If someone wants to check that for me to save some time then I will have a look at it, otherwise it will have to wait. To be honest, I don't really see the need as ecryptfs-simple should probably not be managing .Private anyway.

I'm not against the idea, but ultimately it is just extra work for something that I will never use myself and something that I will likely not properly test in future releases.

kozaki wrote:

Just for clarity, e.g.
It will check that the real user has full permissions to both the directory and mountpoint for the requested operation
...means $HOME/Private needs to be 'drwx' (in place of 'dr-x' as per ecryptfs-setup-private), correct?

Yes. The exact check is

if (access(path, R_OK | W_OK | X_OK))

The directory obviously needs to be readable and executable for the user to see anything inside of it, and I assume that it needs to be writable to create new files. If this is not the case, please let me know.

kozaki wrote:

Also ecryptfs-simple "automount" option still requires the user to enter its own password when login? Here I mean for when login in via ssh or through root 'su - $USER'.

In this context "automount" just means that it should detect previous ecryptfs settings. There's probably a way to skip the password prompt if the key already exists in the keyring but I do not know how. In any case, it will need the password the first time. I don't see how it could be secure otherwise.

Xyne · 2013-09-24 20:06:28

I have encounted problems with eCryptFS (independent of ecryptfs-simple) that have led to data loss. I can no longer recommend the use of eCryptFS. I will continue to maintain this package, but I strongly suggest that users switch to something else such as encfs.

If there are any ecryptfs enthusiasts who know how to recover from random input/output errors, please let me know and I may reconsider this stance.

sas · 2013-09-26 04:29:27

Xyne wrote:

I have encounted problems with eCryptFS (independent of ecryptfs-simple) that have led to data loss.

That's really bad; did you already ask the upstream developers for help or file a bug report?

AFAIK both Ubuntu and Google Chrome OS heavily rely on eCryptFS, so I'm pretty sure they'd want to fix such a bug.

Xyne · 2013-09-26 05:00:03

I didn't bother contacting upstream because I honestly have no desire to waste my time debugging this.* EncFS has worked flawlessly for me for years and the extra overhead is negligible.

* Proper documentation is lacking, the API has changed at least once without notice, the code is tangled, potentially useful user functions are buried in functions with hard-coded paths, etc. I'm guilty of this for several of my own projects, but I honestly expected more from such an old and popular project.

mhogomchungu · 2016-11-11 11:53:59

Hi, i have a project called "SiriKali"[1] and i would like to use your problem as a mean to manage ecryptfs volumes.

1. Will it be possible to host your project at github or gitlab or anywhere else where others users of linux will be able to reach it?. Hosting it on arch is not idea if the project is to be used by non arch users.

2. Will it be possible to have a volume's configuration file in the volume itself,like what encfs is doing with an option to specify an out of volume configuration file?

3. After unmounting a volume,a message[2] is displayed,will it be possible for the project to automatically do whatever is suggested here?

4. A proper build system will be nice(cmake preferred)

[1] https://mhogomchungu.github.io/sirikali/

[2] "You may now remove leftover keys with keyctl if you are done."

Last edited by mhogomchungu (2016-11-11 18:30:27)

mhogomchungu · 2016-11-11 19:54:07

Reporting a contradiction, documentation says config files are located at "$HOME/.config/ecryptfs-simple" but the applications is managing them at "$HOME/.config/.ecryptfs-simple". Notice the dot before "ecryptfs-simple".

Last edited by mhogomchungu (2016-11-11 19:54:30)

mhogomchungu · 2016-11-11 23:47:17

Reporting a bug,the applications currently "dies" when started by SiriKali because it fails to handle stdin to update/restore/retrieve terminal settings and i had to modify the application to make it work by commenting out the "die" function.

The problem here is due to the application expecting that its running from the terminal while QProcess does not emulate the terminal.

Reporting another bug,a volume i have created with the option to encrypt file name has the following string in the config file

ecryptfs_sig=d69bbd024297c5e2,ecryptfs_fnek_sig=d69bbd024297c5e2,ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_passthrough=no,ecryptfs_enable_filename_crypto=no

The bug is in the line "ecryptfs_enable_filename_crypto=no",file names are encrypted though.

A solution to this problem will make git version of SiriKali capable of creating and unlocking "ecryptfs" volumes using "ecryptfs-simple" tool.

Last edited by mhogomchungu (2016-11-12 01:39:45)

mhogomchungu · 2016-11-12 12:56:00

I have put the project on github[1] with the changes i need for SiriKali

[1] https://github.com/mhogomchungu/ecryptfs-simple

Xyne · 2016-11-13 00:57:33

Hi mhogomchungu,

Please use the edit button to append data to your previous post when it is the last in the thread. Bumping is against our forum policy.

I haven't touched this code or ecryptfs in years. I will need to take some time to refamiliarize myself with the code before making any changes to make sure that there is no risk of data loss (due to ecryptfs-simple). I am open to your suggestions. I'll try to reply to each point.

Putting all of my projects on Github or something similar is a long-standing item on my todo list. I don't have time right now to reconfigure my release scripts and I won't do it before I can fully automate the process.
I should be able to add an option to look for the volume configuration file in the encrypted volume directory. I need to check how ecryptfs handles unencrypted files in the encrypted directory (with different options).
ecryptfs-simple can be modified to deal with keyctl automatically via an option. I chose not to do that because I wanted to avoid the added complexity and risk of errors. I expected it to be simple enough to do with a wrapper script. I will reconsider once I have an overview of the code again.
Ok for CMake. Given that you've already created a CMakeLists.txt file, I'll likely backport it or create a new one based on it.
It seems to be using "$HOME/.config/ecryptfs-simple" as expected. Looking over the code, I see nothing that would insert a "." there. Incidentally, that should be updated to use "$XDG_CONFIG_HOME/ecryptfs-simple" if $XDG_CONFIG_HOME is defined.
Do you mean that the parameter prompt fails because SiriKali does not emulate a terminal? If so, it should be possible to add a condition before invoking the prompt.
Looking at the current code, it seems that it expects ecryptfs_enable_filename_crypto to be included among the parameters after the prompt. Maybe it never was or maybe something has changed, but it doesn't seem to be there. I need to figure out where to check for that setting. It seems to be the same for ecryptfs_passthrough.

edit
I have made the following changes:

An option to set configuration file path. If the path begins with "//" then it will be relative to the source/encrypted directory.
Add "ecryptfs_enable_filename_crypto=y" to the options when "ecryptfs_fnek_sig" is detected.
Skip the parameter prompt when not running in a terminal. I don't know how that will deal with the password. Again, I don't remember how ecryptfs works
Fixed some warnings. I have added "-std-gnu99" to the build script for now because I don't have the time to figure out how to deal with warnings for realpath, seteuid, etc.
Added CMake support.

Last edited by Xyne (2016-11-13 06:09:09)

mhogomchungu · 2016-11-13 06:22:11

Do you mean that the parameter prompt fails because SiriKali does not emulate a terminal? If so, it should be possible to add a condition before invoking the prompt.

My version of ecryptfs-simple works with SiriKali because i let it continue with a warning when it fails to tune terminal settings like here[1]. I think the problem will be there with any Qt based frontend that uses QProcess[2] that invoke ecryptfs-simple.

[1] https://github.com/mhogomchungu/ecryptf … le.c#L1303

[2] http://doc.qt.io/qt-4.8/qprocess.html

Last edited by mhogomchungu (2016-11-13 06:23:17)

Xyne · 2016-11-13 06:27:26

How do you get the user password then?

Incidentally, I added the following to skip the prompt when not running in a terminal:

  if (isatty(fileno(stdin)))
  {
    prompt_parameters(opts_str, mnt_params_str);
  }

mhogomchungu · 2016-11-13 06:35:44

I have not tried your new version but with the old version,i send this[1] string with all the expected options when creating a volume and this[2] string with all the expected options when unlocking it.

All the old version needed to do was not to fail out when failing to set terminal properties.

if (isatty(fileno(stdin)))

stdin could be a terminal or a pipe and your application previously assumed its only a terminal and you seem to still have this thinking.

It should work with both. You may test this by trying to invoke your application from a script and pass data to it. Both your versions will fail.

While here,i think you should move away from "strcat" and "strcpy" and replace them with "snprintf"[3]. Just looking your code and i see how its buffers can be trivially abused.

[1] https://github.com/mhogomchungu/sirikal … k.cpp#L508

[2] https://github.com/mhogomchungu/sirikal … k.cpp#L449

[3] http://pubs.opengroup.org/onlinepubs/79 … rintf.html

Last edited by mhogomchungu (2016-11-13 07:29:11)

Xyne · 2016-11-13 08:27:38

It now only tries to disable the echo if it detects that stdin is a terminal.

I will stop using the "unsafe" functions from now on. When I have time, I will update the existing code to replace them. I expect that it will require threading lengths through several functions.

mhogomchungu · 2016-11-13 12:50:59

It now only tries to disable the echo if it detects that stdin is a terminal.

It still will not work because the application will die when "initialize()" function is called.

I just replaced all "strcpy' and "strcat" functions with "snprintf" in my repository with minimal change to the API.

I will switch to yours version after you have it at github.

Xyne · 2016-11-13 20:07:13

mhogomchungu wrote:

with minimal change to the API

The changes are straightforward, but not really minimal. Nevertheless, I've implemented them myself (with minor changes). Some functions remained susceptible to overflows (append_sha512_hexdigest, str_maybe_append_parameter).

It should properly handle input pipes now. I have also included your privilege checks in a separate function that is called from initialize(). By dropping privileges after the check, permission errors occurred when unmounting. I realized that the only time the permissions are needed is when mounting and unmounting (I may be mistaken), so it now drops privileges during initialization and only resumes them for those actions.

I've added some preliminary code for unlinking the key from the keyring when unmounting but I didn't have time to figure out how to work with keyctl.h. All that's missing is a function to get the key ID that contains the ecryptfs_sig in its description. If you can provide (links to) a working example to get me started then I will add it along with an option to unlink the associated keys when unmounting.

mhogomchungu · 2016-11-13 20:37:13

I noticed two things when looking at the code earlier, your code has a potential buffer overflow here[1],without the plus one i added,this[2] line will write past the end of the buffer if "i" equals "len" which is a condition that will break the loop.

One thing puzzled me,you set the buffer to 15 characters with the consequence of a password being at most 14 characters since the buffer must also hold the NULL character and this seems too small,why is the buffer this small?

A command to get a list of entries in a user keyring is:

keyctl list @u

A function that implements the functionality above is here: https://kernel.googlesource.com/pub/scm … yctl.c#794

Hope it'll help.

[1] https://github.com/mhogomchungu/ecryptf … le.c#L1397

[2] https://github.com/mhogomchungu/ecryptf … le.c#L1423

Last edited by mhogomchungu (2016-11-13 21:07:47)

Xyne · 2016-11-14 01:15:18

I don't remember why I set the password limit that low but there was probably a reason. Maybe it was a limit in ecryptfs at the time (I'm not going to check now). I have updated it to use ECRYPTFS_MAX_PASSWORD_LENGTH from ecryptfs.h with the +1 for NULL.

The function was exactly what I needed. There is now a "-k" option to remove the key from the keyring when unmounting. "-k" implies "-u".

mhogomchungu · 2016-11-14 06:42:34

My use case generates two keys,"ecryptfs_fnek_sig" and "ecryptfs_sig" and I have noticed that these keys are sometimes the same and other times different and i think you should check for both of them.

I think the best place to get these keys is from volume's mount options as they show up in "/proc/self/mountinfo". Your current way of finding them will not work if somebody used custom configuration path(opened the volume with --config option,SiriKali does this)

Why do you still use strcpy? Looking at below code for example

  if (arguments.mount_options != NULL)
  {
    strcpy(opts_str, arguments.mount_options);
  }
  else
  {
    opts_str[0] = '\0';
  }

That looks like its taking a string of arbitrary size from users and copying it to a buffer of fixed size,the buffer just begs to be abused. Where are you checking that the buffer is large enough to hold the "arguments.mount_options"?. If it is there then i did not see it with amount a minute of looking around and i shouldnt have to do that since "snprintf" would have carried all the checks right there with zero cost on your part.

Last edited by mhogomchungu (2016-11-14 07:02:34)

Arch Linux

#1 2012-05-29 19:46:30