Bug 712048 - SELinux blocks ecryptfs encryption of home dir
Summary: SELinux blocks ecryptfs encryption of home dir
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: ecryptfs-utils
Version: 20
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
Assignee: Michal Hlavinka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 701451 713799 744618 (view as bug list)
Depends On:
Blocks: 703145 709158
TreeView+ depends on / blocked
 
Reported: 2011-06-09 11:11 UTC by Michal Hlavinka
Modified: 2015-03-09 10:35 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1017402 (view as bug list)
Environment:
Last Closed: 2015-03-09 10:35:08 UTC


Attachments (Terms of Use)
ausearch -m avc -ts 12:50 output (18.11 KB, text/plain)
2011-06-09 11:45 UTC, Michal Hlavinka
no flags Details
ausearch output (without restorecon) (9.62 KB, text/plain)
2011-06-10 06:43 UTC, Michal Hlavinka
no flags Details
ausearch output (with restorecon) (8.25 KB, text/plain)
2011-06-10 06:43 UTC, Michal Hlavinka
no flags Details
ecrypt local policy (1.72 KB, application/octet-stream)
2011-10-05 09:08 UTC, Miroslav Grepl
no flags Details
ecrypt local policy - labels (155 bytes, application/octet-stream)
2011-10-05 09:08 UTC, Miroslav Grepl
no flags Details
the test policy for ecryptfs (1010 bytes, application/x-compressed-tar)
2011-11-21 17:51 UTC, Miroslav Grepl
no flags Details
audit.log & more (4.75 KB, text/plain)
2012-06-04 23:53 UTC, Christian Kujau
no flags Details
Fix selinux to allow ecryptfs-migrate-home (2.29 KB, text/plain)
2012-06-05 12:23 UTC, Flemming from Banana hill
no flags Details

Description Michal Hlavinka 2011-06-09 11:11:32 UTC
Description of problem:
SELinux needs some changes for ecryptfs encrypted home directory to work.



Version-Release number of selected component (if applicable):
selinux-policy-3.9.16-26.fc15.noarch

How reproducible:
always

Steps to Reproduce:
1.update ecryptfs-utils,because there is some problem with /etc/mtab being a symlink in F15:

$ yum update --enablerepo=updates-testing ecryptfs-utils

2.enable ecryptfs pam module:

$ authconfig --enableecryptfs --updateall

3.add test user (with ecryptfs group)

useradd -G ecryptfs etest
passwd etest

4.migrate users home directory

$ ecryptfs-migrate-home -u etest

5.try to log in

Actual results:
ecryptfs encryption not set up correctly

Expected results:
ecryptfs encryption working

Additional info:
# ausearch -m avc -ts recent | audit2allow -R

require {
        type home_root_t;
        type local_login_t;
        type mount_t;
        type user_tmpfs_t;
        type ecryptfs_t;
        type setroubleshootd_t;
        class key write;
        class lnk_file read;
        class dir search;
        class file { read create write getattr unlink open };
}

#============= local_login_t ==============
allow local_login_t ecryptfs_t:dir search;
allow local_login_t ecryptfs_t:lnk_file read;
#!!!! The source type 'local_login_t' can write to a 'file' of the following types:
# pam_var_run_t, pcscd_var_run_t, local_login_lock_t, pam_var_console_t, local_login_tmp_t, cgroup_t, var_auth_t, auth_cache_t, faillog_t, krb5_host_rcache_t

allow local_login_t home_root_t:file { write read getattr open create };
allow local_login_t user_tmpfs_t:file { read getattr unlink open };
fs_manage_tmpfs_dirs(local_login_t)
fs_rw_tmpfs_files(local_login_t)
userdom_home_filetrans_user_home_dir(local_login_t)

#============= mount_t ==============
allow mount_t ecryptfs_t:lnk_file read;
allow mount_t local_login_t:key write;

#============= setroubleshootd_t ==============
dev_read_generic_chr_files(setroubleshootd_t)

Comment 1 Dominick Grift 2011-06-09 11:34:03 UTC
Can you also enclose the AVC denials please?

Comment 2 Miroslav Grepl 2011-06-09 11:41:38 UTC
#701451 bug

Comment 3 Michal Hlavinka 2011-06-09 11:45:36 UTC
Created attachment 503872 [details]
ausearch -m avc -ts 12:50 output

Comment 4 Dominick Grift 2011-06-09 11:55:08 UTC
I guess all login_pgm_domains will need to be able set this up, and seems like a good idea to confine umount.ecryptfs command on first sight.

Comment 5 Miroslav Grepl 2011-06-09 12:07:51 UTC
(In reply to comment #4)
> I guess all login_pgm_domains will need to be able set this up,

it looks so, thinking about a boolean.

Comment 6 Daniel Walsh 2011-06-09 18:22:53 UTC
Michal could you explain what is going on when you do this?  Does the file system end up being an ext* file system when it is done?  Or does the homedir end up labeled ecryptfs_t?

Comment 7 Michal Hlavinka 2011-06-10 06:41:03 UTC
ok, so how it works:

First, it takes /home/<user> and renames it to /home/<user>.<XXXXX> This directory should be deleted after process completes.

Then it sets up encrypted directory /home/<user>. Because ecryptfs needs some encryption configuration data, that are usually in ~/.ecryptfs, it creates new directoriy: /home/.ecryptfs/<user>/.ecryptfs , encrypted data are stored in /home/.ecryptfs/<user>/.Private So it's similar to ~/.ecryptfs and ~/.Private encryption of just ~/Private directory, it's just moved to /home/.ecryptfs/<user> and target directory is /home/<user> instead of /home/<user>/Private

Convert script is (must be) executed as root user, so there are no selinux denials at this point. Now, there is:
root.root unconfined_u:object_r:home_root_t:s0 /home/.ecryptfs(/.*)?
<user>.<user> unconfined_u:object_r:home_root_t:s0 /home/.ecryptfs/<user>(/.*)?
<user>.<user> unconfined_u:object_r:home_root_t:s0 /home/<user>
<user>.<user> unconfined_u:object_r:user_home_dir_t:s0 /home/<user>.s510Cboq

running restorecon -Rv will change home_root_t to user_home_dir_t

Should I add restorecon in ecrypts-migrate-home or it's not required?

When user tries to log in, selinux produces a lot of messages.

Comment 8 Michal Hlavinka 2011-06-10 06:43:24 UTC
Created attachment 504024 [details]
ausearch output (without restorecon)

Comment 9 Michal Hlavinka 2011-06-10 06:43:54 UTC
Created attachment 504025 [details]
ausearch output (with restorecon)

Comment 10 Daniel Walsh 2011-06-10 15:25:39 UTC
Can you ping me on #selinux so we can talk this out?

Comment 11 Miroslav Grepl 2011-06-20 08:03:15 UTC
*** Bug 713799 has been marked as a duplicate of this bug. ***

Comment 12 Michal Hlavinka 2011-09-30 12:29:36 UTC
user almost lost his data because of this bug. Just did not complete home migration process because lack of time. As it is now, migration completes, but encryption key is not stored. It means that after reboot, data are still encrypted without any chance to decrypt them. Setting severity to high.

Comment 13 Miroslav Grepl 2011-09-30 12:41:58 UTC
My, fault. I dropped this one.

Comment 14 Miroslav Grepl 2011-10-05 09:08:08 UTC
Created attachment 526446 [details]
ecrypt local policy

Ok, since extended attr are not supported in this case, it is more complicated to make this working.

I did it with attached local policy. This local policy contains notes which need to be done in the ecrypts-migrate-home script and in the policy.

Dan,
what do you think?

Comment 15 Miroslav Grepl 2011-10-05 09:08:43 UTC
Created attachment 526448 [details]
ecrypt local policy - labels

Comment 16 Miroslav Grepl 2011-10-10 12:36:35 UTC
*** Bug 744618 has been marked as a duplicate of this bug. ***

Comment 17 Miroslav Grepl 2011-11-21 17:51:58 UTC
Created attachment 534831 [details]
the test policy for ecryptfs

Just the note: You should be running in permissive mode because of the test policy.

How to install the ecrypt policy

1. Download this attachment
2. tar zxfv ecrypt.tgz
3. cd ecrypt/
4. sh ecrypt.sh <username>
5. setsebool -P use_ecryptfs_home_dirs 1

and try to re-test it.

Comment 18 Miroslav Grepl 2011-11-23 22:41:56 UTC
*** Bug 701451 has been marked as a duplicate of this bug. ***

Comment 19 Kevin R. Page 2012-06-02 23:04:32 UTC
Is this fixed in Fedora 17? I'd like to try migrating home directories to ecryptfs but comment #12 leaves me wary.

Comment 20 Kevin R. Page 2012-06-03 00:07:20 UTC
I've just tested the instructions in comment #17 -- it doesn't work (Fedora 17). With setenforce 0 the can log in but with the audit.log below (obviously fails with setenforce 1).

What else should I try?

type=AVC msg=audit(1338681693.523:204): avc:  denied  { getattr } for  pid=2825 comm="login" path="/home/.ecryptfs/lae/.ecryptfs/auto-mount" dev="dm-1" ino=394973 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:home_root_t:s0 tclass=file
type=SYSCALL msg=audit(1338681693.523:204): arch=c000003e syscall=4 success=yes exit=0 a0=768d10 a1=7fffc697b4b0 a2=7fffc697b4b0 a3=1f items=0 ppid=1 pid=2825 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty3 ses=4294967295 comm="login" exe="/usr/bin/login" subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1338681693.524:205): avc:  denied  { read } for  pid=2825 comm="login" name="Private.mnt" dev="dm-1" ino=1362 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file
type=AVC msg=audit(1338681693.524:205): avc:  denied  { open } for  pid=2825 comm="login" name="Private.mnt" dev="dm-1" ino=1362 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file
type=SYSCALL msg=audit(1338681693.524:205): arch=c000003e syscall=2 success=yes exit=5 a0=768d10 a1=0 a2=1b6 a3=238 items=0 ppid=1 pid=2825 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty3 ses=4294967295 comm="login" exe="/usr/bin/login" subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1338681693.524:206): avc:  denied  { getattr } for  pid=2825 comm="login" path="/home/.ecryptfs/lae/.ecryptfs/Private.mnt" dev="dm-1" ino=1362 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file
type=SYSCALL msg=audit(1338681693.524:206): arch=c000003e syscall=5 success=yes exit=0 a0=5 a1=7fffc697b3b0 a2=7fffc697b3b0 a3=0 items=0 ppid=1 pid=2825 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty3 ses=4294967295 comm="login" exe="/usr/bin/login" subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 key=(null)
type=USER_AUTH msg=audit(1338681693.525:207): pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="lae" exe="/usr/bin/login" hostname=? addr=? terminal=tty3 res=success'
type=USER_ACCT msg=audit(1338681693.532:208): pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:accounting acct="lae" exe="/usr/bin/login" hostname=? addr=? terminal=tty3 res=success'
type=CRED_ACQ msg=audit(1338681693.533:209): pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="lae" exe="/usr/bin/login" hostname=? addr=? terminal=tty3 res=success'
type=LOGIN msg=audit(1338681693.533:210): login pid=2825 uid=0 old auid=4294967295 new auid=1983 old ses=4294967295 new ses=10
type=USER_ROLE_CHANGE msg=audit(1338681693.590:211): pid=0 uid=0 auid=1983 ses=10 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 selected-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 exe="/usr/bin/login" hostname=? addr=? terminal=tty3 res=success'
type=AVC msg=audit(1338681694.194:212): avc:  denied  { read } for  pid=3050 comm="login" name="wrapped-passphrase" dev="dm-1" ino=394975 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:home_root_t:s0 tclass=file
type=AVC msg=audit(1338681694.194:212): avc:  denied  { open } for  pid=3050 comm="login" name="wrapped-passphrase" dev="dm-1" ino=394975 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:home_root_t:s0 tclass=file
type=SYSCALL msg=audit(1338681694.194:212): arch=c000003e syscall=2 success=yes exit=7 a0=765f60 a1=0 a2=0 a3=7fe8c5cc4f63 items=0 ppid=2825 pid=3050 auid=1983 uid=1983 gid=0 euid=1983 suid=1983 fsuid=1983 egid=0 sgid=0 fsgid=0 tty=tty3 ses=10 comm="login" exe="/usr/bin/login" subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1338681695.114:213): avc:  denied  { getattr } for  pid=2825 comm="login" path="/home/.ecryptfs/lae/.ecryptfs/Private.sig" dev="dm-1" ino=1356 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file
type=SYSCALL msg=audit(1338681695.114:213): arch=c000003e syscall=4 success=yes exit=0 a0=765f90 a1=7fffc697b4f0 a2=7fffc697b4f0 a3=20 items=0 ppid=1 pid=2825 auid=1983 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty3 ses=10 comm="login" exe="/usr/bin/login" subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1338681695.116:214): avc:  denied  { getattr } for  pid=3093 comm="login" path="/home/.ecryptfs/lae/.ecryptfs/auto-mount" dev="dm-1" ino=394973 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:home_root_t:s0 tclass=file
type=SYSCALL msg=audit(1338681695.116:214): arch=c000003e syscall=4 success=yes exit=0 a0=765f60 a1=7fffc697b4f0 a2=7fffc697b4f0 a3=7361702d64657070 items=0 ppid=2825 pid=3093 auid=1983 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty3 ses=10 comm="login" exe="/usr/bin/login" subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 key=(null)
type=USER_START msg=audit(1338681695.145:215): pid=0 uid=0 auid=1983 ses=10 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:session_open acct="lae" exe="/usr/bin/login" hostname=? addr=? terminal=tty3 res=success'
type=CRED_REFR msg=audit(1338681695.145:216): pid=0 uid=0 auid=1983 ses=10 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="lae" exe="/usr/bin/login" hostname=? addr=? terminal=tty3 res=success'
type=USER_LOGIN msg=audit(1338681695.146:217): pid=0 uid=0 auid=1983 ses=10 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=login id=1983 exe="/usr/bin/login" hostname=? addr=? terminal=tty3 res=success'

Comment 21 Christian Kujau 2012-06-04 23:46:58 UTC
Confirmed, SELinux is blocking access to .ecryptfs/wrapped-passphrase during login. Syslog has:

-------
login: pam_unix(login:session): session opened for user alice by LOGIN(uid=0)
login: ecryptfs: fill_keyring: Passphrase file wrapped
login: Error attempting to open [/home/alice/.ecryptfs/wrapped-passphrase] for reading
login: Error attempting to unwrap passphrase from file [/home/alice/.ecryptfs/wrapped-passphrase]; rc = [-5]
login: ecryptfs: fill_keyring: Error adding passphrase key token to user session keyring; rc = [-5]
login: LOGIN ON tty3 BY alice
-------

With "setenforce 0", the same login attempt mounts alice's $HOME and syslog has:

-------
login: pam_unix(login:session): session opened for user alice by LOGIN(uid=0)
login: ecryptfs: fill_keyring: Passphrase file wrapped
login: LOGIN ON tty3 BY alice
-------

Executing "ecrypt.sh alice" and "setsebool -P use_ecryptfs_home_dirs 1" did not help, the home directory is still not mounted. (Btw, what is "Step 1" in comment #17 supposed to be? Looks like an awk script?)

I'll attach the entries from audit.log.

Comment 22 Christian Kujau 2012-06-04 23:53:02 UTC
Created attachment 589308 [details]
audit.log & more

Comment 23 Michal Hlavinka 2012-06-05 08:12:10 UTC
What's the time plan for this bug fix? This bug was reported two fedora releases ago and I'm getting more and more complaints about not working ecryptfs encryption. Is there a plan to fix this soon or should I modify home encryption tool to tell users to disable selinux to get it working?

Comment 24 Miroslav Grepl 2012-06-05 12:22:54 UTC
Yes, a policy fix is going to be part of F17 soon.

Comment 25 Flemming from Banana hill 2012-06-05 12:23:56 UTC
Created attachment 589515 [details]
Fix selinux to allow ecryptfs-migrate-home

I have successfully used the attached script on two F17 installations. After running it home directories can be migrated using ecryptfs-migrate-home without problems. Selinux can be in enforcing mode all the time.

After having dealt with the Selinux errors I occasionally experienced that I could log in but file names were still encrypted. It is probably caused by Bug 754703. A work-around is included at the end of the script.

Comment 26 Michal Hlavinka 2012-06-05 12:38:19 UTC
> After having dealt with the Selinux errors I occasionally experienced that I
> could log in but file names were still encrypted. It is probably caused by
> Bug 754703. A work-around is included at the end of the script.

Yes, it's caused with ecryptfs module not loaded in advance. Scripts (and binaries) used several workarounds for this, but with more and more strict policy, all of them stopped working properly. I've build new packages yesterday and I'm testing them right now. It was working for me and because you've confirmed it works in your case too, I'm going to push it to updates-testing.

Comment 27 Michal Hlavinka 2012-06-29 10:09:39 UTC
(In reply to comment #23)
> > ...Is there a plan to fix this soon or should I modify
> > home encryption tool to tell users to disable selinux to get it working?

> (In reply to comment #24)
> Yes, a policy fix is going to be part of F17 soon.

any time soon?

Comment 28 Miroslav Grepl 2012-07-15 20:05:06 UTC
Fixed in selinux-policy-3.10.0-139.fc17

Comment 29 Michal Hlavinka 2012-07-16 12:30:03 UTC
(In reply to comment #28)
> Fixed in selinux-policy-3.10.0-139.fc17

are any changes (selinux boolean or something) required in ecryptfs-utils?

Comment 30 Miroslav Grepl 2012-07-16 13:01:29 UTC
(In reply to comment #29)
> (In reply to comment #28)
> > Fixed in selinux-policy-3.10.0-139.fc17
> 
> are any changes (selinux boolean or something) required in ecryptfs-utils?

Yes.

# the ecryptfs-migrate-home script needs to be patched using 

# restorecon -R -v $HOME/$USER 
# semanage fcontext -a -e /home /home/.ecryptfs
# restorecon -R -v $HOME/.ecrypfs/$USER

and turn on the boolean.

Comment 31 Fedora Update System 2012-07-18 13:03:40 UTC
selinux-policy-3.10.0-140.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-140.fc17

Comment 32 Fedora Update System 2012-07-19 09:10:34 UTC
Package selinux-policy-3.10.0-140.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.10.0-140.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-10840/selinux-policy-3.10.0-140.fc17
then log in and leave karma (feedback).

Comment 33 Fedora Update System 2012-07-21 22:50:54 UTC
selinux-policy-3.10.0-140.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 34 Kevin R. Page 2012-07-25 21:11:43 UTC
I've applied the selinux-policy update and I'm now trying to update my existing install so I can re-enable selinux. I've performed the first three steps. Could you confirm the fourth is:

setsebool -P use_ecryptfs_home_dirs 1


(In reply to comment #30)
> 
> Yes.
> 
> # the ecryptfs-migrate-home script needs to be patched using 
> 
> # restorecon -R -v $HOME/$USER 
> # semanage fcontext -a -e /home /home/.ecryptfs
> # restorecon -R -v $HOME/.ecrypfs/$USER
> 
> and turn on the boolean.

Thanks.

Comment 35 Miroslav Grepl 2012-07-26 05:15:03 UTC
Yes. Also execute

# restorecon -R -v /home

to make sure all labeling is ok.

Comment 36 Kevin R. Page 2012-07-26 08:09:28 UTC
(In reply to comment #35)
> Yes. Also execute
> # restorecon -R -v /home
> to make sure all labeling is ok.

Thanks! These instructions, in combination with the policy update, work for me and I now have selinux enforcing with ecryptfs home directories.

Comment 37 Miroslav Grepl 2012-07-26 09:46:14 UTC
Great. Thank you for testing.

Comment 38 Dominik Grafenhofer 2013-11-06 10:06:50 UTC
I am currently testing F-20 (alpha + latest updates), and the bug described over here has reemerged: 

I have to run the following to get my ecrypfs home to automount again:

# restorecon -R -v $HOME/$USER 
# semanage fcontext -a -e /home /home/.ecryptfs
# restorecon -R -v $HOME/.ecrypfs/$USER

and turn on the boolean.

Comment 39 Miroslav Grepl 2013-11-06 14:27:22 UTC
What AVC are you getting?

Comment 40 Dominik Grafenhofer 2013-11-06 15:11:00 UTC
Do you need more than that?

type=AVC msg=audit(1383733368.264:584): avc:  denied  { getattr } for  pid=3271 comm="gdm-session-wor" path="/home/.ecryptfs/dominik/.ecryptfs/auto-umount" dev="sdb1" ino=32112646 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:home_root_t:s0 tclass=file

type=SYSCALL msg=audit(1383733368.264:584): arch=x86_64 syscall=stat success=no exit=EACCES a0=7f768b022a50 a1=7fff2adc9a00 a2=7fff2adc9a00 a3=7f767ef557f8 items=0 ppid=3012 pid=3271 auid=1000 uid=0 gid=1000 euid=0 suid=0 fsuid=0 egid=1000 sgid=1000 fsgid=1000 ses=5 tty=(none) comm=gdm-session-wor exe=/usr/libexec/gdm-session-worker subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)

Comment 41 Miroslav Grepl 2014-01-06 12:44:32 UTC
Strange. Does

$ restorecon -R -v /home/.ecryptfs/dominik

fix the labeling?

Comment 42 Dominik Grafenhofer 2014-10-07 11:52:26 UTC
Sorry for answering late...

At the time 

$ restorecon -R -v /home/.ecryptfs/dominik

fixed the labeling.

Comment 43 Martin Wilck 2014-10-07 14:33:20 UTC
Sorry, why is this NOTABUG?

Shouldn't at keast ecryptfs-migrate-home be fixed such that restorecon is run automatically? How are users supposed to know that this manual step is necessary?

Comment 44 Daniel Walsh 2015-01-03 13:56:01 UTC
Any movement on this?

Comment 45 Michal Hlavinka 2015-02-27 11:04:47 UTC
There must be some different problem because ecrypts-migrate-home does call restorecon.

...
restorecon -R /home/.ecryptfs/$USER_NAME >/dev/null 2>&1 ||:
umount "$USER_HOME/"
restorecon -R "$USER_HOME" >/dev/null 2>&1 ||:

so both /home/.ecryptfs/<username> and /home/<username> should have correct selinux context.

Is it still reproducible?

Comment 46 Martin Wilck 2015-02-27 11:40:25 UTC
Before ecryptfs-migrate-home, files in the users home dir have type user_home_t. Afterwards, they have ecryptfs_t. Running restorecon changes nothing. Is that the expected / correct behavior? I would have expected user_home_t after the migration...

But I didn't notice any errors or AVC denials in the procedure below.

[ ~]# rpm -q ecryptfs-utils
ecryptfs-utils-103-4.fc20.x86_64
[ ~]# rpm -q selinux-policy-targeted
selinux-policy-targeted-3.12.1-196.fc20.noarch
[ ~]# getenforce 
Enforcing

[ ~]# useradd -m seppel
[ ~]# passwd seppel
passwd: all authentication tokens updated successfully.

[ ~]# ls -aZ /home/seppel/
drwx------. seppel seppel unconfined_u:object_r:user_home_dir_t:s0 .
drwxr-xr-x. root   root   system_u:object_r:home_root_t:s0 ..
-rw-r--r--. seppel seppel unconfined_u:object_r:user_home_t:s0 .bash_logout
-rw-r--r--. seppel seppel unconfined_u:object_r:user_home_t:s0 .bash_profile

[ ~]# usermod -a -G ecryptfs seppel
[ ~]# ecryptfs-migrate-home -u seppel
 1. The file encryption appears to have completed successfully, however,
    seppel MUST LOGIN IMMEDIATELY, _BEFORE_THE_NEXT_REBOOT_,
    TO COMPLETE THE MIGRATION!!!

(seppel logs in on another terminal, success)

[ ~]# ls -aZ /home/seppel
drwx------. seppel seppel system_u:object_r:ecryptfs_t:s0  .
drwxr-xr-x. root   root   system_u:object_r:home_root_t:s0 ..
-rw-r--r--. seppel seppel system_u:object_r:ecryptfs_t:s0  .bash_logout
-rw-r--r--. seppel seppel system_u:object_r:ecryptfs_t:s0  .bash_profile
-rw-r--r--. seppel seppel system_u:object_r:ecryptfs_t:s0  .bashrc
lrwxrwxrwx. seppel seppel system_u:object_r:ecryptfs_t:s0  .ecryptfs -> /home/.ecryptfs/seppel/.ecryptfs
...

[ ~]# ls -aZ /home/.ecryptfs/seppel/
drwxr-xr-x. seppel seppel unconfined_u:object_r:user_home_dir_t:s0 .
drwxr-xr-x. root   root   unconfined_u:object_r:home_root_t:s0 ..
drwx------. seppel seppel unconfined_u:object_r:ecryptfs_t:s0 .ecryptfs
drwx------. seppel seppel unconfined_u:object_r:ecryptfs_t:s0 .Private

Comment 47 Christian Kujau 2015-03-04 02:46:09 UTC
This seems to work now on Fedora 21, although a few warnings remain:

============================================================================
# yum install ecryptfs-utils lsof
# useradd testuser && passwd testuser
# ls -laZ ~testuser/
drwx------. testuser testuser unconfined_u:object_r:user_home_dir_t:s0 .
drwxr-xr-x. root     root     system_u:object_r:home_root_t:s0 ..
-rw-r--r--. testuser testuser unconfined_u:object_r:user_home_t:s0 .bash_logout
-rw-r--r--. testuser testuser unconfined_u:object_r:user_home_t:s0 .bash_profile
-rw-r--r--. testuser testuser unconfined_u:object_r:user_home_t:s0 .bashrc

# usermod -G ecryptfs testuser
# ecryptfs-migrate-home -u testuser
INFO:  Checking disk space, this may take a few moments.  Please be patient.
INFO:  Checking for open files in /home/testuser
Enter your login passphrase [testuser]: 

************************************************************************
YOU SHOULD RECORD YOUR MOUNT PASSPHRASE AND STORE IT IN A SAFE LOCATION.
  ecryptfs-unwrap-passphrase ~/.ecryptfs/wrapped-passphrase
THIS WILL BE REQUIRED IF YOU NEED TO RECOVER YOUR DATA AT A LATER TIME.
************************************************************************

/usr/sbin/restorecon
/usr/sbin/restorecon

Done configuring.

chown: cannot access ‘/dev/shm/.ecryptfs-testuser’: No such file or directory
INFO:  Encrypted home has been set up, encrypting files now...this may take a while.
sending incremental file list
./
.bash_logout
.bash_profile
.bashrc
Could not unlink the key(s) from your keying. Please use `keyctl unlink` if you wish to remove the key(s). Proceeding with umount.

....

# ssh localhost -l testuser
testuser@localhost's password: 
testuser@fedora0:/home/testuser$ df -h .
Filesystem               Size  Used Avail Use% Mounted on
/home/testuser/.Private  3.7G  1.9G  1.5G  57% /home/testuser

testuser@fedora0:/home/testuser$ ls -laZ
drwx------. testuser testuser system_u:object_r:ecryptfs_t:s0  .
drwxr-xr-x. root     root     system_u:object_r:home_root_t:s0 ..
-rw-------. testuser testuser system_u:object_r:ecryptfs_t:s0  .bash_history
-rw-r--r--. testuser testuser system_u:object_r:ecryptfs_t:s0  .bash_logout
-rw-r--r--. testuser testuser system_u:object_r:ecryptfs_t:s0  .bash_profile
-rw-r--r--. testuser testuser system_u:object_r:ecryptfs_t:s0  .bashrc
lrwxrwxrwx. testuser testuser system_u:object_r:ecryptfs_t:s0  .ecryptfs -> /home/.ecryptfs/testuser/.ecryptfs
lrwxrwxrwx. testuser testuser system_u:object_r:ecryptfs_t:s0  .Private -> /home/.ecryptfs/testuser/.Private
============================================================================

No SELinux warnings were recorded, yay :)

Of course, now I get an error in syslog when a non-ecryptfs-enabled user (e.g. "root") is logging in to the system:

Mar 03 18:43:52 fedora0. sshd[1597]: pam_unix(sshd:session): session opened for user root by (uid=0)
Mar 03 18:43:52 fedora0 sshd[1597]: ecryptfs: fill_keyring: Unable to get ecryptfs pam data : No module specific data is present

...but that may be material for another bug report.


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