All right, so next up, we're going to have Michael talking to us about some boxing with
Landlock.
There you go.
I'll see you on my gone.
Hi.
Hi everyone.
I'm sorry, my name is Mikkelsenar.
I'm a KELMANA, a mainer for Donanlock LSM, and this talk is about Manlock, a new features that
we need for unboxing, and that could be used also for user use cases.
So let's start first by describing what is sendboxing.
So ENSELT is a way to run programs, you know, stick it environment, that we've been
done from doing stuff that are not planned.
So like I've seen, what is from outside this secure environment.
So the one lock is an access control system, so it's not namespace, it doesn't use namespaces,
it's quite octagonal, it can be used with or without namespace, it doesn't matter.
The main important point, balanlock, is that it's used for image processes, and that means
you can create a signal disease on the fly to some boxed fuel applications, your sets
are programs, and you can also eminate these signal diseases into your programs.
So yeah, I'm mostly too used case, if you'll see that just after, and well, if I know
this, enable one most useful.
This talk is also about IDs, so I wanted to recap some stuff that we talked about some
years ago maybe, so there are values use cases for IDs to identify stuff processes,
mostly.
There are use cases for containers, for authorization, for audit logs, security stuff.
We can list of properties for container level or ID, will require this list of properties.
First, we'll be able to identify use cases of container 25, well, the container, if
the process is in a container, well, we need for all processes running in the container,
and you process quite it within a container to keep this IDs level this type.
For some cases, you don't want to be able to forge these levels, these IDs, especially
when you want to do a test station on running software, your system, so you know where
you want these tags to be immutable, but there are also some other use cases that need
this type to be extendable.
For instance, if you have one container running or launching in there's a container
inside, well, you want the container to be able to also tag and level it stuff.
So yeah, some use cases want global IDs for all the system, some other use cases
want this ID to be kind of relative to the execution environment.
For a destination, for instance, you need to have some uniqueness to be able to be sure
that if this process has this tag, then we can trust it or not for this kind of stuff.
Well, for this, some cases you might need to have some predictable IDs to be able to map
kind of a decision logs with running processes to see if something differ.
And, well, if you want to have these kind of IDs, you might want to be able to use
a query to be able to store and restore a state of a step.
So that's kind of a melting pot of different properties, that different communities
would like to have to identify processes.
So now let's talk a bit about Blanak, what is exactly, so there are many two cases.
The first one is one-year launch application that you don't trust or well, you may not have
access to a source code for whatever reason.
So you might want to launch an application in a secure limited environment.
So, well, very committed, it might be a container in times in systems and so on, just consider
your security, your launch process inside.
And the second use case is when you trust our when you develop an application, you might
have to establish a security inside this application, configure this security a launch time
at the early stage of the launch time of an application.
And then when it is launched and money might be compromised because of security vulnerabilities,
well, it will still be contained, still restricted by sometimes.
So three different cases, both complementary.
What we can do, minor with unlock is to, well, this exists to some resources, not all
resources.
There are so many specific sections that are required to not be able to escape a sandbox, like
instance, you cannot debug process, which is outside the sandbox, otherwise it will be easy
to inject code and do whatever you want, outside this sandbox.
So, it's going to provide this implicit restrictions and also, well, explicit access rights
that as a user, C-cellmin developer, you can configure.
So this might apply to the file system network, but it will signal it and some other IPCs.
So more common of that.
What is important to keep in mind is because unlock is targeting unfair users, unfairly
policies that enable malicious process should also be able to use unlock because what
we don't know if this malicious or not, or if it will become malicious, what I mean.
So for this, we need to have to be able to compose, so for instance, someone might configure
security sandbox for their user station, so you might have first sandbox here, and then
one, this user wants to launch a secure environment, the sandbox, explicitly launched
the sandbox, equals to create an Azure, what security security did it to one specific
use case, and in this use case, well, it could also launch an application that will
be some market self, so that will create this case, three different layers, so nest
system exists, and all, and first thing is the own rest section, so we can only add more
section, not what it's capable of, yeah, it's capable of these sandboxes.
So yeah, you can nest sandboxes, nest security policies, but at the same time, you can also
use what other sandboxes for the user, for user applications, or user use cases, so yeah,
there are different ways to do that, and everything can, and that would buy the kernel,
transparent.
So, yeah, nothing to worry about computing, but global system security, to make sure
that this properties will be guaranteed.
So to explain it in a way, there's a time that should be taken into account, for instance,
here, if we have a first process, that is launched.
Well, we can focus on the process, great, but if this initial process P1, one, two, we
stick itself, put itself in a sandbox, because in my launch, and two, three processes,
are do dangerous stuff, well, we can create its own security sandbox, so it's not like.
But in this case, the third process, which was created before the sandbox, will not be
in the sandbox, otherwise, you will have what a net-in-it side effects.
So time is in the back here, and I key, of course, this is also important.
So when P1, after creating the sandbox, create another process, in this case, P3, this
P3 automatically inherits what basically restrictions, and for some P1, was why it would
be easy to escape the sandbox, and the same way, P3 can create its own sandbox, and launch
it out of its own process, and in this case, P4, we need it's bot, both the P3, sandbox,
configuration, and the P1 sandbox, configuration.
Okay, so, not like the main edges, what we want with, with ideas.
So, I sent, I sent, I sent something, I sent a few months ago, so it's still ongoing.
I sent the five version yesterday, this part is about bringing log support to unlock, to
build to log denied actions, and, well, we need a way to identify domain, so domain is
very sandbox, with Lannoc vocabulary.
These ideas are, but there are a lot of them available, so we don't wish to run short,
and they are unique for the whole lifetime as a running system, so 64 bits, kind of.
There are no stats one, audio, the stat, two, both 32, kind of, so they don't stats audio
one, because, well, this gives them some nice properties.
First, it force use base to use, well, unsigned 64 bits, integers, so this way you can
be sure that, well, you space use the same, user uses the right API, and API.
This kind of is a limit called collisions in logs, because when you start two times in
machine, you not get the same ideas at first, so it's not absolute perfect, but in practice
it helps slot, so it's easy to integrate from an ID, in all your logs, from different
boots, and, well, there's not a lot of them change, so they will have two domain IDs at
match them, but if you want to have unique ideas across boots, you can just kind of
concatenate a boot ID with this runtime unique IDs, and, yeah, because it starts with a
high value, well, in practice, that's, it's kind of nice, you can, well, they're mostly aligned
on in the logs. There's no second shell, but not necessarily consecutive,
which means that, well, one initial ID, one first ID will be lower than the next one, but
it might not be just an increment of one. That is to limit a bit, to go back to channels, so
that, because we also need to keep in mind that some boxes can be created by different entities,
different domains, become level of trust, and we want you to avoid, go to channels, that's my
enable one, asexionment, by means, between fan formation from another one. So, this is not perfect,
but we need, we will soon need to keep in mind that there are a lot of other different
cultures in the learning scale, so this is, let's say, a better approach. And, yeah, having
second shell IDs is useful to find IDs, to compare them, and to optimize ID lookup. So,
that's how the one KID are created. So, there are two excuses for another KIDs.
The first one is to, when you create one, or set of some boxes, and launch application
inside is some boxes. Well, you might want you to be sure that, well, the process is well
sandbox, and so that, well, you want you to get the ID of the sandbox you created, and well,
map this ID turning task. And the other use case is that you may want to know the full
restrictions that are tied to a process. And that, my, we acquire not only to get the idea of
the sandbox you created, but to get the idea of sandbox that actually sandboxed this task,
because, again, task can sandbox themselves, so you can have nested sandboxes, so nested IDs.
And, yeah, two main use cases. Then, competitively. So, competitively is competitive, that was
managed a few years ago. So, it's a way, well, it's a five years ago, it's a way to reference
process. So, it has nice properties that you can, in instance, have, well, play a lifetime,
compared to a PID, which is just a number that can be set to be second. And,
similarly, you can, well, avoid risk conditions. So, you can create a PID from PID, or you can
sort of get the PID from the index sockets to get the PID, PID, that returns the PID of this sockets.
And, you can do a lot of different stuff with PID, and it's scoring. So, when it's
sensitive to signal, to wait for the task, but also to, recently, it gained an interesting
video to be able to get process properties. So, when it's time, you can, well, get the subset of
what you can get from the Proc PID statistic, but in a clean and well, well, destination freeway.
And, also, without requiring such product to be mounted, because with such product, there are some
well, requirements, and some safety issues to, you know, with PID namespaces, with mountain
space, and so on. If you want to isolate stuff, that's not a good interface.
So, when it's on, there are two flags, what they're free actually, but let's say we're just
two here. So, PID and PID are in 4C group, ID. So, this kind of a default flag, but they are
enabled to get IDs. So, either UID, the ID, or C group ID, where is it to a process.
And the ID is, with another batch, here is a send yesterday, which is on top of the, or the batch
here is. It's a extensive interface, so the name might change, but the ID is still there.
And, to be able to get two kind of IDs, so to map the two UCCs, yeah, just described before.
So, either you create on some box, and you want to get the nearest send box domain ID,
or you want to get the full, well, the ID with some box that fully send box, fully restrict
your task. So, just can be done, that should be done with one of these flags, or both of these flags.
So, yeah, we're not talking about the PID, FD, I hope to interface in details, but
fit free to get look at the latest canal. So, yeah, it's like a few months old, so you might not
have hit yet in your learning system. Okay, so other works that need it, or want it,
is, for instance, to build two up, we use supports, to build two, well, seven,
store, our new system, and to get the same states. And, as you to be able to, well,
to use IDs, these domain IDs, to get more information, more information than just IDs.
For instance, everything, well, in the logs, when there's a down denial, you get information
about these domains, for instance, the tasks that created these domains, and then that denied
the access request. So, you need to make these information also available at runtime,
for instance, we saw, did it, the total part system, something, and there is to expose
of their properties that are tied to these blank domains. For instance, we could expose
what the command line, that would use, when creating this unbox, and that could, that could
when it stands to be used to level with a string, some box along the domain. So, to map an ID to
level. And, of course, well, the IDs to make it useful for developers, and for people
that want to know what's running on the system, and to know the safety basis that apply to
certain processes, and how it was created and so on, and so to work through how the domain
the nested domain hack is, and get some information, for instance, to know, well, if
one, some of the application wants to access one of those, that's his deny, well, maybe to get
the notification from that. So, that could be kind of a commodity work to what we can get from the
other jobs. So, let's recap a bit. So, we talk about what cool IDs, let's say, contain your IDs,
a label, will mean for all different communities. Well, in this case, I think we have the
property of, in your, in your, in your items. So, once a process is tied, it's some box,
with a block domain. It keeps any of this ID for whole his lifetime. This are
immutable, but also extensive, because we have, we can have nested some boxes, so nested IDs.
This does not rely on strings, for nesting stuff. But you can still have levels, well, you will,
you will still be able to have levels kind of attached to IDs. So, you can do kind of nice mapping.
Well, it can be enforced by glitch services, but also in predict services, and can be relative to
a process that creates some box. So, one thing I didn't talk about, which is, so, in the
end is, in a case, let's say, of this set of processes, we want P1 to be able to see a
sandbox ID of P3, but P3 should not be able to see its own sandbox ID, and P4 is the same.
Otherwise, it would be a kind of way to easily identify if you're ending in the sandbox,
and get information from this sandbox, and that's not what we're seeing from a secret point of view.
So, that's where we can see the relative properties of IDs for one of the main IDs.
This case P2 will be able to see the another ID of P1 of P3 and P4, but P1 can only see the
ID of P3 and P4, and P3 and P4 cannot see any other ID at all.
Okay, so, P1 is uniness for attestation. Well, that could be achieved by using boot ID as the same
time. So, if you use a boot ID for what you get the ID of a boot pattern time, and in a
lot of ID at the same time, you can have a unique ID for all your flits. ID are not predicted
to be predictable, but you can have, you could rely on, let's say, the command name, that tagged,
that's created an ID, and then get predictable set of flubbles instead.
And few is not supported, but well, there's room to improve that, and to bring support to
you, so that should not be in shape. So, that's what I'm about. Now, the ongoing work from
our luck to being support for dits logs, so it's pretty well-advanced. I mean, to land
pretty in the next months, the ongoing work for integration interfaces, like the one
we talk about with P2FD, and there's an ongoing work to bring new access rights to
well-to-more strict your own summitses. If you do contribute, there are a lot of stuff to do
from Canada Raman, to use base Raman, Labrador Raman, Guests, Guests, Guests, whatever.
And, yeah, if you want to download your application, you program, you can do it, if you
will use, in my fit, in one of these rewards program, so that could be interesting.
If you want to try and unlock quickly in a machine, you can just run this command, you'll download
a sandbox example, so that's really an example here, if you'll not use this
introduction, because the interface might change, there's no stable interface, that's a sample.
But, other sandbox tools already use landlock, so, for instance, a mini-jail, perjail, or
stability that. Yeah, thank you, and if you have any question, happy to ask now.
I was wondering, you know, in particular, the labels that you want to use, you also for
attestation, right? You know, one of the nice things of our landlock is that it's unprivileged,
right? Like, you can set all these things up without privileges, but then the labels if you want
to use them for attestation, you need to make sure that nobody can set whatever they want.
So, my follow-up question to that would then be like, you know, C groups has labels in the
C group paths, right? And then has this delegation concept, right? Like, you can create a C group,
and then you can set access rights to it, and that basically allows whoever runs inside of that
to create sub-c groups, and so on, and so on, right? So, it kind of appears to me that,
yeah, you would have to create the same thing there, right? Like, if you want to have control about
who creates which labels, and then what's why not just use C groups in the first slide, right?
So, if you need to use C group, you use C group, they don't use you with that. That's,
I just took a bit of a required feature for our lack, that could be used for use cases.
Now, to answer your question, our labels, so what we should be able to use in the future
is the third here, the common name that created a sandbox. So, you could have, and this
common name can be whatever you want within 16 characters, so that could be kind of a label,
and this will be, well, accessible and readable by any, well, free energy enough process.
So, this kind of actual of labels is accessible. So, if C group is, well, better fits you
to use cases, that's fine, but that could be in a way to have a kind of an accurate labels.
And how can I expose labels? So, the idea is, it's not done yet, the first step was a log,
implementation, then the PID, an ID request, and the next step will be to have a file system,
I interface, that you can interface for an unlock, to be able to map, land, land, land,
domain, these, two, these properties. So, you have kind of a nice properties of PIDs, but also
be able to map to more information, if you want. So, here, without the name, thank you for your talk.
So, I happen to maintain a small go program, which has to supervise some binaries, and
there are, I have some custom sandboxing code in there. So, this could be interesting to me.
And my question will be, what will be the recommended approach if there is one to land lock,
to use land of two sandbox other processes, other than the one that is currently running?
Is that possible? Would you recommend a piggyback binary, something like that?
Yeah. So, sorry, I did not have time for the interface, so you use land lock,
but basically land lock is free, she samples, and well, there are two of them I used to create,
specifically C, and one is used to enforce, specifically C on yourself. And right now, you can only
enforce on yourself, which means the children's fed. And from that, well, it is just that,
you can do whatever you want, you can fork, you can exit V and whatever. And that's
the only way to sandbox a process, because there are some infinite requirements.
Yeah, we could have in the interface to sandbox and as a process, but for now, there's no,
well, use cases, well, I mean, if you don't want to contribute, they can, but for now,
the minimal interface required to use land lock is to sandbox your own process, and then do whatever you want.
So, it work exactly the same as second. So, and that's the same for inheritance.
Yeah, this, this way to work is exactly like second.
So, quick question, clarification here, you said that P1 would be able to see the land lock ID for
the group that contains P3 and P4, but wouldn't be able to see itself, is that correct?
That's right, again here. So, here you said that P1 would be able to see the land lock ID of the
sandbox for P3 and P4. So, in this case, P2, because it did outside all the sandboxes,
could be able to see the domain IDs of all the sandboxes. Yeah, all the, you know, P1,
otherwise, can up, see any information from P2, well, anyway, P2 is not sandbox, but it cannot
anyway. So, it is going to enable, well, yeah, Princeton interface, P1 can only see
domain these of P3 and P4. So, it can, Princeton be sure that P3 and P4 are well sandboxed,
and sandboxed by the sandboxes that he created, it created. And P3 and P4 cannot see any sandbox ID at all.
I see, so the fact that P1 created its own sandbox doesn't allow it to, you know, there's been
sandboxed, or I might just be understanding that. So, in practice, because thanks to P2,
if the properties, you can create the P2, the pointing to yourself before, then sandbox yourself,
and then read from the P2, P2 properties, and you will get your own domain ID.
But yeah, you need to have first access to P2. So, yeah. So, thank you, we're out of time, and
yeah, you're up next, thank you.