apparmor paths are broken when using ecryptfs

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

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.

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

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

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.

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

Dustin,

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

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.

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.

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.

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

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.

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

Used firefox profile in attachment.

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