apparmor paths are broken when using ecryptfs

[Imre Gergely]

Binary package hint: ecryptfs-utils

klamav 0.46-2 with clamav 0.95.
Jaunty with encrypted home directory.

After installing klamav and first running it, it creates /home/user/.klamav/database, in which it downloads the signature databases. This directory gets created OK, but the database download fails with 'Can't create file' error, and the following entry in syslog:

Apr 11 01:11:39 utest-jj kernel: [ 959.044919] type=1503 audit(1239401499.961:33): operation="inode_create" requested_mask="a::" denied_mask="a::" fsuid=1000 name="/home/gimre/.Private/ECRYPTFS_FNEK_ENCRYPTED.FWYWbBX-HCv7D-ShpT0P1qAlMITxm.e31aS9aW.rw0ebxHiizvzjKdHqek--/ECRYPTFS_FNEK_ENCRYPTED.FWYWbBX-HCv7D-ShpT0P1qAlMITxm.e31aS9FGYc1fWwp9RQW-wdr8CQZU--/ECRYPTFS_FNEK_ENCRYPTED.FYYWbBX-HCv7D-ShpT0P1qAlMITxm.e31aS9Pcj74.T8NOQNJ4OdUE2-.LWX5l6N.v2lDmBFyCvWlKqrrt-xoaiQuTGvsGqXcTCI" pid=5164 profile="/usr/bin/freshclam"
Apr 11 01:11:39 utest-jj kernel: [ 959.044937] ecryptfs_do_create: Failure to create dentry in lower fs; rc = [-13]
Apr 11 01:11:39 utest-jj kernel: [ 959.045149] ecryptfs_create: Failed to create file inlower filesystem

After stopping apparmor, the problem goes away, the database gets downloaded correctly.

Can be reproduced by correcting freshclam's apparmor profile, see the following bug:

https://bugs.launchpad.net/ubuntu/+source/clamav/+bug/359301

[Jamie Strandboge (jdstrand)]

ecryptfs breaks Apparmor naming.

TEST CASE:
1. sudo apt-get install ecryptfs-utils
2. sudo adduser --encrypt-home foo
3. login as 'foo' and verify that encrypted home is correct:
$ df |grep '/home/foo/\.Private'
/home/foo/.Private 3936216 3313964 422304 89% /home/foo
4. Create the following file as /tmp/359338.sh:
#!/bin/sh
echo "Touching $HOME/test.txt"
touch $HOME/test.txt

5. chmod 755 /tmp/359338.sh
6. add the following to /etc/apparmor.d/tmp.359338.sh:
#include <tunables/global>

/tmp/359338.sh {
  #include <abstractions/base>

  /bin/dash rix,
  /bin/touch rix,
  /tmp/359338.sh r,

  owner @{HOME}/test.txt rw,
}

7. reload apparmor:
$ sudo /etc/init.d/apparmor force-reload

8. run /tmp/359338.sh as non-foo user:
$ /tmp/359338.sh
Touching /home/jamie/test.txt

9. run /tmp/359338.sh as foo:
$ /tmp/359338.sh
Touching /home/foo/test.txt
touch: cannot touch `/home/foo/test.txt': Permission denied

dmesg should have something like:
Apr 13 16:45:53 sec-jaunty-amd64 kernel: [ 523.233018] type=1503 audit(1239651953.911:114): operation="inode_create" requested_mask="a::" denied_mask="a::" fsuid=1001 name="/home/foo/.Private/ECRYPTFS_FNEK_ENCRYPTED.FWYwjom6xTTrhkQH6NYaDlNzbi4a-Y57kI1XsKcpAS2HNDa3p8fkshGrq---" pid=5038 profile="/tmp/359338.sh"
Apr 13 16:45:53 sec-jaunty-amd64 kernel: [ 523.233027] ecryptfs_do_create: Failure to create dentry in lower fs; rc = [-13]
Apr 13 16:45:53 sec-jaunty-amd64 kernel: [ 523.233045] ecryptfs_create: Failed to create file inlower filesystem

[Steve Beattie (sbeattie)]

The issue here is that apparmor is being asked whether to grant permission to both the encrypted and unencrypted filenames; you can see this if you use the following profile in jamie's test case above:

#include <tunables/global>

/tmp/359338.sh {
  #include <abstractions/base>

  /bin/dash rix,
  /bin/touch rix,
  /tmp/359338.sh r,

  audit owner @{HOME}/test.txt rw,
  audit owner @{HOME}/.Private/** rw,
}

This will result in the following showing up in the apparmor log when user foo runs the script:

[ 6753.287224] type=1501 audit(1239653800.125:47): operation="inode_create" requested_mask="a::" fsuid=1001 name="/home/foo/test.txt" pid=5441 profile="/tmp/359338.sh"
[ 6753.287235] type=1501 audit(1239653800.125:48): operation="inode_create" requested_mask="a::" fsuid=1001 name="/home/foo/.Private/ECRYPTFS_FNEK_ENCRYPTED.FWa-v7eV.gt-MkSIm4CZSyHipWO07nM63KqvRgbGYvdyUIvp87gd.GYus---" pid=5441 profile="/tmp/359338.sh"
[ 6753.287843] type=1501 audit(1239653800.125:49): operation="setattr" requested_mask="w::" fsuid=1001 attribute="atime,mtime,ctime," name="/home/foo/test.txt" pid=5441 profile="/tmp/359338.sh"
[ 6753.287853] type=1501 audit(1239653800.125:50): operation="setattr" requested_mask="w::" fsuid=1001 attribute="atime,mtime,ctime," name="/home/foo/test.txt" pid=5441 profile="/tmp/359338.sh"
[ 6753.287862] type=1501 audit(1239653800.125:51): operation="setattr" requested_mask="w::" fsuid=1001 attribute="atime,mtime,ctime," name="/home/foo/.Private/ECRYPTFS_FNEK_ENCRYPTED.FWa-v7eV.gt-MkSIm4CZSyHipWO07nM63KqvRgbGYvdyUIvp87gd.GYus---" pid=5441 profile="/tmp/359338.sh"
[ 6753.287873] type=1501 audit(1239653800.125:52): operation="setattr" requested_mask="w::" fsuid=1001 attribute="atime,mtime,ctime," name="/home/foo/.Private/ECRYPTFS_FNEK_ENCRYPTED.FWa-v7eV.gt-MkSIm4CZSyHipWO07nM63KqvRgbGYvdyUIvp87gd.GYus---" pid=5441 profile="/tmp/359338.sh"

which is a pretty atrocious workaround, but I doubt anything better can be done before jaunty is released.

[Dustin Kirkland  (kirkland)]

According to jdstrand in IRC, he and sbeattie have determined that this should be solved in the kernel, rather than the userspace ecryptfs utilities. I'm marking the ecryptfs task 'Invalid'.

I'll also note wishlist upstream Bug #278290, which requests proper MAC integration of eCryptfs. If someone out there is interested in solving this for eCryptfs, we upstream maintainers are interested in reviewing patches.

:-Dustin

[Steve Langasek (vorlon)]

Release note added at <https://wiki.ubuntu.com/JauntyJackalope/ReleaseNotes#Apparmor%20profiles%20incompatible%20with%20ecryptfs>:

  Apparmor profiles incompatible with ecryptfs

  When using encrypted home directories together with apparmor in enforcing mode, apparmor will deny access to certain files unexpectedly because the Linux kernel sees the process as accessing the file via both the unencrypted and encrypted paths (359338). As a workaround, users can modify their apparmor profiles under /etc/apparmor.d/ to grant permissions to @{HOME}/.Private/**.

[John Johansen (jjohansen)]

I have looked at this for Jaunty and have a patch that fixes this for all but 1 case in the kernel. That one case however requires a larger change and need further investigation. That one case still requires
owner @{HOME}/.Private/** rw, be added to profiles.

Testing in Karmic has shown that the security_path_XXX hooks work as expected and that rmdir, unlink, mknod, mkdir, link, symlink all work. There is a single known regression case (dentry_open) where the name loop back occurs, resulting in both the encrypted and unencrypted paths being reported.

[Dustin Kirkland  (kirkland)]

On Fri, Jul 17, 2009 at 10:17 AM, John
Johansen<email address hidden> wrote:
> I have looked at this for Jaunty and have a patch that fixes this for all but 1 case in the kernel.  That one case however requires a larger change and need further investigation.  That one case still requires
> owner @{HOME}/.Private/** rw, be added to profiles.

John,

For Karmic, (very soon, actually), I'm planning on moving this data
from $HOME/.Private to /home/.ecryptfs/$USER/.Private.

How does that affect your work?

:-Dustin

[John Johansen (jjohansen)]

Dustin,

it shouldn't matter where the encrypted data is placed, so this change should not have any effect.

[John Johansen (jjohansen)]

This behavior still exists in Jaunty and Karmic and it is going to be handled in the user space at the policy level. The user space tools are being extended to be able to handle, this in a couple of ways.
  1. There will be a global policy file where rules like the work around specified above can be added without having to update the profiles.
  2. The alias command is being extended to cover full regular expression rewriting which will allow the policy to contain the relationship between the encrypted dir and the users actual home. The alias required for ecrypted homes will then be put in the global policy file described in part 1.

This solution can be applied to both Jaunty and Karmic.

[Jamie Strandboge (jdstrand)]

Discussing this with John, the solution for Karmic does not require kernel changes, so moving to AppArmor.

What does need to happen is that the AppArmor userspace needs to be adjusted along with some small profiling work.

[Jamie Strandboge (jdstrand)]

For karmic we'll work around this with pure profiling. When the proper userspace changes come from upstream we can remove the work around. Those userspace changes will solve the stacked filesystems problem generally, but require significant effort.

[Launchpad Janitor (janitor)]

This bug was fixed in the package apparmor - 2.3.1+1403-0ubuntu17

---------------
apparmor (2.3.1+1403-0ubuntu17) karmic; urgency=low

  * abstractions/base: workaround for ecryptfs and apparmor by allowing
    'owner' match for files in .Private. (LP: #359338)

 -- Jamie Strandboge <email address hidden> Mon, 31 Aug 2009 15:38:54 -0500

[Jamie Strandboge (jdstrand)]

This is still an issue for Jaunty, but users can add the following to /etc/apparmor.d/abstractions/base to work around the problem:
  # encrypted ~/.Private and old-style encrypted $HOME
  owner @{HOME}/.Private/** mrixwlk,
  # new-style encrypted $HOME
  owner @{HOMEDIRS}/.ecryptfs/*/.Private/** mrixwlk,

You'll need to reload apparmor before this is in effect. Note that this is a temporary workaround until upstream handles stacked filesystems generally.

[kapetr (kapetr)]

Hello,

I use Ubuntu 10.10 with encrypted home. I'm new with apparmor.
The #13 workaround is part of /etc/apparmor.d/abstractions/base.

My firefox-3.6.13 is now in enforce mode - with standard profile.
With this profile it should have write access only to:
owner @{HOME}/Downloads/* rw,

but I can save files (with standard downloadmanager of firefox) e.g. in $HOME itself and I can't find any other rule, which could allow that. I have thing, that #13 workaround just affects the eCryptFS "part of things" and limitations of normal filenames/paths (in mounted ecryptfs) are still possible.

----------------------------------------------------------------------------------------
So ... why can firefox write elsewhere as in to ${HOME}/Downloads ?
----------------------------------------------------------------------------------------

BTW: I get also this in kern.log (but not by saving a file as wrote above) :

Feb 27 05:49:30 duron650 kernel: [ 2284.886631] type=1400 audit(1298782170.190:48): apparmor="DENIED" operation="open" parent=1782 profile="/usr/lib/firefox-3.6.13/firefox-*bin" name="/home/.ecryptfs/hugo/.Private/ECRYPTFS_FNEK_ENCRYPTED.FWY1tHLaOszg1UQTPB2f1Zq7Xu0xztwk9hVX6-OCUaSGk2nU5ADkJx.rdk--/ECRYPTFS_FNEK_ENCRYPTED.FWY1tHLaOszg1UQTPB2f1Zq7Xu0xztwk9hVXFlmP1qlJBZ2eq7XFiWljUE--" pid=2209 comm="firefox-bin" requested_mask="w" denied_mask="w" fsuid=1000 ouid=0

?? why do firefox try to write to it and why do it fail even with #13 workaround?

Feb 27 06:03:23 duron650 kernel: [ 3118.231818] type=1400 audit(1298783003.534:49): apparmor="DENIED" operation="open" parent=1782 profile="/usr/lib/firefox-3.6.13/firefox-*bin" name="/tmp/.X0-lock" pid=2304 comm="firefox-bin" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

?? Why try firefox to access X lock ?

Thanks for help

--kapetr

[kapetr (kapetr)]

Used firefox profile in attachment.

[Jamie Strandboge (jdstrand)]

kapetr, this bug is closed. Can you please file a new bug?