Add SONiC design doc: TACACS+ improvement

[liuh-80]

Repo	PR title	State
sonic-buildimage	Add plugin support to bash
sonic-buildimage	Extract tacacs support functions into library and fix memory leak issue.
sonic-buildimage	Add Bash TACACS+ plugin for per-command authorization.
sonic-buildimage	Add Config DB schema and HostCfg Enforcer plugin to support TACACS+ per-command authorization&accounting.
sonic-utilities	Add config command for AAA authorization and accounting.
sonic-mgmt	Add TACACS per-command authorization test case.
sonic-buildimage	Add audisp-tacplus for per-command accounting.
sonic-mgmt	Add TACACS per-command accounting test case.
sonic-buildimage	Fix bash build break when re-build bash issue.
sonic-buildimage	fix src\tacacs\bash_tacplus\debian\rules file mode, which cause dirty image version.
sonic-buildimage	Export remote address to environment variable for TACACS authorization.
sonic-buildimage	Send remote address in TACACS+ authorization message.
sonic-buildimage	Fix per-command authorization failed issue when a command with wildcard match more than hundred files.
sonic-buildimage	Fix auditd can't load tacplus plugin issue.

[lguohan]

why rbash is a must for command authorization?

[liuh-80]

The reason is because for command authorization, we create a symbol link for every command we want enable authorization.
Without rbash user can run any command, include those command we not create symbol link.
Then they can bypass the authorization very easy.

[qiluo-msft]

Redirecting

What are the alternatives for user to achieve similar goal? #Closed

[liuh-80]

By patch bash, we can allow user use redirect, will remove this from document.

[qiluo-msft]

Do you have a link to the patch? I am wondering if redirect could be configurable. For example, RW users could use redirect as normal, but RO users are banned to use redirect.

[liuh-80]

It's a very simple code change, remove following code in redir.c line:836

#if defined (RESTRICTED_SHELL)
      if (restricted && (WRITE_REDIRECT (ri)))
{
  free (redirectee_word);
  return (RESTRICTED_REDIRECT);
}
#endif /* RESTRICTED_SHELL */

So for RW allow and RO disable, we can:

1. create a variable isReadonlyUser

2. When bash startup, check current user group and set this variable.

3. If any behavior we want to disable for RO only we can change code like this:

   #if defined (RESTRICTED_SHELL)
   if (restricted && isReadonlyUser && (WRITE_REDIRECT (ri)))
   {
   free (redirectee_word);
   return (RESTRICTED_REDIRECT);
   }
   #endif /* RESTRICTED_SHELL */

[qiluo-msft]

Disable

Disable for RO users are understandable. Is it possible to keep RW users capability at the same time of AAA? #Closed

[liuh-80]

In that case, we need consider some other solution. I will check other solution in POC and update this document.

[liuh-80]

I check some other solution and they are based on shell function hook, those solution have a common limitation: user can bypass restriction by ingest new shell hook.

Then after check the rbash restriction, I think we have 2 solution:

1. Patch bash to allow redirection in restrict mode, and accept most other restriction because those are necessary for use tacplus-auth: those restriction we accept will make both RO/RW user can't access commands not in our white list, and make user can't switch to other shell.

2. Patch bash, so bash can do Authorization before execute any user command.
   With this solution, there is no any restriction in router machine side, in TACACS server side we just need disable user switch to other shell.

I will try a POC for solution 2, it's seems will be a minor change.

[liuh-80]

The POC for solution 2 is ready, which will authorize any user 'disk' command, so if solution 2 is acceptable, will update the document.

For 'disk' command, in bash, if a command is a file stored in disk, it's a disk command. built-in command and bash function are not disk command, executable file and script are disk command.

[qiluo-msft]

clear

clear is part of ncurses-bin. We'd better not to override. #Closed

[liuh-80]

Fixed.

[qiluo-msft]

We have a similar command sonic-clear. ref: https://github.com/Azure/sonic-utilities/blob/888701b67fd4f1cc5b9da534a360048f93f263f4/setup.py#L157

[liuh-80]

Fixed with sonic-clear command, will push update later.

[qiluo-msft]

When remote TACACS server not avaliable

When tacacs server is accessible, do we also use local syslog to account? #WontFix

[liuh-80]

I think it's not necessary.
If tacacs server is accessible, we only put trace log to syslog for metering and debugging.

[qiluo-msft]

I guess your system log == syslog.
Then if the networking is not stable, you will have some random log lines locally, does it help anything?

For login authentication, the log messages always go to local syslog, no matter remote tacacs accessible or not.

[liuh-80]

Document updated.

What I mean here is when the remote TACACS service not accessible, for example TACACS server down after user login, but networking still healthy, then the Authorization and Accounting information will write to syslog. Then the syslog will upload via network later, and those information will not lost.

[qiluo-msft]

3.1

Section numbers are wrong. #Closed

[liu-hua-joe-80]

Fixed.

[qiluo-msft]

can't config to disable 'local' authorization

If tacacs server is not reachable during authorization, we have option to fail the authorization, so local auth is disabled. #Closed

[liu-hua-joe-80]

Fixed.

[qiluo-msft]

My point is that you have 2 options

1. tacacs + local
2. tacacs only, no local
   And this is not a "Operation system limitation".

[liu-hua-joe-80]

Here is a example of this issue:
user name: domainuser
When user login, tacacs return privilege level 0 so in SONiC this user is a RO user, then this user on sonic only have Linux permission to run RO commands.
But in tacacs server side, the 'config' command was config as allow user run.

Then when user trying to run the 'config' command, tacacs authorization succeeded, but user still can't run this command because user not have Linux permission.

In EOS system, the behavior is different:
We add domainuser as local RO user.
In tacacs server config this user can run RW command.
Then we user run a RW command, user can run it.

The reason is the EOS system can bypass the local permission check, but SONiC is a Linux system, and currently we using Linux permission for 'local authorization', so tacacs authorization can't bypass the Linux permission check.

[qiluo-msft]

I see your point!
Actually I am considering another config "tacacs only, no fallback to local", which means tacacs server unreachable, will stop the already-login user to run anything except logout or exit. Then the user need to re-login with local account, local authentication and local authorization.

[jeff-yin]

Should move/add this to the limitations section.
A user can run commands inside a container to evade TACACS authorization and accounting.

It may be good to add a recommendation to administrators to disable access to 'docker exec' for most users.

[liuh-80]

Fixed.

[dgsudharsan]

Is there a way to specify which server is primary in the list of servers?

[liuh-80]

There is no special flag to specify primary server, the first server in the TACACS+ config will will be the primary server.

[seiferteric]

To expand on my comments during the review meeting, here is a list of my concerns, but I don't know how you implemented this patch in bash so some of these concerns may be invalid, so please excuse/ignore them if you have already covered these cases.

Concerns with tacacs+ command authorization:

Cannot limit built-in commands:

• You mention that you cannot limit shell built-ins, but bash has a lot of built-in commands that may allow you to circumvent controls:
  • exec: exec is a built-in command that will execute another process and replace it's own process with the new one. This alone could bypass the authorization.
  • eval: similar to exec
  • alias: can I fool authorization by aliasing an allowed command to a disallowed one?
  • functions: Can a user create a shell function that calls a disallowed command? How about in the users .bashrc, .bash_profile?
  • command: built-in to call another command like: "command /bin/disallowed_command"
  • source or .: sources (runs) a script, will this block disallowed commands?
  • trap: The commands in arg are to be read and executed when the shell receives signal sigspec.

I am not certain how you limit what bash can execute, is it only the top level command, or all sub-commands that a command might run?

• If a user can run a script that uses /bin/sh, can a user not directly run /bin/sh? Or "bash -c /bin/sh"?
• Can a user run the loader directly? Like: /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /bin/sh ?
• Need to disable chroot (should not be a problem) but could be used to trick authorization

Commands that can run other commands:

• Some commands allow the user to run other commands:

  • xargs: reads arguments from stdin and executes command + args
  • find: You may not suspect find command but it has an -exec option to run a command on found files. Not sure if this spawns a sub-shell that will honor the authorization, or forks/exec directly which will not honor authorization.
    Example:

  eric.e.seifert@xenlogin-eqx-04:~/tmp/tmp:$ find . -type f -exec /bin/sh ;
  $ ls
  test
  $ echo $0
  /bin/sh
  $

LD_LIBRARY_PATH LD_PRELOAD:

• These ENV vars can be set to circumvent the use of the installed shared libraries. It could be possible for a user to copy over their own version of libc or any other library that could execute arbitrary commands.

example:
This is just an example using libfakeroot which is harmless, but can demonstrate that you can change library calls with custom loaded libraries. This shows the "whoami" command being tricked to think we are root:

eric.e.seifert@xenlogin-eqx-04:~:$ LD_PRELOAD="/usr/lib/x86_64-linux-gnu/libfakeroot/libfakeroot-0.so /usr/lib/x86_64-linux-gnu/libfakeroot/libfakeroot-sysv.so"  whoami
root
eric.e.seifert@xenlogin-eqx-04:~:$

Prefixes/Quoting:
You can call commands with certain prefixes or quotes:

Example:

admin@sonic:~$ \sh
$
admin@sonic:~$ "sh"
$
admin@sonic:~$ echo `sh -c ls`
docker-sonic-telemetry.gz
admin@sonic:~$ echo $(sh -c ls)
docker-sonic-telemetry.gz

If you are going to go this route, it might be safer/easier to patch glibc execve directly to check user authorization...

[seiferteric]

I wonder if SELinux would be better suited to restrict user commands? Here is some examples: https://access.redhat.com/solutions/65822

[liuh-80]

@seiferteric, Thanks for your comments, about your concern:

1. The reason we doesn't limit built-in commands: in bash, when user run any command stored in disk, the code will go to following method:
   execute_cmd.c

                   /* Call execve (), handling interpreting shell scripts, and handling
             exec failures. */
          int
          shell_execve (command, args, env)
               char *command;
               char **args, **env;
   

   And our patch will work inside this method to check TACACS+ authorization before command been executed.
   Then user cannot use built-in command/function/variable to bypass TACACS+ authorization. So following way to bypass authorization will not work:
   1. Use built-in command to bypass authorization.
   2. Use shell function to bypass authorization.
   3. Use shell variable to bypass authorization.

2. For the bash script authorization, we will only check the script name, and will not check the sub commands inside the script, this may cause potential security issue, so for RO user, administrator should disable user from run any user defined script. and for Admin user, because they already have permission to do anything, so it's not necessary to block them from create/run their scripts.

3. Start another harmless process and run command from it will be a security risk, so administrator should disable RO user from run following commands:
   1. Run another shell.
   2. Run another interpreter command.
   3. Run loader.
   4. Any command can run other commands, for example: find, VI.

I verify following cases with my POC code, and command can be blocked with TACACS+ server side setting:

1. Run script with sh/python or other interpreter.
2. Run find with -exec parameter
3. Run loader
4. Use Prefixes/Quoting to run command.

For the LD_PRELOAD issue, current solution can't block it because this not a command parameter. However this not be a issue because:
For RO user, we tested this trick work with RO user, this have risk but not related with tacacs per-command authorization feature.
Also sonic sudoers file already disable user set LD_PRELOAD environment with sudo command, so this trick not have big impact.
For RW user, they already have permission to do almost all operation, for example create their own script and run it. so this will not be a risk.

[qiluo-msft]

local | tacacs

In below sectin, you support combined local | tacacs, which is different from this syntax. #Closed

[liuh-80]

Will change to config aaa authorization {local | tacacs+ | local tacacs+}

[liuh-80]

Fixed.

[qiluo-msft]

config AAA authorization with TACACS+ only

This a very practical work flow. Normally users found tacacs user could run nothing, they will logout and login with local account, and run command as local authorization, and even tacacs server recovered then, it does not impact local user command authorization. #Closed

[liuh-80]

config AAA authorization with TACACS+ and local, but server not accessible:

Add this step: when remote tacacs accessible, local user still can run command. doesn't impact local user authorization.

Check if we have PR cover this: when tacacs accessible, local can't login.

[qiluo-msft]

Discuss offline, and you will add some step in another test case below.

[liuh-80]

Fixed.

[qiluo-msft]

server accessible

Do you mean "server becomes accessible" #Closed

[liuh-80]

Fixed. also update AAA table schema according to current SONiC yang model.

[qiluo-msft]

Only minor word issue.

[zhangyanzhao]

Please link the code PR by referring to this example #806

[zhangyanzhao]

@liuh-80 please update this PR to add the code PRs with example of #806. Thanks.