Home / server / Questions / 589813
Accepted
Rooster
Asked: 2014-04-18 10:15:24 +0800 CST

build user chroot on first login

  • 772

I'm using ldap for remote user authentication and I basically need to either figure out how to:

a. chroot a user on machine b from machine a via nfs,(which doesn't seem possible without mounting more directories than I'm comfortable with)

or -------

b. After adding a user to the ldap db on machine a, force a script to be executed on machine b during the users login that will auto chroot the user before they are allowed to do anything upon their first login.

I'm thinking my second option is probably the best bet, and was thinking along the lines of using pam_exec.so to call the script. However, I have a few concerns about this approach. First, I'm not sure if the script that will be run will have root permissions which it will need to perform the chroot. Second, I'm not sure if pam_exec happens early enough in the login process to be an effective option. Lastly, I need to make sure that the code works in both pam.d/ssh and pam.d/su to consider it a valid solution.

Are my concerns valid or does it seem like this would be a good solution? Or is there a better approach to this problem.

linux

1 Answers

  1. Best Answer

    First of all, arguably, chroot might not be considered a security feature. There are opinions in the other direction, as well.

    Arguably, what you need to implement is a reproducible, auditable method of limiting the ability of the user to perform actions other than the strictly allowed.

    If you register your users in LDAP, surely you have already deployed the mechanisms to perform LDAP authentication on any machine connected to this LDAP, be it by means of sssd or using any other PAM module, it is not relevant to the rest of the solution, and is assumed to be already in place (in my case, I'm using freeIPA and sssd).

    To implement this scenario, what I currently do is the following (be aware that this kind of restrictions requires that several conditions are met, otherwise the restriction can be easily circumvented):

    • The users do not belong to the wheel group, the only one authorized to use su (enforced via PAM). Usually, a non-LDAP user (sysadm) exists to allow trusted administrators performing actions in cases of disaster recovery or LDAP unavailability.

    • The users are given a properly secured rbash with a read-only PATH pointing to a private ~/bin, this ~/bin/ directory contains links to all allowed commands, for example:

      $ ll ~/bin
total 0
lrwxrwxrwx. 1 root dawud 14 Sep 17 08:58 clear -> /usr/bin/clear*
lrwxrwxrwx. 1 root dawud  7 Sep 17 08:58 df -> /bin/df*
lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 egrep -> /bin/egrep*
lrwxrwxrwx. 1 root dawud  8 Sep 17 08:58 env -> /bin/env*
lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 fgrep -> /bin/fgrep*
lrwxrwxrwx. 1 root dawud  9 Sep 17 08:58 grep -> /bin/grep*
lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 rview -> /bin/rview*
lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 rvim -> /usr/bin/rvim*
lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 sudo -> /usr/bin/sudo*
lrwxrwxrwx. 1 root dawud 17 Sep 17 08:58 sudoedit -> /usr/bin/sudoedit*
lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 tail -> /usr/bin/tail*
lrwxrwxrwx. 1 root dawud 11 Sep 17 08:58 wc -> /usr/bin/wc*

    • the users are given a restricted, read-only environment (think of stuff like LESSSECURE, TMOUT, HISTFILE variables). This is to avoid shell escapes from commands like less or vim.

    • if MAC restrictions are in place (the specific GNU/Linux distribution you are using has SELinux enabled), the users are mapped to the SELinux user staff_u and given rights to execute commands as other user as required via sudo. The specific sudorules allowed need to be carefully reviewed to prevent the user from circumventing these limitations, and can also be deployed in your existing LDAP infrastructure (this is one of freeIPA features).

    • the users' /home, /tmp and possibly /var/tmp are polyinstantiated via /etc/security/namespace.conf:

      /tmp       /tmp/.inst/tmp.inst-$USER-     tmpdir:create   root
/var/tmp   /tmp/.inst/var-tmp.inst-$USER- tmpdir:create   root
$HOME      $HOME/$USER.inst/              tmpdir:create   root

      Polyinstantiation of directories is not a new feature, it has been available for quite a long time now. As a reference, see this article from 2006. As a matter of fact, a lot of modules already use pam_namespace by default, but the default configuration at /etc/security/namespace.conf does not enable polyinstantiation. Also, /etc/security/namespace.init should make all skeletal files read-only for the users and owned by root.

    This way you can choose whether the users can execute any command on their own behalf (via a link in the private ~/bin directory, provisioned via /etc/skel, as explained above), on behalf of other user (via sudo) or none at all.

    • 3