\section{Linux Security Modules}
\begin{frame}
   {What are Linux Security Modules?}

   \begin{itemize}
      \item
      An \textbf{LSM} (\textbf{L}inux \textbf{S}ecurity
      \textbf{M}odule) implements \textbf{mandatory access
         controls} on requests made to the kernel.
      \item
      Use of an \textbf{LSM}:

      \begin{itemize}
         \item
         Minimizes changes to the kernel.
         \item
         Minimizes overhead on the kernel.
         \item
         Permits flexibility and choice between different
         implementations, each of which is presented as a
         self-contained \textbf{LSM} (\textbf{L}inux
         \textbf{S}ecurity \textbf{M}odule).
      \end{itemize}
   \end{itemize}

\end{frame}

\cprotect\note{

   A modern computer system must be made secure, but needs
   vary according to sensitivity of data, number of users
   with accounts, exposure to outside networks, legal
   requirements and other factors. Responsibility for
   enabling good security controls falls both on application
   designers and the \textbf{Linux} kernel developers and
   maintainers. Of course users have to follow good
   procedures as well, but on a well run system,
   non-privileged users should have very limited ability to
   expose the system to security violations.  In this section
   we are concerned with how the \textbf{Linux} kernel
   enhances security through the use of the \textbf{Linux
      Security Modules} framework, particularly with the
   deployment of \textbf{SELinux}.

   The basic idea is to \textbf{hook system calls}; insert
   code whenever an application requests a transition to
   kernel (system) mode in order to accomplish work that
   requires enhanced abilities; this code makes sure
   permissions are valid, malicious intent is protected
   against, etc.  It does this by invoking security-related
   functional steps before and/or after a system call is
   fulfilled by the kernel.

}

\begin{frame}
   {Main LSM Choices}
   \begin{itemize}
      \item
      \textbf{SELinux}:
      \url{https://selinuxproject.org/page/Main_Page}
      \item
      \textbf{AppArmor}: \url {https://apparmor.net}
      \item
      \textbf{Smack}: \url{http://schaufler-ca.com}
      \item
      \textbf{TOMOYO}: \url{https://tomoyo.osdn.jp}

      \begin{important}[Use of Simultaneous LSMs]
         Since 2019 it has been possible to combine
         (stack) \textbf{LSM}s in certain specified
         orders.
      \end{important}

      \item
      See
      \url{https://www.starlab.io/blog/a-brief-tour-of-linux-security-modules}
      for a nice review of the mechanism and choices.
   \end{itemize}

\end{frame}

\cprotect\note{

   For a long time the only enhanced security model implemented
   was \textbf{SELinux}.  When the project was first floated
   upstream in 2001 to be included directly in the kernel,
   there were objections about using only one approach to
   enhanced security.

   As a result the \textbf{LSM} approach was adopted where
   alternative modules to \textbf{SELinux} could be used as
   they were developed and was incorporated into the
   \textbf{Linux} kernel in 2003.

   Originally, only one \textbf{LSM} could be used at a time
   as they can potentially modify the same parts of the
   \textbf{Linux} kernel.

   However, it is now possible to stack them with some care.
   \textbf{LSM}s are now considered as either \textbf{major}
   or \textbf{minor} when configuring their combination.

   We will concentrate primarily on \textbf{SELinux} and
   secondarily on \textbf{AppArmor} in order of usage volume.

}
