Hello, so first of all, thank you so much for staying here this late.
I know that this is how it collides with the Linux Foundation event, so I have to get the
Internet.
I'm Daniel, I'm the software engineer, Vahat, and I'm also somehow trying to run the BPFC
group in Fedora, and I would like to talk to you a little bit about BPS programs and how
you run those out.
It's first of all, so I can get a little bit of a vibe, and how many of you have
ever run a BPFC program?
I've known root, okay cool, but because you don't want, okay, so in non-usein kernel
capability, okay cool, so I think that's going to be interesting, so basically I want to
speak, and this is the main topic about the whole session, about the privilege program,
so as you have been noticing most of the people when they run BPS program, they just say
okay, let's do it in just a fruit, and that's a little bit of a main issue, as when
you first start doing anything in Linux, you will have a fruit, then things work, that's
work, and suddenly you notice and you realize that this is not a good practice, so
then a some point you realize that there is a thing called kernel capabilities, is there
anyone here who's not familiar at all with kernel capabilities, okay, then you're good
but when a BPS was first a thing, it was just using Capsis admin, so that's basically
okay, I'm giving you root access to my system, and you're happy to be able, and things
that work again, so what's same before, but again this is not the best practice at all,
then at some point BPS realized that okay we better go and create one specific capability
for BPS, so that's how we got BPS here, so you can just go and look programs and create
maps, but depending on what you want to do, so let's assume we just got C-scope today
and it's a while in costiness, so let's assume I want to just create an XTP program, this
wouldn't be enough, but you would also need to hurry up and update that into anything
directed when it works in, and there it goes, so basically if you're following me, the
dependency in the privileged program program is still yours alone because you're
keeping in the end root access to your BPS program, so this may lead to let's assume we are
working into Kubernetes here this days, we are running containers, but we may not want to
run a privileged containers, which again would be, again, giving you root access to your
host system, which is not a security goddess in points, so not only, sorry, not only containers,
but you say you may not be happy and specifically in linguistic distributions, because nobody
would like to, there's also things that would be speaking about later, but I see Linux and so forth,
which may be not be happy for you doing all these things, and basically you get too many
privileges, so don't call us BPS talking, what a hell this is, so a BPS talking, the main
idea of that is a little bit like, let's say I'm a privileged user or root whatever, and I'm
going to be giving you access to run BPS programs, but let's go and create such so much
more granularity and scope related, and reduce it, you're reduced way of doing so, so basically
we are going to be having, I make an issue to run this, so just in case you don't know,
BPS uses a pseudo file system, so you can mount it, and you can create a token, then the user
would be opening a token, and then you would have BPS access, but in a limited way, because for
instance, let's assume we are yes using a BPS program, so it's a BPS top, or I just want to
create a K-probe, I may not want to have access to, let's say, open a socket for networking,
it wouldn't make sense at all, and this is going to be a huge, like security risk, again,
modern related distributions, as in our case Fedora, aren't happy with that thing,
so again, how does this works? It's pretty much what I said, but we are going to be speaking
with a little bit with you about like the delegations, the locations are in the scope of the
BPS token, putting that select capabilities, so you can, again, say I'm going to be giving you
access to a limited amount of programs or commands, I'm going to be giving you a limited amount
of permissions in terms of BPS maps, let's say memory, and this is going to be even fine with
very far, so it's totally fine, how does this works? So you trust me, again, there's some
capital dot, but I didn't explain that here, and by the way, you can see there's like there
in the link, this is already in the production links, feel free to load that, so there's a few
things that you can do in terms of delegations, so you can set commands, you can restrict the
list of times that are going to be running, program types, and also attachments, so I put an example
here, is this big enough to make it bigger? Okay, cool, so let's say we are going to be creating
we can load maps, we can create maps, we can load programs, we can create maps arise, but I'm only
going to be using a K-drop in a trace point, which makes sense, if I just want to do something
we can get in trace of okay traces, you can do whatever you like with that, you're not limited to that,
but you can also, let's assume we are using, I don't know, the modern network can see and I
plug in, see we would do something like that, but also allowing to mount to access networks,
to create sockets and so forth, it's an example also for trace only talking, it's pretty much
the same, but what we are doing here, so we first as an admin, as a route, we created token itself
which is a kernel object, and we are basically later on allowing the user, which is a developer,
whatever, so we created the group called developers, what what's happening with this, so now
developers and anyone in the developer's group would be able to run programs, but they wouldn't
be able to load traffic control or exhibit programs that could totally mess up with that, with
this what we are creating is a much higher level of granularity with that because we are allowing
people to run things in our systems, but in a controlled way, so we don't know for them to be
route, and we don't know and need them to be having a much more big enough capability, like
I'm going to capture you so I mean, as I said before, or it can be bad. So, this is just,
I'm not going to demo that later, using like batch and so forth in a Linux kernel, but I like
Rust, like, yeah, if you go, I guess last year, I was just speaking about AIA and a few different
libraries, for the ones that you don't know, AIA is a pure Rust native, EVPS library, which makes
your light match easier, because this supports BbF talking out at the blue, as long as you are
running a Linux with a kernel higher than 67, which is no normal thing. Again, this is pure Rust native,
so going with me with some AIA attachment, but how do I load the brand we're talking in AIA?
It's pretty much the same, so we are checking if the talking exists, we're creating that here,
and then if it exists, apply it and then we can load the program directly. So, no pseudo,
no root, no capability, just simple code in Rust, a couple of lines, is just works, and I think
it's one of the best Rust examples you can find here. But again, with no Rust here, let's see,
compile, it gets there, so come with me with a demo, I got what it intended to be a live demo,
but it didn't work the day, so I got a video, how long? So let's assume that the program that I was
speaking before, we got the AIA treasure and we are trying to run it as this, without any talking,
it will tell you no, no, no, no, how long it will wait, but we are expecting. So, let's see the talking,
so here we are creating a mount in the token and we are allowing it to use K-pop, and now we are
as I was saying before, allowing the developer, to access that and change it the permissions.
So now it's going to be using the BF token, the ligation is going to be loading, and then
you're happy.
It works.
It's the same binary, same user.
Now just using the token, no root comes here, no pseudo.
No, no, no, no, no probability of no permissions.
Which I think is pretty much in a better way.
So again, if you try to load a program that is not allowed by the token, it will just
missively fail in the same way, that's to be expected.
Because why would I allow any user to run a TC or XCP program if I just want to have
a k-pro?
So again, no, I said, I'm an FADOR contributor, I'm a FADOR researcher, tomorrow we got a whole
death run about distributions, and I'm going to be speaking about this in way much more detail,
but why don't we care about that?
In the distribution, we care about security, interoperability, we care about having shared
dependencies in order not to have another load, and when we pack it to staff, we lack for
that to be able to be handed to the users in a safe or interproducible, and limit the
permissions way.
Just think about the links.
So what we are thinking about in the FADOR CIGR for EPPF is to interact in this directly,
with the encoding and our build systems.
So for instance, we can have a system of unit, and this can be controlled, yes, a rootless
system services.
So let's say business system D, as a service, what did we do in the beginning?
It would just mount the BPF token, assign the permission, and it would just work,
and we don't need to run this as a pseudo at all, ever.
In fact, one of the things that we were thinking about is just in FADOR, there's going to be
a proposal for DOR 45, about creating by default an EPPF group, and that's in the same way
as you do wheel.
I mean, no pseudo here, yes, don't miss the things out.
What we can do is like creating a new group called BPF, which would create a token by default,
and they wouldn't have over permissions to people to run BPF tokens.
How do we do that?
Which permissions do we get?
This is not something that's covered with session, but we'll discuss tomorrow.
So, and this also applies a set before the boardman.
So, is anybody using non-wrotless containers important here?
No, nobody.
So that makes sense.
And you may ask me about the two links policies.
This is, as of now, a big issue.
So one of the things that we have to work into the links distributions is about adding
a new scheduling policy.
That would allow you to run BPF token as a default without being screaming no hell in
way, and I don't want to run this into a permissive mode or disabled mode.
So that?
I would like for you.
If you want to help on that, as I said, it's going to be a new proposal for DOR 45.
You want to get involved.
You have ideas about how to basically coordinate and elaborate on this with Fedora.
We are totally welcoming you to come with us and discuss this out.
Because I think it's a big enough topic that both allow links distributions to run BPF programs
basically in a no-it-a-routlet mode, which is like everybody would like to.
And so far, let me quickly go.
I got a demo.
So, let me quickly go through that.
Can you see my screen?
Bigger?
How about now?
Awesome.
Thank you.
So these morning, I can tell you, this demo works.
Then I came to the closing that work and didn't work.
And it's not working.
But I recorded it just in case.
Which I think it's a safe measure.
So let's go through it.
So here, we are going to be taking the kernel and the current BPF loans.
As I said, higher than 67.
And then we got it here.
We got the tokens and it'll get in mount.
So now we can see other legations in the mount.
The amount has those other legations that I was speaking about before.
Okay, preference of four.
Then we're going to be running as a regular user.
And this one worked as a blue because of this is intended to use fs open and not dry
mount.
But let's go and create a container.
Then a regular container would just run as it was before.
This is using containers already do the fs open thing for you.
You don't have to do the thing.
And then main difference on that.
Let me actually put that a little bit there because it was running high on the thought.
So inside the container.
So and yes, you just regard it.
The percated volatility.
This is not in front of man.
But we are using.
This is a rootless container.
It's the root within the container.
But this has been run as a regular user.
We can now mount the BPF B profile system here.
Which means that we can just access the maps and access whatever we want to.
You can see that we are able to access that.
And in the real setup within BPF token.
We can use the BPF token create or just a within the container.
And this would just work.
Without having any previous host, which will again run in the container that's worked within our system.
Coming back to here.
What time is it?
Yeah.
So again in the BPF group.
What we are working into.
To first, one of the things we are interested for further 45 is to add packaging guidelines for
BPF with token.
Half a default token.
That is what I was speaking about like creating the new BPF group.
And so forth.
At support for as a leaner.
And also we would like to have this direct support.
And we would like to have this document using an option.
And documentation of course.
So if you want to get involved.
We got a week here.
Not so if it's speaking enough.
But you can check it out in the slides which are available in the room.
So with these questions.
Hi.
Thanks for the call.
Is there any plan to get on board with that idea?
With various security vendors that are working on the Inux.
That would be like Microsoft, like Central Wall, like Crop Strike.
Can we get them on board with the tail?
Are there any questions?
Is that way of interact with BPF?
Not only.
But first.
What I will be working into is a proposal for $4.45.
Once that we are there.
That's going to be a point for comments to anybody.
And of course I would like to include security.
People in other companies because.
The main idea is that this would become somehow standard.
Not only type to Fedora, but open to any news distribution that would deliver it to that.
I know another hand before.
Thank you for the talk this.
Don't just look amazing.
I'm doing Netful Programming with TC and ITP.
So I'm interested in.
My problem is reverse.
Who?
With XP and TC.
You typically need birth month because you compare pointers.
And it's care is that in the working program.
Can reader be treated care not memory.
Are there any plans to restrict not on the net tax and program plans?
But also helpers and K-fax.
I mean, the main idea that I had in mind was to actually restrict.
But I given that you get it enough access to the token.
You can do anything.
So if you need a net work TC or HP program that needs to follow the access.
What you book me a link to do is to increase the scope of the token.
And it should still help you work.
I haven't tried it though.
That's without reposition.
I can't hear you, sorry.
You need birth month.
Yeah.
Your problem can reach kernel memory.
You need birth month for net working.
But I'm really in a sort of program where they need to reach kernel memory.
They just have birth month because it's necessary to direct packet access.
I see what you mean.
Well, I haven't asked that in mind.
But I would definitely take a look when I brought the proposal.
So thank you for that.
Thank you.
So just a hint to the colleague that has said about net working.
I don't know.
You can get away from direct packet access by using BPFDEN pointers for SKB payload.
At least for TC for HTTP or your stack with direct packet access.
And I had a question for Daniel.
You know, does BPFFS support file system ACLs?
Or we're stuck with just user and group of traditional file permission.
That's so far.
It's not that it doesn't have that support, but I wouldn't need to take it.
So we can just take it out later.
All right.
Thanks.
There have been dozens of CVs in the very fire in the last years.
Some of them you know, like to write and modify kernel memory at runtime.
Do you think about that when you say that's a good idea to allow none privileged users to load any arbitrary
BPF program into the kernel?
Well, this is a little different thing.
So CVs would affect your regardless of you have to download.
And we, as in Fedora, we are very, we got, we are really carried about CVs and so forth.
Not only about BPF, but about, you wouldn't believe the amount of CVs that we've seen the more minor things.
Given that, I said that if you were to study enough, it would be the same up, you know,
allowing you to write to whatever.
So these may be some good idea about trying to use as a Linux to some arbitrary data,
but I believe you think about that when you're more detail when I write the scope.
And I'll be publishing now and it's going to be public.
So feel free to take a look and write any comments if you'd like to help us.
Thank you for that.
Thanks.
Let's see a final question about that.
Hi, Daniel. Thanks for the talk.
I have two questions.
The first one is, what is the lifespan of the token?
Are they valid for forever?
And the BPF program, just going to use that one day I'll load it.
And the second one is, where can we find the actual permissions to actually configure?
Sir.
So the permissions themselves, it's like a,
mainly done by the delegations I was telling before.
So when you select the delegations that you're seeking the token,
you're allowing it to use the comments and the specific BPF capabilities that you wanted to use.
And secondly, about the lifetime of the token itself, that's something that we would need to discuss
because if we think about like having, let's say, a defaulted BPF group,
we may have that one that is forever.
I think that's a terrible idea to be honest.
So we should make it rotating as a fourth.
And one of the things that I'm going to be discussing in the abstract is about like,
how often do you need to rotate soft secret?
So thank you for that too, but it'll be still a simple discussion.
All right.
Can you read the mic?
Sorry.
One more.
Yes.
So I work with embedded systems and my question is,
did you consider also embedded systems when you designed this token management stuff,
like purple, also for example, which is container-based, but for embedded systems?
OpenWT, which is a smart traditional one.
Well, I'm not an embedded engineer, so I didn't consider specifically embedded systems,
but if you're interested, again, I'd be really happy to have it set later if you liked it.
Or just when I put the abstract for there,
but it should just be pretty much the same.
So I was saying, like, any runtime of OCI runtime should work with this,
as long as it has a kernel higher than six-seven.
So it should just work.
But I didn't test it specifically for embedded systems.
So one interesting feature that I guess wasn't mentioned.
I don't know if you're aware of it or not, but actually,
I was really, it's really interesting to see that you mount a file system like this,
and then add it to the container.
One of the other approaches that is, like, really prominent in the initial patch set,
in which this will introduce, is to create a map to essentially have two processes,
which have a unique socket in between them,
and then have the un-prevalent process created the BFFS,
with the new FSS calls,
then send that over the socket to the privileged process.
So it can delegate the permission.
Yes, it will.
And then it sends it, and then that file descriptor you already have,
don't even need to mount it on, like, on the path,
and you can already use that file descriptor with those permissions.
So it's in that model.
So it's slightly different than directly mounting it to a path.
But in that model, you can drop, like, you can close the file descriptor,
and drop it from your permissions.
So it is still voluntary.
It doesn't expire, but you can, like, load your programs,
and then just close the file descriptor, drop it from your options.
Which is, perhaps, a really interesting idea.
The other one is that, in system D and LXC,
I can't remember which name it is, but they already implemented,
like this mechanism natively.
So in BPS system D units, you should already be able to just specify
the delegated command, and it will just do the setup of the BFFS for you,
and LXC does something similar.
I haven't seen it anywhere else, and it will be really interesting to see,
perhaps we could, this also would be part of OCI at some point.
Yeah, but you can just specify it.
I thought you would start in the problem level there.
Yeah, that's just wanted to highlight that.
In fact, I'm really curious about this, it's an integration,
because of course I want to integrate up,
even in existence of course.
So yeah, yeah, thank you for that.
Yeah.
RRPPF tokens integrated with the Linux audit subsystem.
I mean, that's what I was saying before.
I mean, one of the goals for this scope of work
would also to be to enhance a Linux to also support
the amount of the D thing.
Because so far, it would just kill you.
Okay.
Okay, there's no more questions.
Thanks a lot for the organizers here for inviting me over,
and for my family to have it alone me to come here.
Thank you guys.
Thank you very much.
Thank you.