Bug 414951 - [RHEL5.2 - ecryptfs] cannot mv files on or off encrypted mount - AVC denial
[RHEL5.2 - ecryptfs] cannot mv files on or off encrypted mount - AVC denial
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy (Show other bugs)
5.2
All Linux
low Severity low
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-06 17:19 EST by Jarod Wilson
Modified: 2008-05-21 12:06 EDT (History)
7 users (show)

See Also:
Fixed In Version: RHBA-2008-0465
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-21 12:06:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jarod Wilson 2007-12-06 17:19:30 EST
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
Comment 1 Jarod Wilson 2007-12-06 17:20:47 EST
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
Comment 2 Jarod Wilson 2007-12-06 17:28:25 EST
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)
Comment 3 Eric Sandeen 2007-12-06 18:14:18 EST
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? 
Comment 4 Daniel Walsh 2007-12-06 20:37:38 EST
If you run restorecon on an encryptfs does it work? Does ecryptfs support
extended attributes?
Comment 5 Eric Sandeen 2007-12-06 22:20:59 EST
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)

Comment 6 Stephen Smalley 2007-12-07 09:15:08 EST
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.
Comment 7 Stephen Smalley 2007-12-07 09:17:07 EST
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?
Comment 8 Eric Sandeen 2007-12-07 09:35:02 EST
In the absence of any special mount options it says:

SELinux: initialized (dev ecryptfs, type ecryptfs), not configured for labeling

-Eric
Comment 9 Eric Sandeen 2007-12-07 09:44:25 EST
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?
Comment 10 Stephen Smalley 2007-12-07 09:52:16 EST
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
Comment 11 Eric Paris 2007-12-07 10:05:04 EST
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....
Comment 12 Eric Paris 2007-12-07 10:06:37 EST
(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....
Comment 13 Stephen Smalley 2007-12-07 10:25:17 EST
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.
Comment 14 Eric Paris 2007-12-07 10:52:27 EST
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...
Comment 15 Eric Paris 2007-12-07 10:53:54 EST
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....)
Comment 16 Eric Paris 2007-12-07 11:22:44 EST
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...
Comment 17 Stephen Smalley 2007-12-07 11:39:38 EST
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.
Comment 18 Eric Sandeen 2007-12-18 16:39:07 EST
I'm going to move this over to selinux; jarod tested w/ the updated policy in
fedora, and things worked fine.
Comment 19 RHEL Product and Program Management 2007-12-18 16:44:59 EST
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.
Comment 20 Daniel Walsh 2008-01-03 11:07:43 EST
Fixed in /selinux-policy-2.4.6-108.el5
Comment 25 errata-xmlrpc 2008-05-21 12:06:19 EDT
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

Note You need to log in before you can comment on or make changes to this bug.