DANOS has a unique approach to command modeling, command execution and AAA. This document describes the interaction of the major components involved in making this work.

Shell

The DANOS system's shell is built in an unconventional way for a NOS shell. The shell is a standard Bash shell with a customized completion environment and aliases created to invoke custom top level commands. These commands are rendered from the opd and configd processes in the respective shell mode.

admin@vyatta:~$ <tab>
Possible completions:
  add         Add an object to a service
  clear       Clear system information
  clone       Clone an object
  configure   Enter configure mode
  copy        Copy an object
  delete      Delete an object
  generate    Generate an object
  monitor     Monitor system information
  mtrace      Show multicast path in ASCII graphic format
  ping        Send Internet Control Message Protocol (ICMP) echo request
  poweroff    Poweroff the system
  reboot      Reboot the system
  release     Release specified variable
  rename      Rename an object
  renew       Renew specified variable
  request     Request an operation be performed
  reset       Reset a service
  restart     Restart a service
  set         Set operational options
  show        Show system information
  spawn       Spawn a native Linux process
  ssh         Start a remote Secure Shell (SSH) connection.
  start       Start a service
  telnet      Telnet to a node
  traceroute  Track network path to node
  twping      Calculate stats using Two-Way Active Measurement Protocol (TWAMP)
  update      Update data for a service

This shell is capable of running the "modeled" NOS commands at the same time as standard Linux commands. This provides users with a fully featured, robust command execution environment, standard Linux filter tools and access to the NOS's modeled information.

Example:

vyatta@vyatta:~$ show ip route  | grep 0.0.0.0/0
K>* 0.0.0.0/0 [0/1] via 192.168.178.2, dp0p33p1, 1d00h03m

More advanced example, suppose we want to delete all references to the interface dp0p33p1 in a configuration. The following pipeline will do that for us:

[edit]
vyatta@vyatta# eval $(run show configuration commands | grep dp0p33p1 | sed s/set/delete/)
[edit]
vyatta@vyatta# compare
[edit interfaces dataplane dp0p33p1]
-address dhcp
[edit]
vyatta@vyatta#

User Sandbox

Building a shell this way, however, presents a problem for systems deployed in environments that require AAA. For AAA to work properly any system effecting command must be authorized and accounted for. We can't do this for all commands in a standard Bash shell, the hooks simply do not exist.

To address this, the normal users in DANOS are dropped into a sandbox environment. This sandbox contains the customized Bash environment, coreutils (grep, awk, sed, etc.), the DANOS command interpreter programs, and any dependencies of these packages. Bind mounted in this environment are the sockets to the DANOS trusted entry point applications configd and opd. These entry point sockets are the only way for the sandbox to affect changes in the underlying DANOS environment. We take the approach that only the commands that touch the base system need to be authorized and accounted for, and thus we only need to do this at the trusted entry point to the base system from the sandbox.

The superuser class of users doesn't get sandboxed and is logged directly into the underlying environment. They have the full power of the DANOS bash environment and any additional Linux tool to debug or change the system. These users are expected to only be used as a last resort in emergency situations where AAA is likely not available anyway and therefore we only do AAA on the modeled commands for these users.

To create the sandbox DANOS uses the Pluggable Authentication Module (PAM) for the user authentication, accounting, and session creation. During session creation, the sandbox is created if appropriate.

The user sandbox solution introduces a new PAM module that switches the login process and any of its descendant processes into the desired sandbox.

If the user belongs to the DANOS superuser level simple return OK.
Otherwise, set up a sandboxed container if one isn't currently running for this user using a pre-populated read-only root directory and private MOUNT and PID and NET namespaces. Use bind mounts for configd and opd sockets, users home directory etc. This is mostly done using systemd-nspawn/machinectl.
Enter the namespace of the newly created container (nsenter() and chroot()).
Stop the container when all sessions are terminated.

AAA

AAA in the DANOS system is based on the Linux audit infrastructure. The "loginuid" for a process is used as the user's identity when consulting a AAA ruleset. The "loginuid" for a connection to one of the entry point applications is read when the connection is established. This is done as a three step lookup, first we read the PID of the connecting process, then the "loginuid" of that PID is looked up in the "/proc" filesystem, finally the groups associated with that PID are looked up via the NSS lookup routines. This is used as the AAA context for the connection to these entry points.

The Authentication part of AAA is done using the standard Linux login process via PAM. When creating new authentication mechanisms one should consider using SSSD as an implementation frontend as this is in use for existing AAA plugins.

The Authorization part of AAA is done via a plugin infrastructure that the entry point applications support. Both command based authorization and modeled data path based authorization are supported. By default authorization is done via a configurable on box ruleset using path based authorization. Plugins for command authorization can be created and TACACS+ is supplied in the standard distribution.

The Accounting part of AAA is also done via the plugin infrastructure to the entry point applications. Both command based accounting and modeled data path based accounting are supported. By default command accounting accountinggoes to the kernel's audit subsystem and to the system's journal. Plugins for command accounting can be created and TACACS+ is supplied in the standard distribution.

The DANOS distribution provides local logins and TACACS+ as builtin AAA providers.

System Defined Groups

DANOS defines several groups that are treated specially to give users particular permissions

vyattaop – Represent "operator" class users
vyattaadm – Represent "admin" class users
vyattasu – Represent "superuser" class users
secrets – Users that may view the YANG values that are marked with the "configd:secret true" extension.