 Welcome on the talk about using the real built-in security technologies on the daily basis. I'm Dalibor Pospisial. I work as QE at Red Hat for about 10 years almost and my co-presenter is Sergio Correa who's software engineer and he's with Red Hat for like two years almost and I will be giving him a word for the second half roughly. So let's start. What's our today presentation about? I will briefly talk about our team and then I will switch over to technologies we cover. So let's start with our team. We cover quite a lot of components which are not all of them focused on this specific topic I'm going to talk about but our main focus is on authorization of various forms. These forms are mainly about user authorization, USB device authorization, application authorization and automated unlocking of encrypted volumes which is also kind of authorization of this procedure. So what are the technologies I'm going to talk about today? These are sudo, usb guard, FA policy D and PBD and BDE. These are those categories I mentioned before and the technologies which are covering those specific areas. So let's jump directly to sudo. It's a user authorization tool. There are links to upstream and also the customer portal so you can go there and click on it if you want to. So what sudo is about this is like one of the most important tools of CIS admins. It gives great granularity of permission granting to users and also it's able to use different sources for the configuration and the rules. What's important to say is that this is not only a prefix which might be seen in various tutorials in the internet. It does a lot of stuff. For example, it uses the rule sources from various places. It's able to use of course local files. It's able to use LDAP as a backend or through triple SD component. It's able to use various other backends such as IPA. It's able to control access for various persons. So it's able to control who, where, when and what is a user able to do certain actions. And also it can generate and it generates actually logs of various types. Let's jump to some examples. Let's say that we have user test and the user test has this sudo rule. The sudo rule says that user test is able to run on all systems as any user there command ID without giving a password. And it's able to run it between the time like this not before and not after defines the time window. If you take a look at the numbers, it gives user exactly one minute to do like to execute ID command without typing a password. So in real, it looks like this. I run on date and sudo ID command at the same time. So we are quite sure that this is running in that specific time. And you can see that this time 1049 is before 1050, which is defined here in the rule. So the user is asked for the password. Later, when times go and the time is now 1050 and something, user is suddenly able to execute the ID command using sudo. And you can see that the output of ID command here. And again, when times go, when time goes, after 1051, the user should not be able to do that action anymore. So again, it asks for password and because the rule says that usage of ID without password would be just limited within this time frame. So this is just a simple example how to limit the user for using a command within the specific time frame. Let's use a slightly more complicated output, which also shows the abilities to log the session. So the first example was basically you have user, but you want to let him do certain actions just within the specific time frame. And this action is specifically limited to just one command. Now we have different situation where we have some kind of admin user. And we want to give him greater opportunities. So we can specify, for example, this rule that admin user is able to run anything, virtually anything on any system as user test. And it will do input logging, output logging. And again, it won't ask for passwords. It's for this purpose. It's simpler to show it. So what happened if the admin user uses sudo minus I minus you test, which means I want to run interactive session as a user test. So normally, the command line for the test user will pop up. And the admin can type some commands. So I jump to TMP, for example, I do LS minus one, which lists the content of the directory. Now, as a administrator of the system, I trust the admin user a lot because I gave him rights to execute anything. But I want to be sure what's he doing. So I enabled this input and output logging. So I can see if I use sudo replay tool minus L to see what are the recorded sessions. And I can also replay that session. So if you search for the ID of that session here, it's ID 00001. I can use this ID to replay actually what the user did. So I can use the sudo replay again, just with the ID. And it will replay the session for me, including the output and the input and output. So I can see in real time that the user typed these commands and that there was this output and the user then exited the session. So this is like the ability to track what the user is actually doing. So what are the threat preventions here for sudo, like abilities of sudo for threat prevention? So this is basically what I already said that users are limited just to certain actions. And the other one, like these are the most important, of course, there are many more. The other one is the logging activities. So you can you can even log passwords if you want, but these are like disabled by default. Okay, let's jump to another USB guard, which is a tool for USB device authorization. Again, there are some links to upstream reddit portal and also this year's talk, which happened yesterday. So you can go there and see like news of in the USB guard. And of course, you can you can read through the documentation as well. So again, what's the what's the USB guard in general, this is a software framework, which implements authorization policies for USB devices. It helps to protect a system against the intrusive or unwanted devices. There are it's there are three main parts. The first is system service, which enforces the policy. Then there are the policy rules. And there is also the command line interface for managing the rules. Again, some simple examples. So first off, I need to start the service. System CTL start USB guard. Then I can use this USB guard command line interface to list the devices. These are the devices already registered by the service by the running service. So I can see, among others, that there is some, some device QMU USB tablet. Because I'm using a virtual machine for this purpose. So I can see this, this device. And I can see that the device is currently blocked. So what I can do about it to make it work. I can use this CLI command USB guard allow the device. And I just use this number five, which is just the ID, which was provided by the list command. And suddenly, the device is enabled. If I list the devices again, I can see that the device is now allowed. Okay, this is pretty simple. But this is like just one time shot. If I want to create the rules, I need to first generate the policy. For that purpose, there is a command USB guard generate policy, which basically grabs the currently attached devices. And I can put it to the file and to install the file to the final destination, which is the ETC USB guard rules conf. There's also another possibility to use rules D directory. But this is out of scope of this talk. And then I can restart the service. And the service is able now to apply all the rules for all the devices which were generated for the policy. Then I can, of course, tweak it using the CLI or directly directly editing the rules conf, which is not recommended. The CLI is recommended here. Again, what are the threat prevention here? For example, in the servers, in the server room, which is normally secured, but there are some people who has access and someone may want to persuade the administrator of that lab that you want to, you want him to, to put there some USB stick, which is able to do certain actions, like install something to the system and so on. So you can basically lock all the USBs in the server. And enable only those you trust to, for example, you can enable devices just by the serial number. The other possibility, which is more like possible, is imagine the situation you have a laptop in the cafe, and you are talking to somebody else and you turn around and somebody just plugs a little stick in the USB guard, which is almost not noticeable. So it again, can, for example, lock your keystrokes. So that the potential attacker can, can read all your passwords, for example. So this is another case where this can help. The next technology I want to present here is FAPolyCD. This is application authorization tool. Again, you have links here, there was talk at the last year's DEF CONF with more details. So again, you can, you can watch it. And in, in a nutshell, what is FAPolyCD? This is the software framework, which allows you to control applications based on the policy. This is like the most efficient ways, how to prevent running untrusted and possibly malicious applications on the system. Again, it's compounded by various components. There is again, a system service running. There is again, the policy, the rules. There is also a database of trust, which is important. And nowadays, it's like preferred, preferred way to, to use for, for tweaking the policy. And there is a command line interface to, to control it. The rules define the target. It may be allow, deny, allow, audit, deny, audit. And it says these targets for specific subject and object. And so you can specify which subject meaning which running binary can do certain actions with the, with the object, meaning file on the disk. It may be open or execute action. And FAPolyCD can decide based on the rules, what to do, what to allow, what to deny, whether we want to also audit the action. Yeah, so the message is issued to audit log or syslog based on the configuration. Again, some examples. This is a part of, of the default rules. The rules are processed one by one. The first match wins. So if nothing matches, it goes at the end, and there is a like final set of rules which match. And like this yellow one is kind of important for us, because it tells us that any application can execute trusted objects, just this simple information, just trusted objects. And that's something I will explain in the, in the trust database slides later. So what's actually the trust database? This is a database of files, which are normally gathered from our PMDB and local customization list. And this is, as I said, already, this is the preferred way how to tweak the policy, like in general. So all the RPM files, which are deployed on the system are automatically put to the trust DB. So you don't need to bother with those files, just provide the RPM and if administrator installs RPM, all the files are automatically trusted for the FEPOLICID. And there is a command line interface, which provides easy way to manage it. So let's see how to do that. Again, the FEPOLICID is a system service. So we need to start it. And now we have a test user, for example, who is trying to, to, to exec, in this case, ID command user bin ID, you can see that the command executed normally. But if the user copies the binary to its home directory, then he's not able to execute it from that home directory because FEPOLICID no, that does not trust this binary anymore. So what we can do about that, the user may go to the admin and say, Hey, admin, I have this super cool binary, I want to be able to run it. And what should the administrator do is to inspect the binary, see whether it's like official version, not no malware is there. And the admin can add the file to, to the trusted database using the CLI command, dash, dash file, add, meaning add the file to, to the trust DB, trust database, and to upload the new database to, to the memory for the, for the daemon, for the service. So suddenly, a user is able to run the binary from its home directory. So this is like in a nutshell, how it works. The database may be managed by following commands. So I can add file, I can update the file if, if I need some new version, and I replace the, the binary, it won't be trusted anymore, because it has changed. So I need to update it, update it's like attributes in the database. I can also remove the file from the database. And, and I can, or I should, when I do some updates to the database, I need to update or tell the the service to, to reload these database. Now, very new feature here is integrity checking, which shifts the, the trust database to a little higher, like, level. And it's able to check the integrity of that specific trusted files using either size, file size, or hash, come computed directly using the service, or the hash provided by IMA feature. So if, if you happen to have IMA feature enabled on your system, you can use this IMA integration for the integrity. So you save some time for the hash computing. This is basically, like, this is a bit view to the inside. You can, you can jump the trust DB. And if I search the trust DB for that specific file, I was talking about, I can see that it was like local custom modification, it's from file, it's not from RPM. This is the path to the file. This is the size of that file. And this is the hash of the file. If I issue the LS command, I can see that size match. And also if I count the sum, the hash, I can see that the hash also matches. So this is the way how to, like, improve the security. Because if you replace just replace the binary, and you don't use this integrity checking it, it's basically considered just by a path. So it might not be sufficient. Okay. What are the threat prevention here? This is this can be used, for example, using some malware sent by by the email. And imagine the situation you receive an email and you are not careful enough, and click on some link, there might be some, some JavaScript, which downloads some binary from from the internet and tries to execute it. So this is exactly the way how to prevent the execution. Because otherwise, normally, the user one would be able to execute such binary. So this is nice way how to prevent executing of unwanted, unknown, potentially malicious binaries. Okay, and now I will hand over to Sergio, who will continue with BBD and BDE part. So, as Dalibor mentioned, I'm Sergio, I'm a software engineer with the special projects team. And I work mainly with what we call BBD and BDE, which is a technology that allows for the automated unlocking of encrypted volumes. To complement this presentation on some of the technology that we cover in our team, let me talk a bit about NBD and what's new with it. So let's start by taking a look at these acronyms. So what's PBD and what's NBD? So PBD stands for policy based decryption. And it basically enables the unlocking of encrypted volumes with the help of a software called Clevis. This Clevis software runs in the machine with encrypted volumes. So basically on the client side. And then we have NBD, which stands for network bound disk encryption. And this is a subcategory of PBD. It's looking at in a simple way. This is basically PBD, policy based decryption. But when we use a special network server called Tang. So if you do PBD with Tang, this we call NBD network bound disk encryption. So from here, we see that we have on the client side, a software called Clevis. And on the server side, a software called Tang. I listed in here some place where you can find additional info on PBD and NBD. So I have listed three previous talks that basically introduced the concept, why they need for a solution like this. And then other talks that explore it further. So please, I invite you to check them out. I also listed the source code that we have available in GitHub. So please feel free to contribute by either reporting issues or even submitting requests for fixes. So what's new with NBD? Basically, what I'd like to highlight in this talk is that now we have the ability to set up NBD at scale with the help of Ansible. So Ansible is an automation platform that helps system admin with system deployment and maintenance. So we are able to perform maintenance and deployment of several systems at once. And in Ansible, we have the concept of playbooks and roles. So to see it in a simplified way, we can see playbooks as a collection of shell scripts. I mean, this is not a very true analogy, but just help us to see. So playbooks are a way to organize a series of tasks that you'll be run sequentially. And then we have roles which are themselves, self-contained automation units. So we'll have like a set of specific tasks grouped together in a way that makes it simple to reuse it. So we can use roles to basically set up a series of services related service, do some deployment of specific files and configuration and all that. For NBD, we recently made available a couple of Ansible roles, which are NBD server and NBD client. These roles are available as part of the Linux system roles project. So we have, I haven't linked it in the slides. So you can go there and see a lot of roles for doing different stuff. Among them, NBD server and NBD client. So let's see how code we use the NBD roles. So the NBD server role, it allows us for configuring tank servers. It has the ability to rotate fetch and deploy tank keys. And if you see in the gray box, this is the anatomy of a NBD playbook. We basically have the ability to specify a set of hosts in which the actions are performed. So in my particular case, I have a group called NBD servers. And then I specify some variables that are variables from the host, from the role, like configuration settings for the role. I have also listed these lines, the full documentation of the role so you can see every possible setting. In this example, I have one configuration variable called NBD server rotate keys. I'm setting it to no, which basically means that no, I do not want to rotate keys. What is rotating keys in this context? It's basically the act of creating a new set of keys, like we have keys that are currently being used by tank. And periodically, it's recommended that we rotate them, we change them. So this is possible, we can do that for us as well. And finally, I actually use the role itself. So it's not really complicated. Let's also see how could we do that with the NBD client. So for configuring the client, it's a little bit more complicated because it has a little more settings. Again, I have listed the options from the documentation, we can check it out later. But basically this NBD client role will make it simpler for us to deploy Clevis. So if I want to use Clevis with, for instance, a couple of tank servers for high availability, I can do like in this example on the right. So similar to the previous playbook, I also specify my hosts, which in this case is NBD clients. And then I specify my variables. You see now I have an NBD client bindings variable. And inside that, I define some of the settings. For instance, I specify an encrypted device called in this particular case, dev SDA1. And then I specify where I can find the encryption key, key file for that volume. And finally I specify the tank servers. So server one and server two in this example. And again, I call the the role itself. So let's now show a pre-ported demo showing how to use that. Basically, I will have three machines. One that we are, I will call the INSIBLE controller, that will be the machine where INSIBLE will be actually running. And then I will have a couple of machines, one that will be running AVM with encrypted volumes. So I will have claves in there. I will start claves in there with the NBD client role. And in the other one I will use to deploy things. So my claves VM, you will be able to use the tank server that I just deployed. So as you see in the right, I have my claves VM. Since it's AVM with an encrypted volume on boot, it's asking me for the passphrase. So I'm going to provide it initially so that the boot process continues. And then I move out to this machine that I call the INSIBLE controller. You see here a file that I call the inventory. So in the inventory, I will be listing all the hosts involved in my setup. So I have three groups in there. One called all, one called NBD servers, and another one called NBD clients. You see that in all I specify basically every host that I have. In this case, I have two. And then my NBD servers group, I specify the servers that I will be deploying. Thank you. And then NBD clients, I specify the VMs or the machines that where I have the encrypted volumes that I'm going to set up claves. To actually run a playbook, we use a command called INSIBLE playbook. But before that, let me go to the thing machine. So in the thing machine, I'm just making sure that thing is not really installed yet. So it's basically a server without thing. And now I will run the playbook. The command to use it is INSIBLE playbook. And then I'm able to specify the inventory. And then finally, the playbook itself. In this case, servers, EMO. So once it's doing its thing, if you take a little while, I'm going to skip it slightly. So while it's running, it's basically running a set of tasks that's pre-configuring the role. Like it should be able to actually deploy and do all that's required. The role encapsulates all of that logic. So when I run this, after it completes, I will have things deployed to all of my servers listed in the inventory and the playbook. And I can check. For instance, now it's just completed. So it shows our recap at the end, showing the number of tasks that were okay, the number of tasks that caused the roles to be changed. So I will now move to the thing server again and make sure, check if the thing package is now installed. And as you can see, it is installed. So after we run the playbook, it was installed as expected. This is also running right now. I'm now going to run the second playbook, which will deploy Clevis to the Clevis VM, which is showing on the left side. Let me again skip it a little bit. And while it's running, I will also move to the Clevis VM and log in there so that I can later reboot it when it's done. So the ansible role is still running. It's now in one of the last steps, which is updating the init ramfs that I step required for Clevis. In this step, it basically includes some automation machinery in the init ramfs so that this part will be able to do the boot unlocking. And now it completed also successfully. So I went to the Clevis VM and issued a reboot command. So now let's set reboot. Again, that we asked for the passphrase because it's an encrypted volume. But this time, I will not provide it myself. I mean, I will not type the password myself. Since it deployed Clevis, Clevis is bound to the tank server. And it will be able to do the automated unlocking on boot. And basically, now the boot completed as expected. So we were able to deploy both tangy and clevis and it tested it and it works as expected. I have you also listed in the presentation a source for the playbooks and the inventory that I used it in this demo and also the video itself. Since I believe this slides you can share as a PDF. I link the video as I want to watch it later. And that concludes this presentation. So thank you for attending. And if you have any questions, please you have some time. Thank you.