WEBVTT 00:00.000 --> 00:18.640 How are everyone, thank you for coming today, my name is Ibuki Omaz, our student 00:18.640 --> 00:27.480 and I will talk about KVT based security in RedoxOS and I will explain how we are 00:27.480 --> 00:34.880 making RedoxOS more secure by fundamental changing the way resources are accessed or 00:34.880 --> 00:42.960 managed within the system. Once again, my name is Ibuki Omaz, I am a student or Tokyo 00:42.960 --> 00:49.400 member of the college for industrial technology, Japan. I have been active contributor 00:49.400 --> 00:56.300 on RedoxOS since April 2025. I worked these projects in the next few months, I will get 00:56.300 --> 01:06.840 support and work FD passing support in Redox. Before we dive into the details, let me introduce 01:06.840 --> 01:15.400 about RedoxOS. Redox is a general purpose, like Michael Connor based operating system 01:15.400 --> 01:22.920 between Rust. Because it uses Rust, it is memory-safe by default. It prevents common 01:22.920 --> 01:31.320 bugs like buff-overflows and it uses Michael Connor architecture, this means drivers and 01:31.320 --> 01:39.240 services on user space. It improves the variety. It provides driver crashes, the system 01:39.240 --> 01:48.040 will save the life and we also maintain partial project compatibility, making it easier to 01:48.040 --> 02:01.240 relatively easier to put existing software. Finally, the RedoxOS is designed to 02:01.240 --> 02:09.000 be easy to extend and easy to improve. I looked at the architecture, the Connor is very small, 02:09.000 --> 02:19.040 less than 30,000 old code. In this design, the old services, like first systems, networking, 02:19.040 --> 02:28.840 also process management, manager, one separated programs in user space. We call these 02:28.840 --> 02:39.320 service providers, steam, steam. First, operations are handled by these schemes. And to support 02:39.320 --> 02:48.920 applications, we are developing revc. This is a system delivery which can enter in Rust. In 02:48.920 --> 03:00.440 Linux, it maps to grow system codes. But on Redox, it goes through Redox Rampine service. 03:00.440 --> 03:14.600 Work is ongoing to handle Redox Rampine. This means we can secure applications without 03:14.600 --> 03:18.920 were writing them. 03:18.920 --> 03:23.480 Before go deeper, let's define some key terminologies. 03:23.480 --> 03:28.200 Security in this context means minimize the risk 03:28.200 --> 03:31.360 if a program hijacked is hijacked. 03:31.360 --> 03:34.680 The sun-boxing risk-wifting program, 03:34.680 --> 03:42.120 so it can only access specific and contain environment. 03:42.120 --> 03:46.120 The other list is a simple take-a-space list 03:46.120 --> 03:48.360 of something that are allowed. 03:48.360 --> 03:52.040 An ambient also is the most unique system 03:52.040 --> 03:54.120 like rely on this. 03:54.120 --> 03:58.600 It allows the resources are accessed by their name, 03:58.600 --> 04:02.680 checked against the static, really defined punishments. 04:02.680 --> 04:06.720 This is an opposite of capability based. 04:06.720 --> 04:09.360 So what is capability? 04:09.360 --> 04:14.160 Think of it as an exposure token of authority. 04:14.160 --> 04:20.640 It refers to a specific resource with a set of rights. 04:20.640 --> 04:23.600 This is a similar to a five-discution, 04:23.600 --> 04:27.600 but it includes fine-grained permitted actions, 04:27.600 --> 04:30.800 such as ability to get the owner of this file 04:30.800 --> 04:36.000 or change setting terminal settings. 04:36.000 --> 04:39.600 And the application holds this token, 04:39.600 --> 04:43.200 but it exists in protected memory. 04:43.200 --> 04:46.320 So the application cannot forge it. 04:46.320 --> 04:53.040 In RIDAX, five-discuiter is a reference to a capability. 04:53.040 --> 04:59.520 Awex will this concept in more depth later in the talk. 04:59.520 --> 05:02.720 Now, we are learning from other operating systems. 05:02.720 --> 05:04.960 Pre-BSD has capsicum. 05:04.960 --> 05:12.560 It allows the program to enter capability mode to restrict itself. 05:12.560 --> 05:15.600 And the OpenBSD has pledge and unveil 05:15.600 --> 05:19.040 to restrict system codes and file passes. 05:19.040 --> 05:22.560 And SEO for also uses capabilities, 05:22.560 --> 05:26.800 but broadly for system resources. 05:26.800 --> 05:32.640 So this is a tool scope for the purpose of this presentation. 05:33.600 --> 05:38.560 Our main goal is making capability-based security. 05:38.560 --> 05:43.440 The main mechanism for providing services and using resources. 05:43.440 --> 05:46.640 It will serve as the infrastructure 05:46.640 --> 05:50.000 and then its standard project file discreters. 05:50.000 --> 05:57.520 And we will provide APIs, compatible with capsicum, 05:57.520 --> 06:01.360 wasn't washi, and possibly unveil. 06:01.360 --> 06:04.880 And we will also support multiple styles 06:04.880 --> 06:08.880 sandboxing, includes CH route and content. 06:08.880 --> 06:14.320 The content is our own lightweight containerization. 06:14.320 --> 06:20.160 Eventually, it capability will apply to every resources, 06:20.160 --> 06:27.600 such as memory and processes and a file, also file, and threads. 06:27.600 --> 06:32.000 In fact, processes and threads are already also 06:32.000 --> 06:33.920 capability in Redox. 06:33.920 --> 06:42.000 Since we define a file descriptor is our reference to capability. 06:42.000 --> 06:46.720 So here is the status of our current work. 06:46.720 --> 06:50.640 We initially focused on converting memory resources. 06:50.640 --> 06:54.480 To achieve this, we have separated project file discreters 06:54.480 --> 06:59.440 from the Redox internal law use file discreters. 06:59.440 --> 07:04.240 And move, name-based management out of the kernel 07:04.240 --> 07:06.320 to into the user space. 07:06.320 --> 07:11.680 And we also implemented file discreters sending. 07:11.680 --> 07:15.920 Soon, more general capabilities with the audit 07:15.920 --> 07:16.960 is a kernel. 07:16.960 --> 07:21.680 And file discreters will refer them directly. 07:24.480 --> 07:32.560 So this might be hidden from standard project applications, 07:32.560 --> 07:39.520 but it will change how the system works internally. 07:39.520 --> 07:44.800 Two hundred-cented changes, especially namespace management, 07:44.800 --> 07:51.680 we first need to review how Redox handles resources. 07:51.680 --> 07:55.760 So look, so talk about schemes. 07:55.760 --> 07:59.920 In Redox, the scheme identifies a service or driver. 07:59.920 --> 08:03.600 All resources are accessed by scheme with the best. 08:03.600 --> 08:09.840 Originally, we used legacy UI formats. 08:09.840 --> 08:15.440 Scheme name, columns, slash path to resources. 08:15.440 --> 08:19.360 That's why we still call them schemes. 08:19.360 --> 08:24.800 They originally corresponded to the scheme component of UI, 08:24.800 --> 08:32.080 but to improve compatibility, we moved to the current format, 08:32.080 --> 08:39.920 slash schemes, slash scheme names, slash path to resources. 08:39.920 --> 08:46.320 Let's argue the traditional file file for. 08:46.400 --> 08:53.200 This is how resources are accessed by scheme routed best. 08:53.200 --> 08:57.760 Application code, some file, with C-combats, 08:57.760 --> 09:02.160 it to obviously it's scheme routed best. 09:02.160 --> 09:06.480 The kernel, using global name space in the kernel, 09:06.480 --> 09:10.400 to find the target scheme and this part is a request. 09:10.400 --> 09:14.160 In this case, the file is the target scheme, 09:14.240 --> 09:17.840 and the open request will reach it. 09:17.840 --> 09:25.040 Finally, scheme API converts requests to file operations. 09:25.040 --> 09:31.680 In this model, the namespace logic lies inside the kernel. 09:31.680 --> 09:38.400 Our goal is making a change this. 09:38.480 --> 09:45.680 We want namespace to be capability, 09:45.680 --> 09:50.960 not just global identifiers bounded to our process. 09:50.960 --> 09:55.760 Key concepts of this transition is open-art system goal. 09:55.760 --> 10:00.960 Openart opens a file relative to the directory file descriptor. 10:00.960 --> 10:05.360 In an unrestricted mode, it is just a convenience. 10:05.360 --> 10:09.040 But if we, however, issue limited paths to ban is that 10:09.040 --> 10:16.640 jrxd, and rich-wicked program only open-art, 10:16.640 --> 10:20.720 jrxd effectively becomes a sandbox. 10:20.720 --> 10:27.440 A program cannot see or access anything outside the directory. 10:27.440 --> 10:32.320 Based on it, we have introduced the namespace manager in user space. 10:32.320 --> 10:36.720 It sits between an application and schemes, 10:36.720 --> 10:40.800 as on one of the user space scheme. 10:40.800 --> 10:41.760 Here is the file. 10:41.760 --> 10:44.000 Application calls open. 10:44.000 --> 10:48.160 We will see somewhat it to a relative open-art request 10:48.160 --> 10:52.080 using namespace, a process in namespace actually. 10:52.080 --> 10:55.920 Request will reach it, reach namespace manager. 10:55.920 --> 11:00.000 The namespace manager resolves the request, 11:00.000 --> 11:05.200 and call open-art on scheme routes. 11:05.200 --> 11:09.760 The application calls only operates relative to their provided namespace 11:09.760 --> 11:11.200 safety. 11:11.200 --> 11:14.960 This allows us to remove complex scheme and namespace 11:14.960 --> 11:18.240 management from the kernel. 11:18.240 --> 11:22.800 Now, currently schemes are created anonymously in the kernel. 11:22.800 --> 11:30.160 And they register themselves by themselves with their name 11:30.160 --> 11:32.560 and their scheme route directory. 11:36.560 --> 11:43.280 Next, let's go by for the concept of capability in redox OS. 11:43.280 --> 11:48.800 In redox, we don't distinguish resources and capabilities. 11:48.800 --> 11:54.160 Everything is a resource, and every handle is a capability. 11:54.160 --> 11:59.280 However, we can categorize them into two types. 11:59.280 --> 12:00.080 Two types. 12:00.080 --> 12:04.320 First is direct capabilities. 12:04.320 --> 12:12.080 These are handles that you directly operate on. 12:12.080 --> 12:20.320 This category includes what we call resource capabilities. 12:20.320 --> 12:24.880 This points to complete things like files, 12:24.880 --> 12:26.880 and permission capabilities. 12:26.880 --> 12:32.160 It's represents abstract rights. 12:32.160 --> 12:35.440 The second type is indirect capabilities. 12:35.440 --> 12:43.200 And this is a handle that's used as arguments or tokens. 12:43.200 --> 12:50.960 You don't read or write to directly dim directory. 12:51.920 --> 12:59.040 They pass us arguments. 12:59.040 --> 13:05.680 You pass them to verify your authority or providing context, 13:05.680 --> 13:11.920 like UIDFD or the directory FD. 13:11.920 --> 13:19.840 This leads us to how file discute works as capability handles. 13:19.840 --> 13:24.960 There is an important distinction we make here. 13:24.960 --> 13:31.440 For the application, the file discute is just an integer index 13:31.440 --> 13:33.600 into the table of references. 13:33.600 --> 13:41.600 But in the kernel, it maps to the file discution that stores the rights. 13:41.600 --> 13:46.560 You cannot touch file discution directly. 13:46.560 --> 13:50.320 So you cannot project them. 13:50.320 --> 13:59.200 Therefore, the policy in the open file discute is the proof of authority. 13:59.200 --> 14:08.000 Next, let's talk about how we grant capabilities. 14:08.000 --> 14:16.800 We can grant capabilities to a program by withdrawing them. 14:16.800 --> 14:24.800 First, the capabilities can be inherited by the process during folk and exec. 14:24.800 --> 14:32.320 Alternatively, we can grant capabilities to another program by sending it by a 14:32.320 --> 14:37.280 Unix domain socket or Redox native capability of wording. 14:37.280 --> 14:45.440 The once of capability was granted, the receiver has permission to use it. 14:45.440 --> 14:55.760 The scheme will not need to check UID, 14:55.760 --> 15:00.160 use the ID anymore as long as the capability is open. 15:03.200 --> 15:05.200 Look at the diagram. 15:05.200 --> 15:11.040 Here is how file discute is sending works. 15:11.040 --> 15:18.160 It is worth noting, file discute sending can be implemented all schemes. 15:18.160 --> 15:25.920 In this scenario, application A sends activities to application B 15:25.920 --> 15:31.200 via the scheme acting as relay. 15:31.200 --> 15:34.960 So application A sends activities. 15:34.960 --> 15:41.280 The kernel removes the activities from a file table and temporarily hold them. 15:42.880 --> 15:49.360 Then kernel notifies the number of the target scheme and number of 15:50.080 --> 15:59.520 activities and scheme obtained the activities and retrieves the indices of new activities. 16:01.520 --> 16:06.240 The orange ver indicates the client's location of 16:06.720 --> 16:14.400 activities. The kernel holds them so the orange ver moved to the kernel. 16:15.440 --> 16:23.040 The scheme obtained activities and retrieved the scheme indices, indices, 16:24.400 --> 16:29.920 orange ver next assist to the scheme. The scheme returns a response. 16:30.320 --> 16:35.360 At this point, the activities are effectively in the scheme context. 16:36.480 --> 16:46.560 For schemes, they only need to consume activities from another process. 16:46.560 --> 16:50.160 The work flow is end and ends here. 16:50.160 --> 16:55.440 But we want to send activities to application B. Let's continue. 16:56.160 --> 16:58.960 Next, application B request activities. 16:59.680 --> 17:05.120 The kernel notifies the scheme of number of activities. 17:06.000 --> 17:11.520 The scheme moves activities to the kernel to hold them. 17:13.440 --> 17:15.600 The orange ver sits back to the kernel. 17:17.120 --> 17:22.000 The scheme returns a response. 17:22.640 --> 17:30.640 Finally, the kernel adds activities to application B's file table and notifies the 17:30.640 --> 17:34.720 these indices of activities. 17:35.520 --> 17:45.200 With the work moves to application B's context, the file descriptor sending is complete. 17:46.080 --> 17:56.240 Next, let's look at how our sandboxing strategies. 17:58.000 --> 18:04.960 First, these features to support or implement two approaches. 18:05.360 --> 18:09.440 First is CH route, but it adapts to the kernel, 18:09.520 --> 18:16.880 and it adapts to the redox. In Linux, a process has single route, 18:17.600 --> 18:23.360 but on redox, we can have different routes for different schemes. 18:25.840 --> 18:29.760 The namespace manager maps, scheme name, and scheme routes, 18:30.560 --> 18:41.840 but however, the scheme routes don't need to be a scheme original route, 18:41.840 --> 18:44.240 and we can register the virtual route. 18:45.360 --> 18:54.240 For example, if we register a slash jail directory to ask a file scheme route, 18:55.200 --> 19:01.520 all access to the scheme file slash is automatically confined to slash jail slash. 19:03.120 --> 19:07.600 And we also have a tool for the content. 19:08.720 --> 19:14.400 This is this used trusted launcher to define an allow list of paths. 19:15.280 --> 19:24.000 This prevents confused safety proven by ensuring the process can only access 19:24.080 --> 19:33.760 exactly what launcher permits. Next, let's look at how to expand 19:35.840 --> 19:45.600 capabilities. In capability-based system, the programs usually start with limited rights. 19:46.480 --> 19:51.680 They can drop rights, but they cannot gain them by their own. 19:54.080 --> 19:59.280 To expand their scope, they must ask on outside agent. 20:00.000 --> 20:04.000 This is similar to Kaspersavis on 3bst. 20:07.280 --> 20:14.880 In redox, we use five disclosures sending mechanism to grant capabilities to a process. 20:15.840 --> 20:24.480 However, we will need our validation service to verify the request is also advised. 20:27.280 --> 20:36.560 Finally, this is a future work. We want to work five disclosures representation in 20:36.560 --> 20:40.000 user space to work on top of more general capabilities. 20:40.640 --> 20:46.880 And we will provide a fine-grade, fine-grained rights beats into the kernel, 20:48.720 --> 20:54.800 similar to Kaspersavis. And we will implement memory-sharing mechanism with capabilities, 20:55.600 --> 21:05.040 and we will define Kaspersavis like rights and API for file access and port the Kasperskown 21:05.040 --> 21:12.160 test to suit. And we will also develop Kaspersavis like mechanism for capability-based escalation, 21:12.880 --> 21:21.680 and finally, we are going to provide Wazi Kaspersavis. Thank you very much for listening. 21:29.360 --> 21:30.880 More than enough time for questions. 21:36.000 --> 21:40.720 Could you show the slide that this will be the result of the mission? 21:44.960 --> 21:45.440 Yep. 21:45.440 --> 21:52.320 I don't really see why we have to make a difference because you see you can definitely 21:52.320 --> 21:57.280 action that for me, which right or the resource is an action. 21:57.280 --> 22:20.080 I don't see why we don't need to, okay, he asked why we categorize direct or indirect. 22:20.320 --> 22:38.000 Actually, we don't need to need to categorize them into two types, but so you ask, 22:38.960 --> 22:52.720 so you don't understand the difference or why is it there, why is it a direct and it's such a 22:52.720 --> 22:54.720 technical one-tire? 22:54.720 --> 22:56.720 Yes. 23:00.720 --> 23:06.720 Because from me, the resource capability-tip can be implemented as in you have the permission to 23:06.720 --> 23:08.720 wait and have the permission to write. 23:08.720 --> 23:14.720 And maybe the permission to move in the file or all kinds of things you can do in files from 23:14.720 --> 23:16.720 the file needed. 23:18.720 --> 23:26.400 Yeah, um, the differential permission capability and indirect capabilities, okay, for babies. 23:29.120 --> 23:42.080 But, so sorry, it's not that really technical, they're different, more right, but 23:42.080 --> 23:46.080 it's useful for our categorization. 23:50.080 --> 24:00.080 It's just for explanation, so there's no difference, no technical difference, okay. 24:00.080 --> 24:04.080 Any more questions? 24:06.080 --> 24:10.080 Is there a limit of how many capabilities you can have, like in the system? 24:10.080 --> 24:12.080 When the columns have had the limit? 24:12.080 --> 24:16.080 It's just limited by the amount of memory. 24:16.080 --> 24:18.080 Yes, it's limited by the amount of memory. 24:18.080 --> 24:20.080 Yeah, that's dynamic here. 24:20.080 --> 24:22.080 Yeah, I understand. 24:22.080 --> 24:24.080 Okay, I guess. 24:24.080 --> 24:26.080 Yeah. 24:28.080 --> 24:32.080 Just on the viewers, it was the data structure. 24:32.080 --> 24:36.080 In the kernel, that maps the references to the capabilities. 24:36.080 --> 24:38.080 The coin? 24:38.080 --> 24:40.080 Oh, it's going to be easy. 24:40.080 --> 24:42.080 So, it's going to be easy. 24:42.080 --> 24:44.080 Be easy. 24:44.080 --> 24:46.080 Yes. 24:46.080 --> 24:54.080 Has V3 maps to, uh, for, uh, table reference? 24:54.080 --> 24:56.080 Yeah. 25:02.080 --> 25:12.080 Do you have any view of what is performance over the course of running the system? 25:12.080 --> 25:14.080 What is the price of having capabilities? 25:14.080 --> 25:16.080 In terms of performance? 25:16.080 --> 25:30.080 Um, so in, in this, uh, the kind of commentary, uh, this, uh, access to capability 25:30.080 --> 25:32.080 and this system goal. 25:32.080 --> 25:38.080 What's, if we, uh, uh, change capability, uh, 25:38.080 --> 25:46.080 change representation, uh, uh, uh, virtual memory. 25:46.080 --> 25:52.080 Uh, we can, uh, we can access the, without, uh, system goal. 25:52.080 --> 25:58.080 It, uh, it's, uh, it should, uh, uh, uh, 25:59.080 --> 26:02.080 uh, improved performance. 26:02.080 --> 26:04.080 Yeah. 26:04.080 --> 26:07.080 Now we need to move it. 26:07.080 --> 26:09.080 It's a little bit different. 26:09.080 --> 26:11.080 It's a little bit different. 26:11.080 --> 26:12.080 It's a little bit different. 26:12.080 --> 26:16.080 I mean, I mean, in the current, we don't do that. 26:16.080 --> 26:20.080 And that's a lot easier because you just do it in the road, the path. 26:20.080 --> 26:23.080 And then we discuss this with the server. 26:23.080 --> 26:26.080 And we need to understand the protocol we need to pass from. 26:26.080 --> 26:28.080 All it doesn't up and you just get to know. 26:28.080 --> 26:29.080 And that's fine. 26:29.080 --> 26:30.080 So you then open the node. 26:30.080 --> 26:31.080 Maybe it's a fine. 26:31.080 --> 26:32.080 Maybe it's not a fine. 26:32.080 --> 26:33.080 Maybe it's not a fine. 26:33.080 --> 26:34.080 Maybe it's not a fine. 26:34.080 --> 26:36.080 And maybe it's both. 26:36.080 --> 26:39.080 Maybe it's not done because it's all together. 26:39.080 --> 26:40.080 And that's fine. 26:40.080 --> 26:42.080 Because the rule of the void is complicated. 26:42.080 --> 26:43.080 It's true. 26:43.080 --> 26:44.080 It's true. 26:44.080 --> 26:47.080 And I quite understand quite a lot of things. 26:47.080 --> 26:52.080 There really is a different reason for everything. 27:23.080 --> 27:29.080 I would suggest to discuss this offline. 27:29.080 --> 27:30.080 Yeah. 27:30.080 --> 27:32.080 I think this might be. 27:32.080 --> 27:37.080 So anyone else, always I would say thank you for the talk. 27:37.080 --> 27:40.080 Thank you for listening.