WEBVTT 00:00.000 --> 00:10.160 Hi, thanks everyone for coming to the talk. 00:10.160 --> 00:14.440 So what we're going to discuss today, we're going to discuss about containers, why does 00:14.440 --> 00:17.600 the attack surface of containers? 00:17.600 --> 00:20.840 It's probably going to be a rehash of some ideas we have prepared in the previous talk, 00:20.840 --> 00:22.760 so that's very interesting. 00:22.760 --> 00:26.360 We're going to discuss about some known attacks and mitigations. 00:26.360 --> 00:32.000 We're going to see danger zone and divisor, danger zone, will be like a reference project 00:32.000 --> 00:36.760 in order to understand how containers work and can be attacked, and we're going to see 00:36.760 --> 00:40.440 how we integrated those projects. 00:40.440 --> 00:46.280 Quick word about me, I'm a software engineer for freedom of the press foundation, and I'm 00:46.280 --> 00:50.120 a maintainer of the danger zone project. 00:50.120 --> 00:56.160 And quick word about the freedom of the press foundation, we are a US nonprofit, we do 00:56.160 --> 01:02.280 several things regarding press rights, we train journalists, you know, to keep them safe. 01:02.280 --> 01:07.760 We do some advocacy for press freedom rights, we track press freedom violations, probably 01:07.760 --> 01:11.160 we're going to track a bit more in the coming years. 01:11.160 --> 01:15.920 And we build security sensitive tools for journalists, like SecureDrop, I don't know if everyone 01:15.920 --> 01:21.400 knows SecureDrop, and danger zone, which is the other tool, we're having. 01:21.400 --> 01:24.240 So I keep talking about danger zone, let's see what that is. 01:24.240 --> 01:30.280 You can see on the left side live, in practice, it's an open source tool that was written 01:30.280 --> 01:33.600 in 2020 by Michael Lee. 01:33.600 --> 01:38.640 If you don't know the name, it's the guy who did Opsack for the Snowden Licks, so it's 01:38.640 --> 01:40.160 pretty cool. 01:40.160 --> 01:44.560 It's been maintained since 2022 by final press foundation. 01:44.560 --> 01:51.200 It was a written, in order to help journalists on the intercept, which is a US publication, 01:51.200 --> 02:00.120 to sanitize some documents that they got from the sources. 02:00.120 --> 02:04.920 It's basically a desktop application, I transfer my queries, Windows, Linux, because that's 02:04.920 --> 02:07.560 what journalists sent to use. 02:07.560 --> 02:14.800 And it basically takes a suspicious PDF, it passes it through a sandbox, and then it gets 02:14.800 --> 02:17.200 back, let's say, a safe PDF. 02:17.200 --> 02:22.800 This is not a novel idea by Ann Means, it's been used, well, in the army, but besides the army, 02:22.800 --> 02:29.020 it's been used in CubeSOS, which is a very interesting operating system, it has this 02:29.020 --> 02:34.120 trusted PDF feature, and the main logic behind danger zone is there. 02:34.120 --> 02:39.880 Unlike CubeSOS, which uses Zen, the Zen have a visor and disposable VMs, we are using 02:39.880 --> 02:42.520 containers, you know, it will chill out. 02:43.400 --> 02:49.920 I'll briefly explain how the danger zone works, so you have some suspicious dogs, you 02:49.920 --> 02:55.480 pass them to the danger zone, which is the application, but that application does not open 02:55.480 --> 02:59.960 the dogs, and that's important, because they may be malicious, what it does, you know, 02:59.960 --> 03:07.920 is that it opens, it's spawns a container, it passes the dogs through the HDD of that container, 03:07.920 --> 03:12.560 and it gets back, not a safe PDF, but it gets back pixels. 03:12.560 --> 03:17.600 And that's because you don't know what's going on on that sandbox, it may have been compromised 03:17.600 --> 03:24.360 due to the dogs, so what you want to have is like a very damp format of that original 03:24.360 --> 03:30.920 document, and that's just RGB pixels, three genres of color and all that. 03:30.920 --> 03:38.320 We then recreate the original document from set pixels, page by page, and by doing that, 03:38.320 --> 03:45.080 there's this analog call, where essentially we believe that every malware and every metadata 03:45.080 --> 03:47.400 has been raised. 03:47.400 --> 03:52.360 The result in documents is not that is the work with, so we do some OCR extra, so that you 03:52.360 --> 03:54.560 can select text and all that. 03:54.560 --> 04:01.960 As you can see, the containers and their security properties are really important for us. 04:01.960 --> 04:08.040 Else, our users are in danger, and we're talking about users who are being targeted by some 04:08.040 --> 04:09.560 serious people. 04:09.560 --> 04:16.200 So the question here, some will say here, and that was, again, the case of the previous 04:16.200 --> 04:24.880 SOC, that containers are good, but for security sensitive workloads, they may not contain 04:24.880 --> 04:25.880 as well. 04:25.880 --> 04:34.280 And that's true, I agree with that, but we have to think of the alternative, the alternative 04:34.280 --> 04:39.560 is that our users would just open the document in the laptop, and we don't want that. 04:39.560 --> 04:46.680 So unfortunately, or fortunately, we are in a position where we have to do some harm reduction. 04:46.680 --> 04:52.440 You're going to open that file in any case, so try to open it by us, where we use container 04:52.440 --> 04:56.720 so it's easier to install in your macOS Windows laptop. 04:56.720 --> 05:00.720 But at the same time, we'll try to keep you as safe as possible by doing what, by trying 05:00.720 --> 05:08.480 to identify what is the attack service of a container, and trying to figure out ways to reduce 05:08.480 --> 05:09.480 this attack service. 05:09.480 --> 05:14.600 We cannot complete null fight, we are well aware of that, but we at least can reduce it. 05:14.600 --> 05:22.040 So the very first thing we have in mind, and I'm going to talk about mitigations here as 05:22.040 --> 05:27.560 well, is that you cannot have arbitrary code execution in a container if there are no 05:27.560 --> 05:30.520 software bugs in your product. 05:30.520 --> 05:31.520 Does this happen? 05:31.520 --> 05:32.520 No. 05:32.520 --> 05:38.720 What the first mitigation or comes to mind is that you need to constantly scan your container 05:38.720 --> 05:41.120 image and regularly update it. 05:41.120 --> 05:48.680 On the bottom left, you can see an exploit that could affect a LibreOffice at some point, 05:48.680 --> 05:50.440 that was a specific CV for that. 05:50.440 --> 05:55.400 We got that first security scanning, and we should update it very quickly. 05:55.400 --> 06:02.720 Now a second vector is network access, and usually most containers are connected to the 06:02.720 --> 06:09.040 internet, so it doesn't apply to most people, but here's something interesting. 06:09.040 --> 06:11.280 There's this concept called kind of a tokens. 06:11.280 --> 06:16.880 I'm not sure if you're aware of that, but there are, let's say, silent alarms that you can 06:16.880 --> 06:18.760 put in documents. 06:18.760 --> 06:24.840 Usually they are triggered by AcrobotBDF, so not by other views, but in principle, you 06:24.840 --> 06:25.840 can open document. 06:25.840 --> 06:33.600 The document tries to get a fetcher resource from the internet, and that resource is controlled 06:33.600 --> 06:35.240 by the owner of the document. 06:35.240 --> 06:41.440 This way, people can know if what you are viewing right now, if you are viewing actually 06:41.440 --> 06:45.440 a sensitive document, if they're sending an authorized view of the document. 06:45.440 --> 06:50.280 If you are a journalist, you won't really even know traces of such a thing. 06:50.280 --> 06:57.000 So mitigation here, disabling it, working if your container does not need that. 06:57.000 --> 06:59.280 Okay, so the first things were pretty simple. 06:59.280 --> 07:05.240 Let's go to some more juice stuff, third attack vector, it's your shy runtime itself. 07:05.240 --> 07:11.120 The your shy runtime are usually in kind of a privileged position in the sense that they 07:11.120 --> 07:18.400 are written in memory safe languages, go rough, rough, because you know, ready. 07:18.400 --> 07:22.800 And also, they tend to set the states, they tend to create the namespaces, create the 07:22.800 --> 07:29.240 cgroups, fork, and then let the links kernel do the rest of the protections. 07:29.240 --> 07:36.680 That's the theory in practice, the habit bugs, you know, shy runtime's, either letting 07:36.680 --> 07:45.120 the user, the containerized process, take advantage, they exploit the actual runtime or access 07:45.120 --> 07:47.960 resources while being containerized. 07:47.960 --> 07:51.760 Like the host file system, when it should. 07:51.760 --> 07:59.680 So in order to protect the OSHA runtime, well, of course you can run rootless Docker 07:59.680 --> 08:06.480 podman user netters, I'm not sure probably no one does that, but there's this option. 08:06.480 --> 08:12.400 But in practice, for end user laptops and all that, even rootless podman, you're still 08:12.400 --> 08:18.960 the UID 1000, you're the 1000, you can practically read your Firefox history, passwords, 08:18.960 --> 08:22.800 whatever, so it's not a super good mitigation. 08:22.800 --> 08:30.120 Fun fact, for people who are using podman, just so you know, a good thing to do is to disable 08:30.120 --> 08:36.320 logging if you haven't done already for sensitive workloads, because if that workload is 08:36.320 --> 08:42.000 sending out but to STD out, it's logged in your general city. 08:42.000 --> 08:52.560 Now what happens if the process somehow escapes or not actually escapes, but sees the 08:52.560 --> 08:55.880 view of the host file system, there are some mitigations for that as well. 08:55.880 --> 09:03.760 Of course, SLINUPS is a very good mitigation, having the process not gain any new privileges 09:03.760 --> 09:06.600 it's also important as well. 09:06.600 --> 09:14.560 What's also really important is to note that the UID zero root within the namespace usually 09:14.560 --> 09:24.440 maps to the user who created the namespace outside that container, so you have to restrict 09:24.440 --> 09:25.840 it somehow. 09:25.840 --> 09:32.600 It's best to create containers using a different user than UID zero within that, so that's 09:32.600 --> 09:40.040 you, this one thing, and podman for and later has this very cool user and S-NOMAP of 09:40.040 --> 09:48.320 lag in which there's no user from outside the container, from inside the namespace that 09:48.320 --> 09:55.600 is mapped within that container, so practically there is no correlation between use outside 09:55.600 --> 09:58.560 the container and within it, and that's very good. 09:58.560 --> 10:04.520 And of course, dropping all capabilities, you'd be surprised at how many CVs can't 10:04.520 --> 10:09.040 be mitigated by no capabilities in the container. 10:09.040 --> 10:18.120 Of course, your workload may need those capabilities, in our case the engine needed none, 10:18.120 --> 10:22.080 so that was interesting. 10:22.080 --> 10:26.320 We're talking about the OSHA runtime, that's an attack vector, but let's face it, the 10:26.320 --> 10:31.680 biggest attack vector, it's a Linux kernel, and you can't do much there, if there's 10:31.680 --> 10:36.000 a buffer with lower something in the Linux kernel, then it's kind of a game over, and 10:36.000 --> 10:41.320 there's bound to be, because it has like a very vast attack service area, what you can 10:41.320 --> 10:51.560 do here is that there are ways to profile and trace your workload, which will create 10:51.560 --> 10:58.080 a second filter, which will have a more restricted set of Cisco's only the ones that your 10:58.080 --> 11:00.440 workload has used in real time. 11:00.440 --> 11:05.520 This may not be accurate, but it's a good starting point to fine tune some stuff. 11:05.520 --> 11:14.000 The less Cisco's your workload is allowed to do in theory, basically reduces the attack 11:14.000 --> 11:17.720 service of the Linux kernel, so that's a big thing. 11:17.720 --> 11:23.560 And by default, the default second filter has quite a lot of Cisco's enabled, because 11:23.560 --> 11:30.440 you need to, it needs to adapt to most workloads out there. 11:30.440 --> 11:37.040 And finally, there's the vector of hardware bugs, spectrum, meltdown, and all those types 11:37.040 --> 11:38.640 of vulnerabilities. 11:38.720 --> 11:51.120 Historically, VMs were not able to isolate the workload and not exploit those bugs. 11:51.120 --> 11:58.040 So mitigation, either burn your laptop or use a burn your laptop, pick your poison, whatever, 11:58.040 --> 12:01.720 but there's not a good mitigation here. 12:02.640 --> 12:11.160 We know we want to use containers because it's easier for your users, and we know some 12:11.160 --> 12:15.440 ways to reduce the attack service, but still, there is the link to the kernel out there. 12:15.440 --> 12:16.720 There is your share on time. 12:16.720 --> 12:24.720 And ideally, indeed, there's a lot we would like to isolate the containerized process from 12:24.720 --> 12:25.720 those things. 12:25.720 --> 12:28.040 We will slip better at night, let's say. 12:28.040 --> 12:30.480 So can we do better? 12:30.480 --> 12:33.120 This is where the advisor comes into play. 12:33.120 --> 12:39.720 Now, some talks have talked about before, I'll mention a few things real quick. 12:39.720 --> 12:47.320 The advisor is a Google project, it was written in 2014, open source team May 2018. 12:47.320 --> 12:48.320 It's written in Go. 12:48.320 --> 12:56.000 It's available only on Linux, and it has an OSHA runtime run in C, which can take a root 12:56.000 --> 13:01.160 surface path and contain very much and create a container out of it. 13:01.160 --> 13:08.160 Now, what's different from the typical container run times is that it's ocean application 13:08.160 --> 13:09.160 kernel. 13:09.160 --> 13:16.360 What it does, it's very interesting, it intercepts system calls, and it re-implimentant 13:16.360 --> 13:28.320 or it re-implimentant, and does that in Go, and therefore gives the appearance of a 13:28.320 --> 13:35.480 kernel API when there is no such thing to the containerized process. 13:35.480 --> 13:44.280 Explaining what the advisor does is probably requires a talk of its own, so I'm going to do something 13:44.280 --> 13:45.280 different. 13:45.520 --> 13:49.160 I don't have the time to explain, and I don't have the expertise to explain, because 13:49.160 --> 13:53.000 it's a very complicated project, and I'm trying to show you what I mean. 13:53.000 --> 13:56.600 Let's take a simple thing that most container run times do. 13:56.600 --> 14:04.120 Let's say you have a shell in a container, and you want to open a document and read 14:04.120 --> 14:05.120 its contents. 14:05.120 --> 14:09.920 That's a pretty simple thing, you do podman exec, took exec, and you do it all the time. 14:10.240 --> 14:14.840 You assume, and this app does happen with the advisor, that you'll see the file system 14:14.840 --> 14:20.000 hierarchy, and you read the contents of the document, and all that. 14:20.000 --> 14:26.120 What's interesting here is that every word that you see here, every graphic is incorrect. 14:26.120 --> 14:32.480 It doesn't up to the reality, and let's start with the on the file system part. 14:33.480 --> 14:39.520 There is actually nothing that the advisor sandbox can access. 14:39.520 --> 14:44.480 Practically, there is only a slush prok there, it's not even a full slush prok, there are 14:44.480 --> 14:49.200 some things that are missing, so the containerized process. 14:49.200 --> 14:54.480 How can it open a document, that breaks the question, how can it do that? 14:54.480 --> 15:01.160 Well, opening is also like, that does not happen, there is actually a second filter 15:01.160 --> 15:04.920 that this allows the open system code. 15:04.920 --> 15:14.000 What does happen is that the container is a divider, intercepts the open system code. 15:14.000 --> 15:19.480 It re-implements it with an IPC code to a different sandbox, where a go-for process run 15:19.480 --> 15:26.720 with a part of divider, and in that sandbox, it opens a document, and, in fact, it cannot 15:26.720 --> 15:32.160 even read it or write it, it can just open it, it can pass back the file descriptor to 15:32.160 --> 15:37.240 the caller, and that caller can read or write it. 15:37.240 --> 15:41.400 So in practice, if you manage to point any of those two sandboxes, you cannot interact 15:41.400 --> 15:45.680 in the file system, you have to point both, let's say. 15:45.680 --> 15:52.560 In just for kicks, you're seeing a process here, that's also like, that's not the case, 15:53.520 --> 15:59.440 the divider sandbox, there's not even have exactly, it's a knight actually, the exact 15:59.440 --> 16:00.440 system code. 16:00.440 --> 16:07.880 It can only fork stuff, so basically there's a goal, there's a goal team, which kind 16:07.880 --> 16:16.880 of runs the code of the cell, what we're seeing here, using long jump and all that. 16:16.880 --> 16:22.720 So yeah, you can see that divider takes some serious steps in order to try to isolate 16:22.720 --> 16:28.120 stuff as much as possible, and we're very interested in trying that out. 16:28.120 --> 16:36.520 Problem is, we are users, or journalists, or activists, and they are on macOS and Windows 16:36.520 --> 16:41.840 predominantly, there's no that much Linux involved, and also even on Linux, using divider 16:41.840 --> 16:45.760 requires some manual installation steps, and we can't have any of that, we can't have 16:46.080 --> 16:48.840 extra installation steps for our users. 16:48.840 --> 16:59.600 So we want to use divider, it's available on Linux, if only there was a way to use divider 16:59.600 --> 17:08.280 on Windows and macOS, and that got us thinking, what if we could containerize divider? 17:08.280 --> 17:14.760 If we could containerize divider, we could run it in our Docker desktop VM that are users 17:14.840 --> 17:23.040 run, it's a prerequisite, notice you run our, in order to run the divider zone. 17:23.040 --> 17:28.840 And that, in turn, this container could create a nested container, which could run the 17:28.840 --> 17:32.440 actual code. 17:32.440 --> 17:34.760 And that's what we did. 17:34.760 --> 17:40.720 Don't mind not the right side of these slides, it's just the code for those who want 17:40.720 --> 17:43.320 to try at some point. 17:43.320 --> 17:52.480 So essentially, what I wanted to show you here is how easy it kind of was to do it, 17:52.480 --> 17:55.840 well, easy, painless, let's say. 17:55.840 --> 18:02.520 We, what we did, is that created, that we created two container images, basically. 18:02.520 --> 18:07.360 We took the original container image from our Docker file with no modification, and we added 18:07.360 --> 18:11.920 it as a multi-stage build to a new layer. 18:11.920 --> 18:15.120 In other end, in that layer, we installed divider. 18:15.120 --> 18:19.800 So there's just divider and that container image there. 18:19.800 --> 18:26.640 We did this, in order to create two container images with two different purposes. 18:26.640 --> 18:32.440 The outer container image will be the one that contains our logic and contains divider 18:32.440 --> 18:33.440 as well. 18:33.440 --> 18:38.120 It's basically the possibility layer in order to provision divider to our Windows and 18:38.120 --> 18:39.600 Mac OS users. 18:39.600 --> 18:43.400 The inner container image is where the actual fun happens. 18:43.400 --> 18:53.680 The divider runs this container, and it's where our logic sanitizes the documents. 18:53.680 --> 18:56.280 Now, how do we run the inner container image? 18:56.280 --> 19:04.360 We have an entry point script, which takes the command that you want to run, and creates 19:04.360 --> 19:07.640 generates an oceanic config on the fly. 19:07.640 --> 19:08.640 It drops everything. 19:08.640 --> 19:15.880 It drops our ability, it drops, it runs as an previous user, it masks some system 19:15.880 --> 19:16.880 paths. 19:16.880 --> 19:21.200 If you want to, it drops resource limits, it makes it make the root of the first 19:21.200 --> 19:24.480 re-dominant node up. 19:24.480 --> 19:32.160 And then we run divider, rootless, within our outer container image. 19:32.160 --> 19:36.240 And finally, how do we run all those things? 19:36.240 --> 19:40.560 How can the danger of an application run this call, bag of things? 19:40.560 --> 19:45.800 So we have, we run, we run Python. 19:45.800 --> 19:50.720 So what we do is that we call Docker. 19:50.720 --> 19:52.240 And we call Docker. 19:52.240 --> 19:54.120 We follow the mitigations I have mentioned before. 19:54.120 --> 19:55.360 So we drop privileges. 19:55.360 --> 19:59.680 We have, we drop abilities and all that. 19:59.680 --> 20:04.520 However, in order to run divider, one would expect that we will need to add a few extra 20:04.520 --> 20:05.520 things. 20:05.520 --> 20:09.640 It turns out, we need to add just a tiny bit more. 20:09.640 --> 20:17.640 We need to add the sisterhood capability, which is added by default, actually, in most 20:17.640 --> 20:18.640 containers. 20:18.640 --> 20:23.000 The P3 system called the second profile, which is again added by default nowadays, it 20:23.000 --> 20:26.800 was only for like four years ago, it was not there. 20:26.800 --> 20:31.040 And we set the container identity as a Linux label. 20:31.040 --> 20:36.480 Fun fact, this means that this whole, crazy thing, this whole nest, the container thing, actually 20:36.480 --> 20:43.280 runs its systems with S. Linux and forced, divider cannot run in S. Linux and forced systems. 20:43.280 --> 20:45.360 They do not have support for that. 20:45.360 --> 20:52.600 But by doing this thing, we can essentially do it. 20:52.600 --> 20:56.480 And that's the final architecture. 20:56.520 --> 21:02.160 We now have an isolation layer between our application and the kernel. 21:02.160 --> 21:09.040 Now, if an attacker wants to escape to the host, they need to find a flow in divider and 21:09.040 --> 21:10.880 they need to find a flow in the Linux kernel. 21:10.880 --> 21:13.440 So they can do that, sure. 21:13.440 --> 21:17.800 But it raises significantly the barrier to do that. 21:17.800 --> 21:19.480 It raises the cost to do that. 21:19.480 --> 21:23.720 You have to burn the exploits that are pretty huge, because currently there's no divider 21:23.720 --> 21:26.240 expert out there. 21:26.240 --> 21:32.000 So yeah, thanks for listening. 21:32.000 --> 21:37.000 On the right there are ways to get involved, if you want to, divider actually integration 21:37.000 --> 21:45.080 was from a user of ours, and yeah, that's all. 21:45.080 --> 21:47.680 I'm happy to hear any questions as you may have. 21:47.680 --> 22:10.240 Thank you, any questions? 22:10.240 --> 22:11.240 Hello. 22:11.240 --> 22:13.080 Thanks for your presentation. 22:13.080 --> 22:17.200 You said it was a desktop application, so you need to manage the UI, how do you manage 22:17.240 --> 22:24.480 easily the UI with the, as it's containers? 22:24.480 --> 22:31.200 Our users, if you haven't heard the question, it's how you have a way to manage documents. 22:31.200 --> 22:34.560 We have the UI, how do you see the documents? 22:34.560 --> 22:38.160 The containers, we have the UI, I think that's a question, right? 22:38.160 --> 22:43.880 So again, our users are not technical, so we do not show anything about the containers. 22:43.880 --> 22:48.840 We hide this part that they're even used, actually. 22:48.840 --> 22:56.480 What they do know is that they need to open Docker desktop and have it sit there, and 22:56.480 --> 23:03.560 we do everything other food, so they are not aware of something like that. 23:03.560 --> 23:20.280 Another question? 23:20.280 --> 23:28.360 A question that I'm having is, you said that you parse the documents to take it there, 23:28.360 --> 23:33.480 malicious, and then you return them as pixels, and you transfer them back to documents. 23:33.480 --> 23:41.560 How do you not intercept with the original bytes that were, how do you turn them back to 23:41.560 --> 23:43.560 the original bytes? 23:43.560 --> 23:49.240 Or you're just transfer anything to optical for the original documents? 23:49.240 --> 23:57.000 Yeah, good question, so the question is, by doing that by making a printout, let's say 23:57.000 --> 24:01.440 of the document, and then scanning it, how can you return to the original format? 24:01.440 --> 24:09.360 The answer is that we can't, this is a destructive process, we cannot trust anything 24:09.360 --> 24:17.080 in the document, and there's no easy way to reconstruct that format aside for the OCR that 24:17.080 --> 24:31.000 I mentioned, so yeah, we have still time for more questions if they're running. 24:31.000 --> 24:37.080 So you said this is as close as possible to VM level parity for security, why not just use 24:37.080 --> 24:41.720 a VM, like what advantage does do it all this stuff give you? 24:41.720 --> 24:46.000 Good day, question, I was hoping for that, actually. 24:46.000 --> 24:49.520 Kind of use a micro VM, that would be my question. 24:49.520 --> 24:53.840 First of all, we do use VMs, Docker desktop is a VM, let's say. 24:53.840 --> 24:55.680 So we do have that. 24:55.680 --> 25:01.840 Docker desktop does not contain that well, because it has access to the network by default 25:01.840 --> 25:06.040 and it has access to the host file system, it needs to be in order to mount files. 25:06.040 --> 25:10.960 So we don't consider it a VM for the isolation pair, which is what we care about. 25:10.960 --> 25:13.040 So why not a micro VM? 25:13.280 --> 25:20.080 Personally, I had searched about micro VMs that could be used in Windows, in MacOS, and various 25:20.080 --> 25:27.440 flavors of Linux, and to my experience, micro VMs are some of those, I think one, pretty 25:27.440 --> 25:33.040 no one was available in MacOS, but none that was available in all those operating systems 25:33.040 --> 25:41.040 sent, supporting that many flavors of Linux, some micro VMs, and some other micro VMs 25:41.360 --> 25:43.360 that would be very difficult for us. 25:43.360 --> 25:47.160 We are very small team, you know, to do that, so that's the answer. 25:47.160 --> 25:53.720 If someone knows some platform agnostic, and promoted platform micro VM, that could help us, 25:53.720 --> 25:56.720 I'll be your, I am all ears. 25:56.720 --> 26:01.120 Yes, is it possible to find the slides online? 26:01.120 --> 26:03.720 That's my first question. 26:03.720 --> 26:10.560 Yes, my second question, I didn't really catch how the user get back the output of the, let's 26:10.640 --> 26:17.040 say the pixels or the image, do they get it as a file back, or like, is it shown in the application, 26:17.040 --> 26:24.480 itself in the UI, or yes, okay, so two questions for those in the stream, if we can get the slides 26:24.480 --> 26:30.480 online, I will upload them soon after the talk, and add the Google talk link soon. 26:30.480 --> 26:38.960 As for the output, the user gets back, they do not see pixels, of course, it will make sense, 26:38.960 --> 26:47.680 but the user gets back a PDF in the file system, they choose a suffix, and the PDF will be created there, 26:47.680 --> 26:55.600 it will be called a safe PDF, and that PDF will be the optical thing of the original PDF. 26:55.600 --> 27:00.400 The original PDF in order to not accidentally click on it, because we have to think, 27:00.400 --> 27:06.400 security is very good, now that we can add the output as much as we want, but people will click on 27:06.400 --> 27:14.320 the thing by mistake, so we move it to an unsafe file, we call it unsafe, that's the answer. 27:15.600 --> 27:22.720 I have a question, if I understand the workflow correctly, your UI application ensures that the 27:22.720 --> 27:29.760 Docker pulls the current image of your container and for processing the documents, how often do 27:29.840 --> 27:33.520 you release those containers when there is some bug? 27:33.520 --> 27:43.520 Right, so currently, the question is, if there is a Docker pool, we have an image out, 27:43.520 --> 27:48.240 how often do we do these releases? It's worse than that, there's no Docker pool in both 27:48.240 --> 27:57.680 actually. That's a baguette from the first versions of the engine zone. The container 27:57.680 --> 28:04.160 image is actually baked within the application, so we don't only have to create a container image, 28:04.960 --> 28:10.880 we also have to see a whole new application to everyone. How often do we do it? We try to do it 28:10.880 --> 28:23.120 every two months or something, and if there's a CV that we detect, as we have done in 24th of December, 28:23.760 --> 28:29.440 previous year, we will do a release then on 24th of December for crying out loud. 28:29.440 --> 28:33.920 Okay, thank you, we're out of time, and thank you very much. Thanks a lot. 28:37.920 --> 28:41.920 No, thanks a lot.