From: "Lonnie" <lonnie@outstep.com>
To: developer@lists.illumos.org
Subject: A couple of kernel questions
Date: Wed, 17 Jul 2024 15:28:52 +0200 [thread overview]
Message-ID: <48-6697c700-1d7-71122080@11933559> (raw)
Hello All,
While still being new to Illumos (coming from the Linux/FreeBSD world) and ramping up a project that will be based upon either SmartOS, OmniOS, or Tribblix, and recently posted a question asking about the possibility and challenges to implement a type of application sandbox feature that seems to have some out in Solaris 11.4, I had just a couple of other questions for the developers list while I move to get set up to compile Illumos for some initial testing and explorations.
1. As Illumos is designed for zones (VMs), I am wondering if there are driver and service zones implemented such that if a driver crashes then it does not heavily impact the OS in operation? From what I understand so far, the drivers and system wide services are installed in the Global-Zone which makes me think of the Xen Type-1 Hypervisor in which these things are installed in their Dom0 which is similar to the Illumos Global-Zone (GZ)
2. Another crazy thought that I had was about the possibly of investigating what it might take to (fork illumos for an experiment) and try to remove the dependencies on a hierarchal tree-based filesystem and to implement a type of "Property-Graph Database (PGDb)" filesystem. The rationale here is that a hierarchal tree-based filesystem can easily be represented as well but that a PGDb filesystem also allows for assigning new types of attributes to files, blocks, objects, users, etc. and thus allowing for granular security on users at the application level. Users can be allowed/disallowed to see/access application/files/block/objects and only authorized applications are "mapped" to a particular user.
3. I could see that when a user does a login, then a blank empty zones is set up at which time their configured files, directories are mapped in to their container zone and allowed applications are only used. The users cannot escape their zone and does not have access to the rest of the system unless privilege's are elevated. I know that "zlogin" can do this from the GZ, but perhaps automatically and full console since graphic display will be needed.
4. One need that may be a challenge to get done will be the need for a enable/disable consoles such that a local users could use a hot-key (API call) to switch between zone consoles which would include graphics, audio, etc. This would be akin to running multiple VirtualBox OSs, or VMware Guests in which you can step through the guest graphic tabs in fullscreen mode, perhaps. I am seeking to replicate that idea in Illumos to step through guests (maybe in Bhyve or native zones) that are in their own configured zone which is the thought.
I am not sure how these things might be approached and/or tackled in illumos but wanted to start investigating them one by one and build up at the project evolves.
There are a few other ideas that I have but namely the driving thoughts are on strict separation between applications and user data as well as user isolation while mapping in only the specific applications (which will also run sandboxed or in thin-zones) and data that are needed. Its about build an extremely secure OS that minimized the attack-surface should drivers/applications/bad-actor users interact with the OS while still offering high configurability.
Well, I thought that I would ask these questions here since they are more kernel related than OS configuration related and hope that you also find them interesting although may have already been considered in the past well.
Best Regards and have a great day,
Lonnie
next reply other threads:[~2024-07-17 13:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-17 13:28 Lonnie [this message]
2024-07-17 14:06 ` [developer] " Udo Grabowski (IMK)
2024-07-17 20:12 ` Lonnie Cumberland
2024-07-17 19:06 ` John Howard
2024-07-17 20:05 ` Lonnie Cumberland
2024-07-17 20:12 ` Joshua M. Clulow
2024-07-17 20:27 ` Till Wegmüller
2024-07-17 20:09 ` Joshua M. Clulow
2024-07-17 20:22 ` Lonnie Cumberland
2024-07-17 20:47 ` John Howard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48-6697c700-1d7-71122080@11933559 \
--to=lonnie@outstep.com \
--cc=developer@lists.illumos.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).