WEBVTT 00:00.000 --> 00:08.440 Hello, so first of all, thank you so much for staying here this late. 00:08.440 --> 00:12.520 I know that this is how it collides with the Linux Foundation event, so I have to get the 00:12.520 --> 00:13.520 Internet. 00:13.520 --> 00:19.360 I'm Daniel, I'm the software engineer, Vahat, and I'm also somehow trying to run the BPFC 00:19.360 --> 00:25.720 group in Fedora, and I would like to talk to you a little bit about BPS programs and how 00:25.720 --> 00:26.720 you run those out. 00:26.720 --> 00:30.800 It's first of all, so I can get a little bit of a vibe, and how many of you have 00:30.800 --> 00:33.720 ever run a BPFC program? 00:33.720 --> 00:42.900 I've known root, okay cool, but because you don't want, okay, so in non-usein kernel 00:42.900 --> 00:49.360 capability, okay cool, so I think that's going to be interesting, so basically I want to 00:49.360 --> 00:53.640 speak, and this is the main topic about the whole session, about the privilege program, 00:53.640 --> 00:58.280 so as you have been noticing most of the people when they run BPS program, they just say 00:58.280 --> 01:02.080 okay, let's do it in just a fruit, and that's a little bit of a main issue, as when 01:02.080 --> 01:06.880 you first start doing anything in Linux, you will have a fruit, then things work, that's 01:06.880 --> 01:13.040 work, and suddenly you notice and you realize that this is not a good practice, so 01:13.040 --> 01:17.800 then a some point you realize that there is a thing called kernel capabilities, is there 01:17.800 --> 01:22.600 anyone here who's not familiar at all with kernel capabilities, okay, then you're good 01:22.840 --> 01:29.840 but when a BPS was first a thing, it was just using Capsis admin, so that's basically 01:29.840 --> 01:34.600 okay, I'm giving you root access to my system, and you're happy to be able, and things 01:34.600 --> 01:39.800 that work again, so what's same before, but again this is not the best practice at all, 01:39.800 --> 01:46.240 then at some point BPS realized that okay we better go and create one specific capability 01:46.240 --> 01:52.880 for BPS, so that's how we got BPS here, so you can just go and look programs and create 01:52.880 --> 01:57.480 maps, but depending on what you want to do, so let's assume we just got C-scope today 01:57.480 --> 02:03.120 and it's a while in costiness, so let's assume I want to just create an XTP program, this 02:03.120 --> 02:06.400 wouldn't be enough, but you would also need to hurry up and update that into anything 02:06.400 --> 02:12.920 directed when it works in, and there it goes, so basically if you're following me, the 02:12.920 --> 02:16.820 dependency in the privileged program program is still yours alone because you're 02:16.820 --> 02:24.360 keeping in the end root access to your BPS program, so this may lead to let's assume we are 02:24.360 --> 02:30.360 working into Kubernetes here this days, we are running containers, but we may not want to 02:30.360 --> 02:33.960 run a privileged containers, which again would be, again, giving you root access to your 02:34.040 --> 02:44.360 host system, which is not a security goddess in points, so not only, sorry, not only containers, 02:44.360 --> 02:51.880 but you say you may not be happy and specifically in linguistic distributions, because nobody 02:51.880 --> 02:56.280 would like to, there's also things that would be speaking about later, but I see Linux and so forth, 02:56.280 --> 03:00.680 which may be not be happy for you doing all these things, and basically you get too many 03:00.680 --> 03:07.240 privileges, so don't call us BPS talking, what a hell this is, so a BPS talking, the main 03:07.240 --> 03:13.400 idea of that is a little bit like, let's say I'm a privileged user or root whatever, and I'm 03:13.400 --> 03:20.280 going to be giving you access to run BPS programs, but let's go and create such so much 03:20.280 --> 03:27.480 more granularity and scope related, and reduce it, you're reduced way of doing so, so basically 03:27.560 --> 03:35.240 we are going to be having, I make an issue to run this, so just in case you don't know, 03:35.240 --> 03:41.560 BPS uses a pseudo file system, so you can mount it, and you can create a token, then the user 03:41.560 --> 03:46.280 would be opening a token, and then you would have BPS access, but in a limited way, because for 03:46.280 --> 03:52.520 instance, let's assume we are yes using a BPS program, so it's a BPS top, or I just want to 03:52.520 --> 03:58.920 create a K-probe, I may not want to have access to, let's say, open a socket for networking, 03:58.920 --> 04:04.840 it wouldn't make sense at all, and this is going to be a huge, like security risk, again, 04:05.880 --> 04:09.560 modern related distributions, as in our case Fedora, aren't happy with that thing, 04:11.400 --> 04:16.520 so again, how does this works? It's pretty much what I said, but we are going to be speaking 04:16.520 --> 04:21.080 with a little bit with you about like the delegations, the locations are in the scope of the 04:21.080 --> 04:26.680 BPS token, putting that select capabilities, so you can, again, say I'm going to be giving you 04:26.680 --> 04:31.720 access to a limited amount of programs or commands, I'm going to be giving you a limited amount 04:31.720 --> 04:39.080 of permissions in terms of BPS maps, let's say memory, and this is going to be even fine with 04:39.080 --> 04:47.160 very far, so it's totally fine, how does this works? So you trust me, again, there's some 04:47.160 --> 04:52.360 capital dot, but I didn't explain that here, and by the way, you can see there's like there 04:52.360 --> 04:57.560 in the link, this is already in the production links, feel free to load that, so there's a few 04:57.560 --> 05:02.600 things that you can do in terms of delegations, so you can set commands, you can restrict the 05:02.600 --> 05:08.760 list of times that are going to be running, program types, and also attachments, so I put an example 05:08.760 --> 05:16.600 here, is this big enough to make it bigger? Okay, cool, so let's say we are going to be creating 05:16.680 --> 05:22.600 we can load maps, we can create maps, we can load programs, we can create maps arise, but I'm only 05:22.600 --> 05:27.880 going to be using a K-drop in a trace point, which makes sense, if I just want to do something 05:27.880 --> 05:33.640 we can get in trace of okay traces, you can do whatever you like with that, you're not limited to that, 05:33.640 --> 05:38.520 but you can also, let's assume we are using, I don't know, the modern network can see and I 05:38.520 --> 05:46.840 plug in, see we would do something like that, but also allowing to mount to access networks, 05:46.840 --> 05:53.800 to create sockets and so forth, it's an example also for trace only talking, it's pretty much 05:53.800 --> 05:59.400 the same, but what we are doing here, so we first as an admin, as a route, we created token itself 06:00.200 --> 06:07.080 which is a kernel object, and we are basically later on allowing the user, which is a developer, 06:07.080 --> 06:13.080 whatever, so we created the group called developers, what what's happening with this, so now 06:13.080 --> 06:18.440 developers and anyone in the developer's group would be able to run programs, but they wouldn't 06:18.440 --> 06:23.000 be able to load traffic control or exhibit programs that could totally mess up with that, with 06:23.000 --> 06:29.080 this what we are creating is a much higher level of granularity with that because we are allowing 06:29.080 --> 06:33.480 people to run things in our systems, but in a controlled way, so we don't know for them to be 06:33.480 --> 06:39.960 route, and we don't know and need them to be having a much more big enough capability, like 06:39.960 --> 06:46.600 I'm going to capture you so I mean, as I said before, or it can be bad. So, this is just, 06:46.600 --> 06:53.000 I'm not going to demo that later, using like batch and so forth in a Linux kernel, but I like 06:53.000 --> 06:57.720 Rust, like, yeah, if you go, I guess last year, I was just speaking about AIA and a few different 06:57.720 --> 07:03.080 libraries, for the ones that you don't know, AIA is a pure Rust native, EVPS library, which makes 07:03.160 --> 07:07.400 your light match easier, because this supports BbF talking out at the blue, as long as you are 07:07.400 --> 07:15.880 running a Linux with a kernel higher than 67, which is no normal thing. Again, this is pure Rust native, 07:15.880 --> 07:21.880 so going with me with some AIA attachment, but how do I load the brand we're talking in AIA? 07:22.440 --> 07:27.080 It's pretty much the same, so we are checking if the talking exists, we're creating that here, 07:27.400 --> 07:34.360 and then if it exists, apply it and then we can load the program directly. So, no pseudo, 07:34.360 --> 07:40.360 no root, no capability, just simple code in Rust, a couple of lines, is just works, and I think 07:40.360 --> 07:47.320 it's one of the best Rust examples you can find here. But again, with no Rust here, let's see, 07:49.320 --> 07:53.880 compile, it gets there, so come with me with a demo, I got what it intended to be a live demo, 07:53.880 --> 07:59.720 but it didn't work the day, so I got a video, how long? So let's assume that the program that I was 07:59.720 --> 08:05.160 speaking before, we got the AIA treasure and we are trying to run it as this, without any talking, 08:05.160 --> 08:10.440 it will tell you no, no, no, no, how long it will wait, but we are expecting. So, let's see the talking, 08:11.240 --> 08:16.600 so here we are creating a mount in the token and we are allowing it to use K-pop, and now we are 08:16.600 --> 08:21.080 as I was saying before, allowing the developer, to access that and change it the permissions. 08:21.080 --> 08:28.080 So now it's going to be using the BF token, the ligation is going to be loading, and then 08:28.080 --> 08:29.080 you're happy. 08:29.080 --> 08:30.080 It works. 08:30.080 --> 08:31.080 It's the same binary, same user. 08:31.080 --> 08:34.080 Now just using the token, no root comes here, no pseudo. 08:34.080 --> 08:36.080 No, no, no, no, no probability of no permissions. 08:36.080 --> 08:39.080 Which I think is pretty much in a better way. 08:39.080 --> 08:46.080 So again, if you try to load a program that is not allowed by the token, it will just 08:46.080 --> 08:49.080 missively fail in the same way, that's to be expected. 08:49.080 --> 08:55.080 Because why would I allow any user to run a TC or XCP program if I just want to have 08:55.080 --> 08:56.080 a k-pro? 08:56.080 --> 09:04.080 So again, no, I said, I'm an FADOR contributor, I'm a FADOR researcher, tomorrow we got a whole 09:04.080 --> 09:08.080 death run about distributions, and I'm going to be speaking about this in way much more detail, 09:08.080 --> 09:10.080 but why don't we care about that? 09:11.080 --> 09:19.080 In the distribution, we care about security, interoperability, we care about having shared 09:19.080 --> 09:24.080 dependencies in order not to have another load, and when we pack it to staff, we lack for 09:24.080 --> 09:30.080 that to be able to be handed to the users in a safe or interproducible, and limit the 09:30.080 --> 09:31.080 permissions way. 09:31.080 --> 09:33.080 Just think about the links. 09:33.080 --> 09:39.080 So what we are thinking about in the FADOR CIGR for EPPF is to interact in this directly, 09:39.080 --> 09:42.080 with the encoding and our build systems. 09:42.080 --> 09:48.080 So for instance, we can have a system of unit, and this can be controlled, yes, a rootless 09:48.080 --> 09:49.080 system services. 09:49.080 --> 09:53.080 So let's say business system D, as a service, what did we do in the beginning? 09:53.080 --> 09:58.080 It would just mount the BPF token, assign the permission, and it would just work, 09:58.080 --> 10:00.080 and we don't need to run this as a pseudo at all, ever. 10:00.080 --> 10:04.080 In fact, one of the things that we were thinking about is just in FADOR, there's going to be 10:04.080 --> 10:11.080 a proposal for DOR 45, about creating by default an EPPF group, and that's in the same way 10:11.080 --> 10:12.080 as you do wheel. 10:12.080 --> 10:15.080 I mean, no pseudo here, yes, don't miss the things out. 10:15.080 --> 10:21.080 What we can do is like creating a new group called BPF, which would create a token by default, 10:21.080 --> 10:26.080 and they wouldn't have over permissions to people to run BPF tokens. 10:26.080 --> 10:28.080 How do we do that? 10:28.080 --> 10:29.080 Which permissions do we get? 10:29.080 --> 10:33.080 This is not something that's covered with session, but we'll discuss tomorrow. 10:33.080 --> 10:38.080 So, and this also applies a set before the boardman. 10:38.080 --> 10:43.080 So, is anybody using non-wrotless containers important here? 10:43.080 --> 10:45.080 No, nobody. 10:45.080 --> 10:46.080 So that makes sense. 10:46.080 --> 10:48.080 And you may ask me about the two links policies. 10:48.080 --> 10:51.080 This is, as of now, a big issue. 10:51.080 --> 10:57.080 So one of the things that we have to work into the links distributions is about adding 10:57.080 --> 10:58.080 a new scheduling policy. 10:58.080 --> 11:04.080 That would allow you to run BPF token as a default without being screaming no hell in 11:04.080 --> 11:09.080 way, and I don't want to run this into a permissive mode or disabled mode. 11:09.080 --> 11:10.080 So that? 11:10.080 --> 11:11.080 I would like for you. 11:11.080 --> 11:16.080 If you want to help on that, as I said, it's going to be a new proposal for DOR 45. 11:16.080 --> 11:18.080 You want to get involved. 11:18.080 --> 11:24.080 You have ideas about how to basically coordinate and elaborate on this with Fedora. 11:24.080 --> 11:30.080 We are totally welcoming you to come with us and discuss this out. 11:30.080 --> 11:36.080 Because I think it's a big enough topic that both allow links distributions to run BPF programs 11:36.080 --> 11:41.080 basically in a no-it-a-routlet mode, which is like everybody would like to. 11:41.080 --> 11:43.080 And so far, let me quickly go. 11:43.080 --> 11:44.080 I got a demo. 11:44.080 --> 11:47.080 So, let me quickly go through that. 11:47.080 --> 11:55.080 Can you see my screen? 11:55.080 --> 11:58.080 Bigger? 11:58.080 --> 12:00.080 How about now? 12:00.080 --> 12:01.080 Awesome. 12:01.080 --> 12:02.080 Thank you. 12:02.080 --> 12:04.080 So these morning, I can tell you, this demo works. 12:04.080 --> 12:07.080 Then I came to the closing that work and didn't work. 12:07.080 --> 12:08.080 And it's not working. 12:08.080 --> 12:10.080 But I recorded it just in case. 12:10.080 --> 12:12.080 Which I think it's a safe measure. 12:12.080 --> 12:15.080 So let's go through it. 12:15.080 --> 12:19.080 So here, we are going to be taking the kernel and the current BPF loans. 12:19.080 --> 12:22.080 As I said, higher than 67. 12:22.080 --> 12:25.080 And then we got it here. 12:25.080 --> 12:28.080 We got the tokens and it'll get in mount. 12:28.080 --> 12:32.080 So now we can see other legations in the mount. 12:32.080 --> 12:37.080 The amount has those other legations that I was speaking about before. 12:37.080 --> 12:39.080 Okay, preference of four. 12:39.080 --> 12:42.080 Then we're going to be running as a regular user. 12:42.080 --> 12:48.080 And this one worked as a blue because of this is intended to use fs open and not dry 12:48.080 --> 12:49.080 mount. 12:49.080 --> 12:51.080 But let's go and create a container. 12:51.080 --> 12:56.080 Then a regular container would just run as it was before. 12:56.080 --> 13:00.080 This is using containers already do the fs open thing for you. 13:00.080 --> 13:02.080 You don't have to do the thing. 13:02.080 --> 13:04.080 And then main difference on that. 13:04.080 --> 13:08.080 Let me actually put that a little bit there because it was running high on the thought. 13:08.080 --> 13:14.080 So inside the container. 13:14.080 --> 13:16.080 So and yes, you just regard it. 13:16.080 --> 13:17.080 The percated volatility. 13:17.080 --> 13:18.080 This is not in front of man. 13:18.080 --> 13:19.080 But we are using. 13:19.080 --> 13:21.080 This is a rootless container. 13:21.080 --> 13:23.080 It's the root within the container. 13:23.080 --> 13:27.080 But this has been run as a regular user. 13:27.080 --> 13:30.080 We can now mount the BPF B profile system here. 13:30.080 --> 13:34.080 Which means that we can just access the maps and access whatever we want to. 13:35.080 --> 13:38.080 You can see that we are able to access that. 13:38.080 --> 13:41.080 And in the real setup within BPF token. 13:41.080 --> 13:45.080 We can use the BPF token create or just a within the container. 13:45.080 --> 13:47.080 And this would just work. 13:47.080 --> 13:53.080 Without having any previous host, which will again run in the container that's worked within our system. 13:57.080 --> 13:59.080 Coming back to here. 13:59.080 --> 14:01.080 What time is it? 14:01.080 --> 14:02.080 Yeah. 14:03.080 --> 14:06.080 So again in the BPF group. 14:06.080 --> 14:08.080 What we are working into. 14:08.080 --> 14:14.080 To first, one of the things we are interested for further 45 is to add packaging guidelines for 14:14.080 --> 14:16.080 BPF with token. 14:16.080 --> 14:18.080 Half a default token. 14:18.080 --> 14:22.080 That is what I was speaking about like creating the new BPF group. 14:22.080 --> 14:23.080 And so forth. 14:23.080 --> 14:25.080 At support for as a leaner. 14:25.080 --> 14:28.080 And also we would like to have this direct support. 14:28.080 --> 14:30.080 And we would like to have this document using an option. 14:30.080 --> 14:32.080 And documentation of course. 14:32.080 --> 14:33.080 So if you want to get involved. 14:33.080 --> 14:34.080 We got a week here. 14:34.080 --> 14:35.080 Not so if it's speaking enough. 14:35.080 --> 14:38.080 But you can check it out in the slides which are available in the room. 14:38.080 --> 14:42.080 So with these questions. 14:53.080 --> 14:54.080 Hi. 14:54.080 --> 14:56.080 Thanks for the call. 14:57.080 --> 15:02.080 Is there any plan to get on board with that idea? 15:02.080 --> 15:08.080 With various security vendors that are working on the Inux. 15:08.080 --> 15:12.080 That would be like Microsoft, like Central Wall, like Crop Strike. 15:12.080 --> 15:16.080 Can we get them on board with the tail? 15:16.080 --> 15:17.080 Are there any questions? 15:17.080 --> 15:21.080 Is that way of interact with BPF? 15:21.080 --> 15:22.080 Not only. 15:22.080 --> 15:23.080 But first. 15:23.080 --> 15:26.080 What I will be working into is a proposal for $4.45. 15:26.080 --> 15:27.080 Once that we are there. 15:27.080 --> 15:30.080 That's going to be a point for comments to anybody. 15:30.080 --> 15:33.080 And of course I would like to include security. 15:33.080 --> 15:36.080 People in other companies because. 15:36.080 --> 15:39.080 The main idea is that this would become somehow standard. 15:39.080 --> 15:46.080 Not only type to Fedora, but open to any news distribution that would deliver it to that. 15:46.080 --> 15:50.080 I know another hand before. 15:50.080 --> 15:52.080 Thank you for the talk this. 15:52.080 --> 15:53.080 Don't just look amazing. 15:53.080 --> 15:56.080 I'm doing Netful Programming with TC and ITP. 15:56.080 --> 15:58.080 So I'm interested in. 15:58.080 --> 16:00.080 My problem is reverse. 16:00.080 --> 16:01.080 Who? 16:01.080 --> 16:03.080 With XP and TC. 16:03.080 --> 16:08.080 You typically need birth month because you compare pointers. 16:08.080 --> 16:11.080 And it's care is that in the working program. 16:11.080 --> 16:13.080 Can reader be treated care not memory. 16:13.080 --> 16:17.080 Are there any plans to restrict not on the net tax and program plans? 16:17.080 --> 16:21.080 But also helpers and K-fax. 16:21.080 --> 16:25.080 I mean, the main idea that I had in mind was to actually restrict. 16:25.080 --> 16:29.080 But I given that you get it enough access to the token. 16:29.080 --> 16:30.080 You can do anything. 16:30.080 --> 16:36.080 So if you need a net work TC or HP program that needs to follow the access. 16:36.080 --> 16:39.080 What you book me a link to do is to increase the scope of the token. 16:39.080 --> 16:41.080 And it should still help you work. 16:41.080 --> 16:43.080 I haven't tried it though. 16:43.080 --> 16:45.080 That's without reposition. 16:46.080 --> 16:50.080 I can't hear you, sorry. 16:50.080 --> 16:52.080 You need birth month. 16:52.080 --> 16:53.080 Yeah. 16:53.080 --> 16:55.080 Your problem can reach kernel memory. 16:55.080 --> 16:57.080 You need birth month for net working. 16:57.080 --> 17:04.080 But I'm really in a sort of program where they need to reach kernel memory. 17:04.080 --> 17:09.080 They just have birth month because it's necessary to direct packet access. 17:09.080 --> 17:11.080 I see what you mean. 17:11.080 --> 17:14.080 Well, I haven't asked that in mind. 17:14.080 --> 17:17.080 But I would definitely take a look when I brought the proposal. 17:17.080 --> 17:18.080 So thank you for that. 17:18.080 --> 17:19.080 Thank you. 17:23.080 --> 17:27.080 So just a hint to the colleague that has said about net working. 17:27.080 --> 17:28.080 I don't know. 17:28.080 --> 17:38.080 You can get away from direct packet access by using BPFDEN pointers for SKB payload. 17:38.080 --> 17:42.080 At least for TC for HTTP or your stack with direct packet access. 17:42.080 --> 17:44.080 And I had a question for Daniel. 17:44.080 --> 17:50.080 You know, does BPFFS support file system ACLs? 17:50.080 --> 17:56.080 Or we're stuck with just user and group of traditional file permission. 17:56.080 --> 17:57.080 That's so far. 17:57.080 --> 18:01.080 It's not that it doesn't have that support, but I wouldn't need to take it. 18:01.080 --> 18:03.080 So we can just take it out later. 18:03.080 --> 18:04.080 All right. 18:04.080 --> 18:05.080 Thanks. 18:08.080 --> 18:20.080 There have been dozens of CVs in the very fire in the last years. 18:20.080 --> 18:26.080 Some of them you know, like to write and modify kernel memory at runtime. 18:26.080 --> 18:33.080 Do you think about that when you say that's a good idea to allow none privileged users to load any arbitrary 18:33.080 --> 18:35.080 BPF program into the kernel? 18:36.080 --> 18:38.080 Well, this is a little different thing. 18:38.080 --> 18:41.080 So CVs would affect your regardless of you have to download. 18:41.080 --> 18:49.080 And we, as in Fedora, we are very, we got, we are really carried about CVs and so forth. 18:49.080 --> 18:56.080 Not only about BPF, but about, you wouldn't believe the amount of CVs that we've seen the more minor things. 18:56.080 --> 19:01.080 Given that, I said that if you were to study enough, it would be the same up, you know, 19:01.080 --> 19:04.080 allowing you to write to whatever. 19:04.080 --> 19:10.080 So these may be some good idea about trying to use as a Linux to some arbitrary data, 19:10.080 --> 19:14.080 but I believe you think about that when you're more detail when I write the scope. 19:14.080 --> 19:16.080 And I'll be publishing now and it's going to be public. 19:16.080 --> 19:19.080 So feel free to take a look and write any comments if you'd like to help us. 19:19.080 --> 19:20.080 Thank you for that. 19:20.080 --> 19:21.080 Thanks. 19:24.080 --> 19:26.080 Let's see a final question about that. 19:32.080 --> 19:35.080 Hi, Daniel. Thanks for the talk. 19:35.080 --> 19:37.080 I have two questions. 19:37.080 --> 19:42.080 The first one is, what is the lifespan of the token? 19:42.080 --> 19:45.080 Are they valid for forever? 19:45.080 --> 19:50.080 And the BPF program, just going to use that one day I'll load it. 19:50.080 --> 19:59.080 And the second one is, where can we find the actual permissions to actually configure? 19:59.080 --> 20:00.080 Sir. 20:00.080 --> 20:03.080 So the permissions themselves, it's like a, 20:03.080 --> 20:06.080 mainly done by the delegations I was telling before. 20:06.080 --> 20:09.080 So when you select the delegations that you're seeking the token, 20:09.080 --> 20:15.080 you're allowing it to use the comments and the specific BPF capabilities that you wanted to use. 20:15.080 --> 20:21.080 And secondly, about the lifetime of the token itself, that's something that we would need to discuss 20:21.080 --> 20:25.080 because if we think about like having, let's say, a defaulted BPF group, 20:25.080 --> 20:27.080 we may have that one that is forever. 20:27.080 --> 20:29.080 I think that's a terrible idea to be honest. 20:29.080 --> 20:31.080 So we should make it rotating as a fourth. 20:31.080 --> 20:36.080 And one of the things that I'm going to be discussing in the abstract is about like, 20:36.080 --> 20:38.080 how often do you need to rotate soft secret? 20:38.080 --> 20:43.080 So thank you for that too, but it'll be still a simple discussion. 20:43.080 --> 20:45.080 All right. 20:45.080 --> 20:47.080 Can you read the mic? 20:47.080 --> 20:48.080 Sorry. 20:48.080 --> 20:49.080 One more. 20:49.080 --> 20:50.080 Yes. 20:50.080 --> 20:54.080 So I work with embedded systems and my question is, 20:54.080 --> 21:00.080 did you consider also embedded systems when you designed this token management stuff, 21:00.080 --> 21:05.080 like purple, also for example, which is container-based, but for embedded systems? 21:05.080 --> 21:08.080 OpenWT, which is a smart traditional one. 21:08.080 --> 21:12.080 Well, I'm not an embedded engineer, so I didn't consider specifically embedded systems, 21:12.080 --> 21:17.080 but if you're interested, again, I'd be really happy to have it set later if you liked it. 21:17.080 --> 21:20.080 Or just when I put the abstract for there, 21:20.080 --> 21:22.080 but it should just be pretty much the same. 21:22.080 --> 21:26.080 So I was saying, like, any runtime of OCI runtime should work with this, 21:26.080 --> 21:29.080 as long as it has a kernel higher than six-seven. 21:29.080 --> 21:30.080 So it should just work. 21:30.080 --> 21:33.080 But I didn't test it specifically for embedded systems. 21:39.080 --> 21:44.080 So one interesting feature that I guess wasn't mentioned. 21:44.080 --> 21:48.080 I don't know if you're aware of it or not, but actually, 21:48.080 --> 21:53.080 I was really, it's really interesting to see that you mount a file system like this, 21:53.080 --> 21:55.080 and then add it to the container. 21:55.080 --> 22:01.080 One of the other approaches that is, like, really prominent in the initial patch set, 22:01.080 --> 22:07.080 in which this will introduce, is to create a map to essentially have two processes, 22:07.080 --> 22:09.080 which have a unique socket in between them, 22:09.080 --> 22:14.080 and then have the un-prevalent process created the BFFS, 22:15.080 --> 22:19.080 with the new FSS calls, 22:19.080 --> 22:25.080 then send that over the socket to the privileged process. 22:25.080 --> 22:27.080 So it can delegate the permission. 22:27.080 --> 22:28.080 Yes, it will. 22:28.080 --> 22:34.080 And then it sends it, and then that file descriptor you already have, 22:34.080 --> 22:38.080 don't even need to mount it on, like, on the path, 22:38.080 --> 22:43.080 and you can already use that file descriptor with those permissions. 22:43.080 --> 22:45.080 So it's in that model. 22:45.080 --> 22:49.080 So it's slightly different than directly mounting it to a path. 22:49.080 --> 22:53.080 But in that model, you can drop, like, you can close the file descriptor, 22:53.080 --> 22:55.080 and drop it from your permissions. 22:55.080 --> 22:58.080 So it is still voluntary. 22:58.080 --> 23:01.080 It doesn't expire, but you can, like, load your programs, 23:01.080 --> 23:04.080 and then just close the file descriptor, drop it from your options. 23:04.080 --> 23:07.080 Which is, perhaps, a really interesting idea. 23:07.080 --> 23:11.080 The other one is that, in system D and LXC, 23:11.080 --> 23:16.080 I can't remember which name it is, but they already implemented, 23:16.080 --> 23:19.080 like this mechanism natively. 23:19.080 --> 23:24.080 So in BPS system D units, you should already be able to just specify 23:24.080 --> 23:29.080 the delegated command, and it will just do the setup of the BFFS for you, 23:29.080 --> 23:32.080 and LXC does something similar. 23:32.080 --> 23:36.080 I haven't seen it anywhere else, and it will be really interesting to see, 23:37.080 --> 23:41.080 perhaps we could, this also would be part of OCI at some point. 23:41.080 --> 23:43.080 Yeah, but you can just specify it. 23:43.080 --> 23:45.080 I thought you would start in the problem level there. 23:45.080 --> 23:47.080 Yeah, that's just wanted to highlight that. 23:47.080 --> 23:49.080 In fact, I'm really curious about this, it's an integration, 23:49.080 --> 23:51.080 because of course I want to integrate up, 23:51.080 --> 23:52.080 even in existence of course. 23:52.080 --> 23:53.080 So yeah, yeah, thank you for that. 23:53.080 --> 23:54.080 Yeah. 24:00.080 --> 24:04.080 RRPPF tokens integrated with the Linux audit subsystem. 24:04.080 --> 24:06.080 I mean, that's what I was saying before. 24:06.080 --> 24:09.080 I mean, one of the goals for this scope of work 24:09.080 --> 24:13.080 would also to be to enhance a Linux to also support 24:13.080 --> 24:14.080 the amount of the D thing. 24:14.080 --> 24:16.080 Because so far, it would just kill you. 24:16.080 --> 24:17.080 Okay. 24:22.080 --> 24:24.080 Okay, there's no more questions. 24:24.080 --> 24:27.080 Thanks a lot for the organizers here for inviting me over, 24:27.080 --> 24:29.080 and for my family to have it alone me to come here. 24:29.080 --> 24:30.080 Thank you guys. 24:30.080 --> 24:31.080 Thank you very much. 24:34.080 --> 24:36.080 Thank you.