TACACS+ server authorization issues: Authentication is functioning correctly, but I’m encountering challenges in enabling shell command authorization

Question

I have established a TACACS+ server and a PAM TACACS client using the resources available here. I am using TACACS+ to authenticate Linux users using pam_tacplus.so.

Upon user SSH access to the TACACS client machine (Ubuntu 18.04), my objective is to authenticate users through the TACACS+ server and permit the execution of only those commands in the shell that are sanctioned within the TACACS+ server configuration.

Although authentication is functioning correctly, I am encountering challenges in enabling shell command authorization.

This is the tacacs+ server config in /etc/tacacs+/tac_plus.conf:

group = admingroup {
    default service = permit
    service = exec {
        priv-lvl = 12
    }
}
user = test {
    member = admingroup
    global = cleartext "12345"
}
user = test_user {
    global = cleartext "12345"
    cmd = ls {
        permit .*
    }
}

I have also created a local user on the client machine with same username as in the server config.

In the PAM sshd module present in /etc/pam.d I have added:

auth sufficient /lib/security/pam_tacplus.so debug server=192.168.95.161 secret=test_123 service=system protocol=tcp
account sufficient /lib/security/pam_tacplus.so debug server=192.168.95.161 secret=test_123 service=system protocol=tcp
session sufficient /lib/security/pam_tacplus.so debug server=192.168.95.161 secret=test_123 service=system protocol=tcp

In the TACACS+ config, I have allowed test_user can execute only ls command, but all commands can be executed. The client doesn't seem to authorize permitted commands from the server.

Is there any way to implement authorization and accounting through TACACS+?

Answer 1

PAM authentication happens in the level of sessions to specific services, not on individual shell commands. Once the user has been authorized to use a SSH login service, individual commands are not restricted by PAM.

In fact, a PAM module cannot check individual commands, because PAM works during the login/logout process only: at that time, you have not yet specified any commands, so the only way restriction by individual commands could happen would be if PAM could get the list of allowed commands from the TACACS+ server and hand it to the user's shell process. Howewer, this fails for multiple reasons:

• There is no common API in Unix-style shells that could be used by PAM for passing information on such restrictions to the shell.
• In the classic Unix security model, the shell is not expected to be the enforcer of restrictions for regular users in the first place; that's kernel's job. (In a normal Unix-style system, a user might be able to build a custom shell binary for themselves and execute it, and would still be restricted by kernel-enforced file permissions and resource limits tied to their user account and group memberships.)

Note that the Github page for pam_tacplus says:

Limitations:

• only subset of TACACS+ protocol is supported; it's enough for most need, though

A normal shell (such as bash) won't check with an external authentication server before deciding whether to allow a command to be executed or not. While it would be possible to create a shell that would query an authentication server for every command, I don't know of a shell that would check for a TACACS+ authorization for every command entered.

The bash shell actually does have a restricted mode that might be similar to what you're looking for; however, the restrictions can only be configured locally, not by a TACACS+ server.

Also note that such a restricted shell must implement a pretty severe set of restrictions in order to be at all effective: no cd command, no command names containing slashes, no piping/redirection, etc. In addition, deciding the set of allowed commands is a non-trivial task: you would need to study the full functionality of each command you plan to allow, to ensure it does not contain a possibility to start an unrestricted subshell, or otherwise escape the restrictions.

For these reasons, restricted shells tend to be awkward to set up and use for any non-trivial tasks, and other means like chroot jails might be used instead for situations where the user needs shell access but must be restricted to a particular part of the system.