A couple of kernel questions

A couple of kernel questions

[Lonnie]

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

Re: [developer] A couple of kernel questions

[Udo Grabowski (IMK)]

[-- Attachment #1: Type: text/plain, Size: 1103 bytes --]

On 17/07/2024 15:28, Lonnie via illumos-developer wrote:
> ....
> 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.
>

That's mostly ACLs and RBAC/Projects. Already there...
-- 
Dr.Udo Grabowski  Inst.of Meteorology & Climate Research IMK-ASF-SAT
https://www.imk-asf.kit.edu/english/sat.php
KIT - Karlsruhe Institute of Technology          https://www.kit.edu
Postfach 3640,76021 Karlsruhe,Germany T:(+49)721 608-26026 F:-926026


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5804 bytes --]

Re: [developer] A couple of kernel questions

[Lonnie Cumberland]

Yea, I thought about ACLs and RBAC approaches but think that a 
property-graph database could possibly offer much more potential still. 
I could, of course be wrong on this, but I think that it is a very 
interesting possibility maybe worth experimenting with and investigating 
further as a thought.

Also, I think that a hierarchal tree-based filesystem allows for too 
many attack vectors for bad actors who can gain access up and down the 
tree looking and mostly eventually finding weak spots to assault and 
gain access.  A PGDb approach seems like it would not expose neighbor 
nodes (i.e. application libraries and others) and would be perfectly 
in-line with application/data sandboxing ideas while allowing much more 
control with a finer-grained approach, just as a rough thought.

Thanks again,
Lonnie

On 7/17/2024 10:06 AM, Udo Grabowski (IMK) wrote:
> On 17/07/2024 15:28, Lonnie via illumos-developer wrote:
>> ....
>> 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.
>>
>
> That's mostly ACLs and RBAC/Projects. Already there...
>
>
> ------------------------------------------
> illumos: illumos-developer
> Permalink: 
> https://illumos.topicbox.com/groups/developer/Tf2a2de95f2063204-M80e6a50f391c7bb694aa2500
> Delivery options: 
> https://illumos.topicbox.com/groups/developer/subscription

Re: [developer] A couple of kernel questions

[John Howard]

Hello Lonnie.

PGDb sounds interesting to me. (I think ZFS allows sysop defined attributes. Consider adding a temporal attribute to allow time restrictions assigned to executables.)

I am not an illumos expert. I migrated from Windows to Linux to FreeBSD, then illumos for awhile.

My home PC came under incessant attacks from foreign enemies. It started with me downloading a Russian source of a Computer Modern TrueType font. Thrashed to death my Microsoft XP hard disks.

So I tried using Fedora and RedHat Linux. Attacker erased them immediately. Tried using FreeBSD, same result.  Tried using OpenIndiana illumos with ZFS. Attacker immediately erased all my partitions. Tried using Debian, and was finally safe. Internet Service Provider (Time Warner Cable) was no help.

One suggestion I have is to eliminate the closed-bins BLOB from illumos. Build your own illumos. Arm64 illumos server theoretically should use less electricity than Intel. And Raspberry Pi PC’s are the cheapest. Use Arm64 hardware features for security and virtualization.

Simplicity beats complexity.

-- John

On Jul 17, 2024, at 8:28 AM, Lonnie via illumos-developer <developer@lists.illumos.org> wrote:

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


------------------------------------------
illumos: illumos-developer
Permalink: https://illumos.topicbox.com/groups/developer/Tf2a2de95f2063204-M63510774f96f3916dedce355
Delivery options: https://illumos.topicbox.com/groups/developer/subscription

Re: [developer] A couple of kernel questions

[Lonnie Cumberland]

[-- Attachment #1: Type: text/plain, Size: 4600 bytes --]

Hi All,

I have a follow up question on the illumos kernel.

Can the illumos kernel allow for VGA and Audio pass-through from a User 
Zone?  I am trying to discover how it might be possible to pass the 
console to a Zone that might be running a guest Bhyve and some how work 
out to have the guest OS using the console instead to the Global Zone.  
This is not really the same as using zlogin in text mode but I do not 
have a complete picture in my mind on what might be, or not, achievable 
from the kernel perspective.

I guess that this would be a similar question for GPU pass-through from 
a non-Global Zone.

Any thoughts?

Thanks in advance,
Lonnie

On 7/17/2024 9:28 AM, Lonnie via illumos-developer wrote:
> 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
>
>
> ------------------------------------------
> illumos: illumos-developer
> Permalink:https://illumos.topicbox.com/groups/developer/Tf2a2de95f2063204-M63510774f96f3916dedce355
> Delivery options:https://illumos.topicbox.com/groups/developer/subscription

[-- Attachment #2: Type: text/html, Size: 5372 bytes --]

Re: [developer] A couple of kernel questions

[Joshua M. Clulow]

On Wed, 17 Jul 2024 at 13:05, Lonnie Cumberland via illumos-developer
<developer@lists.illumos.org> wrote:
> Can the illumos kernel allow for VGA and Audio pass-through from a User Zone?  I am trying to discover how it might be possible to pass the console to a Zone that might be running a guest Bhyve and some how work out to have the guest OS using the console instead to the Global Zone.  This is not really the same as using zlogin in text mode but I do not have a complete picture in my mind on what might be, or not, achievable from the kernel perspective.
>
> I guess that this would be a similar question for GPU pass-through from a non-Global Zone.

This is not really something we have great support for today, and I
suspect depending on the GPU vendor, is likely to continue to present
challenges.  For example, NVIDIA is not an open source friendly
vendor, but are obviously immensely popular in terms of deployed
hardware in the field.

There is some support for PCI pass-through in bhyve, as I understand
it; see pptadm(8).  I don't believe it will be an easy turnkey
solution for the kind of desktop centric experience you're looking to
create.


Cheers.

-- 
Joshua M. Clulow
http://blog.sysmgr.org

Re: [developer] A couple of kernel questions

[Till Wegmüller]

Outouts atached to the card usually (there are cases where they do not) 
output the Cards Graphics. This is what Virtual OS gaming setups 
leverage to display the Windows Graphics of Games.

Passthrough for graphics cards has been working for people. If the 
Drivers (looking at you Nvidia) allow the card to run.

-Till

On 17.07.24 22:12, Joshua M. Clulow via illumos-developer wrote:
> On Wed, 17 Jul 2024 at 13:05, Lonnie Cumberland via illumos-developer
> <developer@lists.illumos.org> wrote:
>> Can the illumos kernel allow for VGA and Audio pass-through from a User Zone?  I am trying to discover how it might be possible to pass the console to a Zone that might be running a guest Bhyve and some how work out to have the guest OS using the console instead to the Global Zone.  This is not really the same as using zlogin in text mode but I do not have a complete picture in my mind on what might be, or not, achievable from the kernel perspective.
>>
>> I guess that this would be a similar question for GPU pass-through from a non-Global Zone.
> 
> This is not really something we have great support for today, and I
> suspect depending on the GPU vendor, is likely to continue to present
> challenges.  For example, NVIDIA is not an open source friendly
> vendor, but are obviously immensely popular in terms of deployed
> hardware in the field.
> 
> There is some support for PCI pass-through in bhyve, as I understand
> it; see pptadm(8).  I don't believe it will be an easy turnkey
> solution for the kind of desktop centric experience you're looking to
> create.
> 
> 
> Cheers.
> 

Re: [developer] A couple of kernel questions

[Joshua M. Clulow]

On Wed, 17 Jul 2024 at 06:29, Lonnie via illumos-developer
<developer@lists.illumos.org> wrote:
> 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)

It's not so much that illumos is designed _for_ zones or VMs, as that
we have first class features in the OS that support those things.
Aside from those features, illumos is a UNIX operating system with a
monolithic kernel.  Drivers are generally kernel modules, though there
are limited areas in which drivers can be implemented in user mode
software; e.g., ugen(4D) allows for user mode USB drivers, and one of
the FUSE ports would allow for a user mode file system.  That said,
because our consolidation can ship both kernel and user mode software,
we can indeed relatively easily move some things into daemons where
they might have ended up in the kernel in other systems.

We ship a lot of daemons for different purposes, supervised by smf(7)
and in may cases deprivileged by rbac(7) and privileges(7) features in
the OS.  In most or all cases, these daemons could crash and restart
without necessarily bringing down other parts of the system.  If a
daemon restart does cause unavailability, you could definitely file
that as a bug to fix.

> 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.

I think it's unlikely that we would move away from a hierarchical file
system.  It's really at the core of a lot of UNIX abstractions.  We
tend to focus on mandatory access control through privileges(7) and
rbac(7) mechanisms.  Individual users, or processes, can be restricted
from seeing quite a lot of other things occuring on the computer in
other accounts, etc, by removing privileges from their processes.
They can be prevented from making network connections, or seeing other
processes in /proc, etc.  We're always interested in new security and
sandboxing features, but would generally like them to build on and fit
in with the existing designs where possible.  The core team is happy
to help with design advice if someone wants to put together an illumos
project discussion (IPD) document that covers a new sandboxing
feature; see: https://github.com/illumos/ipd.

ZFS, our primary file system, has extensive support for extended
attributes.  It also has rich support for NFSv4 ACLs, which allow for
fine-grained permissions in the regular file system; see acl(7) for
more details.  There is also support for other more complex
attributes, such as marking things totally immutable; see fgetattr(3C)
and chmod(1) for more details.

> 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.

You could achieve a lot of automatic provisioning for users on login
through some combination of NSS and PAM modules and
distribution-specific control software.  I don't think this would
really be a core illumos feature, at least to begin with, but there's
a lot of mechanism that could help you get there!

Graphics is obviously something of an uncharted challenge.  As I
mentioned in your OmniOS thread, our DRM/KMS software needs work to be
brought up to date, and there are probably new facilities that we
would then need to add to the core OS to provide a richer graphical
console experience.  It's also possible that you could, once DRM is
sorted out, drive a lot of that from distribution-specific software
like X11, or a port of DirectFB2, etc, without needing much or any
additional core OS support.

> 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.

This is mostly the same as my comments on graphics above.  Some work
will be required specifically on improving the graphical/desktop
support we have, as part of a project like that.

> 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.

I suspect most of what you want to do, you could get started by
prototyping on top of facilities that exist already!  I can't stress
enough that if you want the graphics stuff to work out, I would work
on that first, as I think it's the biggest risk/unknown in your plans
so far.

> 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.

We generally try to keep the illumos developer list focused on
specific bits of in-progress development (questions about how to
proceed, code and design reviews), or about specific bugs or issues,
etc.  Generally we would do broad, exploratory ideation on the
illumos-discuss list.

Cheers.
-- 
Joshua M. Clulow
http://blog.sysmgr.org

Re: [developer] A couple of kernel questions

[Lonnie Cumberland]

[-- Attachment #1: Type: text/plain, Size: 7554 bytes --]

Hi Joshua,

I sincerely Thank you for the in-dept discussion on these 
questions/ideas and will investigate them further.

Also, I am starting the stage of working on the prototype and am setting 
up but build environment for this purpose. Will probably use X11/Xorg to 
get started along with VNC from the Bhyve side but definitely will be 
seeing what it might take to port DirectFB2 over as well.

Lastly, I think that you are right and I will move to have more 
discussions on these things over at the "illumos-discuss" list and do 
apologize to everyone for the off-topic and tangential discussion not 
specifically related to kernel development.

Hope to see you over on the illumos-discuss list.

Best and have a great evening
Lonnie

On 7/17/2024 4:09 PM, Joshua M. Clulow via illumos-developer wrote:
> On Wed, 17 Jul 2024 at 06:29, Lonnie via illumos-developer
> <developer@lists.illumos.org>  wrote:
>> 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)
> It's not so much that illumos is designed _for_ zones or VMs, as that
> we have first class features in the OS that support those things.
> Aside from those features, illumos is a UNIX operating system with a
> monolithic kernel.  Drivers are generally kernel modules, though there
> are limited areas in which drivers can be implemented in user mode
> software; e.g., ugen(4D) allows for user mode USB drivers, and one of
> the FUSE ports would allow for a user mode file system.  That said,
> because our consolidation can ship both kernel and user mode software,
> we can indeed relatively easily move some things into daemons where
> they might have ended up in the kernel in other systems.
>
> We ship a lot of daemons for different purposes, supervised by smf(7)
> and in may cases deprivileged by rbac(7) and privileges(7) features in
> the OS.  In most or all cases, these daemons could crash and restart
> without necessarily bringing down other parts of the system.  If a
> daemon restart does cause unavailability, you could definitely file
> that as a bug to fix.
>
>> 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.
> I think it's unlikely that we would move away from a hierarchical file
> system.  It's really at the core of a lot of UNIX abstractions.  We
> tend to focus on mandatory access control through privileges(7) and
> rbac(7) mechanisms.  Individual users, or processes, can be restricted
> from seeing quite a lot of other things occuring on the computer in
> other accounts, etc, by removing privileges from their processes.
> They can be prevented from making network connections, or seeing other
> processes in /proc, etc.  We're always interested in new security and
> sandboxing features, but would generally like them to build on and fit
> in with the existing designs where possible.  The core team is happy
> to help with design advice if someone wants to put together an illumos
> project discussion (IPD) document that covers a new sandboxing
> feature; see:https://github.com/illumos/ipd.
>
> ZFS, our primary file system, has extensive support for extended
> attributes.  It also has rich support for NFSv4 ACLs, which allow for
> fine-grained permissions in the regular file system; see acl(7) for
> more details.  There is also support for other more complex
> attributes, such as marking things totally immutable; see fgetattr(3C)
> and chmod(1) for more details.
>
>> 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.
> You could achieve a lot of automatic provisioning for users on login
> through some combination of NSS and PAM modules and
> distribution-specific control software.  I don't think this would
> really be a core illumos feature, at least to begin with, but there's
> a lot of mechanism that could help you get there!
>
> Graphics is obviously something of an uncharted challenge.  As I
> mentioned in your OmniOS thread, our DRM/KMS software needs work to be
> brought up to date, and there are probably new facilities that we
> would then need to add to the core OS to provide a richer graphical
> console experience.  It's also possible that you could, once DRM is
> sorted out, drive a lot of that from distribution-specific software
> like X11, or a port of DirectFB2, etc, without needing much or any
> additional core OS support.
>
>> 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.
> This is mostly the same as my comments on graphics above.  Some work
> will be required specifically on improving the graphical/desktop
> support we have, as part of a project like that.
>
>> 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.
> I suspect most of what you want to do, you could get started by
> prototyping on top of facilities that exist already!  I can't stress
> enough that if you want the graphics stuff to work out, I would work
> on that first, as I think it's the biggest risk/unknown in your plans
> so far.
>
>> 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.
> We generally try to keep the illumos developer list focused on
> specific bits of in-progress development (questions about how to
> proceed, code and design reviews), or about specific bugs or issues,
> etc.  Generally we would do broad, exploratory ideation on the
> illumos-discuss list.
>
> Cheers.

[-- Attachment #2: Type: text/html, Size: 9099 bytes --]

Re: [developer] A couple of kernel questions

[John Howard]

[-- Attachment #1: Type: text/plain, Size: 8071 bytes --]

Nano-X (formerly MicroWindows) is a minimal replacement for both X11 and Win32 API. A Nano-X UI and Nuklear UI are also supported. Anti-grain rendering. Some
have integrated it to render to OpenGL, or Frame Buffer.

Nano-X is on github.

Thank you to the devs for your patience on this subject.

-- John

On Jul 17, 2024, at 3:22 PM, Lonnie Cumberland via illumos-developer <developer@lists.illumos.org> wrote:

Hi Joshua,

I sincerely Thank you for the in-dept discussion on these questions/ideas and will investigate them further.

Also, I am starting the stage of working on the prototype and am setting up but build environment for this purpose. Will probably use X11/Xorg to get started along with VNC from the Bhyve side but definitely will be seeing what it might take to port DirectFB2       over as well.

Lastly, I think that you are right and I will move to have more discussions on these things over at the "illumos-discuss" list and do apologize to everyone for the off-topic and tangential discussion not specifically related to kernel development.

Hope to see you over on the illumos-discuss list.

Best and have a great evening
Lonnie

> On 7/17/2024 4:09 PM, Joshua M. Clulow via illumos-developer wrote:
> On Wed, 17 Jul 2024 at 06:29, Lonnie via illumos-developer
> <developer@lists.illumos.org> wrote:
>> 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)
> It's not so much that illumos is designed _for_ zones or VMs, as that
> we have first class features in the OS that support those things.
> Aside from those features, illumos is a UNIX operating system with a
> monolithic kernel.  Drivers are generally kernel modules, though there
> are limited areas in which drivers can be implemented in user mode
> software; e.g., ugen(4D) allows for user mode USB drivers, and one of
> the FUSE ports would allow for a user mode file system.  That said,
> because our consolidation can ship both kernel and user mode software,
> we can indeed relatively easily move some things into daemons where
> they might have ended up in the kernel in other systems.
> 
> We ship a lot of daemons for different purposes, supervised by smf(7)
> and in may cases deprivileged by rbac(7) and privileges(7) features in
> the OS.  In most or all cases, these daemons could crash and restart
> without necessarily bringing down other parts of the system.  If a
> daemon restart does cause unavailability, you could definitely file
> that as a bug to fix.
> 
>> 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.
> I think it's unlikely that we would move away from a hierarchical file
> system.  It's really at the core of a lot of UNIX abstractions.  We
> tend to focus on mandatory access control through privileges(7) and
> rbac(7) mechanisms.  Individual users, or processes, can be restricted
> from seeing quite a lot of other things occuring on the computer in
> other accounts, etc, by removing privileges from their processes.
> They can be prevented from making network connections, or seeing other
> processes in /proc, etc.  We're always interested in new security and
> sandboxing features, but would generally like them to build on and fit
> in with the existing designs where possible.  The core team is happy
> to help with design advice if someone wants to put together an illumos
> project discussion (IPD) document that covers a new sandboxing
> feature; see: https://github.com/illumos/ipd.
> 
> ZFS, our primary file system, has extensive support for extended
> attributes.  It also has rich support for NFSv4 ACLs, which allow for
> fine-grained permissions in the regular file system; see acl(7) for
> more details.  There is also support for other more complex
> attributes, such as marking things totally immutable; see fgetattr(3C)
> and chmod(1) for more details.
> 
>> 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.
> You could achieve a lot of automatic provisioning for users on login
> through some combination of NSS and PAM modules and
> distribution-specific control software.  I don't think this would
> really be a core illumos feature, at least to begin with, but there's
> a lot of mechanism that could help you get there!
> 
> Graphics is obviously something of an uncharted challenge.  As I
> mentioned in your OmniOS thread, our DRM/KMS software needs work to be
> brought up to date, and there are probably new facilities that we
> would then need to add to the core OS to provide a richer graphical
> console experience.  It's also possible that you could, once DRM is
> sorted out, drive a lot of that from distribution-specific software
> like X11, or a port of DirectFB2, etc, without needing much or any
> additional core OS support.
> 
>> 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.
> This is mostly the same as my comments on graphics above.  Some work
> will be required specifically on improving the graphical/desktop
> support we have, as part of a project like that.
> 
>> 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.
> I suspect most of what you want to do, you could get started by
> prototyping on top of facilities that exist already!  I can't stress
> enough that if you want the graphics stuff to work out, I would work
> on that first, as I think it's the biggest risk/unknown in your plans
> so far.
> 
>> 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.
> We generally try to keep the illumos developer list focused on
> specific bits of in-progress development (questions about how to
> proceed, code and design reviews), or about specific bugs or issues,
> etc.  Generally we would do broad, exploratory ideation on the
> illumos-discuss list.
> 
> Cheers.

illumos / illumos-developer / see discussions + participants + delivery options Permalink

[-- Attachment #2: Type: text/html, Size: 10216 bytes --]