The kdbuswreck

Why? All this does is potentially create new security holes: if you can trick the app into opening an arbitrary file, you can now make it open one of its own FDs too, possibly bypassing chroot environments, etc. (This is in fact already possible through /proc/self, of course.)

> * separate services by security domains (so, choose the granularity of the service operations in a way that you either allowed to talk to the service or not)

No, that's the opposite of capability-based security. This is access control lists, with which it's notoriously difficult to express complex security policies because as the ACLs become more granular the maintenance burden skyrockets.

In capability-based security, you simply give a process capabilities (file descriptors) for the resources it needs to do its job and not for things it doesn't need. Essentially, you can define new "security domains" on-the-fly by specifying a set of capabilities.

> * let processes pass these fd's selectively to others

Unix domain sockets!

> * instead of sockets (streams), use directory trees (like in /sys)

If the goal is to put everything in one directory tree, then, again, you're creating a global namespace which creates risk of confused deputy attacks. OTOH, if you are allowed to have lots of different directory trees where you can give someone access to a particular tree by passing them a file descriptor and using openat() style calls, great. But I think trying to shoehorn arbitrary interfaces into looking like directories tends to create ugly interfaces. I want data types and function calls, not strings and read/write.

> * add an simple but generic remote file system for that

???

> Finally, you'll have something like Plan9 or Inferno ...

Sorry, they don't sound like what I want at all.