WEBVTT 00:00.000 --> 00:11.080 So, yes, we are fully on time, we are about to start with the next one, now we change the 00:11.080 --> 00:12.080 topic. 00:12.080 --> 00:16.760 We are not going to talk about pastless anymore, we had enough talks, and now the next one 00:16.760 --> 00:21.680 is from Alessandevo Koboy, and Alejandro López, they are going to talk about reducing 00:21.680 --> 00:28.080 the attack surface or keep compatibility, lessons from sudares and run serial transition 00:28.080 --> 00:29.080 plans. 00:29.080 --> 00:43.720 Thank you guys, this is not the work that actually done, so this is more like a investigation 00:43.720 --> 00:51.640 on a topic, and discussions behind, well, in the whole ways, and other places, all on the 00:51.640 --> 00:52.640 topic. 00:52.640 --> 00:58.640 Yes, it's working. 00:58.640 --> 01:07.840 So, these kind of investigations, they started actually quite a few years earlier, when 01:07.840 --> 01:16.280 US government started mandates in certain improvements in the IT infrastructure, so people 01:16.280 --> 01:21.960 aware about zero trust architecture where everything has to be validated all the time, then 01:21.960 --> 01:29.040 there was this mandate from the White House about secure and finally right in the software 01:29.040 --> 01:37.800 in a secure manner, and asking the vendors to start switching to a more modern languages 01:37.800 --> 01:46.240 and frameworks and so on, and it's clear that all this process, it takes years. 01:46.240 --> 01:51.400 And maybe decades will take decades to transform, because we have this transformation 01:51.400 --> 01:56.920 happening in parallel for a lot of stuff, so there is this post quantum transition, there 01:56.920 --> 02:07.520 is a zero trust architecture, there's a need to rewrite everything and always have had 02:07.520 --> 02:14.720 on how to rewrite it and what to use, drop protocols, not just languages and so on. 02:14.720 --> 02:26.000 So we started looking into what we have, what we see from customers that use rail identity 02:26.000 --> 02:32.120 management, or free IPA, or keyclog, or the others, so what they are asking, and many of those 02:32.120 --> 02:40.120 customers are kind of non-modern customers, they have history of IT deployments for 45 to 60 02:40.120 --> 02:46.080 years, with a lot of craft accumulated there. 02:46.080 --> 02:55.040 And in many cases, these, like, rewrite, they cost for complete what they call the green 02:55.040 --> 03:04.200 field deployment, but that's not reality, we deal with, especially in the bigger organizations. 03:04.200 --> 03:09.600 There's always a field there that has to be transformed somehow. 03:09.600 --> 03:17.840 So what does it mean from the organizations that already have something to transform to 03:17.840 --> 03:25.280 use these new stuff, so how to reduce this kind of attack surface that they already have? 03:25.280 --> 03:30.600 So they already have deployed software that's supposed to be less secure than the new 03:30.600 --> 03:31.800 stuff. 03:31.800 --> 03:34.240 And we started looking into components. 03:34.240 --> 03:45.880 For example, often, say, replacement for raising the privileges is run 0, which aims, 03:45.880 --> 03:53.640 it's a good aim to have a system where you don't have any binary wave suede rights. 03:53.640 --> 03:59.960 So that any transformation that happens happens through other channels by utilizing already 03:59.960 --> 04:05.080 privileged applications, setting up things for you, and then you're being put into 04:05.080 --> 04:07.640 environment that they set up. 04:07.640 --> 04:17.200 It's bundled with system DE256, written in C, uses out-sources, let's say, authorization 04:17.200 --> 04:22.760 requests to poll-key it, which is another well-known component. 04:22.760 --> 04:28.520 And the other one, okay, not the other one, but this is an example how it works, like 04:28.520 --> 04:38.240 on fedora system, so if you do run 0 echo, you get a flood of system messages, and one 04:38.240 --> 04:46.440 of them is the first one is that the run 0 asks the poll-key to agent, hey, authenticate 04:46.440 --> 04:49.400 this request and authorize it for me. 04:49.400 --> 04:57.440 So it's basically Pam stack being run for the poll-key dash 1, the authentication step of 04:57.440 --> 05:06.160 that stack, and you can see I'm using Pam as a says here, so all this thing. 05:06.160 --> 05:12.960 Then upon the successful run, you get system DE-log in the eCreate and a new session for 05:12.960 --> 05:18.840 this root account, and a lot of account on that session happens. 05:18.840 --> 05:24.440 In the end, you will see that there is a service, somewhere in the middle, started run 05:24.440 --> 05:32.160 there's p63 and so on service unit, so it's literal run as a separate service unit, 05:32.160 --> 05:41.000 like a system DE, job that you can configure how it goes there, but it's pretty limited 05:41.000 --> 05:46.440 in what is allowed to it, what is set up, you can do some limitation on the resources, 05:46.440 --> 05:52.920 and so this is existing today, and can be used by the organization. 05:52.920 --> 06:01.080 Then the other side is the idea of the often quoted reduction of the service attack, 06:01.080 --> 06:08.680 is using the Rust-based applications, and one of them is Sudo RS, and I'm switching to Alejandro 06:08.680 --> 06:12.320 for that. 06:12.320 --> 06:22.840 So Sudo RS is a project that was, it's going to replace Sudo Absentime, so it was 06:22.920 --> 06:33.720 written from scratch, from with the Rust, so the first characteristics there, so it has 06:33.720 --> 06:43.080 memory safety, thread safety, arrow handling and strong typing, all that handled by the compiler, 06:43.080 --> 06:52.600 so it helps with the security, the service attack, so the memory 06:52.600 --> 07:00.600 face safety is handled by allocating and freeing the memory inside the scopes, so as soon 07:00.600 --> 07:06.920 as you live as scope, the memory is released, so you don't have memory leaks, for a safety 07:06.920 --> 07:17.000 they use the memory ownership, data ownership, how they call it, to associate the data to a thread 07:17.080 --> 07:24.680 and reduce the risk conditions, arrow handling, the compiler will detect that you are not 07:24.680 --> 07:29.880 going to an error, for instance, and will tell you that you need to do that, or at least explicitly 07:29.880 --> 07:38.520 say I won't handle that error, and once you type in you know, you will not assign a chart to an 07:38.600 --> 07:47.000 integer and that kind of things, so this is the main characteristic that we are going to focus 07:47.000 --> 07:55.960 on Sudo RS, because the containers they focus on security, but the containers for Sudo 07:55.960 --> 08:03.000 also they focus on security, so this is the main difference between the two projects, 08:03.000 --> 08:14.760 so we have the enterprise environments, you often have a lot of machines enrolled into the 08:15.480 --> 08:23.240 same kind of logical domain, so we know some of the customers, we don't know all of the customers, 08:23.240 --> 08:31.320 because well frankly people using infrastructure software, typically don't tell outside 08:31.320 --> 08:36.360 of the organizations how they use infrastructure software, unless they want something from you, 08:36.360 --> 08:43.640 so we hear unheppicases and heppicases where people really want something more on top of it, 08:43.640 --> 08:49.800 but otherwise they typically do not talk in public how they are organization, how they bank, 08:49.800 --> 08:58.200 or how they are state, is setting things up, so this makes it really hard to find out, 08:58.200 --> 09:05.640 hey how many machines are in those domains, how many how big are the Sudo rules set and so on, 09:05.640 --> 09:13.800 and we know configurations where people run like a million machines in IPA domain which is kind of 09:13.800 --> 09:23.480 crazy, but it also says that yeah we probably scale well in some situations and I know a lot of 09:23.480 --> 09:29.480 organizations that have tens of thousands or hundreds of thousands of Sudo rules, again I 09:29.480 --> 09:39.640 come away that over tens of maybe decades of using these environments and it's very painful to 09:39.640 --> 09:45.880 replace that, so they have to do something with it, that leads you to centralize it in 09:45.880 --> 09:52.600 environments where you have to have some sort of a way to centrally control what's happening on 09:52.600 --> 09:58.440 those machines, even if the machines are themselves like it's not a million machines in the same 09:58.440 --> 10:04.520 scope, the multiple scopes and you still need to control each of those scopes, if you have 10:05.640 --> 10:12.440 especially nowadays with cloud you might have 100,000 machines launch it in one day and then shut down 10:12.600 --> 10:19.160 in one day but you still have to have some sort of order on those machines, who can log in there, 10:19.160 --> 10:25.960 who can do stuff, even if it's agents, not humans, even though agents are behaving as humans 10:25.960 --> 10:32.360 nowadays so they might need to have more control over there, so in these organizations the 10:32.360 --> 10:38.200 organizational kind of issues dominate the technical ones, so you can do technical solutions but in 10:38.200 --> 10:46.040 many cases you have to help organizations to enforce political things or policies and so on and then 10:46.040 --> 10:54.920 you have to do all detail, who, how does this, if all these rules, if all these definitions 10:54.920 --> 11:02.440 they are strictly local on the machine, it makes your life as an system administrator or 11:02.680 --> 11:10.280 IT organization leader, basically impossible, you have to collect all that data together, you have to 11:10.280 --> 11:16.760 make sure there's some area from which that data is propagated so that you can compare 11:16.760 --> 11:26.520 results and so on, so also for example we have to do, to do added support for Ragex's, so 11:26.520 --> 11:32.360 you have generic rules that not exactly strictly define and what will be around but has 11:32.360 --> 11:42.120 some variations, how to handle that with the new things, it's a big question, so I'll take example 11:42.120 --> 11:50.360 of the RUN-0 and Polkit, so what is missing there from the first view because there will be 11:50.360 --> 11:58.680 iterations on how to get there, so for example the Polkit has two distinctive operations, so there 11:59.320 --> 12:07.160 is action definitions that say what you can do, is the request for something, is that something 12:07.160 --> 12:14.760 defined in the configuration, so it's very rigid, fix it, you don't have much flexibility there, 12:15.560 --> 12:22.360 on the other side there's authorization rules, how you can get those rules access to those actions, 12:22.520 --> 12:29.240 who you are, in which context you're happening to do that, in both of these definitions they 12:29.240 --> 12:35.320 kind of fix it as a local files and machines, so you have to have all of them present on the machines, 12:36.120 --> 12:45.960 theoretically things might be dynamically delivered on the machines but not in such dynamic way, 12:45.960 --> 12:52.200 like if you want to happen them at the login they have to be present before login and so on, 12:52.680 --> 13:01.480 same way of the stack that Polkit is used, and so for authentication and then authorization 13:01.480 --> 13:09.880 runs, it first needs to authenticate, who is doing the stuff, we found out that a typical thing is, 13:09.880 --> 13:16.920 if you separate PAM stack from your original execution you'll lose some context, so one simple thing 13:17.000 --> 13:24.680 for the enterprise environment is that if you use Kerberos you have Kerberos credentials stored 13:24.680 --> 13:33.000 in some place and separate an access to them you'll lose context, you have to pass, it sometimes 13:33.000 --> 13:40.200 it's easy, easy fix by passing the environmental variables that define where the configuration, 13:40.200 --> 13:47.320 but sometimes they're more, and we find out that these things never get triggered and these 13:47.320 --> 13:54.520 errors never get reported because nobody uses that software in the environment that is there, 13:54.520 --> 14:01.320 but if we are getting rid of Sudhu at some point and if everybody says they use run zero 14:01.320 --> 14:07.560 and run zero in forces use of Polkit, we suddenly will start hitting the wall like this, 14:10.200 --> 14:17.480 on the other side for Sudhu RS there is plenty of missing functionality as well, and missing 14:17.480 --> 14:26.440 is just a statement, it's not meaning anything like that's wrong, it's because the focus is to 14:26.440 --> 14:32.920 build from ground up and that means removing the, well, not implementing the features that are 14:32.920 --> 14:48.280 not needed on the ground up, expanding the scope gradually, so some of the features that are 14:48.280 --> 14:55.480 currently missing because they still under the development in Sudhu RS are storing the Sudhu rules, 14:56.440 --> 15:03.640 the Sudhu RS rules in centralized location, they are currently reading the rules from the local 15:03.640 --> 15:09.960 fine, as Sudhu does, but at least Sudhu is able to retrieve them from a centralized server, 15:10.920 --> 15:19.480 this can be an adapt server, active directory, free IPA, what else, and there's a 15:19.480 --> 15:31.000 quite new feature in Sudhu which is it is called intercept that allows to so far if you don't 15:31.000 --> 15:39.640 didn't have this feature when you became root with using Sudhu, you could audit that you had 15:39.640 --> 15:46.200 became root and when you stopped being, but not what the user did in the meter, so the user could 15:46.200 --> 15:52.440 do anything with this new feature, everything that they do is locked, so this would be a good thing 15:52.440 --> 16:04.600 to have also on Sudhu RS, because for the large departments having this audit feature is from 16:04.680 --> 16:16.440 the mental, they also also limited support for well-cats, that's okay so far, there are some constraints 16:16.440 --> 16:24.200 but it's nothing terrible, and as before Sudhu RS still is not supporting the 16:24.280 --> 16:33.320 regsies, so you have to write each rule, you can not make some generic rules, and there's a link 16:33.320 --> 16:44.200 over there to their own page stating which are all the features that are missing in Sudhu RS, 16:44.280 --> 17:01.240 they themselves acknowledge that these features are missing, so when we look how to improve this 17:01.240 --> 17:06.600 situation, I'm not saying fixing, because it's just coming from a different environment that 17:06.600 --> 17:13.240 means expanding the news software to this new environment, that's not fixing problems, 17:15.000 --> 17:23.640 it's good to look back and see how we use it already, so if you're looking to the palm stacks, 17:23.640 --> 17:30.120 so palm stack is a bunch of modules that gets loaded into your application, that's bad, right, 17:30.120 --> 17:37.880 you're imparting some stuff that is unclear what it is, it might be linked against 17:38.920 --> 17:45.080 different versions of libraries that you happen to be linked with, so you get symbols conflicts 17:45.080 --> 17:53.320 or structure conflicts theoretically, of course the palm modules are written with a bit more 17:53.400 --> 18:02.440 rigor, but whatever you see in the field might be different, so in the reality, most used 18:02.440 --> 18:10.440 palm modules are written in a such way that they actually basically shins, they communicate with 18:10.440 --> 18:14.760 demon running outside over a unique stomach and so on, and they just forward 18:15.720 --> 18:25.480 requests and responses, so that's what SSD does with palm SSS, that's what NSSLD does with an LCD 18:27.240 --> 18:36.040 demons and all these things, it's a normal behavior, and we cannot enforce what is happening there, 18:36.040 --> 18:41.880 because it's under control of the system administrators, how these configurations could be, 18:41.880 --> 18:48.760 but for example in Fedora and Braille, we have this of select tool, where we have created 18:48.760 --> 18:55.880 palm configurations, where we define what would be in there and show what we do with it, so all of 18:55.880 --> 19:00.840 them are doing the unique stomach and socket communication, that's great, that means that 19:00.840 --> 19:08.760 we'll already have way there, when talking with systemD guys, you often hear, hey, let's do 19:08.760 --> 19:16.360 whirling interfaces, let's make this boundary over effectively, unique stomach and socket, so 19:16.360 --> 19:24.760 this is seem to be a convergence in the community and going there, and what we are looking at is 19:24.760 --> 19:32.440 effectively start doing somewhat like this, so we already have a ticket open again to do our 19:32.440 --> 19:41.640 rest, let's do some some way to get the rules, the plug-in interface to reach to the rules, 19:41.640 --> 19:50.520 we have discussion today with guys from three-factor to continue looking at this and we both 19:51.320 --> 19:59.880 both sides see potential and barley, barley kin, this interface, so that we get there, so literally 19:59.960 --> 20:05.560 that's what state we are, there's a lot of discussion, a lot of communication and 20:06.600 --> 20:11.320 chairman in to that will be really helpful with the use cases and 20:12.600 --> 20:17.240 stories, yep, thank you 20:30.120 --> 20:31.880 you 20:48.360 --> 20:54.680 the question is, are there any incentives to consider pseudo areas instead of pseudo today 20:55.560 --> 21:02.680 as a system administrator, if you don't have centralized environment, you might want to look at that 21:04.040 --> 21:11.000 at the pseudo areas, if you're developer and you're considering to look into 21:12.360 --> 21:18.680 secure execution engine, pseudo areas is actually two big pieces, one of them is 21:19.400 --> 21:25.080 process execution, it's preparation of the process execution in the right way, and they have 21:25.080 --> 21:34.120 already a precedence of using that engine in a different project, like SSH engine that has 21:34.120 --> 21:40.440 the processes coming in and then executed in this safe environment, the other side is the policy 21:40.440 --> 21:47.240 engine, right now the policy engine is kind of hardwired into using the local pseudo areas, 21:47.880 --> 21:57.560 but I see no problem if that engine could be used instead of like doing the own person of that 21:57.560 --> 22:03.320 format, and maybe the format could be decoupled, that's what we're hoping to get, and then 22:03.320 --> 22:09.800 improved to be more generic so that the content of the rules can be transformed into that 22:09.800 --> 22:16.760 generic one and the engine itself can be consumed in other projects to provide these solutions 22:16.760 --> 22:20.840 there's a lot of that