ecryptfs should integrate with selinux/apparmor to add MAC to filesystem access

The Fedora 9 selinux-policy-3.3.1-95.fc9.noarch package carries a patch against the upstream reference policy to make all eCryptfs mount points inherit the 'system_u:object_r:ecryptfs_t:s0' label. All files created inside of the mount point get that label, too. I don't know if other distros are doing something similar, but it would be helpful if that patch was included in the upstream reference policy.

Once the eCryptfs mount point is labeled correctly, it would be up to the policy for the backup program (or it could be done in a local policy module) to deny the backup program's access to directories with the ecryptfs_t type. The labels on the files in the lower filesystem are preserved, so there are really no changes that need to be made to eCryptfs.

See also Bug #359338.

:-Dustin

Note that the proper way to provide the explicitly listed requirement
is to honor keys in the keyring at file open.

As for MAC integration - does ecryptfs not do xattrs? Or is this yet
another result of the idiotic kthread opening all files for everyeone?

-serge

On Mon, Apr 13, 2009 at 5:36 PM, Dustin Kirkland
<email address hidden> wrote:
> See also Bug #359338.
>
> :-Dustin
>
> --
> ecryptfs should integrate with selinux/apparmor to add MAC to filesystem access
> https://bugs.launchpad.net/bugs/278290
> You received this bug notification because you are a member of eCryptfs
> Developers, which is subscribed to eCryptfs.
>
> Status in eCryptfs - Enterprise Cryptographic Filesystem: Confirmed
>
> Bug description:
> It would be nice if SELinux and/or AppArmor could be used in conjunction with eCryptfs to apply Mandatory Access Controls on ecryptfs mounted filesystems.
>
> In this way, automated backups run by the root user would be prevented from accessing the mounted data in the clear.
>
> :-Dustin
>

"do xattrs" -> what do you mean? Encrypt xattrs?

:-Dustin

I just mean support extended attributes. But I'm going to test a bit.

On Mon, Apr 13, 2009 at 6:15 PM, Dustin Kirkland
<email address hidden> wrote:
> "do xattrs" ->  what do you mean?  Encrypt xattrs?
>
> :-Dustin
>
> --
> ecryptfs should integrate with selinux/apparmor to add MAC to filesystem access
> https://bugs.launchpad.net/bugs/278290
> You received this bug notification because you are a member of eCryptfs
> Developers, which is subscribed to eCryptfs.
>
> Status in eCryptfs - Enterprise Cryptographic Filesystem: Confirmed
>
> Bug description:
> It would be nice if SELinux and/or AppArmor could be used in conjunction with eCryptfs to apply Mandatory Access Controls on ecryptfs mounted filesystems.
>
> In this way, automated backups run by the root user would be prevented from accessing the mounted data in the clear.
>
> :-Dustin
>

Dustin Kirkland wrote:
> "do xattrs" -> what do you mean? Encrypt xattrs?
>
> :-Dustin
>

I'm pretty sure he's talking about eCryptfs supporting the xattr
security namespace, used by SELinux. We do support it - we simply pass
the calls on to the lower inode's i_ops for xattrs.

For anyone else reading this, we don't encrypt xattrs.

Dustin - Can you give some more details on what you're looking for?

I just took a look at a f10 and RHEL 5.3 system and did a quick eCryptfs mount to see how files were labeled. To my surprise, they were handled differently.

I did an eCryptfs mount with ecryptfs_passthrough enabled. I created a file in the lower filesystem (plain.file), meaning it is a regular non-eCryptfs file, and then created a file in the upper filesystem (ecryptfs.file), so it got the full eCryptfs treatment. Here's the results:

Mount details:
---
/root/lower on /root/upper type ecryptfs (rw,ecryptfs_sig=7fa06f4b66fcde02,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_passthrough)
---

RHEL 5.3:
---
[root@idea ~]# ls -Z lower/ upper/
lower/:
-rw-r--r-- root root root:object_r:user_home_t ecryptfs.file
-rw-r--r-- root root root:object_r:user_home_t plain.file

upper/:
-rw-r--r-- root root root:object_r:user_home_t ecryptfs.file
-rw-r--r-- root root root:object_r:user_home_t plain.file
---

f10:
---
[root@bracer4 ~]# ls -Z lower/ upper/
lower/:
-rw-r--r-- root root unconfined_u:object_r:admin_home_t:s0 ecryptfs.file
-rw-r--r-- root root unconfined_u:object_r:admin_home_t:s0 plain.file

upper/:
-rw-r--r-- root root system_u:object_r:ecryptfs_t:s0 ecryptfs.file
-rw-r--r-- root root system_u:object_r:ecryptfs_t:s0 plain.file
---

Both have their advantages, but the f10 approach is probably broken (this is a policy issue). The f10 way of doing this could be used to deny your backup application access to files of type ecryptfs_t, but giving all files in an eCryptfs mount ecryptfs_t isn't right. In RHEL 5.3, the labels in the lower filesystem are preserved, making existing policy work as expected, but there's no way to differentiate the encrypted and decrypted files by using the labels.

What changes would you like to see?

When thinking about your encrypted $HOME/Private implementation, you have all of the encrypted files tucked away under the upper mount point. Would it be helpful to have policy rules saying that rsync_t should read the encrypted versions of the files? It seems like that would be difficult without giving the files in the eCryptfs mount a different label (such as what's being done in f10).

All right so I originally assumed this bug was by someone other than Dustin, and was implying that xattrs on either the upper or lower mount were not being respected. But testing proves (fwiw, this might be worth an ltp test) that both are considered.

So like Tyler said, recent fedora (I tested F11) marks the decrypted/upper files as ecryptfs_t. I take it Dustin is asking for the same functionality in jaunty?

I still think providing that functionality through keyring ought to be higher priority, but doing both seems prudent :)

This was a placeholder bug for basically all things MAC-related involving eCryptfs. As such, there's really not a "bug" here.

I'm marking 'Invalid.'

:-Dustin