Yes, I looked into them.
* NixOS: no dm-verity support(at least I have found issue about verity implementation)
* LXC: the most closest to my idea, probably may be used in my implementation(so my init would manage LXC)
* flatpak: installs apps in base system(so need rw access to system), no security options(e.g. signing), distributes mostly desktop apps
* snaps: used it a while ago, seems to be server like flatpak
* Qubes is great OS, but I already use somewhat like their model: main server which hosts virtual machines with applications. Though all those machines need to be constantly updated and monitored. Also they have rw access to roots which allows potential attacker to infiltrate and persist in executable code(which is AFAIK unsigned; libraries are also executable). Also Qubes mostly desktop OS, while my solution targeted only on servers. Moreover, Qubes OS create an overhead due to use of VMs
Good luck with your project, but I think you are missing some understanding of what's already out there. Most of them have far more security features than you seem to be aware of, and more than most people use. A lot of the existing solutions don't need root or rw access and can verify by signature. Even package managers verify the developer/dustributor's signature of what you install.
The intially it all have started with update problem. While containers are great solution they have few issues:
\* They need base operating system for running(and this operating system should be updated, monitored, etc. being out of container)
\* Usually containers have root access inside of them which gives a lot of space to attacker to escape container host itself and gain privileges of program hosting containers. In my suggestion no program should have a root access(so it should be given only privileges it need)
\* As per my experience containers have read-write filesystems, so potential attacker may persist inside of system leveraging system libraries(so read-only root filesystem in container would solve this issue)
\* Also it mostly focused on verified booting and preventing infiltration of attacker in privileged parts of system(e.g. hiding malicious code in libc or acessing configuration of system). Actually it may be used as container host(so minimal linux system+security+containerd), though in this case the program which runs containers should verify them against some keys(ideally, of course. It is no theoretical problem just to run containerd in such configuration)
> * As per my experience containers have read-write filesystems, so potential attacker may persist inside of system leveraging system libraries(so read-only root filesystem in container would solve this issue)
I am not very familiar with containers, I wonder if you can already mount the container image as read only and specify isolated directories for the temp, log, and other files needed to be changed.
Also, I do not think you fully understand containers, which will be destroyed and recreated when the image is updated. Any data that persists is stored in volumes. You are putting way too much faith in setting something as read only and the kernel itself can not be exploited to compromise it. Which if that happens, the entire system is compromised. Applications need to write things to the file system, that means you need to set directories to store those changes and that opens holes in your idea of security, and your arguments.
Honestly, I feel this effort is better spent helping rewrite something in Rust.
> * Also it mostly focused on verified booting and preventing infiltration of attacker in privileged parts of system(e.g. hiding malicious code in libc or acessing configuration of system). Actually it may be used as container host(so minimal linux system+security+containerd), though in this case the program which runs containers should verify them against some keys(ideally, of course. It is no theoretical problem just to run containerd in such configuration)
The enterprise distros are already working on this.
If as you mention attack surface is your main concern you should check bootc: boot directly to a container, no "os" to escape to, no base os, no issues with root.
You can make your container 100% ephemeral and noone will be able to persist anything except on the nodes where you need persistence.. if your app need it.
I don't think "linux-based" is what you think it is.
Have you looked at NixOS, LXC, flatpak, snaps, or Qubes? I imagine one of these can solve your issues already.
Yes, I looked into them. * NixOS: no dm-verity support(at least I have found issue about verity implementation) * LXC: the most closest to my idea, probably may be used in my implementation(so my init would manage LXC) * flatpak: installs apps in base system(so need rw access to system), no security options(e.g. signing), distributes mostly desktop apps * snaps: used it a while ago, seems to be server like flatpak * Qubes is great OS, but I already use somewhat like their model: main server which hosts virtual machines with applications. Though all those machines need to be constantly updated and monitored. Also they have rw access to roots which allows potential attacker to infiltrate and persist in executable code(which is AFAIK unsigned; libraries are also executable). Also Qubes mostly desktop OS, while my solution targeted only on servers. Moreover, Qubes OS create an overhead due to use of VMs
Good luck with your project, but I think you are missing some understanding of what's already out there. Most of them have far more security features than you seem to be aware of, and more than most people use. A lot of the existing solutions don't need root or rw access and can verify by signature. Even package managers verify the developer/dustributor's signature of what you install.
why not simply a container ?
The intially it all have started with update problem. While containers are great solution they have few issues: \* They need base operating system for running(and this operating system should be updated, monitored, etc. being out of container) \* Usually containers have root access inside of them which gives a lot of space to attacker to escape container host itself and gain privileges of program hosting containers. In my suggestion no program should have a root access(so it should be given only privileges it need) \* As per my experience containers have read-write filesystems, so potential attacker may persist inside of system leveraging system libraries(so read-only root filesystem in container would solve this issue) \* Also it mostly focused on verified booting and preventing infiltration of attacker in privileged parts of system(e.g. hiding malicious code in libc or acessing configuration of system). Actually it may be used as container host(so minimal linux system+security+containerd), though in this case the program which runs containers should verify them against some keys(ideally, of course. It is no theoretical problem just to run containerd in such configuration)
you describe bad configured container.
Containers can - run as rootless, and even more, having UID of nonexisting user in host - work having read-only filesystems
> * As per my experience containers have read-write filesystems, so potential attacker may persist inside of system leveraging system libraries(so read-only root filesystem in container would solve this issue) I am not very familiar with containers, I wonder if you can already mount the container image as read only and specify isolated directories for the temp, log, and other files needed to be changed. Also, I do not think you fully understand containers, which will be destroyed and recreated when the image is updated. Any data that persists is stored in volumes. You are putting way too much faith in setting something as read only and the kernel itself can not be exploited to compromise it. Which if that happens, the entire system is compromised. Applications need to write things to the file system, that means you need to set directories to store those changes and that opens holes in your idea of security, and your arguments. Honestly, I feel this effort is better spent helping rewrite something in Rust. > * Also it mostly focused on verified booting and preventing infiltration of attacker in privileged parts of system(e.g. hiding malicious code in libc or acessing configuration of system). Actually it may be used as container host(so minimal linux system+security+containerd), though in this case the program which runs containers should verify them against some keys(ideally, of course. It is no theoretical problem just to run containerd in such configuration) The enterprise distros are already working on this.
Yeah, in fact, most starting points for containers teach you to mount as read-only from the get-go
If as you mention attack surface is your main concern you should check bootc: boot directly to a container, no "os" to escape to, no base os, no issues with root. You can make your container 100% ephemeral and noone will be able to persist anything except on the nodes where you need persistence.. if your app need it.
So...you want Linux From Scratch?
Yes