My topic for today's presentation is learning security module, looking into the learning security module. So to start with the topic, let me introduce myself. I myself is one of them. I've been working as of architect and co-founder of Prasma Systems. I also have been engaged with Learning Foundation for Linux trainings in India. My main focus is in development of system software for Linux and embedded systems, like in warm and product development or embedded systems and network service systems, and enjoy development and training Linux systems and device drivers using the latest tools and methods. So the agenda for today's topic is to get into the understanding of learning security modules starting with an interaction, then digging deeper into its architecture and seeing how it is integrated with the Linux kernel and what are the different security modules that are present in the Linux kernel currently. So let's understand why security module support is needed inside the kernel. So as we are aware, security is chronic and growing problem as more and more systems are getting connected and online and the motivation to attack arises. Linux is not immune to this threat. Linux systems do experience a large number of vulnerabilities and one of the important way to mitigate the software boundaries by using an effective access control policies and methods that Linux security seems to solve this problem by providing a general framework to incorporate the security policies. So we're going to understand and learn as the Linux framework, its architecture and the existing implementation. So let's start with the Linux security module introduction. What is Linux security module? It's a framework integrated into the kernel to provide necessary components to implement mandatory access control without a need to change the kernel every time. And application wireless thing has been proven as one of the most effective way to mitigate the cyber iteration attacks and a convenient way to implement this practice is used by making use of a Linux security module. So what exactly is Linux security module? It's a code combined into the kernel. It uses the LSD framework. Now this LSD framework itself is intended to allow modules to lock down the system by inserting checks whenever the kernel is about to do something. This module hooks into the checkpoints and for each operation checks whether a particular operation is allowed or to be denied by the security policies that are currently being enforced. This Linux framework allows, can access or allow the deny, can deny the access to the important kernel objects such as inodes, file structures, data structures and prediction and inter-process communication objects. So to move ahead, let's understand that the Linux security modules, they are being categorized as major islands and minor islands. Major islands are particularly being used to implement the mandatory access control They mostly have the configuration policies that have been loaded from the user space applications and at the time only a single major alism has been, has to be enabled inside the kernel and as they supposed to have an exclusive control over all the security contexts. And the very common example of major alisms are as you're learning SMAC, APR and TAMOIA. And on top of major alisms and other alisms, minor alisms can be stacked. They are particularly being implemented to provide a particular type of security functionality and they are stopped on top of major alisms and full less security context as compared to major alisms. And basically, they are being configured or enabled by making use of some configuration flags as opposed to having as configuration policies that are loaded from the application space. And the examples of minor alisms are YAMA, LoadPen, SatsipID and Lockdown. Now let's look at the overall architecture of Alism framework. So Alism framework provides modular architecture whereby providing hooks inside the kernel and allowing the security modules to be installed and enforcing the access control policies. Now in this diagram we say that the security module has been part of the kernel is integrated with the security framework and the security policies are been loaded from the user space application with the help of some security utilities. And based on the security policies, utility policies that are been loaded, the security module takes the decision. So now going ahead looking at the architecture of Alism. Alism framework allows the third party access control mechanism to be linked into the kernel and allow it to modify the default discrete access implementation. By default, the framework itself does not provide any security, but it provides the infrastructure to support the security modules. So what does the Alism framework provides? It provides security fields, basically those are white pointers inside the various data kernel data structures and it provides the functionality to insert calls to the book functions at a critical point inside the kernel code to manage that security fields and to perform the actual access control. And besides that, it also provides some miscellaneous functions to register and unregister the security modules. So basically what are the Alism hooks? Alism hooks helps to mediate various operations in the kernel. These hooks invoke functions defined by the chosen modules and they construct authorization queries that are passed to the modules. The function can be overwritten by the security module to manage security fields and mediate their access to the various kernel objects. So other than the hope for the main component of the security module is the security data fields. Now these security data fields, they are being added into various kernel data structures. Those are important kernel data structures and with the help of the security data fields, the security information can be stored and being mediated through the security modules. So Alism Frame enables security modules to associate this information to the kernel objects and they extend the sensitive data types and basically they are opening white data pointers and they are not even managed by the security modules. Now these are the different kernel optics where the security data fields are being present. And as we are talking about the security inside the kernel, the various kernel optics like the kernel objects for process management and program management are like the structure and Linux bin binary program which holds the security data fields. Similarly, the security data fields are also being present in the file system where the security tracing can be. Access control can be managed for file system using the data structures as superblock file structure and the INO structure. Similarly, the security data fields are also being present for networking subsystem inside the packet and network device like the data structure socket buffer which encapsulates the IP packet and the network structure that represents the network device. So the security fields are part of this data structure. Similarly, the security fields are being added into the system V IPC mechanism and some of the data structures is gone IPC bar and message. So here this is just to give an example how the security fields are part of the different kernel objects. So you see the example of file that I know and this superblock. So now once we know that the Linux security module consists of the security hooks and the security data fields, now we'll look at the data structures that used to keep track of the various LSMs and how the function hooks are to be implemented and how they will be called at the various kernel critical code path. So these are some of the main data structures used by this LSM framework. So one of the important data structure is the security hook list structure which means the list of security hook structure itself and stores the information of the LSMs added into the system, the various LSMs that are added into the system. Now each of the LSM provides the set of hook functions. So these functions are being maintained and taken care by the data structure that is a union of security list options. So this data structure is a union function point of security hooks defined for that particular LSM and which are called at various critical paths inside the kernel code. Now once we have defined the various hooks for the particular LSM, we need a mechanism through which this hooks will be called and there has to be some way when there are multiple LSMs being stacked upon each other and for that purpose we have this data structure called a security hook ads which contains the heads of the link list corresponding to each hook and which helps this, this helps for allowing the execution of the hooks in a particular right order when respecting the stacking property of the LSM. So here in this case like if you look back and look into the kernel 3, so here in this case I have a kernel for 5.6 to 14. This is the header file LSM hook stop ad where all these data structures are being defined. So here in this case when you look at the cluster data structure that is security hook list, data structure which holds the list for all the LSMs that are being defined. Similarly we have this, the main data structure is the options data structure which contains the hooks that are to be called at the various kernel code paths based on the different kernel objects that it is referring to such as like file system or networking or IPC mechanism that has been used. So here we say that these are the different, it's a union of function pointers. We'll go into the details as we move ahead with this presentation. So this is to give a little bit snippet of security in this options hooks and this code snippet what you see is some of the function pointers defined for particular kernel operations such as creation of a directory by this function pointer path underscore main directory. Then there is a path underscore RM directory to this hook will be called at a point where the directory has been removed. Then there is a hook for file open whenever file operation open operation happens then in the kernel code path when the file open operation is happening this hook is getting called. Then there is hook for IE node creation, socket creation, task allocation and IPC. So these are some of the operations, some of the hooks that are been defined as part of this data structure as you see to provide the security hooks inside the kernel code. So to give more clarification on this Alison folks, they are mostly been defined to return an integer value and some of them might return a white. So whenever there is an integer value and value zero is basically been used to give an authorization that the access is been allowed. And in either wise case it might return an error condition such as access denied by the security policy or privileges not being present for the action or might be some memory allocation issue. Now when you're talking of the folks, there are like two types of folks. One is object based folks and another is like path based. So when we talk of object based folks, those are like they operate on the data structures like IE nodes, files or sockets and authorization will be based on this object attributes whereas other types of folks they are based on the parts. And to talk more about security data fields, this is like it is a functionality provided by the Alison framework which allows for enabling special fields located in this data structure, various data structures and reserved for use for security modules and usually they ends with the underscore suffix and allows for maintaining a context between different folks. And they are basically been used by the major Alison's and minor Alison to not use the security first. So other functionality being provided by the Alison framework is like they also provide the auditing functionality which provides Alison and wait for generating log files and also have an interface for creation of sort of file system which can be used to interact with the user space application and for loading and editing some access rules and policies for that particular Alison's. So now as we have looked into the data structures that represents the Alison framework, now let's look at how Alison has integrated into the Linux kernel and for enabling the Linux security module inside the kernel there are some of the places where we need to take a look at. One is the kernel configuration which defines the security module policies, not policies but the behavior of that security module and how it has been controlled during the kernel building process as well as when the security module has been enabled and the kernel is up and running. And other than that they'll have the make files which to integrate the Alison code and get compiled inside the kernel based on the kernel configurations and there might be need based on for the basic security module code and then which so as to integrate with the Linux framework. So we'll see one by one what these things so here in this case Alison kernel configuration one of the very basic kernel configuration that is config default configuration kernel config needed to be selected at the boot time so if you want suppose if you are working with a Yama security module so here in this case we see that this config security Yama has been defined in this directory security like we can go back so security there will be Yama name directory and here in this case the config has the kernel configuration defined for security and as we see this by default the security is by default it is movements it will not be built as part of the kernel so when we are building the kernel configuration we have to select this functionality so that it is enabled inside the kernel and it also holds the information like what it is dependent on and various other stuff. So once the kernel configuration has been done the make file is the part that will include the instruction to get that security module code integrated into the kernel and then we see like how the integration happens with the kernel. The major Alison framework code is contained in the security directory particularly security.c5 and it has the lsm framework initialization code which calls the security unit functions and this security function does the work of enabling the Alison framework and loading the security modules in the order like capability module then minor modules and the major modules so now here in this case the basic capabilities as part of the discrete access control and extended security is being compiled as the security capability module which gets loaded at the very first time first module then the minor alasms and the major alasms. Now whenever a security module is being unable it has to be registered with the kernel and that is done with the help of this API called as security ad books which registers this particular alasms inside with the kernel. Now here in this case we see the example of yeah my alasms where it is calling security ad books and the parameters that are passed to this is the area of security hopefully structure and the size of that area. So like if you go back into the current code and look at function it passes it takes this parameter this is nothing but an area of security populist which defines the various functions. These security lists for structures defines the all this different hopes. So here in this case like let's look at how this linking of hopes is used for help for taking care of the stacking of alasms. The mechanism is used for every single hope defined by the alasms it is created into the Linux kernel and enable. So the security ad book function is then expected to correctly link all the security list structures. Yeah security hopeless structures. So this way it helps to obtain one link list for alasms and one link list for hope provided by the alasms. So here in this case now what happens like with the help of the security ad books what we are doing here we are registering a set of functions. For the Yammer module so and then this security hopes will be called from various kernel code path whenever a particular functionality is being exposed. So to get these books being called the kernel how the kernel let's look at how the current calls this alasms books. Now kernel functions that contains the alasms books call the related hook wrapper functions and this wrapper functions they are being defined in security doc c. And then the secure wrapper functions goes and in turn calls either of these two functions that is called in integer hope are called white book. As we have seen previously that the hooks might return and integer value are wide value. So based on that the hooks are being defined. So for instance for Yammer P trace trace me hope which corresponds to P trace trace me current function which is defined in this kernel P trace doc c. So we see that this P trace trace me call security P trace trace me function. So if you go back. So here in this case we are talking about a P trace function which is called from the P trace system call. So here what this P trace system call it is calling the function that is security trace which is defined in security doc c. And this security P trace trace me in turn goes and calls in it calls in it hope function. And that is the hook function is the trace P trace trace me which we have seen as a different as big defined in the Yammer. Yammer as a module. So this is the function that eventually gets called and in that workflow from the kernel function. So we see that the call to car or security P trace defined defined in security doc c calls this in it hope and eventually it will go and call the actual P trace hope defined by Yammer as module. So these calls calls like hoops like all in it hope are called wild hood simply iterate over the link list corresponding to the hoops. Hoops calls define the security modules that are unable on the running system. So this is the definition of this these two macros where it goes and iterates for the books that have been defined for that. All the lessons that have been enabled on the running system. So in case of the books that are returning the integer value the iteration is interrupted if either the book returns a non zero value. But there by satisfying the cannot override the dinner and rule as such. Okay, and by providing limits to the standard API of policy enforcement and elephant ensures to enable the widespread deployment of security hardening of systems. So now let's look at the school flow of security with the help of open system. How the open system called encounters the LSM folks and based on the policy mistakes with decision whether the system call has been allowed or it is to be denied. Okay. So here in this case, the LSM framework integrated into the kernel provides each LSM framework with the folks as we have seen and the previous slides and from the diagram that shows the flow flow of the open system. Now, usually the process in the user space makes an open system call on the file path the system call is dispatched and the path string is used to obtain the kernel object such as file object and I know object corresponding to that file. And if the parameters are incorrect, then error is written. Otherwise, a normal discreet access control file permissions are checked. And if the permissions are not does not match then an error is returned to the user application. But if the discreet access control is satisfied that the LSM framework act on the file, act on each of the file open folks for the LSMs unable. So here in this game, we see that there's an opening board and we also seen that there is corresponding file open hope present. So that is file open hope gets called at this at this point after the discreet access control checks are being passed. So what this file open hope will do is like based on the policies, whether it will check whether the access has to be granted or not. And if the access is not to be granted on it will return a particular return the error to the application. And finally, if all the security checks are passed, the file is open for the process and a new file descriptor is returned to the user space. So here based on the policies that have been loaded from the user applications user space programs, it will take the decision, whether the access to be granted or not. And then if the access will be granted. It will be the file will open on the descriptor file script open file script return to the application. So this, this is how like each of this books takes the decision based on the policies that have been enforced. So now let's look at the various books that are present that are being defined in that union structure which holds the function pointers for the various books. So I will look at the various data structures and the subsystems that where the books are being integrated into the kernel for parts. Okay, so for file system books, the BFS defines the some of the primary data structures like super blog data structure file and object I know data structures. So each of these structures holds the security information and there are set of function pointers or books been defined that operate on this data structures. Okay. And this is interface is perfect place for all of them to mediate the system access. So let's look at some of the books that are used to mediate the super blog or accesses. So super blog, this data structure is used while mounting and unmounting the file system or obtaining the file system statics. And there are some, some couple of books that are being used for operating on this super blog data structures such as like whenever the file system is to be mounted. Then the book called as as we mount will be called. Similarly, when the file system is unmounted, there is a corresponding book called as the unmount book to check the permissions while the file system is to be unmounted. Similarly, like remount book is to verify the mount, verify the mount options and SP status is the book that is to check the permission when a task tries to obtain the file system status. This is the data structure. So here, these are the some of the, so we have seen this SBA statics statics or getting the statics status unmounted. These are the books that are part of the super blog operations. Similarly, there are a set of books to operate the file data structure, the file data structure represents a file that has been opened. And it contains file operation data structure which describes the various operations that can be done on the file. And the various operation can be read, read from or write into or seek through or memory mapping of the file and so on. And Ellison framework provides this hooks to mediate the access to the files. So here in this case, if you look at file operation, file permission, this hook is used to validate the read and write permissions at each file read and write operations. Similarly, like file logs is used when when locking to synchronize multiple readers or writers. And again, there are different hooks as file IUCGL or file FCNTL to be used for miscellaneous file operations that comes to the different system calls like IUCGL or FCNTL. Again, there are hooks for I know data structure which I know data structure represents the kernel objects such as file directory or symbolic link and Ellison provides a group of hooks that mediate the access to this I know data structure. And I know data structure is populated either when the file is full of operation happens or this is file system object creation or creation happens. So, and for all this was different operations, there are very defined hooks been defined to act on the I know such as create a media, remove the air, make new reading link and link symbolic link and set up hooks for getting and setting the attributes and also for permission checking the permissions. So based on the Ellison implementation what kind of mandatory access functionality that particular Ellison is defining all this different Ellison hooks has to be implemented as part of that. Now for taking care of security at the task system level or the process level, the security hooks for task handling is done through the task hook and the task data structure is the current object to represent the schedule level task. And the different hooks that are provided mediate access, mediate a task access to the basic data structure. So these are some of the folks that is task alone, hope is called to verify task has one children and task skill is called when the task exits. So during the life cycle of the task, some information may change like the process can execute a set user ID system calls, which eventually it will go and call another code call as task fits at your ID code. Now, these are some of the codes that are to work with the IPC mechanism system be IPC mechanism such as shared memory or semaphones and message queues and again Ellison provide set of IPC hooks that mediate access to these IPC objects such as IPC permission book create checks the IPC permissions. Similarly, message to this is received for check permission before the message is received from the message to and similarly there are functions for shared memory and semaphore control. Again, now there are another set of codes for working on networking subsystem. As we are aware that networking is an important aspect of products and more importantly, securing the system from network attacks. LSM has provided the extended security to this area. So application layer access to networking is mediated via the series of socket related codes and these codes are fine grained and have been implementation for IPV4, UNIX domain, NETLING and transport protocol as well. And there are set of codes for socket system corresponding to the socket system call such as bind, connect, listen, send and receive messages and the other networking socket system calls. And the network data structure data traverses the network stack in packets encapsulated with socket buffer. Socket buffer is the data structure that represents the packet itself. LSM provides the opaque security fields inside the socket buffer so that security states can be managed across network layers and for packet base. So other than that, there are other areas inside the kernel where the hopes where security data fields are being added and the other system folks are also being added. So this, like if you're to talk about LSM framework and if you do not talk about security of loading and unloading of current modules and this frame of this discussion will be incomplete. So the LSM loading hopes there are also really folks take checks for permissions whether providing the creation and initialization of loadable kernel modules. It also provides hopes for security key management and checking hopes for system change of system time allocating the virtual memory mapping accessing kernel message buffer. Also it has LSM provides hopes for audit framework and so it has hopes for EBF and program functionality using through this EBF system calls. And besides that is also defines a miscellaneous set of folks to protect the remaining security sensitive actions that are not covered by the above functions. So now let's look at the current status of the LSM inside the kernel. As of kernel 5.7, there are nine LSMs present and these are the list of LSMs that is SLINX, MAC, ABAR, MULTOMAYA, YAMA, loadpins, SAPEID, SAPEID, lockdown and VPR. So let's look at each of them to understand what they are. SLINX is one of the first security modules that are added into 2.6 kernel and this is the reason why the whole infrastructure LSM framework came into the Linux kernel. And this is the default mandatory access implementation on Red Hat distribution and it consists of a security module and set of trusted service for administration and secure system execution. Another is the similar to SLINX, MAC is also a attribute-based mandatory access control and it is the second LSM deployment and development that got merged as part of 2.6-24 relays. Basically it is a simplified version and it's designed for embedded systems and to provide a simpler administrator tools and it has been one of the default mandatory access implementation in automotive-grade Linux and Dyson. ABARMOR is another mandatory access implementation and it is the default implementation for Debian-based systems and it is a path-based implementation rather than attribute-based. Policies are based on paths, can protect files on the file systems rather than the attribute-based where attributes are not required for storing security context information. Another is the Tomoyo. Tomoyo is also like a path-based implementation and was merged as part of 2.6-30 kernel relays and Tomoyo is used to enforce mandatory access using the domain which is determined by the process expression history and each domain is represented by the concentration of previously executed paths. Here we see the other LSM load pane which was merged as part of 4.7 kernel and it shows kernel loaded files like kernel modules originate from the same file system. That is the expectation that the file system is backed by the read-only device such as CD-ROM, RDM or Verity. So this is intended to simplify the embedded system development systems that need not have the kernel module signing infrastructure in place. If the system is configured to boot from the read-only devices. Yama is another minor LSM merged in 3.4 kernel and it is intended to collect system-wide distributed access security restrictions that are not handled by the core kernel and its core is reduced to the P-Trace system call so that if a successful attack on one of the processes that are running is happening then based on the Yama policies it can frustrate that whether the process address space can be traced or not. And using P-Trace to extract sensitive information from other processes running as the same user. Now another LSM call set ID was merged as part of 5.1 kernel. It is used to restrict the user ID and group ID transitions from a given user ID group ID to only those that are uprooted by the system-wide list. That's if ID gets the set ID family system calls to restrict transition from a given user ID to only those that are uprooted. Another LSM lockdown was merged as part of 5.4 kernel implementation lockdown feature of the kernel where when lockdown is unable the kernel parameter can be used to lock down the kernel in either of the more integrated confidentiality mode. So when the lockdown is set to integrated, the set of features that allow users space to modify the kernel are disabled such as access tools like Mem or kernel memory of our ports and then TXAC of unsigned images and access wire ports and memory unsafe module parameters. So all those are being denied when the lockdown is set to integrated mode and when the lockdown is set to confidentiality mode along with the integrated feature functionality. It also disables the features that allow user line to extract potential confidential information such as running kernel from the kernel running kernel such as slash croc K4 access or use of K probes or use of bpf to read the kernel memory or unsafe use of corp and use of trace fs. So this gives us the various idea of the various LSM modules that are present in the Linux kernel. So to conclude about the Linux security modules, Linux security models are not designed to prevent a process from being attacked. For that, a good coding practice configuration management and memory safe line wages are the tools. But Linux, the protection provided by the Linux security module to our health protective system from being hacked when the attacker tries to exploit some flaws in the running programs. They are important. They can be important here in any defensive strategy or line systems. And by understanding what protections they provide, you hopefully have a great appreciation for what system needs to protect and how to implement those protections. So this completes our session on understanding the Linux security module and getting into its details on the understanding the various types of security models that are present in the Linux system. Thank you. In this frame, yes indeed, as a Linux is one of the tools to LSM modules that are more into the kernel effect as a Linux support for main reason how the Linux security framework came into effect. And eventually the other, it just was added. Is there any second question? Is there any information which LSM is a major and which is minor in the kernel system? Yes, the comments and the documentation does mention about the set code for LSM modules that are part of the kernel and what we tell the major ones and the minor ones. And of course any configuration that I might cause, they have to specify the order of the minor that has to be loaded when the kernel configuration happens. I have a question by Andrew. Does the security fees of some structures preserved after the reboot? I do not think that the security fees are preserved after the reboot. There is full security content as part of the live kernel and as part of the latest kernel data structures that they are being acted upon. They treat us a very little as long as the kernel is up and running in that context. Another question by Gelsen is what is the best way to measure the overhead of these LSMs? So I have seen one of the, one way is to use the LSM benchmark to measure the performance of the existing calls, performing the different operation and measure in the open to a big sum. There is a file status, text information. And that is one of the things I have been used to measure the performance effects. And one of the questions that she has, Gelsen, let's put up one, has LSM support yet? They did. LSM support has been added since 2.06 and corresponding new LSM orders, but I've been getting added on top of that. I have a question by Andrew. Can some LSM codes be called before the disparate access to those checks? No, actually the order in which the hopes is called before the disparate access complete, hopes checks are being done because that's the in the security feature. And then after the disparate access checks are done, then we LSM comes into picture if there was any major implementation that is in the disparate access complete that will be done. Another question by Shashi is configurable from, to make conflict, yes. So to enable any security module into the government, we have to configure that at the book of our time by making use of make minute conflict. That's another question by Andrew. Does any LSM have clear memory feature that is called or clear in the stack variables? So I don't know, I don't think so. There are any hopes at such a present at this moment for clearing memory feature as such and same with the stack variables. So the memory, these hopes are added at the various subsystem that is file system called a file system networking and answer. So particularly from the clearing memory or clearing stack variables, there are no inputs in present. And the question is as a Linux attribute base? Yes, as a Linux is the attribute base to LSM or many different access implementation. So yeah, I think that's the best question I have. I think that's all from my side. Thank you. Thank you for giving an opportunity to be part of this conference.