Encrypted home directory readable after logout

Asked by Juergen Schmidt

Hello,

I found that other users can easily get access to my encrypted home directory *after* I logged out of the system. This only works if I logged in once after the last reboot of the system and the user needs administrator privileges. He does not need my password though. Is this behavior considered a bug or a feature?

I am using Ubuntu 10.4 LTS with encrypted home directories and I can give easy instructions to reproduce this issue any time.

bye, ju

Question information

Language:
English Edit question
Status:
Answered
For:
eCryptfs Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Ted_Smith (tedsmith28) said :
#1

If it's all been setup correctly, I'd be surprised if that's the case. In my experience, if setup properly (user has logged out and then back in etc etc) no user can read the data, even root. The filenames, possibly, but not the data.

Maybe if you reproduce and paste your steps here?

Revision history for this message
Juergen Schmidt (ju-heisec) said :
#2

This does not really answer my question: Is this behavior - if it occurs - considered a bug or not?

Alice, Bob and Eve all share the same using computer Ubuntu 10.4 LTS with encrypted home directories, all of them are administrators.

Alice boots the computer and logs into the system in the morning and then logs out again.
Eve later logs into the computer later. In a terminal window she checks with "who" that she is really the only one who is logged in and with "mount" she sees that only her home directory is mounted with ecryptfs.
"sudo ls -al /home/alice" only shows the unmounted home dir containing the encrypted files. Everything fine -- but then she enters:

eve@home:~ $ sudo su - alice
[sudo] password for eve:
alice@home:~$ ls
...

And now she is logged in as alice with full access to all of her files.
If Eve tries the same with Bob who has not logged in yet, she gets:
---
keyctl_search: Required key not available
Perhaps try the interactive 'ecryptfs-mount-private'
---

and only sees the unmounted home dir and his encrypted files.

My guess is that for some reason the session is not properly closed for whatever reason -- allthough Alice has confirmed that she wants to log off and terminate all open processes. I can reproduce this on multiple systems, so I don't believe it is something special to mine.

I understand that as an administrator Eve has a lot of other options to sniff on Alice and get access to her password and her files. That's why I ask if this behavior is considered a bug.

bye, ju

Revision history for this message
Serge Hallyn (serge-hallyn) said :
#3

Quoting Juergen Schmidt (<email address hidden>):
> This does not really answer my question: Is this behavior - if it occurs
> - considered a bug or not?
>
> Alice, Bob and Eve all share the same using computer Ubuntu 10.4 LTS
> with encrypted home directories, all of them are administrators.
>
> Alice boots the computer and logs into the system in the morning and then logs out again.
> Eve later logs into the computer later. In a terminal window she checks with "who" that she is really the only one who is logged in and with "mount" she sees that only her home directory is mounted with ecryptfs.
> "sudo ls -al /home/alice" only shows the unmounted home dir containing the encrypted files. Everything fine -- but then she enters:
>
> eve@home:~ $ sudo su - alice
> [sudo] password for eve:
> alice@home:~$ ls
> ...
>
> And now she is logged in as alice with full access to all of her files.
> If Eve tries the same with Bob who has not logged in yet, she gets:

Dustin, wasn't this fixed at least in natty?

Revision history for this message
Dustin Kirkland  (kirkland) said :
#4

Yes, this is fixed in Natty. Arguably, we could/should? SRU this to
Lucid/Maverick.

Revision history for this message
Ted_Smith (tedsmith28) said :
#5

I'm not sure I understand. I must be missing something.

Are we saying that in 10.04, if you switch user, for which you need the other users password, from within another login session, you can see the encrypted files of both users at the same time? Or can you only see the user files of the newly switched to account?

Either way, if you need the password for the other user to su to, then eCryptfs is still working. If you've given the password, you've unlocked the data. eCryptfs was never designed to counter multiple users knowing each others login passwords - if the password chosen is weak or distributed to others, then there's little point in encrypting anyway.

In summary, if you don't know the passwords of other users, you can't su to them. Ergo, you can't access the eCryptfs data. If you know the passwords, then obviously you can, or am I missing something?

Revision history for this message
Ted_Smith (tedsmith28) said :
#6

Sorry...just re-read the thread.

I see what you mean - if 3 users are admins and they are all in the sudo group, any of them can switch about to any of the other admin accounts.

With that said, it's a fair point.

I'm not sure how often this scenario would actually exist though and to compromise a stolen system or when where an authorised user has been given physcial access for a short while, it's unlikely to be an issue as he wouldn't have any of the admin passwords to do this,

The only occasion where I guess it might potentially be an issue is in the corporate world where there may be 2 or more system admins and one of them becomes corrupt. To safeguard against that, I guess it would be better to have it fixed in the LTS release.

Revision history for this message
Ted_Smith (tedsmith28) said :
#7

Yes, I have just done this myself as a test and can confirm.

Created 3 users, test1, test2 and test3. Added test1 and test2 to the admin and sudo user groups. Left test 3 in the default non-admin groups. Logged in as each one and then logged out.

Then logged in using test1, created a text file, logged out.

Logged in as test2, ran sudo su test1 and entered test2 sudo password. Was then able to view the text file of test1.

Repeated with test3, the normal, non-admin account. Was able to view that users data too, using sudo su test1 as before.

Revision history for this message
Dustin Kirkland  (kirkland) said :
#8

Ted,

Can you re-try with Ubuntu's 11.04 ecryptfs-utils?

Revision history for this message
Serge Hallyn (serge-hallyn) said :
#9

Quoting Ted_Smith (<email address hidden>):
> Question #152141 on eCryptfs changed:
> https://answers.launchpad.net/ecryptfs/+question/152141
>
> Ted_Smith proposed the following answer:
> Yes, I have just done this myself as a test and can confirm.
>
> Created 3 users, test1, test2 and test3. Added test1 and test2 to the
> admin and sudo user groups. Left test 3 in the default non-admin groups.
> Logged in as each one and then logged out.
>
> Then logged in using test1, created a text file, logged out.
>
> Logged in as test2, ran sudo su test1 and entered test2 sudo password.
> Was then able to view the text file of test1.
>
> Repeated with test3, the normal, non-admin account. Was able to view
> that users data too, using sudo su test1 as before.

In that case please open a bug, because that is not supposed to be
happening in natty.

Revision history for this message
Serge Hallyn (serge-hallyn) said :
#10

Quoting Ted_Smith (<email address hidden>):
> Question #152141 on eCryptfs changed:
> https://answers.launchpad.net/ecryptfs/+question/152141
>
> Ted_Smith proposed the following answer:
> Sorry...just re-read the thread.
>
> I see what you mean - if 3 users are admins and they are all in the sudo
> group, any of them can switch about to any of the other admin accounts.
>
> With that said, it's a fair point.
>
> I'm not sure how often this scenario would actually exist though and to

Right - ecryptfs is not designed to protect you from admins, which is why
SRUing this fix is controvesial. However we wanted to work on this case
because it's rather extreme.

Revision history for this message
Ted_Smith (tedsmith28) said :
#11

I was doing that with Ubuntu 10.04.2 LTS as that is what the original posting was on.

I'll download Natty and have a go ASAP....

Revision history for this message
Ted_Smith (tedsmith28) said :
#12

Dustin & Serge

It might be worth stressing the following as I initially overlooked this point :

THIS ONLY APPLIES IF THE OTHER USERS HAVE LOGGED IN, AND THEN OUT AND THE SYSTEM IS STILL LIVE WITHOUT A REBOOT. This doesn't happen in either 11.04 or 10.04 if the other users haven't yet logged in for that boot session. I know the original post did state this, but it perhaps needs to be made very clear as it's an important point and one I initially overlooked. I thought initially that it meant you had a free reign across all users if you could sudo su from one to the other, but it's only those that have logged in during that boot session.

That said, yes, using the latest Beta 2 of Natty (11.04), you are prevented from su'ing in this way, even when all accounts are in both the admin group and the sudo group and have been logged in and then out. I received the following error when I tried to su from test2 to test1 :

test2@ubuntu:~$ sudo su test1
[sudo] password for test2: Entered Pass
keyctl_search: Required key not available
Perhaps try the interactive 'ecryptfs-mount-private'
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

using

Distributor ID: Ubuntu
Description: Ubuntu Natty (development branch)
Release: 11.04
Codename: natty

This is the same error that is received in 10.04 when you try to do this attack on an account who has not already logged in during that boot session.

For completeness and to try and be helpful, I did some tests using Ubuntu 10.04 LTS, unpatched (just installed from CD in a VM) just to test and confirm that without logging in first, this was not possible. It wasn't. I then went on to do some group related tests to see how this issue works depending on what group the users are in. Results are below.

================================

Distributor ID: Ubuntu
Description: Ubuntu 10.04 LTS
Release: 10.04
Codename: lucid

If the users are in BOTH the admin group AND the sudo group, the attack works as already described (users log in, then out, then you can "sudo su user" and gain access).

If the users are in just the sudo group, but not the admin group, the attack works, even if the user is just a regular user who has been made part of the sudo group.

If the users are in just the admin group, but NOT the sudo group, the attack fails, reporting:

test2@suspect:~$ sudo su test1
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

So the sudo group is key to this working, not necessarily whether you're part of the admin group. You could be a regular user who has been put into the sudo group or who has managed to escalate his priviliges to that group and the attack will work for him too.

This also happens with 10.04.2 LTS

Revision history for this message
Dustin Kirkland  (kirkland) said :
#13

Cheers, thanks a lot for the clarifications and testing Ted ;-)

Can you help with this problem?

Provide an answer of your own, or ask Juergen Schmidt for more information if necessary.

To post a message you must log in.