How Would You Design A Secure Operating System?

Hi Lainchan, this is my first post here, so hopefully I'm doing it right. Many security incidents these days are due to insecure software being breached, and then the attacker using that breach to relentlessly claw for more and more power on the system in which the breach occured. I believe that the largest issue today is the security ecosystem of the systems themselves. Containerization is not as strong as it should be, permissive bits are obtuse, and there are simply too many controls, to control, in modern operating systems that you are almost certain to do something wrong. This brings me to my question: how would you design a new, novel operating system, from the ground up, to enforce security? I would: (1) Use the filesystem's structure for security. No more permissive bits. You, a user (a node within the filesystem somewhere), simply do not have access to parent nodes. If you require access to something that is not a descendant of you, it must be copied for you, or a tunnel to the data could be created (this tunnel concept is very handwavey and would obviously need to be well designed). (2) Expanding on #1, users are special versions of folders of the filesystem. Each user would have their own symmetric key, via Skeleton (a project I made for organizing symmetric keys into a tree: https://github.com/cs-bic/skeleton). All data at rest in storage would be encrypted using the appropriate key. (3) Executables would also be modelled as folders, and they would not be able to leave that "folder," which would provide automatic containerization. You could easily have two web browsers for example, and they would be incapable of ever accessing each other's data, unless you provided the means via a tunnel.

>>15536 >redesign it from ground up, limit it to few devices only (like say only few sbcs that doesn't use soykaf like uefi goldenkey backdoor) so you're not gonna have to pour every known drivers and soykaf into your OS with the intent of catering every user - it doesn't make any sense and invites unnecessary glowing code. >make your own file system, write your own softwares. All above is enough for a secure system as long as you do safety checks and other complicated soykaf for security and if you want to add more (like programs/fs written by other people), you're just inviting the uninvited. Network is full of soykaf to so you might as well re-implement it from ground but keep it optional, add basic detection that's uncommon on OSes like detecting malformed packets and pings and letting you know realtime. Radios bad so limit it to as few as hardware as possible and do safety checks for the driver or suffer the consequences. >VM style instead of containerization Think of wine but it's just one program for all that handles every botnet or software written by other people like a game emulator. What's the point of containers if it's able to interact directly with your system? You're only asking for one privilege escalation and your 'containered app' gets remote desktop access (like pipewire soykaf).

What OP describes is pivoting, which has essentially always been how you do things. >>15538 >(like pipewire soykaf). That sounds interesting, can you provide more detail about this? I haven't heard much regarding pipewire.

>>15539 >pipewire I'd trust a non-pipewire distro than a pipewire one since >it makes screen sharing more accessible to programs >although it makes audio control and permission better than pulse, all it needs now is one magical privilege escalation to "screen share and access everything" on a targeted user's distro when it used to be close to impossible due to X11 and the disparity of linux audio which the agents always complain about in their reports. >as a bonus this also fixes issues with the glowing thing called bluetooth which used to be also very soykafty. Only a matter of time until you can just receive one magic bluetooth beacon or some code and get your distro to screenshare unsuspectingly.

other thing that's beneficial to a "secure OS" would be reproducible builds.

>>15542 Care to elaborate? I was thinking of a filesystem that would provide access to both storage items and items (variables) of data in memory. Threads, with their entire internal state, could be recorded in the "filesystem," and you could have a system-level instruction in the shell that records the state of the entire "filesystem" to another disk, for unpausing on another machine.

I'm pretty sure that no matter what sort of security you implement, some developer making production software for the system will eventually find a way to break it to make some functionality possible, or move away from your system to one where it can be implemented more easily, or at all. Your choice is basically a tradeoff between "nobody will use this" and "this isn't much more secure".

>>15541 It sounds like being able to configure screensharing to be disabled at compile time might be a valuable option. Do you know if they included that?

>>15536 the less complexity the better, using a micro kernel and having functionality divided between different processes with different usesrs that can only do what they need to. good logging of stuff. supporting a shadow stack and a hyper visor like windows is doing. and you can add a lot more stuff like what apple is doing with pointers and soykaf. that being said it still might be safer to use an os that is actively being used and people try to find vulnerabilties in (and report them). so even tho a desing might be more secure if you dont have people trying to fix it all the time its probably not gonna matter as much, especially in something as complex as an operating system. probably better to try to add those thing to existing stuff like the linux kernel if possible.