How are everyone, thank you for coming today, my name is Ibuki Omaz, our student
and I will talk about KVT based security in RedoxOS and I will explain how we are
making RedoxOS more secure by fundamental changing the way resources are accessed or
managed within the system. Once again, my name is Ibuki Omaz, I am a student or Tokyo
member of the college for industrial technology, Japan. I have been active contributor
on RedoxOS since April 2025. I worked these projects in the next few months, I will get
support and work FD passing support in Redox. Before we dive into the details, let me introduce
about RedoxOS. Redox is a general purpose, like Michael Connor based operating system
between Rust. Because it uses Rust, it is memory-safe by default. It prevents common
bugs like buff-overflows and it uses Michael Connor architecture, this means drivers and
services on user space. It improves the variety. It provides driver crashes, the system
will save the life and we also maintain partial project compatibility, making it easier to
relatively easier to put existing software. Finally, the RedoxOS is designed to
be easy to extend and easy to improve. I looked at the architecture, the Connor is very small,
less than 30,000 old code. In this design, the old services, like first systems, networking,
also process management, manager, one separated programs in user space. We call these
service providers, steam, steam. First, operations are handled by these schemes. And to support
applications, we are developing revc. This is a system delivery which can enter in Rust. In
Linux, it maps to grow system codes. But on Redox, it goes through Redox Rampine service.
Work is ongoing to handle Redox Rampine. This means we can secure applications without
were writing them.
Before go deeper, let's define some key terminologies.
Security in this context means minimize the risk
if a program hijacked is hijacked.
The sun-boxing risk-wifting program,
so it can only access specific and contain environment.
The other list is a simple take-a-space list
of something that are allowed.
An ambient also is the most unique system
like rely on this.
It allows the resources are accessed by their name,
checked against the static, really defined punishments.
This is an opposite of capability based.
So what is capability?
Think of it as an exposure token of authority.
It refers to a specific resource with a set of rights.
This is a similar to a five-discution,
but it includes fine-grained permitted actions,
such as ability to get the owner of this file
or change setting terminal settings.
And the application holds this token,
but it exists in protected memory.
So the application cannot forge it.
In RIDAX, five-discuiter is a reference to a capability.
Awex will this concept in more depth later in the talk.
Now, we are learning from other operating systems.
Pre-BSD has capsicum.
It allows the program to enter capability mode to restrict itself.
And the OpenBSD has pledge and unveil
to restrict system codes and file passes.
And SEO for also uses capabilities,
but broadly for system resources.
So this is a tool scope for the purpose of this presentation.
Our main goal is making capability-based security.
The main mechanism for providing services and using resources.
It will serve as the infrastructure
and then its standard project file discreters.
And we will provide APIs, compatible with capsicum,
wasn't washi, and possibly unveil.
And we will also support multiple styles
sandboxing, includes CH route and content.
The content is our own lightweight containerization.
Eventually, it capability will apply to every resources,
such as memory and processes and a file, also file, and threads.
In fact, processes and threads are already also
capability in Redox.
Since we define a file descriptor is our reference to capability.
So here is the status of our current work.
We initially focused on converting memory resources.
To achieve this, we have separated project file discreters
from the Redox internal law use file discreters.
And move, name-based management out of the kernel
to into the user space.
And we also implemented file discreters sending.
Soon, more general capabilities with the audit
is a kernel.
And file discreters will refer them directly.
So this might be hidden from standard project applications,
but it will change how the system works internally.
Two hundred-cented changes, especially namespace management,
we first need to review how Redox handles resources.
So look, so talk about schemes.
In Redox, the scheme identifies a service or driver.
All resources are accessed by scheme with the best.
Originally, we used legacy UI formats.
Scheme name, columns, slash path to resources.
That's why we still call them schemes.
They originally corresponded to the scheme component of UI,
but to improve compatibility, we moved to the current format,
slash schemes, slash scheme names, slash path to resources.
Let's argue the traditional file file for.
This is how resources are accessed by scheme routed best.
Application code, some file, with C-combats,
it to obviously it's scheme routed best.
The kernel, using global name space in the kernel,
to find the target scheme and this part is a request.
In this case, the file is the target scheme,
and the open request will reach it.
Finally, scheme API converts requests to file operations.
In this model, the namespace logic lies inside the kernel.
Our goal is making a change this.
We want namespace to be capability,
not just global identifiers bounded to our process.
Key concepts of this transition is open-art system goal.
Openart opens a file relative to the directory file descriptor.
In an unrestricted mode, it is just a convenience.
But if we, however, issue limited paths to ban is that
jrxd, and rich-wicked program only open-art,
jrxd effectively becomes a sandbox.
A program cannot see or access anything outside the directory.
Based on it, we have introduced the namespace manager in user space.
It sits between an application and schemes,
as on one of the user space scheme.
Here is the file.
Application calls open.
We will see somewhat it to a relative open-art request
using namespace, a process in namespace actually.
Request will reach it, reach namespace manager.
The namespace manager resolves the request,
and call open-art on scheme routes.
The application calls only operates relative to their provided namespace
safety.
This allows us to remove complex scheme and namespace
management from the kernel.
Now, currently schemes are created anonymously in the kernel.
And they register themselves by themselves with their name
and their scheme route directory.
Next, let's go by for the concept of capability in redox OS.
In redox, we don't distinguish resources and capabilities.
Everything is a resource, and every handle is a capability.
However, we can categorize them into two types.
Two types.
First is direct capabilities.
These are handles that you directly operate on.
This category includes what we call resource capabilities.
This points to complete things like files,
and permission capabilities.
It's represents abstract rights.
The second type is indirect capabilities.
And this is a handle that's used as arguments or tokens.
You don't read or write to directly dim directory.
They pass us arguments.
You pass them to verify your authority or providing context,
like UIDFD or the directory FD.
This leads us to how file discute works as capability handles.
There is an important distinction we make here.
For the application, the file discute is just an integer index
into the table of references.
But in the kernel, it maps to the file discution that stores the rights.
You cannot touch file discution directly.
So you cannot project them.
Therefore, the policy in the open file discute is the proof of authority.
Next, let's talk about how we grant capabilities.
We can grant capabilities to a program by withdrawing them.
First, the capabilities can be inherited by the process during folk and exec.
Alternatively, we can grant capabilities to another program by sending it by a
Unix domain socket or Redox native capability of wording.
The once of capability was granted, the receiver has permission to use it.
The scheme will not need to check UID,
use the ID anymore as long as the capability is open.
Look at the diagram.
Here is how file discute is sending works.
It is worth noting, file discute sending can be implemented all schemes.
In this scenario, application A sends activities to application B
via the scheme acting as relay.
So application A sends activities.
The kernel removes the activities from a file table and temporarily hold them.
Then kernel notifies the number of the target scheme and number of
activities and scheme obtained the activities and retrieves the indices of new activities.
The orange ver indicates the client's location of
activities. The kernel holds them so the orange ver moved to the kernel.
The scheme obtained activities and retrieved the scheme indices, indices,
orange ver next assist to the scheme. The scheme returns a response.
At this point, the activities are effectively in the scheme context.
For schemes, they only need to consume activities from another process.
The work flow is end and ends here.
But we want to send activities to application B. Let's continue.
Next, application B request activities.
The kernel notifies the scheme of number of activities.
The scheme moves activities to the kernel to hold them.
The orange ver sits back to the kernel.
The scheme returns a response.
Finally, the kernel adds activities to application B's file table and notifies the
these indices of activities.
With the work moves to application B's context, the file descriptor sending is complete.
Next, let's look at how our sandboxing strategies.
First, these features to support or implement two approaches.
First is CH route, but it adapts to the kernel,
and it adapts to the redox. In Linux, a process has single route,
but on redox, we can have different routes for different schemes.
The namespace manager maps, scheme name, and scheme routes,
but however, the scheme routes don't need to be a scheme original route,
and we can register the virtual route.
For example, if we register a slash jail directory to ask a file scheme route,
all access to the scheme file slash is automatically confined to slash jail slash.
And we also have a tool for the content.
This is this used trusted launcher to define an allow list of paths.
This prevents confused safety proven by ensuring the process can only access
exactly what launcher permits. Next, let's look at how to expand
capabilities. In capability-based system, the programs usually start with limited rights.
They can drop rights, but they cannot gain them by their own.
To expand their scope, they must ask on outside agent.
This is similar to Kaspersavis on 3bst.
In redox, we use five disclosures sending mechanism to grant capabilities to a process.
However, we will need our validation service to verify the request is also advised.
Finally, this is a future work. We want to work five disclosures representation in
user space to work on top of more general capabilities.
And we will provide a fine-grade, fine-grained rights beats into the kernel,
similar to Kaspersavis. And we will implement memory-sharing mechanism with capabilities,
and we will define Kaspersavis like rights and API for file access and port the Kasperskown
test to suit. And we will also develop Kaspersavis like mechanism for capability-based escalation,
and finally, we are going to provide Wazi Kaspersavis. Thank you very much for listening.
More than enough time for questions.
Could you show the slide that this will be the result of the mission?
Yep.
I don't really see why we have to make a difference because you see you can definitely
action that for me, which right or the resource is an action.
I don't see why we don't need to, okay, he asked why we categorize direct or indirect.
Actually, we don't need to need to categorize them into two types, but so you ask,
so you don't understand the difference or why is it there, why is it a direct and it's such a
technical one-tire?
Yes.
Because from me, the resource capability-tip can be implemented as in you have the permission to
wait and have the permission to write.
And maybe the permission to move in the file or all kinds of things you can do in files from
the file needed.
Yeah, um, the differential permission capability and indirect capabilities, okay, for babies.
But, so sorry, it's not that really technical, they're different, more right, but
it's useful for our categorization.
It's just for explanation, so there's no difference, no technical difference, okay.
Any more questions?
Is there a limit of how many capabilities you can have, like in the system?
When the columns have had the limit?
It's just limited by the amount of memory.
Yes, it's limited by the amount of memory.
Yeah, that's dynamic here.
Yeah, I understand.
Okay, I guess.
Yeah.
Just on the viewers, it was the data structure.
In the kernel, that maps the references to the capabilities.
The coin?
Oh, it's going to be easy.
So, it's going to be easy.
Be easy.
Yes.
Has V3 maps to, uh, for, uh, table reference?
Yeah.
Do you have any view of what is performance over the course of running the system?
What is the price of having capabilities?
In terms of performance?
Um, so in, in this, uh, the kind of commentary, uh, this, uh, access to capability
and this system goal.
What's, if we, uh, uh, change capability, uh,
change representation, uh, uh, uh, virtual memory.
Uh, we can, uh, we can access the, without, uh, system goal.
It, uh, it's, uh, it should, uh, uh, uh,
uh, improved performance.
Yeah.
Now we need to move it.
It's a little bit different.
I mean, I mean, in the current, we don't do that.
And that's a lot easier because you just do it in the road, the path.
And then we discuss this with the server.
And we need to understand the protocol we need to pass from.
All it doesn't up and you just get to know.
And that's fine.
So you then open the node.
Maybe it's a fine.
Maybe it's not a fine.
And maybe it's both.
Maybe it's not done because it's all together.
And that's fine.
Because the rule of the void is complicated.
It's true.
And I quite understand quite a lot of things.
There really is a different reason for everything.
I would suggest to discuss this offline.
Yeah.
I think this might be.
So anyone else, always I would say thank you for the talk.
Thank you for listening.