QUBES 3.2 Not Playing Well with CF-31

Due to overwhelming demand, we have created a forum just dedicated to Toughbook users who use Linux!
Message
Author
droppointalpha
Posts: 63
Joined: Sun Nov 23, 2014 1:13 pm

QUBES 3.2 Not Playing Well with CF-31

#1 Post by droppointalpha »

FYI- Touchpad not working and VM's not displaying windows.

Since it is on one of my work drives, not exploring any deeper at the present.

User avatar
SHEEPMAN!
Posts: 2239
Joined: Thu Oct 14, 2010 1:13 pm
Location: TDR-HQ California

Re: QUBES 3.2 Not Playing Well with CF-31

#2 Post by SHEEPMAN! »

31 MK-2 and 3 have interlink versapad. This is a PS/2 type NOT Synaptics. Forget Synaptic drivers.
Cut and paste the following to a TERMINAL line. It will save itself.

Code: Select all

sudo echo "options psmouse proto=imps" | sudo tee /etc/modprobe.d/psmouse.conf >/dev/null
Sometimes does not work. See below.

Another way. I've had more success with it on odd or different flavors of Linux...like Ubuntu for instance.
Reminder this is for Interlink Versapad. (MK 2 and 3 CF-31 and some cf-19)((From an article I read))

Down the road when installing updates answer no when asked if you want to install new version of /etc/default/grub.

I'll try this new install in a CF-30 MK3 and see what develops after a while.

Here is my /etc/default/grub:

Code: Select all

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT="0"
GRUB_TIMEOUT="5"
GRUB_DISTRIBUTOR="`lsb_release -i -s 2> /dev/null || echo Debian`"
GRUB_CMDLINE_LINUX_DEFAULT=" i8042.notimeout i8042.nomux"
GRUB_CMDLINE_LINUX=""
--------------------------------------------------------------------------------------------------------------
#The object is to insert i8042.notimeout i8042.nomux BETWEEN the quotes on a GRUB_CMDLINE. And update-grub saves it.
--------------------------------------------------------------------------------------------------------------
This is from a messy thread at: viewtopic.php?f=39&t=2662&start=20

--------------------------------------------------------------------------------------------------------------
When loading a LiveDVD or USB on the aforementioned 31's, hit tab (or e) when grub menu appears. Add the i8042 entries between quotes and F10 or whatever to boot. This will be temporary for the session only. Try to remember to do this on new installs or you find yourself navigating with an un-calibrated TS. :swords:

Repeating again if the first one does not seem to work, use the second.
Fair for you/ Fair for me.
I chose to NOT be organized.

-------------------------------------------------------------------[/color]
http://toughbooktalk.com/
http://forum.notebookreview.com/panasonic/

droppointalpha
Posts: 63
Joined: Sun Nov 23, 2014 1:13 pm

Re: QUBES 3.2 Not Playing Well with CF-31

#3 Post by droppointalpha »

You know.. I knew I had to do something for the touchpad but hadn't gotten around to looking at my cheat sheet to find it.

But there are other problems. Starting up VMs like the DispVM for a temp browser, the VM manager shows the VM starting up but no browser window appears.

I'm bouncing back to 3.1 for a bit.

User avatar
SHEEPMAN!
Posts: 2239
Joined: Thu Oct 14, 2010 1:13 pm
Location: TDR-HQ California

Re: QUBES 3.2 Not Playing Well with CF-31

#4 Post by SHEEPMAN! »

I had no idea what Qubes was....so I DMOR (did my own research :))....which ended up with reading the fine print on 3.2. Particularly the supported laptop section. They had security features I had never seen nor heard of.

I know you do your research it was the first time I saw DYOR yesterday....so had to use a modified version. :D

Ask someone else about VM. heh! ignorance is bliss here. :salute:
Fair for you/ Fair for me.
I chose to NOT be organized.

-------------------------------------------------------------------[/color]
http://toughbooktalk.com/
http://forum.notebookreview.com/panasonic/

droppointalpha
Posts: 63
Joined: Sun Nov 23, 2014 1:13 pm

Re: QUBES 3.2 Not Playing Well with CF-31

#5 Post by droppointalpha »

Yeah... it was a... what's the phrase I'm looking for... "interesting learning experience" diving head deep into Qubes.

I am still learning but once I got over the hump, it has been a great tool for travelling without requiring a constant switching of harddrives/OS to shift from work to personal to experimental and back again.

User avatar
Karl Klammer
Posts: 193
Joined: Tue Oct 13, 2015 3:19 am
Location: Old Europe

Re: QUBES 3.2 Not Playing Well with CF-31

#6 Post by Karl Klammer »

I've played around with qubes 3.2 on a cf19 yesterday evening.

try1) cf19mk3: graphics installer hangs prior to loading graphics
try2) cf19mk3: command line installer is broken (complains about missing luks password ... does not offer a way to enter the luks password)
try3) cf19mk6: graphics installer works, touchpad works out of the box, incl scrolling

First 5 impressions:
1) Why run SYSTEMD on a supposedly secure plattform?
2) Why base a supposedly lightweight core on fedora, a bloated desktop linux?
3) Couldn't figure out how to setup wlan within 20 minutes. Well I did find a configuration screen for the correct network card, but that screen didn't allow me to enter any values.
4) Decided to play around setting up VMs without networking, just to see how it works.It only offers VM templates for fedora....
5) decided to power down and not look back untill they've doubled the version number

Summary: What the fuck were they th^Wdrinking?

droppointalpha
Posts: 63
Joined: Sun Nov 23, 2014 1:13 pm

Re: QUBES 3.2 Not Playing Well with CF-31

#7 Post by droppointalpha »

Karl- a partial answer to some of your experiences (to the limit of my knowledge and understanding). But first, I hope you didn't actually just download this OS and tried to hit the floor running with it. There is a bit of documentation to read that might alleviate the headache (or simply stop you from torturing yourself in the first place).


1- PCI pass through and USB handling can be a pain, hence graphics cards of any kind are rough. It is fortunate that our interfaces are still PS/2 as we lack the 'fun' some other have in isolating and assigning USB controllers to Dom0 for their keyboard or touchpad to work.


2- Systemd is only vulnerable in the VM it is compromised in and is native to Gnome. A complete pain to remove it from the environment as I understand and quite a bit of software depends on it. Even then, the big "exploit" of systemd requires local user input or some payload to deliver it to the system. Assuming one is using a disposable VM to first open any files, the result is what? They crash the disposable VM? Systemd has had much made of its vulnerabilities yet not much seems to have come of it since I first saw the doomsaying 2 or 3 years ago. Yes, there is the local user exploit as addressed above but nothing earth shattering. And the VM environment isolates systemd exploits and the severely stripped down nature of the VMs and startup sequence removes a lot of attack surface.

One day will it be an issue? Perhaps. Of course, if Linux doesn't catch up and get some standardization (as systemd appears to be offering in its continual mission creep), it will loose out on users for simply not being capable of meeting demands. The already strained support for the variety of environments, in a way, hurts Linux. To an extent, it is the price we pay for choice in distros, desktops, et al. On the other hand, the widespread adoption of systemd by many trunks and branches of Linux does ease a lot of programming strain and helps ensure more work is progress rather than compatibility. Something like it was bound to happen simply because, if it didn't, Linux would forever be servers and a tiny percentage of the users due to the nature of the community (and lack of money to really push the whole thing further forward).

This discussion also talks about systemd but is not long. https://groups.google.com/forum/#!topic ... v-glWiqezU


3- Fedora used in Qubes is stripped down; WAY stripped down. The move from KDE to XFCE was offered in 3.1 and made default in 3.2, removing a lot of bloat in KDE environment. Up till I think 3.2, the Dom0 actually uses the Fedora 20 build. 3.1 shipped with the AppVM default being 23 and 3.2 R3 is 24 (IIRC) with 25 coming in shortly. Also offered alongside in 3.1 is Debian 8.

It is critical to note that is one is really security conscious, neither of these actually ever touch the network even through the firewall or whonix VMs; they are all given NO network access by neutering them in their VM settings (vault is this way by default, not set to connect to any net-vm nor allowing USB attachment). Everything would be handled via whonix workstation or disposable vms when on the internet (and always through both a VPN and TOR connection). Even after downloading a pdf or some such, the file itself is opened in a VM to avoid contamination. The only time one might use the Fedora or Debian bases while on the internet might be in a VPN connection through the firewall for something like email or bank website, where those systems may enter alarm state when random worldwide IPs connect from a locations not near your home or in your country.

As a furtherance, there is anticipation of Subgraph OS as a new template base once it exits testing. It is a project to sandbox all applications within the environment, which would then been run inside a VM. https://www.youtube.com/watch?v=Nol8kKoB-co https://subgraph.com/sgos/

Additionally, one can acquire even more heavily stripped down Fedora versions for specialize AppVM builds for specific purposes. Honestly though, I have no idea what other Linux offerings could be used as a wide-spread template base for all the various hardware VMs and AppVM and be capable of running individually on about 300mb RAM. Not a realm I'm familiar with but the arguments I read indicate that there are support issues that restrict the option list of OS-bases and guaranteed continual updating of flaws. Many high security OSes bandied about fall into one of the two categories, either they lack support (hardware, VM, whatever) or they are not maintained with continual feature improvements that would help keep Qubes OS relevant (as is Linux's biggest problem- too much work needs to be done to 'bring it up to speed' with the support range an OS like Windows offers).

Right now, by one of its own words, it is not at the point of 'everyman' user ready yet. Current iteration rate appears to be about two major releases a year, with the next version jumping to 4.0 sometime next year.


4- WLAN is sometimes an issue, depending on card. This frequently has to do with driver support, if I understand most of the 'help me' posts I see. One important point is that only the net-vm has access to the network interfaces and it is there that any/all work has to be done. Drivers, settings, et al. Also, a lot of stuff is done via terminal, not GUI. sudo yum install linux-firmware in the NetVM's template may resolve this issue with lack of out-of-box support from the open source drivers shipped with Qubes.

Hardware support is actually going to be a problem, as the hardware used in our beloved toughbooks tend to either be well behind the times or lacking in some support of more modern features available (for instance, VT-d, which prevents access of PCI hardware memory via DMA operation though most attack vectors for the netVM require the attacker at least be on the same local network or wifi or physical access in the case of a USB).


5-As far as methodology (or 'what were they thinking'), they seem to focus on several 'most-likely' vectors (internet exposed software like browsers and network-based attacks), malicious code in files, and hardware-based vulnerabilities. The VM setup largely works to prevent or limit the spread or damage such can cause via hardware-exclusive VMs, isolation of the DomVM (which has greatest VM privileges), disposable VMs where suspect files can be opened/tested prior to moving or discarding, and segregation so that owned VMs only give up data in the VM. If you read the discussions raging, everyone is aware there is much ground left to cover and some attack vectors are impossible, today, to solve as the underlying hardware is vunerable. Vulnerabilities in memory layout, issues with Intel's x86 processors, and untold discussions of boot attack vectors and hardware vulnerabilities enough to make a man swear off computers forever. (two fun papers- one on Intel chips https://blog.invisiblethings.org/papers ... armful.pdf and the other on possible solution of hardware vulnerabilities via stateless systems https://blog.invisiblethings.org/papers ... armful.pdf)

As many discussions of computing security around the internet will attest, the biggest threat to system security (after basic tasks such as firewall setup and limitation of running services) is actually the user themselves. By using separate VMs, it helps a user have a single OS (instead of multiboot nightmares or slow-as-hell live discs or easy to compromise USB-based OS options) under a bottom-up encryption protection where many identities may be managed (work, personal, etc) with reduced possibility of compromise of more than one identity. Next up, I suppose, is the hardware issues like memory attacks, compromised boot, BadUSB, IntelME, et al.

User avatar
SHEEPMAN!
Posts: 2239
Joined: Thu Oct 14, 2010 1:13 pm
Location: TDR-HQ California

Re: QUBES 3.2 Not Playing Well with CF-31

#8 Post by SHEEPMAN! »

As many discussions of computing security around the internet will attest, the biggest threat to system security (after basic tasks such as firewall setup and limitation of running services) is actually the user themselves.
Thank you for the time that you spent here. (this was NOT a five minute job) You sir, are very articulate and we appreciate it.

Also thanks to Karl for getting you stirred up. :rofl:

Please hang around.

Jeff
Fair for you/ Fair for me.
I chose to NOT be organized.

-------------------------------------------------------------------[/color]
http://toughbooktalk.com/
http://forum.notebookreview.com/panasonic/

User avatar
Karl Klammer
Posts: 193
Joined: Tue Oct 13, 2015 3:19 am
Location: Old Europe

Re: QUBES 3.2 Not Playing Well with CF-31

#9 Post by Karl Klammer »

Hi droppointalpha,

thanks for your elaborate answers, quite an essay. :salute:

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?



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


Regarding the individual topics (using your numbering scheme):
1) pci- and usb-passthrough
no major issues so far, afaict

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?

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.

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.



Maybe I'll find some time for some actual RTFM and give it another shot between the years...let's see.
Your post rekindled my interest :cheers:

droppointalpha
Posts: 63
Joined: Sun Nov 23, 2014 1:13 pm

Re: QUBES 3.2 Not Playing Well with CF-31

#10 Post by droppointalpha »

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.

Post Reply

Return to “The LINUX forum!!!”