[seL4] Re: seL4 service discovery question

On Wed, 7 Apr 2021 at 22:51, Andrew Warkentin wrote:

On 4/7/21, William ML Leslie wrote:

...

On Wed, 7 Apr 2021 at 22:13, William ML Leslie

Oh, I should probably clarify with an example: when porting setuid binaries, the common practice (at least to a first order) is to have the "normal" filesystem be the default root filesystem of the exec server, but to also gain a capability to the caller's filesystem to use for resolving user-provided filenames. It's not ideal, and yet already a huge step forward over the unix permissions model.

That's a little bit like the path-capability mechanism I'm planning to implement, although the path-capability API will only provide paths for informational purposes such as displaying in a GUI. Also, UX/RT won't have any client-visible concept of a "capability to a filesystem" (that's way too coarse-grained for my liking; security boundaries usually don't correspond to disk partitions or network shares, and having to set up some kind of filter filesystem for every directory/file you want to control access to is cumbersome). However it will be possible to give a process access to all files in a directory (mount point or otherwise) through either its permission list or through a path capability.

There's nothing to say that a filesystem is a disk partition or such; in CapROS at least you could be handed access to a Directory which is a map to as few or as many capabilities as you like, which may or may not be references to Files or Directories. I have heard stories that KeyKOS has access to a unix-style filesystem, but in all the descendants I have access to, directories were just normal orthogonally-persistent objects that allowed you to ask for a capability by name and any other resemblance to the unix filesystem is probably accidental. The reason I find forwarding a reference to a filesystem an interesting concept is that you may want some applications interaction with the system state to be transactional. My favourite example is the installer. More and more installers think that it's acceptable to call sudo on your behalf (it's really not; I'm looking at you, nix and waterfox) but even if you use the standard gnu build system `$ ./configure ; $ make ; # make install` there's often no easy way to tell how it might clobber the system on `make install`. Running the installer itself within a transaction and allowing the user to inspect the changes is a great usability improvement, and the way to force the installer to submit to the transaction is to only allow it access to resources that are transaction aware (such as an overlay filesystem). I'm aware that if you don't have any need to support legacy you can often avoid the need for such things, but that's a rare place to be in, considering we're talking about full-cream desktop operating systems. -- William Leslie Q: What is your boss's password? A: "Authentication", clearly Notice: Likely much of this email is, by the nature of copyright, covered under copyright law. You absolutely MAY reproduce any part of it in accordance with the copyright law of the nation you are reading this in. Any attempt to DENY YOU THOSE RIGHTS would be illegal without prior contractual agreement.