And I have everyone, this is a sick place, UK, CIDOCI, Introduction to a Secure
Container and Time for Linux.
I'm a lipolotel and I serve a developer.
Before we start, here is some information about CID, you can take a photo if you want.
We have a CTF game, if you want to play and check out CID,
and we have extensive documentation as main pages.
And if you have any questions that you can ask here, just pop up on, I'll see your metrics and find me.
I'm usually there.
So, yeah, and before we start, again, I should be perfectly honest.
I know next to nothing about containers.
And me, having written a container runtime was a bit of an accidental thing.
And today, it wouldn't have been possible without the great work of the UK developers,
which they told me they've been watching.
So, I want to give a round of applause to the UK developers.
Thank you.
So, what's the UK, I got this from their manual page.
It's an implementation of all-sear runtime spec in Rust.
So, it's basically run-seer it in Rust, you can think of it like.
And this is how it's pronounced.
It's a Japanese word meaning cheerful or merry or hilarious.
And they have their reasons for picking Rust here, which is Rust is one of the best languages
to implement the OCI runtime spec.
Many, very nice container tools are currently written and go, however,
the container runtime requires use of system calls, which requires a bit of special handling
that implemented and go.
I'll speak a bit about this later than comparing Rust with go.
So, writing container runtime in Rust is typically a bit easier than writing in Go.
So, what is CIDOCI?
CIDOCI was basically a friend of mine coming to me and telling me,
why aren't you making CIDA container runtime?
And as I said, I know nothing about containers,
and I was like, is there anything that I can use for this?
And then I came across UK.
For a bit of introduction, CIDA is a sandbox to,
with a motto to make sandboxing as easy as text searching is with crap.
And for those who want to know more, watch my talk in the morning,
if you haven't watched it already, or go to our manual pages and check it out.
And what you'll keep people have also done very nicely is that they have actually written libraries,
not just the binary.
So, they provided the Rust environment very nice libraries,
so everyone can go out and write their own container runtime,
which is what I did basically CIDOCI was just a weekend's work to,
to replace the default executor with a special executor for sit.
And basically, Yoki sets up everything and in the very last stage,
before he execute the binary, we set up to sit sandbox,
and you execute it inside the sandbox.
So, that came CIDOCI.
CIDOCI is a secure container runtime for OCI compliant Linux containers.
It's GPL-3 and it's forever free.
And this is how you install it.
You need to pass features OCI when you are building sit.
It's not enabled by default.
And we have Pandora for learning mode,
which I will try to display in a bit.
And then it's just a matter of passing runtime CIDOCI
to Docker or PodMan or whichever container I'm using.
It should just work as a dossier compliant.
And how do we do this?
This is a bit of how CIDOCI works.
And basically, the idea is you have a sandbox policy,
and you load this policy into sit on at startup.
You can also configure the sandbox as you go,
which I'll also display to you.
And this page goes on to explain how this file is picked.
And in the last, you will see if you have no files to configure,
then sit below this built in OCI profile.
And this is designed to be used with Pandora and learning mode.
So, you can run your container first.
Check if it's behavior, create a profile,
and then force a profile, and then you sit like that.
And now here, give a brief comparison with Jeevizer,
because Jeevizer seems to be the most commonly used sandbox these days,
and yeah.
So, what's different in sit OCI than Jeevizer?
It's first of all, it's Rust versus Go,
which is a completely different poll subject.
I will not go deep here.
However, I will explain my part of it in writing a sandbox in Rust.
Last, there's a idiomatic and strict error checking,
which really helps when you're writing safe code.
Last has no garbage collection.
Again, this is a subject for a different poll.
I will not discuss whether having a garbage collection is good or not.
But when writing that low-level code,
having less side effects in code actually allows directly
for more refined perceived threat, second,
PDF filters, for instance.
And we have in sit, sit is a multi-traded process,
and each process has a different name,
and they have their different duties,
sit mains, it emu, sit monitor and sit interrupt and so on.
And each of these threat confines itself on its own,
based on their duties and so on.
And what else is different?
We have a position in dependent executables.
You cannot, as far as I know,
to this day, build, grow binary's position independently.
So typically, a compromised device that is far less severe
than a compromised sit.
And moreover, sit also enforces position
in dependent executables.
So you cannot execute non-py binary's under sit,
unless you actually set it start up to allow them.
Then sit set 80 secure,
the auxiliary vector, like a parmordas,
which means you don't get to load,
or load, or elderly luxury pet or other shenanigans.
And we have set big art.
Again, I like to do this a bit in my last talk.
And we have mitigations for the secret and oriented programming,
and the return oriented programming, the device that doesn't have.
And you can go ahead and read about this in sit,
seven manual page, it's all documented nicely.
And sit also, I is not as simply faster than G-wiseer.
I'm not going to give any numbers,
because I don't really have clean benchmarks honestly,
but typically sit also,
I does less isolation, so it has less overhead.
I'm not claiming they are doing the same thing,
and I'm doing it much faster.
Now, G-wiseer has their own memory management,
their own network stack and so on,
and that's why they have more overhead,
and yeah.
For those who are interested, they can go to the Git repo,
and check out the benchmarks.
Typically, the numbers are in, like,
four, four sit, it's 10 to 15 percent.
I would have in my measurements and for device,
it varies between 40 to 70 percent.
And the device has layered security,
which is really impressive,
and we have something similar,
and I want to give an example here,
which we had in effect in real time,
very recently.
Sit with sit, you can also use landlock as an additional,
as an additional layer,
and landlock has recently had a break.
People who are interested can go to the CD and look for it.
The break was essentially,
you would execute a malicious case CTL call,
and then the landlock was broken and you could open any path.
But under said, because the malicious case CTL call,
and the open happens in different processes,
sit, email processes are responsible
for actually running the system calls.
Sit does not continue the system call in the sandbox process,
after the access check,
and such is not vulnerable to time of check,
to time of use.
And if you need more fast,
go fast and roll my loops.
For every mitigation in sit,
we have an allow one safe close
that you can use to disable that mitigation.
There is like maybe 30 of them right now,
and the three most important that come to mind
when you want performance at this.
My default sit will run processes with low priority,
and we use P trace,
and you can disable all of these if you want.
As in, see this is a general purpose sandbox.
There is no way to write a one per one,
one size CTL type of sandbox.
It's typically impossible,
but what we do is for every mitigation,
we have an allow one safe close,
so you can disable it and use it for your own case.
And yes, now I will try to display it a little bit.
I don't have a really demo yet,
but what I have here is,
let me quickly show you.
Can everyone in the back seat,
what's written?
Yes, that's great.
Okay, so this should be a little container file here.
Yeah.
So this is how you configure all CI for podmen,
and I'm going to run a rootless podmen here now,
with run hopefully, yes, this one.
So as usual, there is nothing special,
we are running in the sit and the way you learn this is,
through the mask.
So you get some fancy pink fluid lyrics.
And then, right now,
the sandbox is running in warning mode.
So every warning is put into the mask.
You can also make it right to standard error,
or do something else,
and just, it's basically a lines of JSON.
You can fit them up to Pandora after whatever you want.
And here I will just basically show you,
just download a page,
and then,
and then, actually,
hang on.
Yes.
This is going to be a little tricky,
but let me see.
I want to,
right?
Yes.
I'm going to copy the Pandora static binary into it.
This will be much more easier when distributions have
upon Pandora and sit package, of course,
but just for now.
We have Pandora in the container now,
and I will tell Pandora to just go through the system,
and create me a profile.
This takes a bit,
because it is going to verify the check sums of the binaries,
but not too much, hopefully.
Wish me luck.
Come on.
Okay, so the idea is,
we have all the sandbox blocks,
and then we take them and create them.
Okay, let's make this actually.
And the faster.
All right, okay.
Anyhow.
So, we generate the profile.
I will quickly show you the profile.
So, these are what we have done so far.
We have downloaded the web pages.
You can see these are there.
We did some terminal I obtained and so on.
Everything is in here.
And now you can actually load this in runtime dynamically,
into sit with some fancy command that we have here.
Dev sit is the virtual path that you use.
Load is used to load a file descriptor.
It can be any descriptor.
It doesn't matter.
And before we do this,
let me quickly show you the state of the sandbox.
Again, as you can see, right now.
The default action is warm.
So it's going to just warm and do nothing.
So now we are going to load.
Let's go.
Yes.
As you see, we have loaded this file into sit.
And now if I try again,
you'll see the rules are actually loaded into sit.
And this is still not enforced to actually enforce.
You need to do a final bit to load and force profile.
And now if I try to download the same page,
it's going to work.
But if I try to download another web page,
it's going to deny me.
And we can see this.
My other sandbox locks, as you can see.
And the sit gives you tips.
So let's go ahead and try to download leeches.
By allowing it from my one, which takes a bit.
Again, here I wanted to show how to configure the sandbox dynamically.
You can do this all statically at startup as well.
That's try again. OK, this is another one.
So let's allow this.
It will take a bit to end of all of them.
So basically, you can do this one by one.
You can load a file descriptor as we did before.
Let's get now.
OK, we are coming close.
So now we are going to allow this.
And also four, four, three.
And we should be good to go.
See, it downloaded.
As you can see, you can configure this sandbox from it in sandbox as well.
So this way, you can make a step by step, open BST pledge like the confinement as well.
And this is all I have.
See, if you have any questions, I can't take now.
No questions?
Yes, please.
How complete is the implementation comprehensive?
How complete is the implementation complete?
Where to device the question?
First of all, sit has been used for 16 years as the default sandbox of Exarbo.
An Exarbo has packaged testing by default.
So we run all tests under sit box.
Any test that passes without the sit box, but not without sit is considered a sandbox box.
But, and over the years, we have fixed a lot of things.
Complete is a big, big work.
You can say sit stable, you can say sit gives you a stable Linux API.
So, yeah.
And this day, you can use it as a general purpose sandbox from sandboxing and genics,
to sandboxing files or any similar workload.
Yeah.
Any other questions, please?
Okay.
Just pause map, Mama-Ils had an interestingCI.
OK.
Right.
There's no room.
Hello.
Ready?
Yes, thank you.
Thank you.
Bye.
Next?
To update on tour.
I want to ask that question.
Please.
Yes, please, please wait to mic.
So I have question, because right now, of course, it's going to be questioned about AI.
Right now, we have some problems like trying to sandbox machine learning workloads.
And some teams, some organizations are doing something like running clusters with full access to the internet because we're not.
Of course, you can create a pop proxy and limitations but still.
There are options that you try to run the images of the models.
How can we use this setup to mitigate this kind of attacks, especially when some models try to load the glitches code from the internet?
Is it possible?
Yes, it's possible. First of all, it is possible to sandbox AI workloads.
With sit, we have what's called Iochial sandbox and where you can sandbox rather than paths.
You actually sandbox Iochial requests. And maybe I can quickly show you here in the, in the,
Where is it? I lost it nice.
Okay, anyway, it's an unfortunate content.
But I was going to show you the Iochial requests.
You can even in learning mode, it will learn which Iochial requests are done to the whatever device, the AI or AI, whatever.
And then it will give you a list of all these requests.
And then with that, you can just run your AI workload under sit.
And then what you are limiting is basically up to you, are you allowing it network?
Are you want to run it in a network namespace? Again, sit is a general sandbox.
You are supposed to build to actual sandbox with your configuration, but this is very much possible.
You can't tell it to go to some IP addresses, but not others and so on. This is possible, yes.
Thank you for the question.
Yes, please.
What about the workloads on the GPU? How do you handle this?
For example, idea.
It's basically the same thing.
GPU access is typically done through Iochials.
And what device or does is actually device or keeps a list of and media Iochials by version, right?
So in this way, it's easier for you to use device or sit doesn't give you that.
But sit gives you a way to do this.
So you can run it under learning more than quickly get the request numbers.
These are basically random looking numbers that you have to allow for the GPU access.
And that's how it works.
Yeah, yeah, sure.
Any other questions?
Looking around?
All right, thank you everyone for watching.