Hello all. I would like to share with you my ideas regarding proposals of future possible hardening of security of Qubes OS. I would be thankfull for a substantive discussion and responses.
My idea of the hardening include among others (but not limited to):
minimal custom kernel with would become maximally hardened and secured
deeper implementation of following access control types:
Discretionary access control (DAC)
Access control list (ACL)
Attribute-based access control (ABAC)
Context-based access control (CBAC)
Graph-based access control (GBAC)
Lattice-based access control (LBAC)
Mandatory access control (MAC)
Role-based access control (RBAC)
Rule-set-based access control (RSBAC)
Capability-based security (CBA)
Risk-based authentication (RBA)
XACML (eXtensible Access Control Markup Language)
Policy-based access control (PBAC)
There is also a Wikipedia a article titled “Rainbow Books” that contain all DoD computer secutity standards. In between of them is one titled “Trusted Computer System Evaluation Criteria” (aka “Orange Book”) that describes among others the security (clearance) levels to access certain resources.
I think that above proposal’s could become taken into consideration for future releases. Thanks to them, Qubes would recieve a chance to become the world’s most secure Linux system and maybe in future the security standard for other Linux distro’s.
The minimal kernel requested for me isn’t the same as the one for you. If you have ideas on how to automate compiling a kernel individually for each user during first-time installation, that would be a great addition.
In the meantime, you can set up your own kernel. Need link to docs?
Thanks. The idea of making Qubes OS more secure is good, but the proposal lists many different security systems without explaining what problem each one would solve. Some overlap, some serve different purposes, and adding them all could make Qubes harder to build, maintain, and understand without making it safer. A stronger proposal would identify one specific weakness and suggest one practical change to address it.
Just to add: At its core, Qubes OS relies on the security mechanisms of Xen. Linux-code parts (the kernel and applications) merely provide an “API” for applications and drivers. I prefer it this way because it won’t require much investment. It just needs proper compartment planning.
I had proposed a idea of more fine access control for Qubes that would cut-off any potential bad actor ways to do damage, steal data, plant anything on the device. It would also increase the devices privacy and security aspecially if anyone would decide to steal or size the device under any pretext (and excuse)
Do you mean that you want to develop a program like qube Manager, or do you want to create a program like an antivirus that runs in the background?
(If you are referring to access permissions (similar to those assigned to individual users in Linux) please clarify which specific entity you intend to restrict (since the system is designed for a single user, I have ruled out the possibility that you are referring to the user).)
the core is xen not unix (like) familly
As for the Linux component (dom0), it is responsible for controlling the entire system, though it is not a kernel in itself.
(At least that is how I understood it; if I am mistaken, I would be happy to be corrected.)
First of, Xen is a Virtual Machine (VM) supervisor and not a Operating System
Second, imagine yourself access control system like a corridor separated with enforced doors that require a unique key to open each of them. More doors are on the way of any potential attacker then he’s motivation to progress will drop, aspecially if the next door would be stronger then the previous one
I’m sure that even FBI and CIA (not sure about NSA) could have difficulties to break thru such protections
I am just having a casual discussion; if my comment bothers you, feel free to let me know.
Yes, that is why the Qubes OS system acts as a layer that makes it usable by the average user on standard hardware.
Description from the documents
Qubes OS is a free and open-source, security-oriented operating system for single-user desktop computing. Qubes OS leverages Xen-based virtualization to allow for the creation and management of isolated compartments called qubes.
I understand the general idea, but my question was: what entity are you trying to restrict (program, VM, user, or something else)?
If I still don’t quite understand or if i ask about something else by mistake,
could you clarify which part of this illustration you would like to improve?
This is an overview of the security layers in the Qubes OS, illustrating the level of each security layer and the (difficulty/risk) associated with breaching it.
(I use translation tools, so I have difficulty understanding the analogies.)
In my personal opinion, it is actually better to approach(sure) this term with some caution; it does not align with reality. For instance, while Qubes OS offers a sufficient level of security, no one can definitively claim that it is immune to every potential threat scenario, or that it is secure enough for all users in its default configuration.
In closing, I would like to thank you for your efforts in improving the Qubes os. It is a long journey, and I hope you continue to learn throughout your journey. I would also like to remind you that it is perfectly fine to make mistakes from time to time; we all do. The best among us are those who learn from their errors (after all, isn’t the trial-and-error method an essential part of the learning process?)
Hello. I meant the protection as an general concept as maming the current layered design of Qubes more “air tight”.
As for example for usage, I would use a server containing any kind of confidental informations that require a more fine-graded access control then is curently provided.
In my modest opinion, Qubes is currently one of most secure distributions I had tested, but nothing stands in the way to improve it even more in the future releases.
All my proposals are meant in good intentions and it would be nice if they coild become seen as my attempt to contribute into Qubes security improvement
I would like to friendly turn your notice to he fact that all descriptions of Qubes are focused solelly on the side of the hypervisor, but are skipping the obvious that it’s unable to work standalone at it own when starting the device from BIOS or UEFI and still require at latest Unix or Linux class core binaries to be able to start-up and run. If I’n not mistaken, this role is provided by dom0 that runs the hypevisor and allow to run qubes
Because of this skip, there oftenly people become confused. I hope that it helped at latest a bit to clear the things out
