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.

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:

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:

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.

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.

1. If the user belongs to the DANOS superuser level simple return OK.

2. 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.

3. Enter the namespace of the newly created container (nsenter() and chroot()).

4. Stop the container when all sessions are terminated.

Open

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.

Open

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.

Related source code

Shell

https://github.com/danos/opd/blob/master/scripts/bash_completion/vyatta-op

https://github.com/danos/opd/blob/master/scripts/interpreter/vyatta-op-run

https://github.com/danos/vyatta-cfg/blob/master/etc/bash_completion.d/vyatta-cfg

Sandbox

AAA

AAA Plugin Example