Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pam_fscrypt messes up user groups during login #77

Closed
stephan-gh opened this issue Jan 23, 2018 · 21 comments
Closed

pam_fscrypt messes up user groups during login #77

stephan-gh opened this issue Jan 23, 2018 · 21 comments
Labels

Comments

@stephan-gh
Copy link

I've added pam_fscrypt to /etc/pam.d/system-auth (on Arch Linux) as described in the README:

auth      required  pam_unix.so     try_first_pass nullok
auth      optional  pam_permit.so
auth      required  pam_env.so
auth      optional  pam_fscrypt.so

account   required  pam_unix.so
account   optional  pam_permit.so
account   required  pam_time.so

password  required  pam_unix.so     try_first_pass nullok sha512 shadow
password  optional  pam_permit.so
password  optional  pam_fscrypt.so

session   required  pam_limits.so
session   required  pam_unix.so
session   optional  pam_permit.so
session   optional  pam_fscrypt.so  drop_caches lock_policies

With pam_fscrypt enabled, I'm no longer in the wheel group after login for some reason, which means I can no longer use sudo. Instead, it adds me to the root group:

$ id
uid=1000(i3test) gid=1000(i3test) groups=1000(i3test),0(root)

With session optional pam_fscrypt.so commented out:

$ id
uid=1000(i3test) gid=1000(i3test) groups=1000(i3test),985(wheel)

Log:

login[434]: pam_unix(login:session): session opened for user i3test by LOGIN(uid=0)
pam_fscrypt[434]: OpenSession()
pam_fscrypt[434]: Session count for UID=1000 updated to 1
pam_fscrypt[434]: KeyctlLink(483117192, 57274768) = <nil>
pam_fscrypt[434]: Setting privileges to "i3test"
pam_fscrypt[434]: Setregid(-1, 1000) = <nil>
pam_fscrypt[434]: Setgroups([1000 985]) = <nil>
pam_fscrypt[434]: Setreuid(-1, 1000) = <nil>
pam_fscrypt[434]: Reading config from "/etc/fscrypt.conf"
pam_fscrypt[434]: creating context for "i3test"
pam_fscrypt[434]: found ext4 filesystem "/" (/dev/sda2)
pam_fscrypt[434]: listing descriptors in "/.fscrypt/protectors"
pam_fscrypt[434]: found 0 descriptor(s)
pam_fscrypt[434]: no protector to unlock: no PAM protector for UID=1000 on "/"
pam_fscrypt[434]: Setting privileges to "root"
pam_fscrypt[434]: Setreuid(-1, 0) = <nil>
pam_fscrypt[434]: Setregid(-1, 0) = <nil>
pam_fscrypt[434]: Setgroups([0]) = <nil>
pam_fscrypt[434]: pam func succeeded
login[434]: LOGIN ON tty1 BY i3test
login[434]: pam_unix(login:session): session closed for user i3test
pam_fscrypt[434]: CloseSession(map[drop_caches:true lock_policies:true debug:true])
pam_fscrypt[434]: Session count for UID=1000 updated to 0
pam_fscrypt[434]: locking polices protected with login protector
pam_fscrypt[434]: KeyctlLink(483117192, 57274768) = <nil>
pam_fscrypt[434]: Setting privileges to "i3test"
pam_fscrypt[434]: Setregid(-1, 1000) = <nil>
pam_fscrypt[434]: Setgroups([1000 985]) = <nil>
pam_fscrypt[434]: Setreuid(-1, 1000) = <nil>
pam_fscrypt[434]: Reading config from "/etc/fscrypt.conf"
pam_fscrypt[434]: creating context for "i3test"
pam_fscrypt[434]: found ext4 filesystem "/" (/dev/sda2)
pam_fscrypt[434]: listing descriptors in "/.fscrypt/protectors"
pam_fscrypt[434]: found 0 descriptor(s)
pam_fscrypt[434]: nothing to lock: no PAM protector for UID=1000 on "/"
pam_fscrypt[434]: Setting privileges to "root"
pam_fscrypt[434]: Setreuid(-1, 0) = <nil>
pam_fscrypt[434]: Setregid(-1, 0) = <nil>
pam_fscrypt[434]: Setgroups([0]) = <nil>
pam_fscrypt[434]: dropping appropriate filesystem caches at session close
pam_fscrypt[434]: syncing changes to filesystem
pam_fscrypt[434]: freeing reclaimable inodes and dentries
pam_fscrypt[434]: pam func succeeded
kernel: login (434): drop_caches: 2

Any ideas? :)

@ghost
Copy link

ghost commented Jan 24, 2018

Add pam_fscrypt to /etc/pam.d/system-login instead. Auth module at bottom and session module just below pam_keyinit:

auth       required   pam_tally.so         onerr=succeed file=/var/log/faillog
auth       required   pam_shells.so
auth       requisite  pam_nologin.so
auth       include    system-auth
auth      optional  pam_fscrypt.so
session    optional   pam_loginuid.so
session    optional   pam_keyinit.so       force revoke
session   optional  pam_fscrypt.so  drop_caches lock_policies
session    include    system-auth
...

@stephan-gh
Copy link
Author

@fancytenseletters Hmm, I just tried that but it doesn't make any difference unfortunately :( Same thing is still happening.

I removed it from /etc/pam.d/system-auth and changed /etc/pam.d/system-login to:

#%PAM-1.0

auth       required   pam_tally.so         onerr=succeed file=/var/log/faillog
auth       required   pam_shells.so
auth       requisite  pam_nologin.so
auth       include    system-auth
auth       optional   pam_fscrypt.so

account    required   pam_access.so
account    required   pam_nologin.so
account    include    system-auth

password   include    system-auth

session    optional   pam_loginuid.so
session    optional   pam_keyinit.so       force revoke
session    optional   pam_fscrypt.so       drop_caches lock_policies
session    include    system-auth
session    optional   pam_motd.so          motd=/etc/motd
session    optional   pam_mail.so          dir=/var/spool/mail standard quiet
#-session   optional   pam_systemd.so
session    required   pam_env.so

@ghost
Copy link

ghost commented Jan 24, 2018

@Minecrell can you try uncommenting pam_systemd.so and adding bypass for it (I assume you use systemd):

#%PAM-1.0

auth       required   pam_tally.so         onerr=succeed file=/var/log/faillog
auth       required   pam_shells.so
auth       requisite  pam_nologin.so
auth       include    system-auth
auth       optional   pam_fscrypt.so

account    required   pam_access.so
account    required   pam_nologin.so
account    include    system-auth

password   include    system-auth

session    optional   pam_loginuid.so
session    optional   pam_keyinit.so       force revoke
session [success=1 default=ignore]  pam_succeed_if.so  service = systemd-user quiet
session    optional   pam_fscrypt.so       drop_caches lock_policies
session    include    system-auth
session    optional   pam_motd.so          motd=/etc/motd
session    optional   pam_mail.so          dir=/var/spool/mail standard quiet
-session   optional   pam_systemd.so
session    required   pam_env.so

@stephan-gh
Copy link
Author

stephan-gh commented Jan 24, 2018

@fancytenseletters Yeah, I disabled pam_systemd.so because it was causing OpenSession() to be called twice for some reason, but it seems like your bypass using pam_succeed_if.so fixes that too :) Thanks!

I copied your config as-is to /etc/pam.d/system-login, but the problem persists: the user is still in the root group instead of wheel with pam_fscrypt.so enabled.

@ghost
Copy link

ghost commented Jan 24, 2018

Perhaps there is some bug in fscrypt.
Could you post your /etc/passwd /etc/groups and log from login again?

Also, can you try to create and encrypt some folder and try to relogin? How do you login? Console/sddm/lightdm/gdm?

@stephan-gh
Copy link
Author

stephan-gh commented Jan 24, 2018

@fancytenseletters Sure, I appreciate your help! :)

Normally I use lightdm, but for testing I have disabled it and just login from the default console login prompt. For some reason, login in lightdm is entirely broken with pam_fscrypt. It seems to start logging in (screen turns black), but shortly after the login mask of lightdm appears again.

I've posted the files and logs (for console login and lightdm login) at https://gist.github.com/Minecrell/33fea177022b36313d357a3c5994b9d9

The folder I created is unlocked correctly, but with console login the group is wrong and with lightdm it doesn't even log in properly.

@ghost
Copy link

ghost commented Jan 24, 2018

Do you have https://www.archlinux.org/packages/extra/x86_64/accountsservice/ package installed?

@stephan-gh
Copy link
Author

I did not, but I just installed it and it doesn't make any difference either :(

@sebadoom
Copy link

sebadoom commented Feb 2, 2018

I just realized I am also experiencing this bug. In my case, my user is not in the vboxusers group, preventing me from using USB devices in VirtualBox. I am also on Arch and using systemd (as default on Arch).

@sebadoom
Copy link

sebadoom commented Feb 2, 2018

Should we keep the pam_fscrypt.so in system-auth file for the password directive and move the other two to system-login?

EDIT: I can confirm doing this change appears to fix the groups issue for me as well.

@ghost
Copy link

ghost commented Feb 8, 2018

@Minecrell can you confirm that adding pam_fscrypt password module to /etc/pam.d/system-auth fixes your issue? Example below:

password  required  pam_unix.so     try_first_pass sha512 shadow
password  optional  pam_fscrypt.so
password  optional  pam_permit.so

@stephan-gh
Copy link
Author

Doesn't seem to make any difference for me :( I still get:

$ id
uid=1000(i3test) gid=1000(i3test) groups=1000(i3test),0(root)

... with these configs & logs: https://gist.github.com/Minecrell/53e478dc8495c93357a6bf38449fff39

@sebadoom
Copy link

sebadoom commented Feb 8, 2018

@Minecrell I just compared your config files with mine and they look identical except for the debug directive in one of the fscrypt entries. Sorry I cannot be of more help.

@sebadoom
Copy link

sebadoom commented Feb 15, 2018

As I was looking into reproducing #93 I managed to reproduce this bug. Here's a QEMU VM that triggers the bug running HEAD:

https://drive.google.com/open?id=1soLFKOoFHK47d31RCn6qmJB7AORe2ysg

Uncompress (using xz, no tarball) and launch using virt-manager. Fedora 26 settings. Two users: root and qemu, both have the same password: qemu. User qemu's home is encrypted, PAM unlocking is setup.

@josephlr
Copy link
Member

@sebadoom, this is great, will investigate tonight.

@lathiat
Copy link

lathiat commented Mar 8, 2018

For me, the simple change that makes this happen was when I added pam_fscrypt to "/etc/pam.d/systemd-user" on my Ubuntu 18.04 (Bionic) system.

Currently, the Ubuntu package does not run pam_fscrypt for /etc/pam.d/common-session-noninteractive which is what systemd-user uses. I was guessing this also means most of the background daemons on login don't have access to the filesystem.

In my attempt to resolve this I added pam.d to /etc/pam.d/systemd-user - whether I put it before or after systemd the login groups are messed up, and the session/user keys don't end up linked.

My understanding of PAM is really lacking at this point to understand that more.. it sounds like this is going to get replaced by systemd integration never the less thought I'd add the comment.

@lathiat
Copy link

lathiat commented Mar 8, 2018

I've realised part of the issue for me.. gnome-terminal is not actually running as a new process but is instead powered by 'gnome-terminal-server' which runs under the systemd-user session .. so gnome-terminal itself and all commands you run inside of it are "broken" much like other services started by systemd-user in many configurations.

@lathiat
Copy link

lathiat commented Apr 17, 2018

I can reproduce this on a fresh Ubuntu 18.04 installation. It happens for any PAM context where pam_fscrypt is loaded (even if no filesystems are in use)

(1) Install 18.04 using http://cdimage.ubuntu.com/daily-live/current/bionic-desktop-amd64.iso
(2) apt-get install libpam-fscrypt fscrypt xterm
(3) Reboot (no need to do any fscrypt setup)
(4) Login, launch xterm, run "id" (no groups); compare to the output from "Terminal" (has groups); xterm (and anything else launched from gnome-shell) runs under the session scope but gnome-terminal runs under the user scope due to using gnome-terminal-server as a backend process. Same issue occurs for anything launched from gnome-shell that requires a group, e.g. virt-manager, etc.. gnome-terminal is special because it's really using a process under the systemd-user scope. By default on Ubuntu, /etc/pam.d/systemd-user has neither pam_fscrypt nor pam_keyinit (the latter is a bug, systemd upstream added it in 2016).
(5) If you then add pam_fscrypt (for session) into /etc/pam.d/systemd-user then neither xterm nor gnome-terminal have any groups.. so it seems generally loading pam_fscrypt.so as a session module is the step causing this behavior.

Have not debugged how/why it causes the behaviour.

Also happens when installing from git

@stephan-gh
Copy link
Author

stephan-gh commented Apr 28, 2018

I've debugged this in detail and it boils down to the call to setGroups when dropping/restoring privileges:

if err := setGroups(target); err != nil {
return err
}

With this commented out, the user groups are correct after login. Otherwise the user is only in the root group.

Looking at the source code of /usr/bin/login (comes from util-linux on ArchLinux), there is an indication why changing the groups causes this issue: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tree/login-utils/login.c?h=v2.32#n1251

Unlike UID and GID, the supplementary group list of the target user is applied before the PAM modules are called. fscrypt breaks this by applying the supplementary groups of the root user when restoring the privileges.

There are a few ways to fix this but I'm not sure which one is the best solution:

  • Is changing the supplementary group list even necessary? The groups of the target user are already set, so dropping and restoring the original privileges would always apply the same groups. However, I'm not sure if we can always rely on having the right groups already set. (e.g. when not using /usr/bin/login from util-linux?)

  • Store the original supplementary group list by calling getgroups before dropping privileges. That way, fscrypt could always restore them correctly.

@stephan-gh
Copy link
Author

Additional note: I haven't checked this in detail, but it seems like Ubuntu might be using /usr/bin/login from the "shadow" package while Arch Linux uses the one from "util-linux". Unlike util-linux (as far as I can see from looking at the shadow source code), shadow sets up the groups after opening the session. This might be why this issue only happens on some distributions (those using /usr/bin/login from util-linux):

See: https://github.com/shadow-maint/shadow/blob/164dcfe65b7e81ce908121711754497c6f05a4f3/src/login.c#L868-L901

Considering we can't rely on having the groups already correct, solution 2 is probably the more reliable one.

@josephlr
Copy link
Member

@Minecrell thank you so much for reporting this, and it's my bad for missing the security implications of this bug. The fix in #103 is similar to your proposed solution 2.

Thanks for the great work in finding this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants