Going to have to inline this or I'll miss something....
Karl Klammer wrote:
Are you in any way involved in the qubes project?
Do you know if OpenBSD 6 and Win7 can be run reasonably well inside qubes?
No- I am not in any serious way involved with the project outside of using the system and reporting if I find issues/solutions, which is not much as I am still feeling very much in the kiddie pool with Linux. Chalk it up to a lack of serious, year or two sit-down study under a mentor. The lack of programming experience probably doesn't help either.
The supported OSes right now are limited though a number of people have done work and reported results for incorporating Windows (I do not recall much in the way of OpenBSD mentioned). I do know there are some issues with Windows in virtual machine where the key verification process seems to have issues because it fails anti-pirate hardware checks. I have not followed these discussions, results, or progress/fixes (sadly) with any real attention as I have enough Windows systems around and little desire to use the system for more than entertainment.
By the Documentation page, the following have templates available
Fedora, Fedora Minimal, Debian, ArchLinux, Ubuntu (though not in binary due to Cannonical's policies), and Whonix.
Pentesting is on going for BlackArch, and Kali
Information on Windows installation can be found here
https://www.qubes-os.org/doc/windows-appvms/ and
https://www.qubes-os.org/doc/hvm/
Karl Klammer wrote:
About that "hit the floor running with it" part:
Yes, that's excactly what I was trying to accomplish.
You see, I've got nearly 20 years of unix hackery under my belt (bsd, sun, hp, linux, osx, some aix),
and thus thought that I've got the knack of flying figured out by now.
("The knack lies in learning how to throw yourself at the ground and miss.")
I cannot fault your approach (I did the same thing). You probably were better equipped that I when I did just about the same thing but I got lucky.
Karl Klammer wrote:
I did like the streamlined user-friendly installer.
Bonus points for Luks, Tor and Whonix setup during installation.
The first boot/login could not hold up to the UX promises that were implied by the installer.
Give 3.1 a shot. A lot of people reported issues with 3.2 (revisions 1-3) and hardware conflicts on install. It seems where 3.1 capitalized on lessons from 3.0 and made a solid consolidation, 3.2 was the next round of attempted advances.
Karl Klammer wrote:
2-3) systemd and fedora
okay, methodology seems rather odd from my minimalistic "every line of code has a potential bug" point of view,
but I can understand that one uses the path of least resistance when trying to get a project off the ground
Just to clarify: Fedora with Systemd and X11 runs as Dom0 - correct?
I certainly understand the approach of less complexity, less vulnerability. Perhaps we are taking a side trail to theory land but I believe we are hitting a point where complexity-related bug/exploit issues are unavoidable and system strategies should focus more on mitigation, rather than employing only solid, thoroughly debugged software. Of course, debugging and patching carries on but solid software build simply advances too slowly, with (it seems) only Red Hat putting up the money and manpower to significantly advance Linux capabilities. I suppose it is telling that many of the security-conscious gov't agencies are dealing with RH more and more rather than Microsoft for secure systems (and cheaper I hear to boot).
Fedora 20 (for me) is the stripped down base for Dom0 (a 3.2 user would have 23 IIRC). Almost all AppVMs I use are either Fedora 23 or Debian 8 (or Whonix's Debian variation) as templates. 3.2 users of the latest revision would have Fedora 24 IIRC as their Fedora AppVM template.
I would be a lying sack of crap if I tried to properly explain how the whole thing interacts because I'm likely to get something backwards; I am still very weak on how they implement their thin virtualization versus familiar methods like VirtualBox. Architecture overview is here
https://www.qubes-os.org/doc/architecture/ and the main docs page here
https://www.qubes-os.org/doc/
Karl Klammer wrote:
4) wifi
It's a standard intel 6235 wifi card (yes...intel backdoor, different topic) and was detected correctly by qubes.
My issue was that the network config dialog didn't allow me to configure/add any networks to the correctly identified card.
Hmmm. Odd. I suppose again all I can say is try 3.1 and see how the cookie crumbles.
Karl Klammer wrote:
5) "what were they thinking"
I like the containerization approach, and basically understand it as a "VMWare ESX with integrated VSphere on display :0".
The "what were they thinking" part of my rant was refering to systemd, fedora and the gnarly "user experience disconnect" that I had after completing the initial boot:
The system was really easy to install but then left me hanging high and dry when it came to the absolute basics like setting up wifi and VMs.
Well, I would say that your initial thought to wait for a few revisions to come and go is probably the solution to some of the above. It is not terribly polished and many aspects of the system still require terminal usage. A glaring example for me is setting up VMs. Iterating a new AppVM is easy and backing up existing AppVMs was easy. Trying to setup a new template or iterating a dispVM under a new template or with modifications is worrisome as I am not that confident in terminal.
Systemd is widespread and trying to go around by writing something new was likely evaluated as a waste of time. Given how stripped the OSes are and (as I understand) many aspects of systemd's function can be effectively chopped off for Dom0 or a given hardwareVM or AppVM (because those functions are purposefully removed for isolation in each VM), I suppose the people who sat down a determined systemd was not a big deal.
Certainly the lady who helps head the security team (she wrote those two papers on x86 and stateless systems that reminded me calculus was a very long time ago) surely gave the matter some thought and figured either the threats could be managed or the alternatives had either their own problems or were too functionless to work as a modern substitute OS to the future general population user.
Honestly, reading their threat vector assessments and possible compromises and preventative methods et al is enough to make me paranoid. While I love computers and enjoy learning, I must admit I am in no way remotely as knowledgeable and skilled as I could/should? be. As with many of my interests, I am a jack of the trade, not a master (though I take comfort in the often left-off other half of that saying of being better than a master of one).
The containerize/isolate operational method makes more sense to me that many traditional methods to system security of layered defenses and limited privileges as it assumes what I see is largely inevitable- a breach will occur at some point. These are human built machines with human designed hardware running several layers of human designed code (from the machine language up to the software) and none of it is perfect. As more information/money is found on computing platforms, the drive to find compromises only goes up with no end in sight.
The only real chance there is to double down and truly hone anything to a razor edge of reliability and security is for performance demand to flat-line, redirecting monetary drivers away from increasing features/capabilities/power and towards resolving issues of stability and security.
Even then, the computing environment would have to be such that hardware changes to evolve more hardened chips can be done without requiring alterations to OSes or software. Stated otherwise, the OS and its environment must be able to truly 'float' over hardware with as complete agnosticism as possible. Simultaneously, the OS and software must be broken down and rebuilt repeatedly until vulnerabilities are conquered. Having thought about this, it seems to me the only realistic method lay in a AI hypervisor able to intelligently monitor OS(es) operation and audit for traditional exploit methods like privilege elevation, memory access, logic/divide-by-zero, etc. This AI-Hypervisor would essentially need to be standalone; once built, it cannot ever be updated or modified as a way of preventing corruption or AI-logic attack methods; a monitor forever separated by one way mirror, able to see and act on OS activities but never be acted on itself in return.
I am happy to get to discuss this and hope we can stir up a good bit of information and keep the Linux interest alive here. While I may appear articulate (a precision diction habit from experience/work), I am probably one of the less-educated Linux users here and will probably get more out of this than I give.