2

(Developer here - relative novice in the sysadmin world).

Does anyone know of a way that files can be restricted (no read, write, or execute access) from the sudo user?

A little background on the situation: We're currently searching for a way to provide sudo access to some users while still restricting access to a set of files. Unless this is accomplished, sudo access will not be an option, and we will instead whitelist files/commands (or wrap them in a script) as necessary in response to user requests.

As you might expect, the whitelist option would require a great deal more upkeep and delay as users wait for the sysadmin team to respond to requests.

5

The way I usually implement this kind of restrictions requires that several conditions are met, otherwise the restrictions can be easily circumvented:

  • The user does not belong to the wheel group, the only one authorized to use su (enforced via PAM).
  • The user is given a properly secured rbash with a read-only PATH pointing to a private ~/bin, this ~/bin/ directory contains links to simple utilities:

    $ 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 user is given a restricted, read-only environment (think of stuff like LESSSECURE, TMOUT, HISTFILE variables).

  • optionally, the user is mapped to the SELinux user staff_u and given rights to execute commands as other user as required via sudo.
  • the user's /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
    

    Also, /etc/security/namespace.init makes all skeletal files readonly for the user and owned by root.

This way you can choose whether $USER can execute any command on his/her 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.

With regards to "access to a set of files", you don't specify whether it's read-only or read-write access.

In any case, this can be set up through sudo rules. I would implement rules to grant read-only access to files via rview and read-write via rvim, the latter normally being configured using the editor directive in your sudoers file:

Defaults editor=/usr/bin/rvim

So users can sudoedit allowed files.

This solution can be fairly easily implemented using your configuration management tool of choice.

New commands can be added to the private ~/bin directory very quickly (since they are just symlinks managed from the namespacing logic). New sudo rules can also be managed the same way.

  • Thanks for the response (and sorry it took me so long to reply)! I'll pass this along to my sysadmin team and see what we can do. – Jeff Levine Jan 18 '17 at 10:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.