4 ms·

The kernel knows about system-local users, but not the remote ones. Servers may need to access data of multiple users at once, so it's not as simple as some set

by pornel 2y ago

The kernel knows about system-local users, but not the remote ones. Servers may need to access data of multiple users at once, so it's not as simple as some setuid+chroot CGI for every cookie received. Kernels like Linux are not designed for that. Maybe it would be more feasible with some capability-based kernel, but you'd inherently have a lot of logic around user accounts, privileges, and queries. You end up involving the kernel in what is row-level database security. That adds a lot of complexity to the kernel, which also makes the isolation itself have more of the attack surface. OTOH you can write your logic in a memory-safe language today. The VM/runtime/guaranteed-safe-subset is your "kernel" that protects the process from getting hijacked — an off-by-one error can't cause arbitrary code execution. The VM/runtime itself can still have vulnerabilities, but that just becomes analogous to kernel vulnerabilities.

MisterTea 2y ago
> That adds a lot of complexity to the kernel, which also makes the isolation itself have more of the attack surface. Not if you remove auth from the kernel: https://doc.cat-v.org/plan_9/4th_edition/papers/auth https://doc.cat-v.org/plan_9/4th_edition/papers/auth The Plan 9 kernel is very small and portable which demonstrates that you don't need complexity to do distributed auth properly. The current OS hegemony is incredibly dated design wise because their kernels were all designed to run on a single machine. > OTOH you can write your logic in a memory-safe language today. Memory safety is not security.
- pornel 2y ago
  > Not if you remove auth from the kernel The factoctum looks very much like a microservice or a database with stored procedures handling access control, but of course plan9 makes it a file system instead of some RPC. It's a sensible design, but if IPC is the solution, then you don't even need plan9 for it. > Memory safety is not security. I didn't say it was. However, it is an isolation barrier for the memory-safe code. It's roughly equivalent to process isolation, but in userland. Instead of an MMU you have bounds checks in software. Kernels implement process isolation cheaply with the help of hardware, but that isn't the only way to achieve the same effect. It can be emulated in software. When the code is memory safe, it can't be made to execute arbitrary logic that isn't in the program's code. If the program attempts some out-of-bounds access, it will be caught with userland checks instead of a page fault, but in either case it won't end up with an illegal memory access.
  - MisterTea 2y ago
    > but of course plan9 makes it a file system instead of some RPC. Actually, Plan 9 does IPC via 9P, the RPC based file system protocol. The protocol serves a tree of named byte addressable objects which are composable per process. The Plan 9 kernel is a VFS multiplexer. It *only* speaks 9P. All disk file systems,e.g. ext4, are served via user space micro services the bell labs people called file servers. Unlike clunky Unix and it's copies there are no special files or character files nor ioctl(). It's all via the foundational concept of how people organize resources into "files" and folders (directories) via path names. All this is transparent over the network by default. The reality is the OS is a very portable light weight channel based container host, the container being the process. Each with it's own namespace which means it's own collection of mounted resources composed of 9P mounts and binds organized into a tree of named objects. Those objects are protected by Unix-like permissions: user/group/everyone-RWX served from as m yet another micro service using the same protocol. A process can rfork() more with flags to share resources and control it's file system view to only what the child container needs to see. Those containers then fork off more. You can keep firing off boxes with CPU and RAM and whatever what is hanging off via pxe and instantly have access to that compute and resources. 9P is architecture independent so file servers running on arm are no different than any other arch like x86, mips, risc-v, etc. anyone can mount any other hardware. It's a light weight cloud ready micro service host that was stated in the 80's by the same people who made Unix and c. It's friggin wild. I highly encourage people try to really understand how it works. It's pretty damn eye opening and refreshing. It sorta blew my mind when I saw the process as the container that can fork off more and more with the ability to control the system view of each one. And you can understand the code. Like all of it.
vacuity 2y ago
> Maybe it would be more feasible with some capability-based kernel, but you'd inherently have a lot of logic around user accounts, privileges, and queries. You end up involving the kernel in what is row-level database security. That adds a lot of complexity to the kernel, which also makes the isolation itself have more of the attack surface. Microkernels/exokernels sacrificing some performance to bring reliable kernels that allow for reliable userspace.

by pornel 2y ago

MisterTea 2y ago

> That adds a lot of complexity to the kernel, which also makes the isolation itself have more of the attack surface. Not if you remove auth from the kernel: https://doc.cat-v.org/plan_9/4th_edition/papers/auth https://doc.cat-v.org/plan_9/4th_edition/papers/auth The Plan 9 kernel is very small and portable which demonstrates that you don't need complexity to do distributed auth properly. The current OS hegemony is incredibly dated design wise because their kernels were all designed to run on a single machine. > OTOH you can write your logic in a memory-safe language today. Memory safety is not security.

pornel 2y ago
> Not if you remove auth from the kernel The factoctum looks very much like a microservice or a database with stored procedures handling access control, but of course plan9 makes it a file system instead of some RPC. It's a sensible design, but if IPC is the solution, then you don't even need plan9 for it. > Memory safety is not security. I didn't say it was. However, it is an isolation barrier for the memory-safe code. It's roughly equivalent to process isolation, but in userland. Instead of an MMU you have bounds checks in software. Kernels implement process isolation cheaply with the help of hardware, but that isn't the only way to achieve the same effect. It can be emulated in software. When the code is memory safe, it can't be made to execute arbitrary logic that isn't in the program's code. If the program attempts some out-of-bounds access, it will be caught with userland checks instead of a page fault, but in either case it won't end up with an illegal memory access.
- MisterTea 2y ago
  > but of course plan9 makes it a file system instead of some RPC. Actually, Plan 9 does IPC via 9P, the RPC based file system protocol. The protocol serves a tree of named byte addressable objects which are composable per process. The Plan 9 kernel is a VFS multiplexer. It *only* speaks 9P. All disk file systems,e.g. ext4, are served via user space micro services the bell labs people called file servers. Unlike clunky Unix and it's copies there are no special files or character files nor ioctl(). It's all via the foundational concept of how people organize resources into "files" and folders (directories) via path names. All this is transparent over the network by default. The reality is the OS is a very portable light weight channel based container host, the container being the process. Each with it's own namespace which means it's own collection of mounted resources composed of 9P mounts and binds organized into a tree of named objects. Those objects are protected by Unix-like permissions: user/group/everyone-RWX served from as m yet another micro service using the same protocol. A process can rfork() more with flags to share resources and control it's file system view to only what the child container needs to see. Those containers then fork off more. You can keep firing off boxes with CPU and RAM and whatever what is hanging off via pxe and instantly have access to that compute and resources. 9P is architecture independent so file servers running on arm are no different than any other arch like x86, mips, risc-v, etc. anyone can mount any other hardware. It's a light weight cloud ready micro service host that was stated in the 80's by the same people who made Unix and c. It's friggin wild. I highly encourage people try to really understand how it works. It's pretty damn eye opening and refreshing. It sorta blew my mind when I saw the process as the container that can fork off more and more with the ability to control the system view of each one. And you can understand the code. Like all of it.

vacuity 2y ago

> Maybe it would be more feasible with some capability-based kernel, but you'd inherently have a lot of logic around user accounts, privileges, and queries. You end up involving the kernel in what is row-level database security. That adds a lot of complexity to the kernel, which also makes the isolation itself have more of the attack surface. Microkernels/exokernels sacrificing some performance to bring reliable kernels that allow for reliable userspace.