All right, well, thank you.
I have a student's part of yes.
Thank you very much for having me here.
My name is Luca.
By day, I work as a software engineer in the Linux Azure group,
in the Linux system group and Microsoft.
By night, I am involved in various open source projects,
most relevant for this talk.
I am one of the upstream containers and developers of SystemD.
Now, today I am here to talk to you about what I think is one of the latest things
to come out of this is the project, which is a particle OS.
It's purpose is to let you build immutable systems.
So, first of all, quick look at the agenda.
We are going to look at why do we want this thing.
What tools do we use to build one?
What do we build it from?
What are the components?
How do we put it together?
Where do we put it together and then what we end up with at the end?
Up through some delicious immutable image.
Now, I don't know if I'm not going to do all the items,
not in a time, but there's lies online on the schedule.
You can download them or the bootings are links,
like, clickable, if you don't know, and about these things,
you can check them online.
Only one thing I want to mention here,
because this is the distribution of everyone.
So, in order to build an immutable system,
one of the requirements that we have at least we have to use
is the metric user.
As a concept, this just means that your OS,
when the three or the distribution of the three,
is self-contained under the user.
Everything else can be regenerated and boot when needed
or installed or on factor Z.
Now, in practice, if you are a distribution package
of the developer, in 99% of the cases, this just means
if you need system users or groups, use cusers.d to create them.
Don't handle your script, bash script and your maintenance scripts.
And if your software needs some directories of files
under var, or if you see, use tmp files.d instead of,
again, under all your maintenance script,
your postings, or whatever.
Because that way we can recreate them on boot.
These are decorative tools with the creating configuration
that can be used for these purpose.
Now, first of all, what is even an immutable system?
The embedded people have been shipping redone images
for the devices for ever, right?
So there's not a new concept.
What we're trying to do here is to push the envelope
a little further.
And especially from the security point of view,
I know to do that, we need to establish some ground rules.
Now, this is, of course, my view and the view of other people,
but I might not be universal, but if I talk so I'm going to tell you about my view.
Now, an immutable system means immutable.
If you just need to run some commands as root
and you persist to change the content of your OS,
it's not really immutable.
If you just do mount, minus, or re-mount,
or W, and you get a completely rightable
and persisting of the system, it's not an immutable system.
If you run some, as napper, zipper,
or pianos, take commands that you can add,
arbitrary programs to that, and then just boot into it,
locally, it's not really an immutable system anymore.
Now, is it?
Now, the way to look at this, in my view,
is to look at the, to think about the threat model.
Now, if you have any system that have any value whatsoever,
as some point, they will be under attack.
And you will have some malware that tries to escape
whatever confinement it finds itself in,
whether that's your browser, and the sandbox in features it has,
or whether that's a container processing
and trusted data from the network.
The question is, what happens after that?
If malware can rotate itself,
in stories that make it self persistent,
then you're going to have a bad time.
So, the harder that is, the better
for any system where security matters.
So, to not do that,
there are some prerequisites, and you can use some tools
that we're going to look into.
But the translation here is,
you really want to use a kernel verified,
the n-varrity partition for your programs,
so that they can be verified,
cryptography by the kernel when they run.
And that way, you don't just,
the malware doesn't just have to escape the sandbox,
doesn't just have to get execution privileges,
doesn't just have to get robot,
but also needs to break into the kernel
and get invertible access to kernel memory.
And that's hard, but impossible,
but hard.
And the other thing is,
the more expensive it is,
the less appetizing your system is for the,
the bad people.
Now, this is used to be really hard to do.
In possible, in fact, if you have a couple years ago,
but one of the purposes of particle OS
is to give you the tools and the recipes
to very easily create such systems and images.
So, that's the motivation.
Now, let's look at the tools.
And because I,
the system projects,
image building tools,
because of course,
we have a image builder tool in this project.
Everybody's got an image building tool.
I think it's a mandatory step in any use,
engineers career to write a new image building tool themselves.
So, this was created by Leonard.
Some years ago,
to facilitate its development work for our system.
These days,
it's done.
It's doing most of the work,
maintain it together with your work.
It's a python tree.
Of course,
it has a nice style configuration files.
We love our,
our, our,
our config in system.
As you might have read,
don't I can use this,
because we are Microsoft shields.
So, we are by a nice files.
Now,
the main differentiator of these two versus all the others
is that it's meant to make use of all the,
fancy tools that come out of this in the project.
So, the greatest and greatest stuff.
And you can use it for,
to build various types of images and artifacts.
Now,
as I mentioned,
it was created for a local developer's work tools.
And it's too great for that.
It has some great features.
And in fact,
there's other projects using this.
I know some kernel developers will use them
because I thought they local development flows.
But we have evolved it past it.
And you can now use it for production images as well.
You can run this on a header server.
We know user interaction.
All look down and it will work and build artifacts for you.
And the images and build the artifacts,
they are just thing to do.
Always is designing.
Right?
So, we support two types of work tools there.
The easiest one is a PCS 11-based one.
So, if your build systems,
security hardware,
as a PCS 11 interface for signing,
it's super easy.
You just said that the config file,
the PCS 11-URI,
macOS IDOS,
everything for you,
and that's super nice and easy.
Not all the systems do that.
A lot of the systems
have bespoke and custom solutions.
But most of those have the same work.
So, that is,
you do multi-stage builds.
So, if first you do your normal builds,
you end up with artifacts,
then your building stops.
But from these artifacts,
it takes hashes,
sends them somewhere,
and then you get back signatures of those hashes.
And then you'll build the starts,
and you get the artifacts,
and the signatures.
And instead of rebuilding your supposed to put them together again.
Now, we support this for one particular build system
that we talk about in a moment.
But,
generically,
because I suppose this work was where you do the build stop,
and then you can start to reattach things,
like the invariant signatures, for example.
Now,
let's see for the tools now,
what are the ingredients of this OS?
Now,
and what is,
particularly as in practice?
It's not a distribution.
It is not a full-blown self-contained distribution.
distribution maintainers do a tremendous difficulty,
and hard,
and fantastic job on maintaining two chains,
and everything else on top of it.
We think that the packages that the distribution builds
are the right and the social layer,
where to start big images from.
Rather than trying to reinvent what packages do
like things like,
like, for example,
in terms of the tools.
So,
particle OS is a set of recipes,
and that's why the abstract has some sort of culinary team there.
Because it is really just a set of recipes
to take packages from distributions,
and use some tools and give out these images
with these particular properties.
We have recipes written for Fedora,
Arch-Suzen-Vebium.
Any distribution supported by M. Kuzi
can be trivially added.
There are both speaking three categories of work
you need to do in order to add a distribution to particle OS recipes.
Well, first of all,
particle OS has a bunch of bulletin config and roof
from M. Kuzi,
and we have that.
The second one is list of packages,
like any image building tool that is based on packages.
You need to write package lists.
If you do that, and then,
you know, we have hooks and tools and commissionals
for distribution.
Version architecture and all the stuff that you expect.
But yeah,
you need to write the list of packages that you want in your image
that is specific to your distribution.
The third of the final thing is,
well, work around,
like,
as anybody who develops image building tools knows
there's always work around for these or that kind of case.
In our particular situation,
the main kind of work around,
that we have,
are for the distribution that don't support
hermetic user or don't support it fully.
And that's why I did a shout out
beginning about that.
Now,
distributions are on a spectrum about that.
Some are better and some are a bit worse.
So there's always work around to be added.
But yeah,
that's the other thing.
If M. Kuzi supports your package manager,
then it's super easy,
super trivial to add a new list or to particle OS.
If it's not,
like we support app,
DNF,
Vper Pacman,
and whatever the post-market OS use,
adding a new package manager is super easy,
like two Python modules,
and we work on PR so that.
Right, so that's for the content.
Now, where do we build this?
Where do we use M. Kuzi to build these images?
Now,
every distribution has their own build system.
Right.
I particularly like the Susan LBS1
for the OpenBus service for a few reasons.
First of all,
usually,
a distribution of the system is only used for that distribution.
You can't build a federal package or imaging at
the BMB network,
and vice versa.
But Susan took a very different approach here,
and it's very open,
and it supports a ton of targets.
So you can build the package.
If you have packages,
and arching your packages,
and more,
and you can build container images.
Then since 2022,
I have the support for M. Kuzi recipes as well.
So if you upload to our OBS project,
the particular recipes,
it will build an image for you.
So that's one of the reasons.
I like this system.
The other is that I particularly like
how they do their signature handling and key management.
Now, very often in distributions,
you have first-class packages that can have access
to the HSNs,
to, for example, sign kernels for secure boot,
and then you have their available boot.
It doesn't, or as just access to some test keys
that are actually public.
In Susan,
it's not the case in the OBS.
Every single package,
you'll imagine it's built on the system.
From my random open source developer,
account, and build things to Susan,
leap or tumbleweed or microes production images,
they use exactly the same sign-in code,
the sign-in components,
and key management strategy, and certificate management strategy.
So there is a high degree of confidence
that, you know,
if you take the start of the dive being on the system,
the project, the particular semages,
it has the key management for that is done sensibly.
On top of this, as a developer,
that creates an image,
and this is going to be,
as a particular semage,
I don't have access to the private keys
that are used to sign that.
Nobody does.
The only things that get signed
are the packages uploaded here in the public
that you can see.
So you know, if you use this,
if you trust these signatures,
I'm not, you know,
you might act of signing with the same key,
so malware that can push to your servers
if they use the particular semages.
And this is a very nice property that LBS gives you.
Now after you build and sign then,
so there's a CDN,
so it's published there,
the nice thing about this is that
the system needs to for updating your,
your OS,
and the format used to publish this
is supported by a set of data automatically,
so it's some PGP sign-minuses,
and it works out of the box,
so you just point this update to it,
and it will update your system as builds happen.
So as mentioned,
we have been in a few of these particular semages,
so if you're going to link there
under the system the namespace on the BS,
you can download a GNOME X86 image,
that are based on the 42,
43, 44,
the event 13 and the event 14.
And also,
yeah, our images,
um,
64 for the event 13 and 14.
I use that on my Raspberry Pi for some,
all automation.
Um,
so anybody can go download this and use them,
and try them now,
VM or hardware or whatever else.
Um,
define a great thing about this system,
this bit system,
and why it's the way for particularly my opinion,
is that users can,
um,
just,
for the images that I'm building there,
and get them under their own project,
and then they get signed by their own project keys,
instead of mine,
and they can be even customized.
Now, I wanted to show the page how this looks like,
I don't trust the networks like a screenshot.
I hope it's visible.
Um,
um, but basically,
this is the particulars,
fedora,
be good on the BS.
On the left and side,
if you're signing in any,
any open source that they're working signing in,
and get an account,
you click on the branch package there,
and this will get copied,
you know,
the configuration under your own project.
So it gets signed by your own certificate,
instead of mine under this namespace,
and,
uh,
so you have a different arse chain.
And then,
if you click,
the underscore service file,
it's visible there.
Well, basically,
that's where it's an XML,
that defines the iteratively points to.
So you can then build your own version of a particular
as customizing your recipes,
and this is that simple.
You just push it to a bit repository,
uh,
click branch,
change the service file to point to your repo,
and you get images,
which is pretty awesome if you ask me.
Um,
now,
what is the end result?
Uh,
why do we want this thing?
Uh,
what are the tools?
How do we put it together?
And where?
What is the end result?
How do we get out of this?
Um,
so first of all,
you get a UFS,
um,
for the system,
for the accusatory,
um,
signed,
protected by sign,
the severity,
and it's based on federal art,
social,
they're depending on what you build.
For your BSB,
this federal,
they're being,
um,
you can of course be the local,
and then you can choose other,
other combinations.
Um,
and then the image,
we also have,
um,
and you can assign UKI.
And so this two,
a partitioner combine in a GPT image,
um,
so I'll fill with this color of this image.
And then,
um,
you can run this in,
system IVM spawn,
or N spawn,
or QMU,
or Bermetal,
and what happens at the first boot,
um,
system D,
we'll format the,
um,
the root,
for the system,
um,
the home,
for the system,
and again,
the TPM2,
the local TPM2.
Um,
so you got,
um,
lots to encrypt the partitions there.
Um,
so then you can also have,
system D,
this is update,
um,
configuration,
and again,
points of the BS,
if you download the images from the BS.
So,
uh,
as new beings happen,
um,
so BS automatically will be,
when the penises changes,
for example.
So,
your system,
we automatically get updated.
So,
we'll decide when it runs,
and you can also,
how to reboot if you want,
that's something you can configure.
Um,
it uses an AB partition in skin,
so it will install,
um,
the new version in the,
in the free space,
in the free partition,
in the unused partition,
and then it will use something similar
to the previous talk,
so boot assessment,
um,
if the boot phase,
we automatically,
for back to the previous one,
um,
it will also use,
HomeD,
um,
for user,
and,
so we have known,
uh,
favels,
and KD,
uh,
favels as well.
We have the recipe for that.
I don't be that obvious,
nobody asked for it.
Um,
but it's there.
You can be the locally,
but both of these,
if you build these favels,
then they will come with the,
flat up in your wallet,
because,
of course,
your,
uh,
window three is the only,
you cannot add stuff.
Um,
the idea with this is that,
the way to add new software is,
um, you can download,
a flat,
self-packification from startup,
so it's already enabled,
but it's for the front-level deposit,
to a configured.
Um,
if it's a server,
then use your stuff,
you know,
you have containers,
you have portable services,
which are awesome.
Um,
you have,
um,
these are books,
or whatever you want.
Now,
the fun I think,
um,
that's quite important for the next slide,
is that the UKIs,
also come with profile,
so UKIs can have multiple profiles
that you can choose to boot into.
And one of those,
as the IPSM enabled with the policy,
IP stands for Integrity Policy Enforcement,
and it's a new Linux system,
you know,
security module that Microsoft added to the kernel last year.
And,
why is it important?
Well,
because,
when I saw the total calculus,
um,
chatting about the security model of this,
and how we want to impose security,
and this is how we do it.
What you end up at the end,
is that,
if security boot is enabled on the system,
in set up mode,
when you first boot,
a particular image,
it will self-enroll the certificates,
that are used to sign the,
the,
the images on the BS,
so that security boot is automatically enabled.
Um,
so then you have the user,
the chain of tasks,
so the CPU verifies the firmware,
the firmware verifies system reboot,
as the boot verifies the UKIs,
using the firmware again,
and the UKI contains the kernel,
which at this point is verified as well,
because it was contained in the UKI,
and then the new thing in the kernel,
then verifies the vendor tree,
because it's a sign-in,
very typical,
not just the invariable sign,
and the signature is part of the,
uh,
GPT partition table,
using the DDI,
discovered this image of scheme.
And that means the kernel trusts your vendor tree,
and as proof that is genuine,
because the certificate is the same,
and there was used to sign everything else,
because we have all,
um,
the,
the same keys,
and then they get,
pass down to the kernels,
um,
machine and platform keyrings.
Um,
at that point,
uh,
if you have the IP,
the integrated-positive,
uh,
enforcement LSM,
with opposing the inter-D,
that is signed,
then we get loaded by system-D,
and at that point,
the kernel,
we verify that every single binary,
or library,
that gets loaded for execution on the system,
comes from a sign,
the invariant image that it trusts.
If it doesn't,
it will reject,
um,
execution.
So what this gives you,
uh,
is an end-dwind,
immutable,
and cryptographic,
verified,
chain-of-trust,
the status of the hardware,
and compasses,
everything,
only way,
including your user-space software.
Um,
now,
this is not complete,
right?
This is working progress.
Um,
for example,
now Microsoft is the interpreter scripts.
Uh,
IP currently covers only binaries.
Um,
if you do bash some scripts,
then you cannot verify that.
But,
um,
the kernel of the algorithm,
um,
API,
implemented anywhere else.
Uh,
I think other colleagues,
um,
in NS are trying to,
uh,
get the first interpreters enlightened,
but the end goal for Microsoft is to be able to run,
this,
uh,
kind of images on servers,
um,
about people cannot run any kind of code.
Um,
the other thing that would be good to do,
not for Microsoft,
but for,
another,
with another hat on,
is to make GNOME,
uh,
IP-friendly.
I know it isn't because of the JavaScript,
uh,
and the JavaScript stuff of the UI.
Um,
so I would really love to be able to make,
um,
make it possible to boot,
like GNOME profile,
um,
uh,
with IP enabled,
but right now it's not possible.
Um,
right.
Now,
I have four minutes left.
I have two demos,
but they're recorded.
Um,
so they can be watched online.
I actually prefer to do questions or comments,
if there are,
um,
in the last four minutes.
Please.
Is that key,
compatible with platforms?
No.
That is another thing we need to do.
Uh,
first GNOME is to be compatible with that.
Sorry.
The question was,
is IP compatible with that pack?
And the answer is not yet.
So first we need to get GNOME to work with,
uh,
call integrity and the problem is,
uh,
and then platform uses
tables,
um,
tables are not great.
Um,
for integrity protection.
So,
no,
it doesn't,
um,
we have some chats with some people.
It would be great if
flat pack did,
um,
signed the invited for there.
Uh,
images,
and then it would work out of the box,
but it doesn't ring out.
And there are no concrete plans that I know of,
to do that.
It would be great if they were.
Yes.
So the question is,
with water at what point of the,
um,
provisioning,
do you do the enrollment of the,
of the keys that are used on a BS?
Um,
the answer is,
um,
on boot,
um,
by system boot.
So when the,
you boot on a system,
uh,
as I mentioned,
secure boot needs to be enabled,
but in stat mode.
And then that means system D can still boot.
Um,
the ESP contains under the loader,
or slash auto,
no,
orders,
loader,
slash key,
auto directory.
Um,
the,
the certificates in the format that,
uh,
you feel understands.
And then it will self-ahold them.
So it's that point.
And then from there,
they get percolated all the way down to the kernel,
because the kernel picks up keys in the db,
in the db,
and puts them into the machine gear.
Any other question?
Yes.
So how many years are you having?
So I mean,
the question was,
how many users do I have?
Um,
I have one user at home,
who doesn't know about it?
That is my partner,
on the laptop.
Uh,
So I'm willing user there.
Um,
and in fact,
like,
Sorry, but yes, and then I think let not as one lap to the use it
Might as a very par use it then as a node lap to the use it
I don't know we more users. Yes, please go and use this
It will it will only break your toaster and your goal vision your cat if you do, but it's going to be fun
Now most in the speaking Microsoft uses this technology is in their own in our own Azure infrastructure
It's not particularly as but it's the same stuff with the American IP and so on so forth
Get question
30 seconds
Any more question as 25 seconds. Yes, where are you using this at Microsoft?
So
Part of the question was where do we use this as Microsoft the answer is we don't use particle S it's to new
We use the severity sign the severity and IP and that is in the Azure infrastructure
So various components of the Azure infrastructure the run Linux
One of which is called Azure boost which is what I do as my day job is a harder Linux
Parting system and use