github.com/aporeto-inc/trireme-lib@v10.358.0+incompatible/docs/linux_processes.md (about)

     1  # Trireme and Linux Processes
     2  
     3  The goal of Trireme is to assign an identity with every application and use this
     4  identity to transparently insert authentication and authorization in any communication.
     5  The Trireme library has been designed to support both containers as well as any
     6  application supporting linux processes.
     7  
     8  In this document we will describe how one can use Trireme with Linux processes
     9  and what are the underlying mechanisms used by the library.
    10  
    11  Essentially, Trireme allows you to introduce end-to-end authentication and
    12  authorization between any two Linux processes without ever touching the
    13  process. Through this mechanism you can achieve detailed access control
    14  in your Linux environment without the need for firewall rules, ACLs,
    15  and a complex infrastructure.
    16  
    17  # TL;DR - Show me how
    18  
    19  In order to illustrate how to use Trireme with Linux processes we will use
    20  the Trireme example with default settings.
    21  
    22  1. Download and build trireme-example from https://go.aporeto.io/trireme-example
    23     Follow the instructions in the Readme file and make sure all the dependencies
    24     are installed in your system.
    25  
    26  2. Start trireme-example in one window
    27  ```bash
    28  % sudo trireme-example daemon --hybrid
    29  ```
    30  The above command will start the Trireme daemon supporting both Linux Processes
    31  and docker containers and basic PSK authentication. You will be able to see
    32  all the Trireme messages in the window.
    33  
    34  3. In a different window start an nginx server protected by Trireme
    35  ```bash
    36  % sudo trireme-example run --ports=80 --label=app=web nginx
    37  ```
    38  Note, that we use sudo for this since nginx requires root access by default. The
    39  additional parameters are:
    40  - Nginx will be listening on port 80
    41  - The label app=web will be attached to the nginx service.
    42  
    43  4. Try to access the nginx server with a standard curl command
    44  ```bash
    45  % curl http://127.0.0.1
    46  ```
    47  You will see that the curl command fails to connect to the nginx server, even
    48  though the server is running and listening on port 80.
    49  
    50  5. Run a curl command with a Trireme identity so that it can actually access
    51  the server:
    52  ```bash
    53  % trireme-example run --label=app=web curl -- http://127.0.0.1
    54  ```
    55  In this case your curl command will succeed.
    56  
    57  6. Let's run now a bash shell in the Trireme context
    58  ```bash
    59  % trireme-example run --label=app=web /bin/bash
    60  ```
    61  We essentially started just a standard bash shell within the Trireme context
    62  and protected by Trireme. In this case our bash shell can actually access the
    63  nginx server. A simple curl will succeed.
    64  ```bash
    65  curl http://127.0.0.1
    66  ```
    67  
    68  ## What did we do?
    69  
    70  We started the Trireme daemon and started an nginx server protected by Trireme. By
    71  default only authorized traffic will be able to ever reach this nginx server
    72  at this point. Even processes in the same host will be unable to reach the
    73  server, unless they are also started with Trireme and they are protected by
    74  the same authorization framework.
    75  
    76  Trireme allows us very easily to introduce authorization to
    77  any process in the Linux subsystem within the same host or across hosts over
    78  the network.
    79  
    80  # Trireme and Linux Processes
    81  
    82  In this section we will describe how Trireme introduces the transparent authorization
    83  for every Linux Process. This has several use cases that we will illustrate
    84  in some subsequent blogs. Some examples are:
    85  
    86  1. Separate Linux users in different authorization contexts and allow them only
    87  specific access to network resources.
    88  2. Isolate important applications like databases from the network and restrict
    89  access to authorized sources only.
    90  3. Isolate the sshd daemon and allow access only to management tool like
    91  Ansible to ssh into the machine.
    92  4. Restrict communication between processes based on libraries, checksums on
    93  executables, SELinux labels or other structures.
    94  
    95  ## The forgotten cgroup : net_cls
    96  
    97  For several reasons the Linux kernel does not have an easy method to differentiate
    98  traffic based on the source or destination process. However, it has a very
    99  important facility that is not very well documented, but very useful. One
   100  of the cgroup controllers is known as net_cls. When a process is associated with
   101  this controller, the Linux kernel will mark all packets initiated by a process
   102  with a mark that is set in the configuration of the net_cls cgroup. For example,
   103  in a standard Ubuntu distribution you can see the mark in
   104  /sys/fs/cgroup/net_cls/net_cls.classid. The standard value there is 0, indicating
   105  that there is essentially no mark placed on the packets.
   106  
   107  In the case of Trireme, you will find a trireme directory under this controller
   108  in /sys/fs/cgroup/net_cls/trireme and Trireme will create a sub-directory there
   109  for every process that is protected by Trireme. Let us assume that the nginx
   110  process above had a process ID of 100. Then Trireme will create the directory
   111  /sys/fs/cgroup/net_cls/trireme/100 and it will populate the net_cls.classid
   112  file there with a mark value. For example 100.
   113  
   114  Once Trireme does that, it means that all packets out of the nginx server or any
   115  of its children will be marked with the same mark. We cannot apply the Trireme
   116  ACLs that capture Syn/SynAck traffic only on packets with this mark. As a result,
   117  we can apply policy to a specific Linux processes and not just a container.
   118  
   119  Of course we need some more work. Eventually the process will die and we need
   120  to clean up. Fortunately, there is a kernel  facility for that. The file
   121  /sys/fs/cgroup/net_cls/trireme/100/notify_on_release is populated with 1, meaning
   122  that the kernel should notify a release agent that there are no more processes
   123  associated with the particular cgroup. The file /sys/fs/cgroup/net_cls/release_agent
   124  identifies the binary that should be executed when such an event happens.
   125  
   126  We can now put all the parts together.
   127  1. The trireme-example command sends an
   128  RPC message to the Trireme daemon requesting to run a process in the Trireme
   129  context.
   130  2. The daemon resolves the policy for the requested command and populates
   131  the right fields in the net_cls file structures.
   132  3. It then does a simple exec and release command to the requested process.
   133  4. When the process dies, the release_agent notifies the Trireme daemon about
   134  the event, and the Trireme daemon cleans up the state.
   135  
   136  ## Metadata Extractor and Linux Processes
   137  
   138  One of the most powerful features of the Trireme approach is the metadata extractor.
   139  In the above example we used a simple method where the labels that are forming
   140  the identity are provided by the user. However, these are not the only attributes
   141  that Trireme identifies and it can be extended to actually associate any attribute
   142  with this identity model.
   143  
   144  By default the metadata extractor will capture the following information:
   145  - Md5 checksum of the binary that is executed.
   146  - Library dependencies of the binary
   147  - User ID
   148  - Group ID
   149  - Executable path
   150  
   151  The result is that a user can define an authorization policy across any of these
   152  attributes. For example, you can define a policy that only a binary with a specific
   153  checksum can access a database. Or that only a process with a given User ID can
   154  access an application. Or that users with sudo capability can never talk to the
   155  Internet.
   156  
   157  One can enhance this metadata extractor with additional sources. For example in
   158  an AWS environment, the ami ID, VPC ID, subnet, SELinux/AppArmor labels and so on.
   159  The possibilities are unlimited.
   160  
   161  By associating custom and system metadata with a process, Trireme allows
   162  you to create a "contextual identity" for every Linux process. You can then
   163  use this identity to control access over the network without worrying about IP
   164  addresses and port numbers. It is the identity that matters.