
This Summer in Redox: A Complete Rewrite of the Kernel - snvzz
https://www.redox-os.org/news/this-summer-in-redox-15/
======
naasking
Is there a documentation reference for "scheme-centric capabilities"? Most
people who use the term "capabilities" use it incorrectly, or their
capabilities have the wrong properties which destroys some of their benefits,
so I'm curious what redox is doing here.

Skimming through the code in the fork [1], it looks like they place
restrictions on sending capabilities in a misguided attempt to "enhance
security" [1]. But this compromises the property that actually makes
capabilities so much better: unrestricted delegation leads to the principle of
least authority via fine-grained permissions. The fact that capabilities can
be passed arbitrarily leads you naturally to defining fine-grained
authorizations so that eventual abuse can be minimized, detected, and revoked.

If you have other "security" mechanisms restricting delegation, then you can
get sloppy and start aggregating permissions into larger groups, thus making
inevitable vulnerabilities much worse than they otherwise would be.

[1]
[https://github.com/ticki/kernel/blob/master/kernel/capabilit...](https://github.com/ticki/kernel/blob/master/kernel/capability.rs)

~~~
Yoric
> But this compromises the property that actually makes capabilities so much
> better: unrestricted delegation leads to the principle of least authority
> via fine-grained permissions. The fact that capabilities can be passed
> arbitrarily leads you naturally to defining fine-grained authorizations so
> that eventual abuse can be minimized, detected, and revoked.

Really? I would have assumed that letting anyone send capabilities to anyone
without going through the kernel was a highway towards privilege escalation.

Do you have documentation on this topic? I'm pretty interested – in particular
since I'm hoping to contribute to this fork.

~~~
naasking
> Really? I would have assumed that letting anyone send capabilities to anyone
> without going through the kernel was a highway towards privilege escalation.

"Unrestricted" in my post doesn't mean "you can send to anyone", it means "no
restrictions on passing capabilities beyond that defined by the capability
model".

The capability security model requires that you can only send capabilities via
your other capabilities. So if you have a capability to another process, then
you can send any of your other capabilities to that process. The Redox design
appears to violate this.

The capability model is actually simple and surprisingly common. Take any
memory-safe object-oriented language, and remove static mutable state and the
file system and network APIs (all sources of "ambient authority"). An object
reference is now a capability. Passing an object reference via method
parameters is a capability send, and you can only pass around references you
actually have, and only to objects to which you have references. That's
capability security.

You can look at any context and see precisely what side-effects can occur
simply by analyzing the set of object references available in that context.
It's bad design to define functions that take a huge number of parameters, but
it's also bad security. Capability security aligns maintainability concerns
with security concerns thus yielding POLA.

Edit: as for documentation, I'm not sure if you want OS documentation, or
general capability documentation. The seL4 and EROS papers are good for
capabilities in operating systems, the E and Joe-E programming languages are
good references for capabilities in general.

~~~
Yoric
I am actually pretty familiar with (some instances of) the capability model,
in particular process algebra-style capabilities, which pretty much don't
limit sending capabilities, but also don't need to deal with Unix-style
`fork`, for instance. I was just wondering if you had specific problems in
mind.

In this case, how would you modify the design? Getting rid of `Kind`, I
assume?

If so, how would you enable/disable passing capabilities? By having a meta-
capability "I can pass capability foo"? That's pretty much how I would do it
in a process algebra, but that doesn't look very usable in practice.

~~~
naasking
> If so, how would you enable/disable passing capabilities? By having a meta-
> capability "I can pass capability foo"?

I would first question why you think you need to disable capability passing at
all, which was the main thrust of my post [1]. What _specific_ problem are you
trying to solve by restricting capability passing?

Perhaps Unix-style 'fork' has some undesirable semantics, but I don't see how
restricting capability delegation would solve them. POSIX sandboxes using
capabilities have been done a few times, originally KeyKOS and then EROS.
Perhaps the most accessible introduction for those coming from a UNIX
introduction would be Capsicum [2].

[1] Yes, "kind" classifies capabilities into those that can be passed around
without restriction, and those that can't, so I'm questioning the utility of
that

[2]
[https://www.usenix.org/legacy/event/sec10/tech/full_papers/W...](https://www.usenix.org/legacy/event/sec10/tech/full_papers/Watson.pdf)

~~~
Yoric
> I would first question why you think you need to disable capability passing
> at all, which was the main thrust of my post [1]. What specific problem are
> you trying to solve by restricting capability passing?

Right now, my specific problems #1 (resp. #2) is understanding what you (resp
ticki) have in mind :)

But I can also think of problems such as: 1/ limiting privilege escalation; 2/
somehow transitively revoking privileges that have been obtained through a
compromised process.

Not sure if `Kind` has any effect on either, but I'll spend a few days
thinking about these issues. I'd be happy to chat with you if you're
interested (I'm Yoric on irc.mozilla.org).

~~~
naasking
Revocation is a solved problem for pure capabilities [1,2]. Privilege
escalation is typically not so important in capability systems because
processes run with least privileges. There is a pattern whereby authority can
be increased if you're granted a special type of capability -- the operation
is called "rights amplification" in capability parlance, but these
capabilities are closely held by the trusted base.

Finally, the reason restricting delegation doesn't generally work is that a
process can just proxy access to the undelegable capability, which means you
haven't actually attentuated authority in any meaningful way. At best, you've
merely reduced the bandwidth, so overall performance suffers, and you've also
sacrificed compositional reasoning.

Anyway, that's why I initially asked for any design documents for Redox's
capability system, so I encourage ticki and any others working on this to
write a rough draft of the ideas. I know plenty of capability people who would
happily provide feedback.

[1] [https://www.cs.ucsb.edu/~chris/teaching/cs290/doc/eros-
sosp9...](https://www.cs.ucsb.edu/~chris/teaching/cs290/doc/eros-sosp99.pdf)

[2]
[https://sel4.systems/Info/Docs/seL4-manual-2.0.0.pdf](https://sel4.systems/Info/Docs/seL4-manual-2.0.0.pdf)

------
snvzz
I applaud lessons taken from Liedtke/L4, a major step in the right direction.
Now I can look at that project seriously, rather than consider it yet another
pre-Liedtke mistake.

I'm not so sure, however, about concurrency in the kernel. The locks and added
complexity certainly aren't going to help keep WCET low and bound.

NICTA's SSRG did study this:
[https://ts.data61.csiro.au/publications/nictaabstracts/Peter...](https://ts.data61.csiro.au/publications/nictaabstracts/Peters_DEH_15.abstract.pml)

~~~
cm3
Yeah, I wish they had teamed up with Robigalia in order to build on seL4 or at
least translated that 1:1 to Rust, foregoing the verified nature of seL4.

~~~
cmrx64
I wrote on their forum about why they "shouldn't" use seL4, and definitely
shouldn't port it to Rust:

[https://discourse.redox-os.org/t/why-not-port-
sel4-microkern...](https://discourse.redox-os.org/t/why-not-port-
sel4-microkernel-instead-of-starting-from-scratch/337/5)

If the goal is trusthworthy, reliable software, then you should use seL4. If
the goal is to yell about how great Rust is, you could port seL4 to Rust.

~~~
pjmlp
Fully support your point of view.

What we always see on programming languages is that when shortcuts for
arriving faster at our goals are taken, usually they give ammunition to
remarks of the sort "language X cannot do Y".

Apparently most lack vision and need to be proven wrong.

So I hope they manage to just use Rust and Assembly.

EDIT: Improved the sentence

------
cm3
> In order to continue the development in a reasonable speed, we stop
> conforming to the specification of ZFS. As such, we can no longer call it a
> ZFS implementation.

They have their valid reasons, but it's a shame, because an implementation of
the very complex ZFS filesystem in Rust would have been a great thing to have.
Not to mention the ability to mount redox zfs images with illumos or FreeBSD
or ZOL.

~~~
jackpot51
TFS will be mountable on any OS with FUSE - Linux, BSD, illumos, and OS X

~~~
Yoric
Well, there's the problem of testing the implementation on every OS.

------
nwmcsween
The kernel from this limited bit of info is almost an exokernel, it's missing
the most important bits, an asyncish syscall api and proper capabilities.
Batching is a nice mitigation but not ideal, an ideal way to mitigate context
switches would be a data-driven api that let's the kernel (due to info the
kernel has access to) decide. Both a data-driven api and exokernel with a
proper language you could apply optimizations across the entire operating
system.

------
mtgx
Will the TFS also support native encryption like Apple's APFS?

~~~
Yoric
I just talked to Ticki and he said he would support that.

As a personal note: is it really the right place to support encryption? I seem
to remember that APFS's encryption had a pretty bad reputation in terms of
actual security.

~~~
xenadu02
> I seem to remember that APFS's encryption had a pretty bad reputation in
> terms of actual security.

Based on what exactly? APFS actually has really good security. You can encrypt
on a per-file or per-directory basis. Each per-file key can be encrypted with
different levels (the shared key or per-user keys, so permission bypasses are
useless).

~~~
Yoric
As in I'm pretty sure that in a previous job, I received semi-official
government-issued guidelines: « Don't use it, we know how to crack it, and
we're pretty sure that we're not the only ones. If you value your data, use
TrueCrypt instead. »

It was pretty thin on details, and the stuff may have been fixed in the
meantime, but here you go.

~~~
johncolanduoni
Are you sure you don't mean CoreStorage's encryption? APFS isn't even finished
yet.

~~~
Yoric
Ah, I'm probably confusing, then. Sorry for the noise.

------
forgottenacc57
The server would be interesting if it implemented libvirt virtual network and
virtual hard disk drivers so it could run on cloud hosts.

Does it?

