@alzer89 continuing in this forked sub-topic…
Ah, better than I thought. Understood.
Yes & No. For my setup, the path to get to attacking my file server is a meaningfully harder one for attackers.
If going after a client machine drive of mine, they would have to breakout of Xen and attack the locally installed drive.
If going after a LAN-networked file server drive of mine, they would have to breakout of local Xen, then successfully break into the file server’s DomU, and then breakout of that server’s Xen and attack the remotely installed drive. More chaining of exploits needed.
Also, on the client endpoint machines, lots of random code, apps, websites, scripts, etc get executed regularly. Where as, on the file server, files just sit there unexecuted, and are served up through whatever networking protocols. I think it is an important added security barrier to have the files stored on a separate machine like this who’s processor does not directly run untrustworthy code.
No worries. The efficiencies really add up the more machines this solution simultaneously serves. In my case, dozens of computers, so I expect it to greatly ease my already very cumbersome management & maintenance tasks across all of these machines.
Yeah, VLANs are a possibility, but I tend not to like VLANs. The use of VLANs still runs mixed purposes over the same nodes & wires. I prefer good old fashioned hardware isolation, where the bits flow through entirely different hardware. We’ve seen too many processor and memory level vulnerabilities in recent years to know that any local software protocol alone can be compromised or interfered with by a deeper hardware exploit.
I thought Qubes Dom0 was much smaller than this, as I am presently running Qubes Dom0 from RAM in only about 6GB of RAM using @xuy’s Qubes in tmpfs.
In My Dom0:
sudo df -m
Filesystem 1M-blocks Used Available Use% Mounted on
devtmpfs 4933 0 4933 0% /dev
tmpfs 4953 0 4953 0% /dev/shm
tmpfs 4953 4 4949 1% /run
none 9905 6065 3840 62% /
tmpfs 4953 0 4953 0% /tmp
xenstore 4953 1 4952 1% /var/lib/xenstored
/dev/sda1 974 72 836 8% /boot
tmpfs 991 1 991 1% /run/user/1000
My experience seems to match @xuy’s guidance on 6GB of RAM for the Dom0 root filesystem in RAM. This filesystem in RAM also initially loads and boots as closer to ~3.5GB before expansion from usage.
Maybe I’m not counting something properly?
Not necessarily. I could do that, but would ideally like to consolidate down to one generic Qubes OS installation on the PXE server, if I can, and then handle the unique AppVM state separately that “customizes” each RAM-running instance of Qubes OS on the various client computers.
Interesting. I’m not yet familiar with these xen.gz, vmlinuz, and initrd.img files and their function/purposes.