Description of problem: I'm unable to move files onto an encrypted mount. I can *copy* files on, but not *move* them on. Version-Release number of selected component (if applicable): kernel 2.6.18-58.el5 + eric's ecryptfs backport How reproducible: [root@xw4400-01 ~]# echo "this is an encrypted file, encrypted with key 94733f578c4b75f6" > 94733f578c4b75f6.txt [root@xw4400-01 ~]# mv 94733f578c4b75f6.txt /secret/ mv: cannot create regular file `/secret/94733f578c4b75f6.txt': Permission denied [root@xw4400-01 ~]# echo "this is an encrypted file, encrypted with key 94733f578c4b75f6" > /secret/94733f578c4b75f6.txt [root@xw4400-01 ~]# cat /secret/94733f578c4b75f6.txt this is an encrypted file, encrypted with key 94733f578c4b75f6 [root@xw4400-01 ~]# cp 94733f578c4b75f6.txt /secret/blah.txt [root@xw4400-01 ~]# cat /secret/blah.txt this is an encrypted file, encrypted with key 94733f578c4b75f6 [root@xw4400-01 ~]# mv 94733f578c4b75f6.txt /secret/work_dammit.txt mv: cannot create regular file `/secret/work_dammit.txt': Permission denied
Also cannot move files off: [root@xw4400-01 ~]# cd /secret/ [root@xw4400-01 secret]# ls 94733f578c4b75f6.txt blah.txt [root@xw4400-01 secret]# cp blah.txt /root/ [root@xw4400-01 secret]# rm -f /root/blah.txt [root@xw4400-01 secret]# mv blah.txt /root/ mv: cannot create regular file `/root/blah.txt': Permission denied
Appears to be selinux hating ecryptfs: type=AVC msg=audit(1196979196.290:58): avc: denied { associate } for pid=19833 comm="mv" name="94733f578c4b75f6.txt" scontext=root:object_r:user_home_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem type=SYSCALL msg=audit(1196979196.290:58): arch=c000003e syscall=2 success=no exit=-13 a0=1413db0 a1=41 a2=81a4 a3=1413f80 items=0 ppid=3268 pid=19833 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="mv" exe="/bin/mv" subj=root:system_r:unconfined_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1196979344.661:59): avc: denied { associate } for pid=19882 comm="mv" name="work_dammit.txt" scontext=root:object_r:user_home_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem type=SYSCALL msg=audit(1196979344.661:59): arch=c000003e syscall=2 success=no exit=-13 a0=7fff957d3bbc a1=41 a2=81a4 a3=29a2f50 items=0 ppid=3268 pid=19882 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="mv" exe="/bin/mv" subj=root:system_r:unconfined_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1196979618.151:60): avc: denied { associate } for pid=19894 comm="mv" name="blah.txt" scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem type=SYSCALL msg=audit(1196979618.151:60): arch=c000003e syscall=2 success=no exit=-13 a0=df4fdb0 a1=41 a2=81a4 a3=df4ff70 items=0 ppid=3268 pid=19894 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="mv" exe="/bin/mv" subj=root:system_r:unconfined_t:s0-s0:c0.c1023 key=(null)
If I mount ecryptfs with an option like "context=system_u:object_r:tmp_t" it's ok. I don't know for sure *how* ecryptfs should interact w/ selinux... Would it make any sense for selinux to know that ecryptfs is backed by ext3 and can use xattrs?
If you run restorecon on an encryptfs does it work? Does ecryptfs support extended attributes?
ecryptfs uses extended attributes if the underlying fs supports it. ecryptfs stores its information in an attr if so, and if mounted with the xattr option: [root@bear-05 secret3]# setfattr -n user.foo -v value bar [root@bear-05 secret3]# getfattr -L bar # file: bar user.ecryptfs user.foo [root@bear-05 secret3]# getfattr -n user.foo bar # file: bar user.foo="value" [root@bear-05 secret3]# getfattr -n user.ecryptfs bar # file: bar user.ecryptfs=0sAAAAAAAAAAAO4yM9MmKUyAMAAAYAABAAAAABigPPXcft9Vr+JQGEPVvV3KF6m3aQV0nl9OJ2zxFvRmjZl//uf9o18MZfAwAAieYjAuTLMx75kiSqMtZULX/oLTasYofIAs0bXCSOUMF3votWw7xgIjq8TIfY89WfDegrS5PFg9GPeAf/LS9chJclqpXxcGcB0WPSbf7f2gwwpuaHNCmNDNH5oWKiaA== However: [root@bear-05 secret3]# restorecon bar restorecon set context /root/secret3/bar->root:object_r:user_home_t:s0 failed:'Permission denied' and it generates: type=AVC msg=audit(1196997460.677:240): avc: denied { associate } for pid=3600 comm="restorecon" name="bar" dev=ecryptfs ino=2196035 scontext=root:object_r:user_home_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem type=SYSCALL msg=audit(1196997460.677:240): arch=40000003 syscall=227 success=no exit=-13 a0=bfbf7d57 a1=8452b3 a2=94f5608 a3=1d items=0 ppid=2747 pid=3600 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="restorecon" exe="/sbin/restorecon" subj=root:system_r:restorecon_t:s0-s0:c0.c1023 key=(null)
In /var/log/messages*, what did SELinux say when it initialized ecryptfs, ala: SELinux: initialized (dev ..., type ecryptfs), uses ... What does the RHEL5.2 policy have for ecryptfs fs_use behavior? Current refpolicy has fs_use_xattr.
BTW, two separate bugs here: one seemingly in policy or kernel with respect to proper handling of ecryptfs labeling, and one seemingly in coreutils (mv) - it shouldn't fail but should rather fall back to moving the file with a warning in this situation (Unable to preserve security context or something like that). I thought we had the same issue with NFS for a while and mv was fixed?
In the absence of any special mount options it says: SELinux: initialized (dev ecryptfs, type ecryptfs), not configured for labeling -Eric
I see that F8 only recently got a policy for ecryptfs: http://www.redhat.com/archives/fedora-extras-commits/2007-October/msg06999.html though I wonder what happens when ecryptfs is mounted over a filesystem which does not support xattrs?
We don't have a good way of handling that presently; policy specifies how to handle labeling for a given filesystem type and if the filesystem type doesn't oblige (e.g. doesn't implement getxattr or returns -EOPNOTSUPP), then we'll fail the mount altogether with an error. So: 1) bug in kernel: unable to gracefully handle a filesystem that may support different labeling behaviors at runtime ala ecryptfs, 2) bug in policy: lack of fs_use rule for ecryptfs 3) bug in coreutils: mv should not fail if context cannot be preserved
what the hell, how can you send this update at the same time I'm writing a message to selinux list about this problem (although i didn't know about this bug) Stephen, GET OUT OF MY HEAD! Anyway, #1, would there be a problem changing security_fs_use() to fall back to looking for rc = root_inode->i_op->getxattr(root, XATTR_NAME_SELINUX, NULL, 0); and deciding to use xattr labeling if it exists? Abdmittedly my three seconds of though does have a solution for how to set the sid in that case, doubt we want to leave it unlabeled.... That should solve the eCryptfs issues in both kernel and policy....
(In reply to comment #11) > and deciding to use xattr labeling if it exists? Abdmittedly my three seconds > of though does have a solution for how to set the sid in that case, doubt we > want to leave it unlabeled.... my three seconds of thoughT does NOT have a solution for how to....
Sorry about peering at your screen and keyboard from space - bad habits die hard. The problem with merely probing ->getxattr and using it if supported is that filesystems lie to us ;) For example, tmpfs implements ->getxattr for security.* so that it can return a label to userspace, but internally just calls back to the security module to get the in-core label (this was the case originally, then we switched to using vfs fallbacks, then it went back to being implemented by tmpfs when they added tmpfs ACL support and needed to push the getxattr handling back into the fs). So I think we still need to let it be policy-directed, or otherwise specified (e.g. filesystem type structure could itself specify the right behavior via a flag if we wanted to go that route). What could change is the limitation to a single behavior per fs - we could allow defining multiple fs use behaviors per fs type and try them, starting with the xattr rule if present and falling back to the other otherwise.
Wouldn't it be better to "fix" the broken cases like tmpfs by having its definition in policy be right? I'm saying we only check for xattr support if we don't find anything in policy. This way all the new thing that come along (just recently I can think of ext4dev, ext4, and no eCryptfs) would work right out of the box. If there is a problem we add them to the policy. Just felt to me like it would be better to try to make new things 'just work' and fix problems as they arise rather than assume everything is a problem...
I guess i should really look at how things like tmpfs would have exploded assuming they were not defined in policy.... (and now i'm scared of someone using tmpfs as the underlying filesystem for eCryptfs no matter how we solve this....)
And yes, sandeen tried it for me and you can use tmpfs as your underlying filesystem. We probably need to have some sort of way for the security module to learn what FS is underneath when dealing with fs stacking...
Falling back to testing ->getxattr if the filesystem is not configured for labeling in policy might be workable. There isn't anything wrong with the definition in policy for tmpfs (fs_use_trans) today - not sure what you mean by that. If we had lacked a definition for it, I think it would fall back to calling the security module's getsecurity method, and thus end up just being unlabeled_t - no real harm, just inaccessible. tmpfs under unionfs should be ok; SELinux would label the tmpfs inodes via fs_use_trans, then it would label the unionfs inodes via getxattr, and the getxattr would ripple down to tmpfs and grab it from the tmpfs inode - which is correct at that point.
I'm going to move this over to selinux; jarod tested w/ the updated policy in fedora, and things worked fine.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Fixed in /selinux-policy-2.4.6-108.el5
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2008-0465.html