WEBVTT 00:00.000 --> 00:13.320 All right, so next up, we're going to have Michael talking to us about some boxing with 00:13.320 --> 00:14.320 Landlock. 00:14.320 --> 00:15.320 There you go. 00:15.320 --> 00:17.320 I'll see you on my gone. 00:17.320 --> 00:18.320 Hi. 00:18.320 --> 00:19.320 Hi everyone. 00:19.320 --> 00:24.320 I'm sorry, my name is Mikkelsenar. 00:24.640 --> 00:32.720 I'm a KELMANA, a mainer for Donanlock LSM, and this talk is about Manlock, a new features that 00:32.720 --> 00:37.400 we need for unboxing, and that could be used also for user use cases. 00:37.400 --> 00:42.400 So let's start first by describing what is sendboxing. 00:42.400 --> 00:48.920 So ENSELT is a way to run programs, you know, stick it environment, that we've been 00:49.000 --> 00:54.000 done from doing stuff that are not planned. 00:54.000 --> 01:00.160 So like I've seen, what is from outside this secure environment. 01:00.160 --> 01:08.840 So the one lock is an access control system, so it's not namespace, it doesn't use namespaces, 01:08.840 --> 01:15.160 it's quite octagonal, it can be used with or without namespace, it doesn't matter. 01:15.160 --> 01:22.440 The main important point, balanlock, is that it's used for image processes, and that means 01:22.440 --> 01:28.440 you can create a signal disease on the fly to some boxed fuel applications, your sets 01:28.440 --> 01:34.280 are programs, and you can also eminate these signal diseases into your programs. 01:34.280 --> 01:40.720 So yeah, I'm mostly too used case, if you'll see that just after, and well, if I know 01:40.760 --> 01:44.280 this, enable one most useful. 01:44.280 --> 01:54.000 This talk is also about IDs, so I wanted to recap some stuff that we talked about some 01:54.000 --> 02:00.160 years ago maybe, so there are values use cases for IDs to identify stuff processes, 02:00.160 --> 02:01.160 mostly. 02:01.160 --> 02:07.640 There are use cases for containers, for authorization, for audit logs, security stuff. 02:07.640 --> 02:21.160 We can list of properties for container level or ID, will require this list of properties. 02:21.160 --> 02:31.520 First, we'll be able to identify use cases of container 25, well, the container, if 02:31.520 --> 02:36.080 the process is in a container, well, we need for all processes running in the container, 02:36.080 --> 02:44.840 and you process quite it within a container to keep this IDs level this type. 02:44.840 --> 02:50.080 For some cases, you don't want to be able to forge these levels, these IDs, especially 02:50.080 --> 02:56.880 when you want to do a test station on running software, your system, so you know where 02:56.880 --> 03:04.480 you want these tags to be immutable, but there are also some other use cases that need 03:04.480 --> 03:05.960 this type to be extendable. 03:05.960 --> 03:09.760 For instance, if you have one container running or launching in there's a container 03:09.760 --> 03:18.680 inside, well, you want the container to be able to also tag and level it stuff. 03:18.680 --> 03:25.600 So yeah, some use cases want global IDs for all the system, some other use cases 03:25.600 --> 03:32.320 want this ID to be kind of relative to the execution environment. 03:32.320 --> 03:37.120 For a destination, for instance, you need to have some uniqueness to be able to be sure 03:37.120 --> 03:48.080 that if this process has this tag, then we can trust it or not for this kind of stuff. 03:48.960 --> 03:56.840 Well, for this, some cases you might need to have some predictable IDs to be able to map 03:56.840 --> 04:04.600 kind of a decision logs with running processes to see if something differ. 04:04.600 --> 04:10.640 And, well, if you want to have these kind of IDs, you might want to be able to use 04:10.640 --> 04:18.800 a query to be able to store and restore a state of a step. 04:18.800 --> 04:25.040 So that's kind of a melting pot of different properties, that different communities 04:25.040 --> 04:28.680 would like to have to identify processes. 04:28.680 --> 04:35.720 So now let's talk a bit about Blanak, what is exactly, so there are many two cases. 04:35.720 --> 04:42.280 The first one is one-year launch application that you don't trust or well, you may not have 04:42.280 --> 04:46.520 access to a source code for whatever reason. 04:46.520 --> 04:51.400 So you might want to launch an application in a secure limited environment. 04:51.400 --> 04:56.800 So, well, very committed, it might be a container in times in systems and so on, just consider 04:56.800 --> 05:00.160 your security, your launch process inside. 05:00.160 --> 05:04.520 And the second use case is when you trust our when you develop an application, you might 05:04.520 --> 05:10.960 have to establish a security inside this application, configure this security a launch time 05:10.960 --> 05:15.800 at the early stage of the launch time of an application. 05:15.800 --> 05:20.480 And then when it is launched and money might be compromised because of security vulnerabilities, 05:20.480 --> 05:25.040 well, it will still be contained, still restricted by sometimes. 05:25.040 --> 05:30.880 So three different cases, both complementary. 05:30.880 --> 05:37.880 What we can do, minor with unlock is to, well, this exists to some resources, not all 05:37.880 --> 05:38.880 resources. 05:38.880 --> 05:44.160 There are so many specific sections that are required to not be able to escape a sandbox, like 05:44.160 --> 05:48.280 instance, you cannot debug process, which is outside the sandbox, otherwise it will be easy 05:48.280 --> 05:52.200 to inject code and do whatever you want, outside this sandbox. 05:52.200 --> 05:58.880 So, it's going to provide this implicit restrictions and also, well, explicit access rights 05:58.880 --> 06:03.520 that as a user, C-cellmin developer, you can configure. 06:03.520 --> 06:10.080 So this might apply to the file system network, but it will signal it and some other IPCs. 06:10.080 --> 06:13.680 So more common of that. 06:13.680 --> 06:19.160 What is important to keep in mind is because unlock is targeting unfair users, unfairly 06:19.160 --> 06:25.880 policies that enable malicious process should also be able to use unlock because what 06:25.880 --> 06:32.880 we don't know if this malicious or not, or if it will become malicious, what I mean. 06:32.880 --> 06:40.400 So for this, we need to have to be able to compose, so for instance, someone might configure 06:40.400 --> 06:50.640 security sandbox for their user station, so you might have first sandbox here, and then 06:50.640 --> 06:57.640 one, this user wants to launch a secure environment, the sandbox, explicitly launched 06:57.640 --> 07:02.240 the sandbox, equals to create an Azure, what security security did it to one specific 07:02.240 --> 07:07.200 use case, and in this use case, well, it could also launch an application that will 07:07.200 --> 07:12.380 be some market self, so that will create this case, three different layers, so nest 07:12.380 --> 07:17.700 system exists, and all, and first thing is the own rest section, so we can only add more 07:17.700 --> 07:23.780 section, not what it's capable of, yeah, it's capable of these sandboxes. 07:23.780 --> 07:29.420 So yeah, you can nest sandboxes, nest security policies, but at the same time, you can also 07:29.420 --> 07:41.060 use what other sandboxes for the user, for user applications, or user use cases, so yeah, 07:41.060 --> 07:47.180 there are different ways to do that, and everything can, and that would buy the kernel, 07:47.180 --> 07:48.180 transparent. 07:48.180 --> 07:53.540 So, yeah, nothing to worry about computing, but global system security, to make sure 07:53.540 --> 07:58.420 that this properties will be guaranteed. 07:58.420 --> 08:05.260 So to explain it in a way, there's a time that should be taken into account, for instance, 08:05.260 --> 08:08.940 here, if we have a first process, that is launched. 08:09.420 --> 08:16.660 Well, we can focus on the process, great, but if this initial process P1, one, two, we 08:16.660 --> 08:22.380 stick itself, put itself in a sandbox, because in my launch, and two, three processes, 08:22.380 --> 08:29.260 are do dangerous stuff, well, we can create its own security sandbox, so it's not like. 08:29.260 --> 08:34.420 But in this case, the third process, which was created before the sandbox, will not be 08:34.420 --> 08:41.180 in the sandbox, otherwise, you will have what a net-in-it side effects. 08:41.180 --> 08:44.940 So time is in the back here, and I key, of course, this is also important. 08:44.940 --> 08:50.420 So when P1, after creating the sandbox, create another process, in this case, P3, this 08:50.420 --> 08:57.620 P3 automatically inherits what basically restrictions, and for some P1, was why it would 08:57.620 --> 09:02.740 be easy to escape the sandbox, and the same way, P3 can create its own sandbox, and launch 09:02.740 --> 09:09.740 it out of its own process, and in this case, P4, we need it's bot, both the P3, sandbox, 09:09.740 --> 09:14.940 configuration, and the P1 sandbox, configuration. 09:14.940 --> 09:20.780 Okay, so, not like the main edges, what we want with, with ideas. 09:20.780 --> 09:28.860 So, I sent, I sent, I sent something, I sent a few months ago, so it's still ongoing. 09:28.860 --> 09:36.260 I sent the five version yesterday, this part is about bringing log support to unlock, to 09:36.260 --> 09:43.300 build to log denied actions, and, well, we need a way to identify domain, so domain is 09:43.300 --> 09:49.180 very sandbox, with Lannoc vocabulary. 09:49.180 --> 10:03.260 These ideas are, but there are a lot of them available, so we don't wish to run short, 10:03.260 --> 10:11.060 and they are unique for the whole lifetime as a running system, so 64 bits, kind of. 10:11.980 --> 10:25.220 There are no stats one, audio, the stat, two, both 32, kind of, so they don't stats audio 10:25.220 --> 10:30.740 one, because, well, this gives them some nice properties. 10:30.740 --> 10:40.020 First, it force use base to use, well, unsigned 64 bits, integers, so this way you can 10:40.020 --> 10:48.100 be sure that, well, you space use the same, user uses the right API, and API. 10:48.100 --> 10:55.460 This kind of is a limit called collisions in logs, because when you start two times in 10:55.460 --> 11:07.300 machine, you not get the same ideas at first, so it's not absolute perfect, but in practice 11:07.300 --> 11:12.980 it helps slot, so it's easy to integrate from an ID, in all your logs, from different 11:12.980 --> 11:18.180 boots, and, well, there's not a lot of them change, so they will have two domain IDs at 11:18.180 --> 11:24.100 match them, but if you want to have unique ideas across boots, you can just kind of 11:24.100 --> 11:32.740 concatenate a boot ID with this runtime unique IDs, and, yeah, because it starts with a 11:32.820 --> 11:40.180 high value, well, in practice, that's, it's kind of nice, you can, well, they're mostly aligned 11:40.180 --> 11:47.460 on in the logs. There's no second shell, but not necessarily consecutive, 11:47.460 --> 11:55.860 which means that, well, one initial ID, one first ID will be lower than the next one, but 11:55.860 --> 12:04.740 it might not be just an increment of one. That is to limit a bit, to go back to channels, so 12:04.740 --> 12:09.620 that, because we also need to keep in mind that some boxes can be created by different entities, 12:09.620 --> 12:16.100 different domains, become level of trust, and we want you to avoid, go to channels, that's my 12:16.980 --> 12:23.460 enable one, asexionment, by means, between fan formation from another one. So, this is not perfect, 12:23.540 --> 12:28.020 but we need, we will soon need to keep in mind that there are a lot of other different 12:28.020 --> 12:38.740 cultures in the learning scale, so this is, let's say, a better approach. And, yeah, having 12:38.740 --> 12:46.580 second shell IDs is useful to find IDs, to compare them, and to optimize ID lookup. So, 12:46.580 --> 12:53.940 that's how the one KID are created. So, there are two excuses for another KIDs. 12:54.820 --> 13:00.820 The first one is to, when you create one, or set of some boxes, and launch application 13:00.820 --> 13:06.820 inside is some boxes. Well, you might want you to be sure that, well, the process is well 13:06.820 --> 13:14.740 sandbox, and so that, well, you want you to get the ID of the sandbox you created, and well, 13:14.820 --> 13:24.180 map this ID turning task. And the other use case is that you may want to know the full 13:24.180 --> 13:33.540 restrictions that are tied to a process. And that, my, we acquire not only to get the idea of 13:33.540 --> 13:39.540 the sandbox you created, but to get the idea of sandbox that actually sandboxed this task, 13:39.540 --> 13:46.180 because, again, task can sandbox themselves, so you can have nested sandboxes, so nested IDs. 13:47.700 --> 13:57.540 And, yeah, two main use cases. Then, competitively. So, competitively is competitive, that was 13:57.540 --> 14:03.620 managed a few years ago. So, it's a way, well, it's a five years ago, it's a way to reference 14:03.780 --> 14:11.620 process. So, it has nice properties that you can, in instance, have, well, play a lifetime, 14:13.060 --> 14:17.860 compared to a PID, which is just a number that can be set to be second. And, 14:18.980 --> 14:29.220 similarly, you can, well, avoid risk conditions. So, you can create a PID from PID, or you can 14:29.220 --> 14:35.300 sort of get the PID from the index sockets to get the PID, PID, that returns the PID of this sockets. 14:37.700 --> 14:44.020 And, you can do a lot of different stuff with PID, and it's scoring. So, when it's 14:44.020 --> 14:50.020 sensitive to signal, to wait for the task, but also to, recently, it gained an interesting 14:50.020 --> 14:55.940 video to be able to get process properties. So, when it's time, you can, well, get the subset of 14:56.020 --> 15:03.940 what you can get from the Proc PID statistic, but in a clean and well, well, destination freeway. 15:05.540 --> 15:12.420 And, also, without requiring such product to be mounted, because with such product, there are some 15:13.540 --> 15:21.060 well, requirements, and some safety issues to, you know, with PID namespaces, with mountain 15:21.140 --> 15:27.940 space, and so on. If you want to isolate stuff, that's not a good interface. 15:29.540 --> 15:34.500 So, when it's on, there are two flags, what they're free actually, but let's say we're just 15:34.500 --> 15:43.380 two here. So, PID and PID are in 4C group, ID. So, this kind of a default flag, but they are 15:43.460 --> 15:51.780 enabled to get IDs. So, either UID, the ID, or C group ID, where is it to a process. 15:53.140 --> 16:00.980 And the ID is, with another batch, here is a send yesterday, which is on top of the, or the batch 16:00.980 --> 16:08.180 here is. It's a extensive interface, so the name might change, but the ID is still there. 16:09.140 --> 16:19.140 And, to be able to get two kind of IDs, so to map the two UCCs, yeah, just described before. 16:19.140 --> 16:25.300 So, either you create on some box, and you want to get the nearest send box domain ID, 16:26.020 --> 16:32.740 or you want to get the full, well, the ID with some box that fully send box, fully restrict 16:33.540 --> 16:45.220 your task. So, just can be done, that should be done with one of these flags, or both of these flags. 16:46.260 --> 16:52.820 So, yeah, we're not talking about the PID, FD, I hope to interface in details, but 16:53.460 --> 17:06.660 fit free to get look at the latest canal. So, yeah, it's like a few months old, so you might not 17:06.660 --> 17:15.540 have hit yet in your learning system. Okay, so other works that need it, or want it, 17:16.260 --> 17:22.340 is, for instance, to build two up, we use supports, to build two, well, seven, 17:22.340 --> 17:29.860 store, our new system, and to get the same states. And, as you to be able to, well, 17:31.860 --> 17:38.900 to use IDs, these domain IDs, to get more information, more information than just IDs. 17:39.860 --> 17:47.380 For instance, everything, well, in the logs, when there's a down denial, you get information 17:47.380 --> 17:53.460 about these domains, for instance, the tasks that created these domains, and then that denied 17:54.020 --> 17:58.660 the access request. So, you need to make these information also available at runtime, 17:59.380 --> 18:06.980 for instance, we saw, did it, the total part system, something, and there is to expose 18:07.140 --> 18:13.620 of their properties that are tied to these blank domains. For instance, we could expose 18:14.660 --> 18:20.660 what the command line, that would use, when creating this unbox, and that could, that could 18:20.660 --> 18:29.700 when it stands to be used to level with a string, some box along the domain. So, to map an ID to 18:29.780 --> 18:37.780 level. And, of course, well, the IDs to make it useful for developers, and for people 18:37.780 --> 18:43.140 that want to know what's running on the system, and to know the safety basis that apply to 18:43.140 --> 18:50.100 certain processes, and how it was created and so on, and so to work through how the domain 18:50.180 --> 18:57.780 the nested domain hack is, and get some information, for instance, to know, well, if 18:59.540 --> 19:04.580 one, some of the application wants to access one of those, that's his deny, well, maybe to get 19:04.580 --> 19:12.100 the notification from that. So, that could be kind of a commodity work to what we can get from the 19:12.180 --> 19:25.060 other jobs. So, let's recap a bit. So, we talk about what cool IDs, let's say, contain your IDs, 19:25.060 --> 19:33.940 a label, will mean for all different communities. Well, in this case, I think we have the 19:34.020 --> 19:39.540 property of, in your, in your, in your items. So, once a process is tied, it's some box, 19:39.540 --> 19:49.620 with a block domain. It keeps any of this ID for whole his lifetime. This are 19:49.620 --> 19:54.740 immutable, but also extensive, because we have, we can have nested some boxes, so nested IDs. 19:55.300 --> 20:05.300 This does not rely on strings, for nesting stuff. But you can still have levels, well, you will, 20:05.300 --> 20:12.660 you will still be able to have levels kind of attached to IDs. So, you can do kind of nice mapping. 20:14.340 --> 20:19.460 Well, it can be enforced by glitch services, but also in predict services, and can be relative to 20:19.540 --> 20:28.500 a process that creates some box. So, one thing I didn't talk about, which is, so, in the 20:28.500 --> 20:41.540 end is, in a case, let's say, of this set of processes, we want P1 to be able to see a 20:41.620 --> 20:50.180 sandbox ID of P3, but P3 should not be able to see its own sandbox ID, and P4 is the same. 20:50.180 --> 20:54.980 Otherwise, it would be a kind of way to easily identify if you're ending in the sandbox, 20:54.980 --> 21:01.220 and get information from this sandbox, and that's not what we're seeing from a secret point of view. 21:02.180 --> 21:12.580 So, that's where we can see the relative properties of IDs for one of the main IDs. 21:14.660 --> 21:21.620 This case P2 will be able to see the another ID of P1 of P3 and P4, but P1 can only see the 21:21.620 --> 21:26.820 ID of P3 and P4, and P3 and P4 cannot see any other ID at all. 21:32.100 --> 21:42.740 Okay, so, P1 is uniness for attestation. Well, that could be achieved by using boot ID as the same 21:42.740 --> 21:49.460 time. So, if you use a boot ID for what you get the ID of a boot pattern time, and in a 21:49.460 --> 21:57.780 lot of ID at the same time, you can have a unique ID for all your flits. ID are not predicted 21:57.940 --> 22:06.580 to be predictable, but you can have, you could rely on, let's say, the command name, that tagged, 22:06.580 --> 22:13.460 that's created an ID, and then get predictable set of flubbles instead. 22:15.700 --> 22:22.180 And few is not supported, but well, there's room to improve that, and to bring support to 22:22.180 --> 22:30.980 you, so that should not be in shape. So, that's what I'm about. Now, the ongoing work from 22:30.980 --> 22:37.380 our luck to being support for dits logs, so it's pretty well-advanced. I mean, to land 22:37.780 --> 22:44.580 pretty in the next months, the ongoing work for integration interfaces, like the one 22:44.660 --> 22:51.540 we talk about with P2FD, and there's an ongoing work to bring new access rights to 22:51.540 --> 23:00.980 well-to-more strict your own summitses. If you do contribute, there are a lot of stuff to do 23:02.020 --> 23:06.740 from Canada Raman, to use base Raman, Labrador Raman, Guests, Guests, Guests, whatever. 23:08.260 --> 23:12.260 And, yeah, if you want to download your application, you program, you can do it, if you 23:12.500 --> 23:18.340 will use, in my fit, in one of these rewards program, so that could be interesting. 23:20.340 --> 23:25.780 If you want to try and unlock quickly in a machine, you can just run this command, you'll download 23:26.900 --> 23:33.300 a sandbox example, so that's really an example here, if you'll not use this 23:33.300 --> 23:38.900 introduction, because the interface might change, there's no stable interface, that's a sample. 23:39.220 --> 23:47.860 But, other sandbox tools already use landlock, so, for instance, a mini-jail, perjail, or 23:47.860 --> 23:54.820 stability that. Yeah, thank you, and if you have any question, happy to ask now. 23:54.820 --> 24:13.780 I was wondering, you know, in particular, the labels that you want to use, you also for 24:13.780 --> 24:18.740 attestation, right? You know, one of the nice things of our landlock is that it's unprivileged, 24:18.740 --> 24:23.780 right? Like, you can set all these things up without privileges, but then the labels if you want 24:23.860 --> 24:28.420 to use them for attestation, you need to make sure that nobody can set whatever they want. 24:28.420 --> 24:36.900 So, my follow-up question to that would then be like, you know, C groups has labels in the 24:36.900 --> 24:41.620 C group paths, right? And then has this delegation concept, right? Like, you can create a C group, 24:41.620 --> 24:46.740 and then you can set access rights to it, and that basically allows whoever runs inside of that 24:46.820 --> 24:53.860 to create sub-c groups, and so on, and so on, right? So, it kind of appears to me that, 24:54.660 --> 24:59.220 yeah, you would have to create the same thing there, right? Like, if you want to have control about 24:59.220 --> 25:04.820 who creates which labels, and then what's why not just use C groups in the first slide, right? 25:04.820 --> 25:09.460 So, if you need to use C group, you use C group, they don't use you with that. That's, 25:10.420 --> 25:16.820 I just took a bit of a required feature for our lack, that could be used for use cases. 25:16.820 --> 25:24.020 Now, to answer your question, our labels, so what we should be able to use in the future 25:25.220 --> 25:32.020 is the third here, the common name that created a sandbox. So, you could have, and this 25:32.020 --> 25:38.580 common name can be whatever you want within 16 characters, so that could be kind of a label, 25:39.460 --> 25:48.020 and this will be, well, accessible and readable by any, well, free energy enough process. 25:48.980 --> 25:55.300 So, this kind of actual of labels is accessible. So, if C group is, well, better fits you 25:55.300 --> 26:01.780 to use cases, that's fine, but that could be in a way to have a kind of an accurate labels. 26:03.300 --> 26:11.300 And how can I expose labels? So, the idea is, it's not done yet, the first step was a log, 26:11.300 --> 26:18.580 implementation, then the PID, an ID request, and the next step will be to have a file system, 26:18.900 --> 26:24.260 I interface, that you can interface for an unlock, to be able to map, land, land, land, 26:24.260 --> 26:32.660 domain, these, two, these properties. So, you have kind of a nice properties of PIDs, but also 26:32.660 --> 26:42.820 be able to map to more information, if you want. So, here, without the name, thank you for your talk. 26:42.900 --> 26:50.020 So, I happen to maintain a small go program, which has to supervise some binaries, and 26:50.020 --> 26:55.220 there are, I have some custom sandboxing code in there. So, this could be interesting to me. 26:55.220 --> 27:02.500 And my question will be, what will be the recommended approach if there is one to land lock, 27:02.500 --> 27:07.700 to use land of two sandbox other processes, other than the one that is currently running? 27:07.700 --> 27:11.700 Is that possible? Would you recommend a piggyback binary, something like that? 27:12.420 --> 27:18.980 Yeah. So, sorry, I did not have time for the interface, so you use land lock, 27:18.980 --> 27:25.940 but basically land lock is free, she samples, and well, there are two of them I used to create, 27:25.940 --> 27:30.740 specifically C, and one is used to enforce, specifically C on yourself. And right now, you can only 27:30.740 --> 27:36.980 enforce on yourself, which means the children's fed. And from that, well, it is just that, 27:37.060 --> 27:41.060 you can do whatever you want, you can fork, you can exit V and whatever. And that's 27:41.940 --> 27:48.420 the only way to sandbox a process, because there are some infinite requirements. 27:51.300 --> 27:57.620 Yeah, we could have in the interface to sandbox and as a process, but for now, there's no, 27:58.580 --> 28:08.980 well, use cases, well, I mean, if you don't want to contribute, they can, but for now, 28:08.980 --> 28:14.820 the minimal interface required to use land lock is to sandbox your own process, and then do whatever you want. 28:14.820 --> 28:21.460 So, it work exactly the same as second. So, and that's the same for inheritance. 28:21.460 --> 28:28.340 Yeah, this, this way to work is exactly like second. 28:31.220 --> 28:38.100 So, quick question, clarification here, you said that P1 would be able to see the land lock ID for 28:38.100 --> 28:43.140 the group that contains P3 and P4, but wouldn't be able to see itself, is that correct? 28:43.860 --> 28:49.940 That's right, again here. So, here you said that P1 would be able to see the land lock ID of the 28:50.020 --> 28:57.300 sandbox for P3 and P4. So, in this case, P2, because it did outside all the sandboxes, 28:57.300 --> 29:02.100 could be able to see the domain IDs of all the sandboxes. Yeah, all the, you know, P1, 29:02.100 --> 29:08.980 otherwise, can up, see any information from P2, well, anyway, P2 is not sandbox, but it cannot 29:08.980 --> 29:16.740 anyway. So, it is going to enable, well, yeah, Princeton interface, P1 can only see 29:17.380 --> 29:23.220 domain these of P3 and P4. So, it can, Princeton be sure that P3 and P4 are well sandboxed, 29:23.220 --> 29:29.620 and sandboxed by the sandboxes that he created, it created. And P3 and P4 cannot see any sandbox ID at all. 29:30.820 --> 29:37.220 I see, so the fact that P1 created its own sandbox doesn't allow it to, you know, there's been 29:37.220 --> 29:44.180 sandboxed, or I might just be understanding that. So, in practice, because thanks to P2, 29:44.180 --> 29:50.020 if the properties, you can create the P2, the pointing to yourself before, then sandbox yourself, 29:51.380 --> 29:58.100 and then read from the P2, P2 properties, and you will get your own domain ID. 30:00.420 --> 30:07.380 But yeah, you need to have first access to P2. So, yeah. So, thank you, we're out of time, and 30:07.380 --> 30:14.180 yeah, you're up next, thank you.