from:"Chris Laprise"

Re: [qubes-users] Re: btrfs for template/appvm

2020-12-13 Thread Chris Laprise

On 12/12/20 11:14 AM, unman wrote:

On Sat, Dec 12, 2020 at 07:32:13AM +, 'keyandthegate' via qubes-users wrote:

I have btrfs set up for dom0 and I'm using the refilnk driver, but my appvms
themselves seem to be ext4? Where would I even set this? I don't see an option
on the pool or on qvm-create.

? Original Message ?
On Saturday, December 12, 2020 12:36 AM, keyandthegate
wrote:

I want to use btrfs for the snapshots feature in my appvms.

I know Qubes supports btrfs for dom0:
https://github.com/QubesOS/qubes-issues/issues/2340

Does Qubes support using btrfs in individual appvms?

If not is there some other way I can get snapshots? It would make me less
afraid to make a mistake while using my computer.

I *think* you would have to custom build templates using btrfs, but I
have no idea if that would work - I'll try and report back.

When I'm making significant changes then I make liberal use of
qvm-clone: then I may archive off, but more usually just throw away the
clone if I'm happy. (On the rare occasions that I work with Windows
qubes I do this a lot.)

Yes. If you have Btrfs in dom0 then you already have those features at
the VM level at least. And I would recommend against putting Btrfs on
top of Btrfs, as its more CPU intensive.

For those who have the default LVM in dom0, Btrfs in appVMs is a better
prospect. But since LVM also has snapshots, to me the only two
overriding reasons to use Btrfs this way is for compression (Btrfs has
Zstandard now!) of things like databases and email archives; and also
for its integrity checking.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/a7f06577-40d9-00e9-6035-8e79765ec553%40posteo.net.

Re: [qubes-users] What's the best way to run a VPN app on Qubes?

2020-10-29 Thread Chris Laprise

On 10/29/20 8:31 AM, 'Totally Zoid' via qubes-users wrote:

Hello,

ATM I'm using standard Fedora qubes with NetworkManager enabled and
OpenVPN in order to connect to a VPN. I'd like to switch to the VPN's
own full-fledged program to use features such as easy switching between
exit servers and killswitch. I've previously used exclusively OpenVPN,
but on Qubes, stuck in its own qube, I guess there isn't really anything
the VPN's program can spy (other than traffic obv), and I reasonably
trust this particular service.

The app comes as .deb/.rpm or, mercifully, source code. I've tried
installing the .rpm but naturally I'd have to either do it on each
restart, do it in the main Fedora template (which could compromise it),
or do it in its own TemplateVM which would take up another 5 GB.
Bind-dirs looks like an option but I'm not sure which files the .rpm
install changes, and it looks like an update could easily break it.

Is there anything I'm missing? Looks like I'll have to either waste
another 5GB space on a new template for a single program (and run
updates for that template regularly), or have to compile it from source,
possibly every time there's an update for the VPN program (not looking
forward to that hehe). I'm thinking there has to be a better way...

The things you may be missing here:

1. Its more secure to have a 'sys-vpn' VM dedicated to the VPN client.

2. Service provider apps generally don't work or don't secure a
dedicated VM properly. They assume a PC network architecture while a
Qubes proxy VM is more like a router.

From a security standpoint the best way is probably Qubes-vpn-support
(see my github link below). But it doesn't have easy GUI switching
between servers; you would have to 'cp' the config for the new server
then 'systemctl restart' the service to switch.

Its possible to setup Network Manager in a dedicated VPN VM including
added anti-leak firewall rules. See the Qubes vpn doc for details.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] [unofficial] Qubes security advisory

2020-10-26 Thread Chris Laprise

On 10/25/20 10:24 PM, 'J.M. Porup' via qubes-users wrote:

One morning last week, I launched a disposable Debian 10 template with my preset
defaults of no netvm and a blank page preset--but instead a default page of
"https://www.youtube.com/; appeared. It only happened once, but it was enough.

So to clarify, you launched a dispVM with no networking, and a youtube
page was loaded and rendered on screen?

That seems highly unlikely to be an accidental input or glitch.

Does this rise to the standard of journalist proof I'm accustomed to? Of course
not. Would I risk my reputation by writing this email to the qubes-users list
if I was not confident in my assessment? What do you think?

So why am I writing this message? First, and most importantly, there is clearly
a great Qubes 0-day floating around that needs to be found and squashed. But
also,
if Five Eyes are prepared to risk a Qubes 0-day on a clown, who would they *not*
risk it on? There must be dozens, if not hundreds, of active Qubes implants out
there right now.

Maybe there are other explanations, but you won't know for sure unless
you saved the contents of your system in that state.

However, if you're looking for plausible explanations and attack
vectors, you should look at side-channels first (I don't think
exploiting a side-channel against Qubes would count as a 0-day).

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] AMD Ryzen 7 PRO compatibility

2020-10-20 Thread Chris Laprise

On 10/19/20 9:43 PM, 'trichel' via qubes-users wrote:

Because of the security issues with Intel Processors, AMD processors seem to be
a very interesting alternative for a new system running Qubes.

The AMD Ryzen 7 Pro 4750G with integrated graphics would be ideal
price/performance wise and it ticks all the boxes: no Intel, no Nvidia, 8
cores, and integrated graphics which are just fine for most Qubes users,
certainly for me. But right now apparently Qubes has problems with the AMD PRO
features SME and SEV. (I read in an older thread)

Would it be too much of a gamble to still get the AMD Pro for a new system and
hope it will be possible to run Qubes in some (4 -8) months? Or maybe it is
(will be) possible to get these PRO processors running Qubes with all the Qubes
security features intact but with SME and SEV switched off?

I'm not sure what thread you're referring to (re SEV). A few of us are
running Qubes 4.1 alpha on new Thinkpad Ryzen 7 PRO 4750U systems
because the older version of Xen used in Qubes 4.0 is incompatible.

The newer Xen in R4.1 alpha still has a bug that affects CPU scheduling,
so there is a trick to configuring it for a smooth running system.

Qubes reports that safety features (IOMMU etc) are working. What does
not currently work is S3 sleep.

Stability is already quite good if you avoid badly-behaved wifi drivers
(unfortunately the Thinkpad's Intel AX200 is in this category, so I use
a USB wifi device instead).

I'd say its not too much of a gamble if you're willing to run a new
alpha or beta of Qubes. But keep in mind your 4750G motherboard may have
significant differences vs Thinkpad laptops; IMO you need to go with a
high-quality brand, preferably a pre-built business system from the
traditional top-3 (Lenovo, Dell, HP).

Here is a relevant thread:
https://qubes-os.discourse.group/t/qubes-support-on-amd-4000-series-lenovo-x13-t14/202/1

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] VPN issue

2020-10-17 Thread Chris Laprise


On 10/17/20 11:52 AM, 'src11' via qubes-users wrote:
I am using Proton VPN and am seemingly unable to get it connected using 
the network manager in the latest version of Qubes. I add a new VPN 
connection, import the .ovpn file downloaded from their site which 
automatically populates all the info, and then enter my username and 
password credentials but it won't connect and just times out. Any ideas?


Usually, importing ovpn files into NM is error prone, but this seems to 
be the recommended way according to ProtonVPN's Linux guide.


You can check the system log with 'journalctl' to see what errors 
openvpn is reporting.


Instead of NM, I've used ProtonVPN with my own VPN support project 
without issues:


https://github.com/tasket/Qubes-vpn-support

This setup also tends to function better than NM in my experience.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c750e296-d518-a557-7bf8-c1c280c49827%40posteo.net.

Re: [qubes-users] change priority of running vms

2020-10-10 Thread Chris Laprise


On 10/10/20 4:32 PM, lik...@gmx.de wrote:

Hi,

does xen/qubes offer an ability to adjust vCPU priorities dynamically or 
limit the vCPU usage for some VMs from dom0.


Similar to cpulimit or nice.

Use case: sometimes some VMs tend to consume to much cpu and block other 
VMs currently active. I'd like to reduce their CPU priority without 
shuting them down and decrease amount of vcpus.


Thanks in advance, P.



To do this directly in Xen I think you have to use 'xl sched-credit2' 
command. See 'man xl' for details.


--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a3203cb8-1001-f972-083f-ce475a923a3b%40posteo.net.

Re: [qubes-users] Witch one is the best?

2020-09-21 Thread Chris Laprise

On 9/21/20 8:17 AM, Stumpy wrote:

On 2020-09-20 14:24, Chris Laprise wrote:

On 9/20/20 2:08 PM, Chris Laprise wrote:

On 9/19/20 11:16 PM, Jarrah wrote:

My question is, would some of the newer/faster AMD CPUs and chipsets
work with Qubes?

I can speak for the 2000 series working. I believe some people have
working 3000 series, but 4000 has been a serious issue. Not sure if
that's the CPU or the specific laptop.

https://qubes-os.discourse.group/t/qubes-support-on-amd-4000-series-lenovo-x13-t14/202/1

Based on the patches that have to be applied to get Qubes 4.1 working
on Ryzen 4000, I'd say its a Qubes-vs-CPU compatibility issue and not
about the computers' other specifics.

BTW the patches are already applied in the Qubes 4.1 repository; I
don't want to imply you have to do that manually. And a 4.1 alpha may
be coming really soon.

But getting Qubes 4.0 working on Ryzen 4000 appears unlikely.

But a Ryzen 3000 is a relatively safe bet?

I would say the evidence is scant, except that someone with a Ryzen 3000
laptop had problems that sounded a lot like the Ryzen 4000 problems.
OTOH at least one Ryzen 3000 _desktop_ is known to work:

https://groups.google.com/d/msgid/qubes-users/caa18235-cecd-64c7-f989-5bf4661f59c8%40posteo.de

For laptops, Ryzen 1xxx and 2xxx appear to be a safer bet. Personally, I
think Ryzen 4000 is compelling enough to go through the trouble of
building a Qubes 4.1 installer (and then fixing the installer's mistakes).

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Witch one is the best?

2020-09-20 Thread Chris Laprise


On 9/20/20 2:08 PM, Chris Laprise wrote:

On 9/19/20 11:16 PM, Jarrah wrote:




My question is, would some of the newer/faster AMD CPUs and chipsets
work with Qubes?


I can speak for the 2000 series working. I believe some people have
working 3000 series, but 4000 has been a serious issue. Not sure if
that's the CPU or the specific laptop.

https://qubes-os.discourse.group/t/qubes-support-on-amd-4000-series-lenovo-x13-t14/202/1 





Based on the patches that have to be applied to get Qubes 4.1 working on 
Ryzen 4000, I'd say its a Qubes-vs-CPU compatibility issue and not about 
the computers' other specifics.




BTW the patches are already applied in the Qubes 4.1 repository; I don't 
want to imply you have to do that manually. And a 4.1 alpha may be 
coming really soon.


But getting Qubes 4.0 working on Ryzen 4000 appears unlikely.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/fb5367d0-022f-6e94-8192-410625deafac%40posteo.net.

Re: [qubes-users] Witch one is the best?

2020-09-20 Thread Chris Laprise


On 9/19/20 11:16 PM, Jarrah wrote:




My question is, would some of the newer/faster AMD CPUs and chipsets
work with Qubes?


I can speak for the 2000 series working. I believe some people have
working 3000 series, but 4000 has been a serious issue. Not sure if
that's the CPU or the specific laptop.

https://qubes-os.discourse.group/t/qubes-support-on-amd-4000-series-lenovo-x13-t14/202/1



Based on the patches that have to be applied to get Qubes 4.1 working on 
Ryzen 4000, I'd say its a Qubes-vs-CPU compatibility issue and not about 
the computers' other specifics.


--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/105b221d-4ddf-b059-08c9-6935ceb1339a%40posteo.net.

Re: [qubes-users] Adding new kernels to iso?

2020-09-18 Thread Chris Laprise

On 9/18/20 1:25 AM, Ondřej Fiala wrote:

Thank you for the reply! Since I don't have Google account which seems to be
required to view the initial discussion (as linked in the first post of the
thread), could you please give me a brief summary of what the core issue is?

On Sep 17, 2020 23:19, Chris Laprise wrote: > > On 9/17/20 5:00 PM, Ondřej Fiala wrote: > > Hello, > > > > first a little bit of background: I am trying to install Qubes 4.0.3 on a system with Ryzen 3600
& GTX1650. After some tweaks, I have managed to get it to display the boot menu. However, when selecting the 'Install Qubes' option, it goes blank after 'launching installer'. When running in limited graphics mode, the same
happens. The only visible error before this happens is "dracut-pre-udev[609]: rp.idmapd: conf_reinit: open ("(null)", 0_RDONLY) failed.". I am not sure how significant it is, but there is a lot of OK-looking
output before the screen goes blank. When I edit limited graphics mode's options to xdriver=nouveau and remove the nomodeset option, this error is printed to output: "(EE) [drm] Failed to open DRM device for pci ...",
followed by X.org exiting with error. Also "Pane is dead". The driver in use is nouveau and according to nouveau's wiki, this error means that the GPU is not supported by the driver. Sure enough, Xorg lists the driver as
only supporting cards before GTX400. However, the latest version of nouveau actually supports much newer cards, including GTX1650. This lead me to the thought that perhaps replacing the 4.19.94 kernel with a newer one, which should
include a newer nouveau version, could fix this issue. So now the actual subject of my email: > > Your underlying problem is probably the same as ours in this Ryzen 4000 > laptop thread: > >
https://qubes-os.discourse.group/t/qubes-support-on-amd-4000-series-lenovo-x13-t14/202/1 > > We have taken the route of building Qubes 4.1 pre-releases with > updated/patched Xen 4.14 & Kernel 5.8. These appear to be
the bare > minimum versions required for Ryzen 4000/Renoir chip sets. > > > > > How do I add new kernels to the iso? I am aware of the extrakernels/ directory in the iso's root, but I haven't been able to figure
out in which format I should add them there for it to work. Note: I know how to modify the iso, that's not what this question is about. Any advice will be greatly appreciated. > > There was some discussion about that I think
in the above thread. IIRC > altering a 4.0 iso was a manageable task but using above Xen version > with it appeared unlikely... while altering a 4.1 iso seems much harder. > > I think I just finished building my first
Ryzen 4000-ready iso and I'm > about to test it! > > -- > Chris Laprise, tas...@posteo.net > https://github.com/tasket > https://twitter.com/ttaskett > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

The link is to discourse.net, not google:

https://qubes-os.discourse.group/t/qubes-support-on-amd-4000-series-lenovo-x13-t14/202/1

The core issue with the laptops is Xen 4.8 incompatibility (requiring
4.14 instead). Of course, Nvidia is not a factor in our case so maybe
this isn't a match for your situation.

In general, when it comes to using open source OSes, I recommend people
avoid Nvidia; it is a tightly closed graphics platform.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Adding new kernels to iso?

2020-09-17 Thread Chris Laprise

On 9/17/20 5:00 PM, Ondřej Fiala wrote:

Hello,

first a little bit of background: I am trying to install Qubes 4.0.3 on a system with Ryzen 3600 & GTX1650. After some
tweaks, I have managed to get it to display the boot menu. However, when selecting the 'Install Qubes' option, it goes
blank after 'launching installer'. When running in limited graphics mode, the same happens. The only visible error before
this happens is "dracut-pre-udev[609]: rp.idmapd: conf_reinit: open ("(null)", 0_RDONLY) failed.". I am
not sure how significant it is, but there is a lot of OK-looking output before the screen goes blank. When I edit limited
graphics mode's options to xdriver=nouveau and remove the nomodeset option, this error is printed to output: "(EE)
[drm] Failed to open DRM device for pci ...", followed by X.org exiting with error. Also "Pane is dead". The
driver in use is nouveau and according to nouveau's wiki, this error means that the GPU is not supported by the driver.
Sure enough, Xorg lists the driver as only supporting cards before GTX400. However, the latest version of nouveau actually
supports much newer cards, including GTX1650. This lead me to the thought that perhaps replacing the 4.19.94 kernel with a
newer one, which should include a newer nouveau version, could fix this issue. So now the actual subject of my email:

Your underlying problem is probably the same as ours in this Ryzen 4000
laptop thread:

https://qubes-os.discourse.group/t/qubes-support-on-amd-4000-series-lenovo-x13-t14/202/1

We have taken the route of building Qubes 4.1 pre-releases with
updated/patched Xen 4.14 & Kernel 5.8. These appear to be the bare
minimum versions required for Ryzen 4000/Renoir chip sets.

How do I add new kernels to the iso? I am aware of the extrakernels/ directory
in the iso's root, but I haven't been able to figure out in which format I
should add them there for it to work. Note: I know how to modify the iso,
that's not what this question is about. Any advice will be greatly appreciated.

There was some discussion about that I think in the above thread. IIRC
altering a 4.0 iso was a manageable task but using above Xen version
with it appeared unlikely... while altering a 4.1 iso seems much harder.

I think I just finished building my first Ryzen 4000-ready iso and I'm
about to test it!

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Special template to isolate less trusted software?

2020-09-03 Thread Chris Laprise


On 9/2/20 11:39 PM, airelemental via qubes-users wrote:




I just don't like the idea of putting untrusted code in a templateVM used by 
sensitive VMs.


Me neither! But I avoid multiplying templates by installing apps directly into 
appvms.
This minimizes the number of templates I have to keep up-to-date.


FYI, that approach is risky. The code sitting in /rw or /home becomes a 
way for malware to persist between VM restarts.



The general strategy with installing packages inside appvms (at least those 
based on debian) is to make the package cache into a bind-dir and then 
reinstall package from cache every appvm startup.



A safer way to add apps at startup would be to use Qubes-vm-hardening 
(see my github below) and stash the packages in the 
/etc/defaults/vms/ dir... the vm-boot-protect service will run 
just before /rw is mounted and see that config files matching the 
current VM name exist. Its a good way to specialize appVMs without 
creating new templates.


Should also mention that snaps and flatpaks may be a better fit for 
adding apps at boot-time, since there is a chance you can do it quicker 
using little more than 'mv'.


--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ad660e38-766f-d21b-c49b-69696864b0e2%40posteo.net.

Re: [qubes-users] KDE high dom0 CPU usage

2020-08-19 Thread Chris Laprise

On 8/20/20 12:29 AM, 54th Parallel wrote:

On Thursday, 20 August 2020 at 06:58:35 UTC+8 Chris Laprise wrote:

Not an issue with dom0 KDE here. But I did have this problem with
k/ubuntu on my new AMD Ryzen Thinkpad... graphics driver was not
working
and defaulted to a non-accelerated framebuffer mode. In this case I had
to upgrade the kernel to resolve it.

Check output of 'sudo lspci -nnk' and look for the section with 'VGA'.
If it says 'unclaimed' then your graphics driver isn't working. The
'lshw' command can also be used for a different view; it will show the
VGA section with a line 'configuration:
driver=' if
its working or the 'driver' part will be absent if its not working.

--
Chris Laprise, tas...@posteo.net

https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

lspci -nnk showed VGA working fine, but the output gave me other ideas
(lshw not available on dom0). I modified xen.cfg so that
i915.alpha_support=1 became i915.preliminary_hw_support=1 but that made
things worse. I then switched to a newer kernel (5.6) and saw a minor
framerate improvement, but the high CPU usage remained. I removed
iommu=no-igfx and saw a better framerate, but again, high CPU usage
remained.

I looked around and found that KDE and NVidia don't mix--at least for
the older versions of KDE
(https://www.phoronix.com/scan.php?page=news_item=NVIDIA-KDE-High-CPU-Fix).
The KDE Plasma version of dom0 current is 5.10, but the NVidia GPU in my
laptop (which is weaker than my iGPU's) needs 5.16. But the thing is--I
don't remember installing an NVidia propietary driver at all. Anyways, I
installed the recommended fix ('export __GL_MaxFramesAllowed=1' in an
executable script in /etc/profile.d) but that didn't work as well, so I
gave up and uninstalled KDE.

I switch off any nvidia gpus before installation. The company is
anti-open source and I'm not interested in running drivers that are the
result of a cat-and-mouse obfuscation game.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] KDE high dom0 CPU usage

2020-08-19 Thread Chris Laprise

On 8/19/20 2:08 PM, 54th Parallel wrote:

Quick question:

I decided to try out KDE on 4.0 and was liking it until I noticed the
low overall framerate and the high CPU usage of dom0 shown in xentop
whenever there's motion (like dragging windows around). Since I'm using
an i7-1065G7, power shouldn't be an issue, so I was surprised.

Is there any way I can fix this? Has anyone here experienced this?

Not an issue with dom0 KDE here. But I did have this problem with
k/ubuntu on my new AMD Ryzen Thinkpad... graphics driver was not working
and defaulted to a non-accelerated framebuffer mode. In this case I had
to upgrade the kernel to resolve it.

Check output of 'sudo lspci -nnk' and look for the section with 'VGA'.
If it says 'unclaimed' then your graphics driver isn't working. The
'lshw' command can also be used for a different view; it will show the
VGA section with a line 'configuration: driver=' if
its working or the 'driver' part will be absent if its not working.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Re: Black Screen when installing 4.0.3 & 4.1 on AMD Ryzen 4750U

2020-08-19 Thread Chris Laprise

On 8/19/20 8:52 AM, Dylanger Daly wrote:
So I managed to wrestle with Qube's build system and compile
kernel-latest 5.8.1 after installing the resulting rpm I'm still
observing the same black screen bug.

/Linux dom0 5.8.1-1.qubes.x86_64 #1 SMP Wed Aug 19 11:21:32 UTC 2020
x86_64 x86_64 x86_64 GNU/Linux/

Thanks for trying this.

This bug must be something IOMMU / Memory Management related.

> Yes, better support for new Ryzen CPU's would be nice.

I'm sure this issue will be fixed within a few weeks, AMD's new Laptop
CPUs are all the rage right now, support shouldn't be too far behind, in
the meantime I'll monitor the master branch for Xen
<https://github.com/xen-project/xen/commits/master>and watch for any AMD
specific commits.

I am thinking of ways to make a standard Linux KVM environment more
Qubes-like just in case this takes months or forever. My short list is:

1. Secure copy+paste

2. Auto snap-back (like read-only) for guest root

3. Isolated NICs via passthrough

4. Split GPG

Probably a good place to get tips for these would be Whonix forum, since
they also use non-Qubes virtualization.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [EXT] Re: [qubes-users] Google requiring login to access qubes-users

2020-08-16 Thread Chris Laprise

On 8/16/20 8:08 PM, unman wrote:

On Mon, Aug 17, 2020 at 12:41:27AM +0200, Ulrich Windl wrote:

On 8/16/20 2:29 AM, unman wrote:

On Sat, Aug 15, 2020 at 07:39:19PM +, tetrahedra via qubes-users wrote:

WHen I try to access the Google Groups qubes-users site, sometimes (circa
50%) I'm presented with a Google login prompt and can't access the
qubes-users group unless I have a Google account.

Since Qubes is privacy-focused it seems like maybe the Qubes mailing lists
should migrate to a less Orwellian mailing list provider.

This comes up repeatedly.
If you don't like Google Groups, but want a web interface, use the mail
archive at https://www.mail-archive.com/qubes-users@googlegroups.com/
If you don't want a web interface, interact with it as a mailing list.

But still your messages will be sent to Google...

And so?
I don't send messages to Google - I send them to people who read the
mailing list. Since that is a public activity I don't care if Google sees
it.
The list is public, so Google will be all over it in any case.
Does this mean that I favour Google in any way? Not at all.

I never use the google web client, and it aggravates me when people link to
messages there, instead of in the mail archive. I wish they wouldn't.

The mail-archive site doesn't come up prominently in searches and I even
forgot it existed, but thanks for the reminder.

The list remains in peoples' minds as being a "Google group" so they are
likely to gravitate toward Google to read its contents. So what we have
is a pressure tactic from Google to trace more user activity across the
web – user logs into Google to read some list messages, and Google links
their recent and future browsing history to the users' identity.

This doesn't affect list subscribers much, as we can read messages in
our email clients. But Google knows the many 'casual' list users who are
not subscribed are not 'casual' users of the entire web, and they are
likely to sign in just to get at a handful of messages that could solve
their problem.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Re: Running Qubes 4.1 under VirtualBox as migration strategy

2020-08-16 Thread Chris Laprise


On 8/16/20 9:26 AM, Yethal wrote:
Try KVM instead of vbox, that's what qubes automated testing 
infrastructure uses.


I had a quick try with Virtual Machine Manager UI (using QEMU/KVM) with 
no success. After choosing 'install' from the Qubes iso menu I just see 
a blinking cursor. I tried with BIOS and also with one of the EFI options.


--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2bc8b8e5-e0e4-6615-5d7d-61ec470409f7%40posteo.net.

Re: [qubes-users] Re: Black Screen when installing 4.0.3 & 4.1 on AMD Ryzen 4750U

2020-08-16 Thread Chris Laprise

On 8/11/20 1:13 AM, Dylanger Daly wrote:

> I'm going to experiment with moving a couple of my Qubes VMs over to the
Ubuntu install under KVM (using VM Manager app).

Nice, I've had the same thought with Fedora Silverblue, but Qube's qvm-
etc tools make everything so much easier.

> The Qubes 4.1 tree appears to have Xen 4.13 and Linux 5.7, currently.

Indeed R4.1 is using Xen 4.13.1
<https://github.com/xen-project/xen/commits/RELEASE-4.13.1> last commit
was back on May 7th 2020, I can't seem to see any AMD/Ryzen specific
commits that are newer than this date, I was looking at cherry picking
Xen commits related to AMD/Ryzen however I can't find any.

Any and all AMD Related commits I can find were made in 2019 and are
included in the current Xen 4.13.1

So perhaps this is actually a dom0/Linux Kernel issue? Surely if it were
Xen they'd have something committed by now?

On Monday, August 10, 2020 at 8:21:05 PM UTC+10 Chris Laprise wrote:

I've experimented a bit with Ubuntu and some different kernels. I was
not able to get 5.7.0 kernel graphics to work at all (not even
vga/framebuffer), while 5.8.0 and 5.8.1 work beautifully and 'lshw'
confirms the amdgpu driver is being used to drive the display. The
default 5.4.0 kernel won't recognize the gpu but graphics do work
without acceleration.

I don't know why graphics are broken in 5.7 (dmesg didn't show any
vga/amdgpu errors) when that is the first kernel to receive AMD Renoir
support. It could be that 5.8 has a fixed amdgpu driver, or that the
presence of power management drivers is required to properly drive the
Vega gpu.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[qubes-users] Running Qubes 4.1 under VirtualBox as migration strategy

2020-08-15 Thread Chris Laprise

Unfortunately, Qubes does not yet run on recent AMD hardware so I am 
thinking of ways I can migrate the Qubes setup I have on my old Intel 
machine to my new Thinkpad T14. The new machine is blazing fast, cool 
and quiet (and lighter and better display, etc.) so I'm very interested 
in migrating to the new system even if compromises are made. Currently, 
I have Qubes 4.1 installed in VirtualBox 6.1 (Ubuntu 20.04).


Since only PV mode is available to Qubes VMs under vbox, I've tried to 
configure sys-net accordingly by removing the device assignments and 
specifying PV mode. But there is no network available and I'm not sure 
what to do here.


The PV VMs also do not start cleanly from qvm-run and apps only run in 
the VMs when the VM is already running.


I'm looking for pointers on getting networking running and for general 
overall smooth operation...


--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/02a45b1c-02e7-85a3-dfb1-fa14d333eff8%40posteo.net.

Re: [qubes-users] How would you remotely infiltrate a default Qubes OS?

2020-08-15 Thread Chris Laprise

On 8/13/20 10:32 PM, 54th Parallel wrote:

> Since the lions' share of Qubes installs are Intel based, I think a
> side-channel attack would be the most likely way to breach a Qubes
> system.

I thought Spectre and Meltdown have been dealt with by shutting off
hyperthreading and updating microcode? Also, the latest CPUs have
Spectre mitigation built-in, though this only deals with the earlier
variants of the attacks if I remember correctly.

I'm not going to get into details now, but the short story is Intel
haven't addressed all the sidechannel vulnerabilities, and the long and
varied trend of Intel vulns points to a fundamentally flawed
implementation... too many cheap shortcuts were taken.

Even worse is that Intel are now retiring their patch process for some
CPUs that are still popular with Qubes users, for example Ivy Bridge (I
expect Haswell to not be far behind if it hasn't already been ghosted).
To do this with a CPU that is 7 years old (when they announced it) is
very disappointing.

IIRC for a relatively recent generation (I think it was Skylake!) they
said the expected mitigation was for You + Me to replace their junk with
newer hardware. No refund, no exchange program... just "We're the Big
Gorilla and you give us more of your money now".

FTS!

> DDR4 memory offers a big attack surface as well

Does this refer to the RowHammer (HammerRow?) attack?

Yes, rowhammer and its offshoots. Unfortunately, the changes in DDR4
that were supposed to increase resistance were eventually discovered to
be cheap shortcuts themselves and have actually made the situation worse.

> OTOH, a state actor wishing to attack a Qubes system might have better
luck with the RPM MITM against Fedora that we discussed in another thread.

Pretty much my biggest concern right now, though I'm procrastinating on
writing the damn script

Relevant to the thread:
https://arstechnica.com/information-technology/2020/08/nsa-and-fbi-warn-that-new-linux-malware-threatens-national-security/

P.S. I'm not liking this new Google Groups look
On Friday, 14 August 2020 at 00:06:42 UTC+8 Chris Laprise wrote:

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] How would you remotely infiltrate a default Qubes OS?

2020-08-13 Thread Chris Laprise

On 8/13/20 10:59 AM, fiftyfourthparal...@gmail.com wrote:
If you were tasked with remotely hacking into a default but updated
Qubes OS system (installation configuration of 4.0.3, but with updated
templates and dom0), how would you do it? What would you attack? The
precise objective (e.g. retrieve a PGP key from a vault, read a text
document, achieve persistence, modify the system) is open--I just want
to see how people might generally approach this question so I might
better plug potential holes.

Sorry for the extremely broad question--please think of this as
something like a 'red team' exercise.

Since the lions' share of Qubes installs are Intel based, I think a
side-channel attack would be the most likely way to breach a Qubes
system. But also its not just Intel CPUs that are weak here; DDR4 memory
offers a big attack surface as well. Such attacks can be carried out
with javascript from websites.

OTOH, a state actor wishing to attack a Qubes system might have better
luck with the RPM MITM against Fedora that we discussed in another thread.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Why Fedora?

2020-08-11 Thread Chris Laprise


On 8/11/20 11:31 AM, Claudio Chinicz wrote:

Hi, I've been following this thread, as well as others on this user group.

Without being critic, or trying to bring some positive feedback, I can say that Qubes 
needs to evolve towards to being more user friendly and manageable as a corporate 
product. On the positive side, I can say from my personal experience that, once properly 
configured, it works and is stable. Maybe creating some user admin features that would 
limit what an end user can do would make it "user proof" (is there something 
like that?) and enterprise fit.


From this perspective, the underlying OS is less of a concern, provided it is 
stable and automatically upgradable.




Qubes does have remote management capability. However, we should be 
careful what we wish for, lest we wake up one day with the realization 
that Qubes is a kind of 'IntelME in software' environment.


--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/94e344d5-c5d6-67b6-e137-7ff78034b618%40posteo.net.

Re: [qubes-users] Why Fedora?

2020-08-10 Thread Chris Laprise


On 8/10/20 5:22 PM, Toptin wrote:

Chris Laprise:

On 8/10/20 12:30 PM, Toptin wrote:

Jeff Kayser:

Here is one reason to use Fedora.

https://www.fossmint.com/which-linux-distribution-does-linus-torvalds-use/



Ah, see... Mr Torvalds is your God. That isn't a reason at all. But
thanks you put a smile on my face.



~Jeff Kayser

-Original Message-
From: qubes-users@googlegroups.com  On
Behalf Of Chris Laprise
Sent: Monday, August 10, 2020 9:18 AM
To: qubes-users@googlegroups.com
Subject: Re: [qubes-users] Why Fedora?

This email originated from outside the organization

On 8/10/20 12:05 PM, Toptin wrote:

Dear Qubes Users,

I'm currently digging my way through the exceptional good Qubes
documentation. Everything is nicely explained as to why a certain
decision / implementation was made, except for the use of Fedora as
main distribution.

I wonder what's the rationale of that decision; Fedora 25 isn't even
supported anymore. No offense or critic intended, just curiosity.

Regards, toptin.


I think the subtext here is that Fedora gets the changes first and it
makes a good development environment (for Linux code anyway). But that's
also why they don't curate or test or secure it like a regular
production-ready OS. And also why they don't care about having a wide
array of apps.

I'd rather see a transition to something more stable like Debian which
is also flexible enough to let you pull in newer packages from a tiered
repository (stable, testing, unstable, and experimental).



That was my thinking too, but still as mentioned in my previous post I
would have thought something like Arch-Linux or even Gentoo would be
better choice because both distribution are actually meta-distributions
(a distribution to build a target distribution). I worked with both and
wouldn't recommend it to an end-user but for development to build
something like Qubes? Yes, I would consider that.

Nothing against Debian. Definitely not. Very trustworthy and
knowledgeable community, but still quite a big system, especially if one
wants to strip it down. And then those unfortunate version upgrades. But
once it's installed it's rock solid.


I don't know if bare-minimum really signifies, at least with the way 
most people define it. A lot of the things you would remove to reduce 
attack surface won't make a big impact on the install's disk space 
usage. Compounding that is Qubes being a PC operating system after all, 
and I've found just about the only DE that gets all the GUI and HID 
stuff working correctly is big ol KDE. For most users, XFCE is suitable 
for already mired-in-Linux users who are conditioned to accept broken or 
absent UI features.


OTOH if its the klocs themselves that are seen as a threat (enabling 
attacks from upstream) then that's a tough spot bc very low kloc IMO is 
a recipe for bad UI w too many missing features that make users feel 
paralyzed. At the end of the day these are still computers and their job 
is to manage complexity and _that_ requires lots of vertical integration.


--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6ff01b60-02ad-2ba0-d5c2-033902d667dd%40posteo.net.

Re: [qubes-users] Why Fedora?

2020-08-10 Thread Chris Laprise


On 8/10/20 12:30 PM, Toptin wrote:

Jeff Kayser:

Here is one reason to use Fedora.

https://www.fossmint.com/which-linux-distribution-does-linus-torvalds-use/


Ah, see... Mr Torvalds is your God. That isn't a reason at all. But
thanks you put a smile on my face.



~Jeff Kayser

-Original Message-
From: qubes-users@googlegroups.com  On Behalf Of 
Chris Laprise
Sent: Monday, August 10, 2020 9:18 AM
To: qubes-users@googlegroups.com
Subject: Re: [qubes-users] Why Fedora?

This email originated from outside the organization

On 8/10/20 12:05 PM, Toptin wrote:

Dear Qubes Users,

I'm currently digging my way through the exceptional good Qubes
documentation. Everything is nicely explained as to why a certain
decision / implementation was made, except for the use of Fedora as
main distribution.

I wonder what's the rationale of that decision; Fedora 25 isn't even
supported anymore. No offense or critic intended, just curiosity.

Regards, toptin.


I think the subtext here is that Fedora gets the changes first and it 
makes a good development environment (for Linux code anyway). But that's 
also why they don't curate or test or secure it like a regular 
production-ready OS. And also why they don't care about having a wide 
array of apps.


I'd rather see a transition to something more stable like Debian which 
is also flexible enough to let you pull in newer packages from a tiered 
repository (stable, testing, unstable, and experimental).


--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9488d0a3-7cce-4b79-646e-5774dd1bf188%40posteo.net.

Re: [qubes-users] Global Dark Theme For Qt (KDE) Based Applications

2020-08-10 Thread Chris Laprise

On 8/10/20 12:10 PM, Qubes wrote:

On 6/23/20 5:37 PM, Sven Semmler wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 6/23/20 9:47 AM, Qubes wrote:

Would anybody here know how you apply a global dark theme to your
AppVM(s) for Qt (KDE) based applications like Amarok, Krusader,
etc?

Install qt5ct and style plugins ...

Fedora: sudo dnf install qt5ct qt5-qtstyleplugins
Debian: sudo apt install qt5ct qt5-style-plugins

Then set QT_QPA_PLATFORMTHEME=qt5ct in etc/environment and reboot the
qube.

Now launch qt5ct and select the 'gtk2' theme. If you are simply using
Adwaita-Dark then qt5ct has a dedicated theme for that. Or you may
install and select the themes you mentioned.

For me this only works on Debian, the 'Qt5 Settings' application does
not work as it should Fedora (30, 31, 32).

Finally there is also the Kvantum engine with it's dedicated manager
you could search for.

Kvantum looks like something I am checking this out as well. Maybe
Kvantum will play better with Fedora than the Qt5 control panel.

I found this page supremely helpful:
https://wiki.archlinux.org/index.php/Uniform_Look_for_QT_and_GTK_Applica
tions

Yeah, the best option seems to be Debian template, install KDE with
'tasksel' command, then run 'systemsettings5' to select the KDE theme or
color scheme.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Why Fedora?

2020-08-10 Thread Chris Laprise


On 8/10/20 12:05 PM, Toptin wrote:

Dear Qubes Users,

I'm currently digging my way through the exceptional good Qubes
documentation. Everything is nicely explained as to why a certain
decision / implementation was made, except for the use of Fedora as main
distribution.

I wonder what's the rationale of that decision; Fedora 25 isn't even
supported anymore. No offense or critic intended, just curiosity.

Regards, toptin.



IIRC the core Linux developer for Qubes stated that Fedora was simply 
what he was used to when starting the project.


Since then an issue has been open to replace Fedora in dom0 with 
something else.


--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f27b8bcd-9f82-7aa0-799e-c5887ce4ca79%40posteo.net.

Re: [qubes-users] Re: Black Screen when installing 4.0.3 & 4.1 on AMD Ryzen 4750U

2020-08-10 Thread Chris Laprise

On 8/5/20 7:29 PM, Dylanger Daly wrote:
Hmm, wonder if I should try building a 4.1 ISO with a Linux 5.8 Kernel,
it's interesting because Xen is able to write to the framebuffer just
fine, I think it's dom0 that isn't able to remap it so it stays at an
address Xen had it configured for, it almost smells like an IOMMU/Memory
Mapping issue, not necessarily GPU.

My Thinkpad T14 arrived and Qubes 4.0.3 installer behaves the same on
the T14 as what you reported.

With Ubuntu upgraded to kernel 5.8.0 to fix broken suspend & brightness
and system running hot; now its great extremely fast, cool and
quiet. (Yes, I upgraded kernel bc the existing one had.)

I'm going to experiment with moving a couple of my Qubes VMs over to the
Ubuntu install under KVM (using VM Manager app). I've already got an LVM
thin pool setup and re-provisioning OS root snapshots to specific VMs
before they boot as if they were templates.

There's UEFI Options for the UMA Framebuffer size of 512MB, 1GB and 2GB
I've tried all variants unsuccessfully.
I don't think it's a Xen issue because I tried simply moving my current
laptop's NVMe, when I entered my LUKs Password (Blind) I could see LEDs
on the keyboard initialize so I think 4.0.3 does indeed work fine.

FYI release notes for both Xen 4.13 and 4.14 mention additional support
for new AMD Epyc processors. I interpret this as a server-oriented way
of expressing support for certain generations of AMD processors, though
I don't know how close Ryzen and Epyc are in terms of operation.

The Qubes 4.1 tree appears to have Xen 4.13 and Linux 5.7, currently.

I don't think there's a migration path for 4.0.3 - 4.1 (Backup &
Restore) yet, I don't think the Qubes team have even signed any 4.1 ISOs
yet either so I'd rather 4.0.3 but I'll take anything I can get at this
point.

I feel the same way. I would love to run Qubes on my T14 but I have a
feeling that Linux 5.7 won't cut it and I'm not experienced enough with
qubes builder to confidently upgrade either Linux or Xen. I did make a
sloppy attempt with ISO Master to replace the Qubes 4.0.3 installer ISO
kernel with the Ubuntu 5.8.0 kernel but due to my ignorance about the
format I couldn't get it to initiate the boot process.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Qubes dom0-update-guard script

2020-08-09 Thread Chris Laprise

On 8/8/20 10:20 AM, fiftyfourthparal...@gmail.com wrote:
So the new overview of the script is: have a dedicated (and hardened?)
tor VM --basically, whonix-ws-- download the metadata from a few mirror
sites, compare them to the metadata from Tor, and if all checks out,
compare the tor version to the packages installed in dom0. If it doesn't
check out, alert user and ask whether to proceed. To do this entirely in
dom0 (keeping it safe and simple for a newbie at programming), I'm going
to use qvm-run with --pass-io somewhere in my script, along with
something to read the whonix output and run cross checks.

Just an idea: Use the Qubes Security Bulletins as your reference for
checking package versions:

https://www.qubes-os.org/security/pack/

These bulletins are signed txt files, which makes them secure. The
difficult part would be parsing the QSBs themselves but I wonder if
Qubes devs would agree to a standard format going forward to make it
easier + reliable.

A concern: I've noticed that a lot of Qubes mirrors are often offline.
Would this create vulnerabilities?

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Qubes dom0-update-guard script

2020-08-07 Thread Chris Laprise


On 8/7/20 2:56 PM, 'awokd' via qubes-users wrote:

fiftyfourthparal...@gmail.com:


Right now my plan is to take the output of 'rpm -qa' or 'yum list
installed' and compare it via some sort of 'match' or 'crosscheck' function
to a repo list pulled from somewhere secure (i.e. not tampered with by
potential adversaries) and maybe imported into dom0 from a specialized
secure appVM, creating a security tradeoff.


"[P]ulled from somewhere secure"- if the concern is someone tampering
with your HTTPS traffic in particular, you will probably want to use a
different method of obtaining the repo list. Tor might work.


I think this is only properly done via a trusted .onion address, i2p 
address, etc... Unless Tor's DNS lookups have been improved since the 
last time I checked.


Just for reference here, threat model I'm thinking of here is when an 
attacker tries to MiTM while having the cooperation of the certificate 
authority.


--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/fb3c89f6-8e3b-073a-559b-f80e30d331c3%40posteo.net.

Re: [EXT] Re: [qubes-users] Update templates in parallel

2020-08-06 Thread Chris Laprise

On 8/6/20 12:23 PM, fiftyfourthparal...@gmail.com wrote:

On Friday, 7 August 2020 00:13:52 UTC+8, Chris Laprise wrote:

IIRC that setting refers to checking packages, not the repomd.xml
files.
That's why an attacker can't replace packages with their own versions;
they have to manipulate the metadata to hold back packages from
receiving updates.

--
Chris Laprise, tas...@posteo.net

https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

So as long as I verify that the version numbers of packages in dom0
match those of the actual repo website, I can assume that my dom0
updates have not been tampered with by adversaries?

Yes. Note that Qubes Security Bulletins are issued for vulns that affect
dom0 and they reference the package versions that contain the patches.
For example:

https://groups.google.com/d/msgid/qubes-users/34eddc9a-300c-743c-cb12-acc677f5784f%40qubes-os.org

However, most vulns that affect templates are not addressed by QSBs
because they're not Qubes-specific. That's one reason to avoid Fedora
templates in general.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [EXT] Re: [qubes-users] Update templates in parallel

2020-08-06 Thread Chris Laprise


On 8/6/20 10:37 AM, fiftyfourthparal...@gmail.com wrote:

I hate to break that feeling, but Fedora is unique in that it doesn't
sign its repo metadata, and sadly that is what matters. They put a
bandaid on it by fetching more hashes via https... so the update
security in Fedora is based on the strength of https. That is bad, as
https can be subverted by resourceful attackers.


On the other hand, following the instructions on these sites shows me 
that /etc/yum.conf and the repos in /etc/yum.repos.d/  all have 
gpgcheck=1. I'm not sure what this means.


https://www.qubes-os.org/doc/security-guidelines/

https://docs.fedoraproject.org/en-US/Fedora/12/html/Deployment_Guide/sec-Configuring_Yum_and_Yum_Repositories.html 


IIRC that setting refers to checking packages, not the repomd.xml files. 
That's why an attacker can't replace packages with their own versions; 
they have to manipulate the metadata to hold back packages from 
receiving updates.


--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/acb5bfda-3d1e-1fac-051a-fae865491f19%40posteo.net.

Re: [EXT] Re: [qubes-users] Update templates in parallel

2020-08-06 Thread Chris Laprise

On 8/6/20 3:54 AM, fiftyfourthparal...@gmail.com wrote:

On Thursday, 6 August 2020 12:31:44 UTC+8, Emily wrote:

-- I'm not unman, but I just checked the repo data and it appears
they use sha256

This is reassuring. Thanks, Emily

I hate to break that feeling, but Fedora is unique in that it doesn't
sign its repo metadata, and sadly that is what matters. They put a
bandaid on it by fetching more hashes via https... so the update
security in Fedora is based on the strength of https. That is bad, as
https can be subverted by resourceful attackers.

https://bugzilla.redhat.com/show_bug.cgi?id=1130491

What this potentially allows is an attacker to blind Fedora systems to
specific package updates, where the systems appear to retrieve updates
normally without the users being aware that particular packages with
known vulnerabilities have been held back.

Note that RHEL and Centos _do_ sign their repomd.xml. So we're looking
at some kind of decision made either by Red Hat's marketing department
(keep Fedora off RHEL's expensive turf) or by some idea that Fedora is
not for serious mission critical environments, or both.

So this is a sizable hole in Qubes security. The best advice I can give
is to avoid using Fedora templates and pay attention to Qubes Security
Bulletins when they mention which dom0 components will be updated (and
pay close attention when running qubes-dom0-update to look for the
mentioned components).

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Re: Whonix-gw: trouble after disabling passwordless root access

2020-08-06 Thread Chris Laprise

On 8/5/20 11:48 PM, fiftyfourthparal...@gmail.com wrote:

On Thursday, 6 August 2020 00:37:08 UTC+8, Qubes wrote:

What risk(s) are you mitigating by disabling passwordless root?

You should look at this the other way around--what do I stand to lose
by keeping passwordless root? If I can take a low-cost step that would
dramatically raise the cost for would-be attackers, wouldn't it be a
prudent step to take? Besides, even Joanna herself backtracked on her
claim that passwordless root is the best option (forgot where I read it,
but I definitely did)

IIRC she gave some indication that guest VMs shouldn't be defenseless
internally.

My own philosophy (which prompted me to create Qubes-VM-hardening) is
that if we're going to have these VMs running regular OSes, they should
at least have their normal security or some equivalent intact. And also
that the combination of normal security and Qubes security should yield
extra benefits, which I think Qubes-VM-hardening does.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Re: Black Screen when installing 4.0.3 & 4.1 on AMD Ryzen 4750U

2020-08-05 Thread Chris Laprise


On 8/5/20 7:56 AM, Chris Laprise wrote:

On 8/5/20 6:54 AM, Dylanger Daly wrote:
On Wednesday, August 5, 2020 at 4:04:32 PM UTC+10 dylang...@gmail.com 
wrote:


    When trying to install Qubes 4.0.3 or 4.1 (Test ISO) into a Ryzen
    4750U based laptop, I see xen output, it relinquishes vga to dom0,
    then black.

    I managed to enabled logging, where it prints dom0's dmesg super
    slow, line by line.

    |
    efifb:cannot reserve video memory at 0x6000
    efi:EFI_MEMMAP isnotenabled
    |


    Then it crashes but it continues to come all the way to Anaconda
    confirming it's a GPU/Memory Issue

    This seems to be related to UMA / iGPU Memory Management, unsure if
    it's just that Kernel Support for this CPU is spotty, Fedora 32 Live
    USB boots perfectly.

    This is 100% a Display/GPU issue has everything else comes up
    smitten, I just don't see anything / the framebuffer isn't passed
    from Xen to dom0.


Another user had similar symptoms as you with a Ryzen 3200G, apparently 
not resolved...


https://groups.google.com/d/msgid/qubes-users/75241cee-4e22-4a63-b81e-46581ede9308%40googlegroups.com

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/97da6d42-2548-f29d-df31-6b69105cab92%40posteo.net.

Re: [qubes-users] Re: Black Screen when installing 4.0.3 & 4.1 on AMD Ryzen 4750U

2020-08-05 Thread Chris Laprise

On 8/5/20 6:54 AM, Dylanger Daly wrote:

The Device is a Lenovo X13 (AMD).

You have good taste in laptops. :)

Does anyone have any ideas? I've tried essentially all variations on the
"UEFI Troubleshooting" guide

I have a Thinkpad T14 with a Ryzen 4750U on its way. These new Ryzen
APUs are becoming popular... its going to become a real sticking point
to get them working with Qubes!

A user named Claudia had a long thread about installing Qubes on a
previous gen Ryzen...

https://groups.google.com/d/msgid/qubes-users/ae710f3839c46261d257d7d188da32b9%40disroot.org

Also worth noting is that some Ryzen 4000 power management drivers have
just landed in Linux 5.8.

On Wednesday, August 5, 2020 at 4:04:32 PM UTC+10 dylang...@gmail.com wrote:

When trying to install Qubes 4.0.3 or 4.1 (Test ISO) into a Ryzen
4750U based laptop, I see xen output, it relinquishes vga to dom0,
then black.

I managed to enabled logging, where it prints dom0's dmesg super
slow, line by line.

|
efifb:cannot reserve video memory at 0x6000
efi:EFI_MEMMAP isnotenabled
|

Then it crashes but it continues to come all the way to Anaconda
confirming it's a GPU/Memory Issue

This seems to be related to UMA / iGPU Memory Management, unsure if
it's just that Kernel Support for this CPU is spotty, Fedora 32 Live
USB boots perfectly.

This is 100% a Display/GPU issue has everything else comes up
smitten, I just don't see anything / the framebuffer isn't passed
from Xen to dom0.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Can my pc be compromised and if so can I just create a new net-vm and firewall-vm and if so how when I can’t clone them ?

2020-08-05 Thread Chris Laprise

On 8/5/20 7:40 AM, Chris Laprise wrote:

On 8/5/20 3:46 AM, anneeyr...@gmail.com wrote:
Can I just delete the firewall-vm and the net-vm and create new ones
afterwards and shall I just create them in the same way when creating
new app-vm’s or standalone-vm’s or how shall I create them when I
can’t clone them ?

The possibility for sys-firewall to be compromised is pretty low, but if
you wipe/replace sys-net its easy to do the same for sys-firewall 'just
in case'.

To do it for sys-net, here is the one-step method in dom0:

sudo blkdiscard /dev/qubes_dom0/vm-sys-net-private

Be careful, as 'blkdiscard' is basically a bulk erase command. There are
other ways to do it, such as creating a new replacement for sys-net, but
they involve multiple steps and are frankly a bit frustrating to
describe and use.

I should have mentioned to shut down sys-net first. Using 'qvm-kill
sys-net' from the command line will do this without fuss. Then do the
'blkdiscard' step.

After the 'blkdiscard' you can start the wiped sys-net with 'qvm-start
sys-net'. You will need to re-enter any Wifi passwords that you were using.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Can my pc be compromised and if so can I just create a new net-vm and firewall-vm and if so how when I can’t clone them ?

2020-08-05 Thread Chris Laprise

On 8/5/20 3:46 AM, anneeyr...@gmail.com wrote:

I’m a victim of stalking.

Lately my 3. new mobile in about a year 1 day after using it suddenly said that
it’s new sim card was blocked. And sadly I restarted the phone although I
thought the reason for this was that it had been compromised and probably
should had set it back to factory settings.

I was at my parents house at he time and the phone haven’t been any other place
at the time.

Afterwards I found a sign of a installed and deleted app on my mothers Ipad.

I have read on the web that it is possible to use software like for example an
Ipad app to get access to mobile phones and mobile broadband.

As my new pc also only have been there and I have Qubes OS installed on it and
I have been using my own mobile broadband modem together with it, I wonder if
my pc also can be infected and if so could it be that only the firewall-vm and
the net-vm is compromised or could it be the whole system... ?

Are you confident the Qubes boot partition is safe? That is the
vulnerable spot in terms of someone getting physical access to your
machine. A few things can help keep boot safe:

1. Anti-evil maid

2. Heads

3. Putting an ATA lock password on your internal boot drive

The third option is not considered very strong, but its still a
deterrent of sorts and its easier to setup than the first two.

Can I just delete the firewall-vm and the net-vm and create new ones afterwards
and shall I just create them in the same way when creating new app-vm’s or
standalone-vm’s or how shall I create them when I can’t clone them ?

The possibility for sys-firewall to be compromised is pretty low, but if
you wipe/replace sys-net its easy to do the same for sys-firewall 'just
in case'.

To do it for sys-net, here is the one-step method in dom0:

sudo blkdiscard /dev/qubes_dom0/vm-sys-net-private

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Update templates in parallel

2020-08-03 Thread Chris Laprise


On 8/3/20 10:48 AM, fiftyfourthparal...@gmail.com wrote:
Oh, and while I have you here, Chris, I thought I'd let you know that 
your Wireguard guide in Qubes-VPN-Support doesn't work--I followed it 
step-by-step but was left frustrated, so I took another route.


I just came across this Reddit post where the poster seems to have gone 
through the same experience, so that reminded me to let you know:


https://old.reddit.com/r/Qubes/comments/i2cza9/cant_for_the_life_of_me_get_wireguard_to_work/


Yes, the requirements to get it running keep changing. Right now the 
easiest way is to install 'kernel-latest-qubes-vm' from dom0 to get a 
5.x kernel for VMs (the 5.x kernels have wg module included), then 
install the wireguard-tools package without dependencies in your template.


I'll be switching to wireguard in the next few weeks so I'll be updating 
the wiki then.


--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2265eb4b-76c3-d793-fddb-fee24910fec8%40posteo.net.

Re: [qubes-users] Update templates in parallel

2020-08-03 Thread Chris Laprise

On 8/3/20 10:18 AM, fiftyfourthparal...@gmail.com wrote:

On Monday, 3 August 2020 18:36:28 UTC+8, Chris Laprise wrote:

'curl' would only be used in a Whonix template. This is to signal
Qubes'
proxy to start the Tor-based updateVM as soon as possible. It should
not
try to run curl in a Fedora or regular Debian template.

To suppress interactive prompts, you need to run the script with
'-u' or
'--unattended'.

Thanks--I managed to figure that out and respondright before you posted
<https://groups.google.com/d/msg/qubes-users/SbLGJ1CWAWw/Bk1SyD-JAQAJ>,
so now I'm using the -atu option.

Not sure if it's a bug, but it seems like your script attempted to run
curl in Fedora. I can't copy the output, but the VM basically goes,
"Errors during downloading metadata for repository 'updates': Curl error
(28); Curl Error (23)" several times before throwing up its arms and
giving up. Then the script tells me that fedora-32-minimal update
returned non-zero status.

Seems like dnf itself uses curl. Searching for 'dnf curl' shows a lot of
hits. dnf is saying it couldn't use curl to retrieve metadata for the
updates repo. Maybe there is an issue with the way the updatevm is setup
on your system?

To test manually, here is the command the script uses:

dnf update -y --best

I also just tested the script with a fresh fedora-32-minimal and it
works (interesting to note that "curl-minimal" was one of the updated
packages).

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Update templates in parallel

2020-08-03 Thread Chris Laprise

On 8/3/20 4:11 AM, fiftyfourthparal...@gmail.com wrote:

Your Qubes-VM-Hardening tool was one of the first things installed
into my first Qubes, but I'm still not very familiar with how it
works. I think vm-boot-protect might be blocking me from adding a
.desktop file into ~/.config/autostart, as Steve suggested (Steve:
does this need to be done in templates? If done in an appVM, wouldn't
it get purged upon restart?).

BTW, I think the appVM is the right place to make the .config/autostart
change if the custom .desktop file is being applied on a per-VM basis.

If you want it for _all_ VMs based on that template, that's a little
harder. Putting the .desktop file in /etc/skel would only make the
change when an appVM is first created, so existing VMs using that
template would not benefit. However, vm-boot-protect-root has the
ability to copy or "deploy" files into /home on each boot; you would
have to save the .desktop file under
/etc/default/vms/vms.all/rw/home/user/.config/autostart in the template.

Another idea is to use rc.local to launch the app via 'systemd-run'
using its "timer" features or some other way to delay execution. Or you
could even try adding the .desktop file to /home using rc.local.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Update templates in parallel

2020-08-03 Thread Chris Laprise

On 8/3/20 4:11 AM, fiftyfourthparal...@gmail.com wrote:

On Sunday, 2 August 2020 22:42:31 UTC+8, Chris Laprise wrote:

You can check out my github for some interesting stuff. The
'Qubes-scripts' project has a (serial) template updater that lets you
select by certain criteria. It could be parallelized pretty easily.

[...]

Finally, there is a VPN tool and one to enhance VM internal security.

--
Chris Laprise, tas...@posteo.net

https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

I tested your halt-vm-by-window and system-stats-xen and found them very
useful. I also tried your qubes4-multi-update but ran into three issues:
one is that it relies on curl, which my Fedora minimal wasn't happy
about; another is that it [Y/n] prompts me for upgrades, which it
shouldn't do, according to the script; the last is that it attempts to
update mirage firewall standalones and when it fails, the whole process
stops.

'curl' would only be used in a Whonix template. This is to signal Qubes'
proxy to start the Tor-based updateVM as soon as possible. It should not
try to run curl in a Fedora or regular Debian template.

To suppress interactive prompts, you need to run the script with '-u' or
'--unattended'.

Your Qubes-VM-Hardening tool was one of the first things installed into
my first Qubes, but I'm still not very familiar with how it works. I
think vm-boot-protect might be blocking me from adding a .desktop file
into ~/.config/autostart, as Steve suggested (Steve: does this need to
be done in templates? If done in an appVM, wouldn't it get purged upon
restart?).

Yes, vm-boot-protect does lock down that dir, along with other startup
files and dirs in /home. The way it does this is with the 'immutable'
flag. To change it (re)start the VM and do:

sudo chattr -i -R .config/autostart

Then change what you need to in that path and restart the VM. During the
startup process the dir and its contents will be automatically made
immutable again.

Anyways, your tools are very convnient and I think they should be more
widely known, if not integrated into Qubes proper. Thank you

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Update templates in parallel

2020-08-02 Thread Chris Laprise

On 8/2/20 8:32 AM, fiftyfourthparal...@gmail.com wrote:
I have a ton of templates and standalones (>10), so updating them one by
one serially is a pain. I found a convenient dom0 script so I thought
I'd share.

Basically, take this and paste it into dom0 then make it executable.
There'a also a handy test function. All credit goes to Andrea Micheloni.
Anyone have similarly handy modifications/scripts?

https://m7i.org/tips/qubes-update-all-templates/

IIRC there is an option somewhere in 'qubesctl' for parallel template
updates.

You can check out my github for some interesting stuff. The
'Qubes-scripts' project has a (serial) template updater that lets you
select by certain criteria. It could be parallelized pretty easily.

Since you have a lot of templates+standalones, the 'findpref' tool might
also be of interest. It can bulk search/replace VM prefs, such as
changing all the VMs that are using 'sys-vpn1' to use 'sys-vpn3'
instead, or change VMs to use a different template.

I also wrote 'wyng-backup', a fast LVM incremental backup tool that only
scans where LVM reports new activity.

Finally, there is a VPN tool and one to enhance VM internal security.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] External Fully Encrypted SSD Drive. What do you think?

2020-07-28 Thread Chris Laprise

On 7/28/20 7:09 AM, load...@gmail.com wrote:

Hi everyone,

I am thinking now to buy a Macbook Pro 16' and use this laptop in 2
different ways:

1. /Mac OS/ for non-working tasks on internal drive.
2. /Qubes OS/ for all working process on external encrypted drive.

So for External Encrypted Drive I chose:
https://istorage-uk.com/product/diskashur2/

_One of the important tech specs is SSD Speed:_
361MB/s /Read/
358MB/s /Write/

_So I have 2 questions:

_*1. Is this enough for comfort using Qubes OS with this speed of SSD?

This is highly subjective but I would consider it fast enough.

2. What kind of _Hardware_ Encrypted Drive do you know which has more
speed capacity?*

Not that I'm aware. However, for a better security profile you might
check out Samsung's SSD products; I recall some of their models were
considered exemplary in a security review where most other brands had
major issues.

P.S.
I know that most of you could tell me that this is not very smart to do
this way, but I have my own reasons why I need external and encrypted
drive. When I will finish this setup I will write full guide how I am
using Qubes OS and hope it would helps someone to understand which way
to use is better for each one.
You're probably aware that Qubes on a USB drive means you can't use
'sys-usb' which means you can't block 'badUSB' attacks. That is one
compromise.

Another problem is that Macs typically experience more compatibility
issues with Linux.

Also: The Mac laptop keyboards are USB, not PS/2 as most "PC" laptops
are. USB internal keyboard is problematic with Qubes features like
sys-usb and anti-evil-maid.

Finally, Macs only give you Intel CPUs to choose from and those suffer a
lot more from side-channel vulnerabilities than other brands including
AMD. (FYI, Intel just fired their head of engineering and Intel Macs may
soon be in the dustbin category when Apple switches to ARM-based Macs.)

So I'd say that overall you're setting yourself up for the least optimal
experience, at least on all the Qubes-related fronts. I very much get
the attraction of OS X, but in 2020 the only real appeal of Mac hardware
is the exterior design and 16:10 screen. OTOH, a business model from HP,
Lenovo or Dell should net you the best Qubes compatibility and you can
get a top-performing 8-core system for less than what an MBP costs.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] QSB #058: Insufficient cache write-back under VT-d (XSA-321)

2020-07-07 Thread Chris Laprise


On 7/7/20 9:57 AM, Andrew David Wong wrote:

Only Intel systems are affected. AMD systems are not affected.


Per usual!

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6470bedd-0536-be4e-32f6-2ca7ee1fd1c6%40posteo.net.

Re: [qubes-users] Qubes better dove tailed for Journalists, and Human Rights Workers.

2020-05-14 Thread Chris Laprise

On 5/9/20 8:45 PM, donov...@unseen.is wrote:
There are some that are both tech and investigators. I personally found
Qubes to be a solution I wish I had found long before I did. In fact,
for me it was easier to move from Windows (and DOS before that) to Linux
as my primary work environment via Qubes rather than just a standalone
linux box or VM because it provided two solutions in one - move away
from Windows and provide multiple more secure and isolated environments
for my work. The technology landscape and associated threat vectors are
very fluid and Qubes is part of the foundation for dealing with that. I
even go so far as to suggest that Qubes should actually be the default
OS for any computer user, but that is unrealistic of course.

I cringe at the occasional post that suggests or implies that Qubes is
difficult. My background is almost exclusively M$ with the odd *nix
appliance thrown in, hardly the foundation for moving essentially
cold-turkey to Qubes that, for me, is based on an unfamiliar hypervisor
and linux vms. It is a tool, albeit one that is a bit specialized to
emphasize security. And like any tool, you have to learn how to use it
to maximize its intended purpose. It's not rocket surgery or brain
science, but it's also not a toaster. That said, I personally feel that
moving to LibreOffice and Thunderbird in the Windows environment many
years ago made the transition much easier and more familiar. My prior
profession also required that I maintain some level of proficiency at
the command/terminal prompt. That can be a big hurdle for people
considering the transition to Qubes from Windows. That said, I still
struggle with some tasks in Linux for which I have not developed any
"muscle memory" for - yet. But it gets easier daily.

I tend to agree with this assessment of Qubes. I think more techies
adopt it bc they understand what Qubes is doing for them under the hood.
But otherwise its still a pretty friendly environment that presents its
biggest challenges at install time.

Two of the biggest Qubes pitfalls are the template upgrade snafus (as
originally described) and lack of access to AppVM internal configuration
which is never presented in the menu by default.

I see a lot of posters attempting to use Qubes in much the same manner
as they might a standalone box and sometimes with less than sterling
results. All of that adds to the knowledge base of Qubes, but everything
that I have read tells me that being a reasonably secure OS on a
computer in a connected, information-centric production environment (as
in, making a living) is the primary purpose for its creation. It serves
that purpose well in my view. It'll likely not be a gaming box, a
screaming video or CAD rendering beast or even support bleeding-edge
hardware.

Qubes is a serious tool in the very serious and uncompromising world
where the bar for what is considered dangerous information is lowered on
a daily basis.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Qubes better dove tailed for Journalists, and Human Rights Workers.

2020-05-14 Thread Chris Laprise

On 5/9/20 5:02 PM, Steve Coleman wrote:

On Fri, May 8, 2020 at 7:13 PM Catacombs <mailto:ggg...@gmail.com>> wrote:

A Journalist or a Human Rights investigator, I think are more
comfortable with ease of use, not secure.

There is always a trade-off between security and usability for sure. One
trade-off for the non geek users is to enable networking in the software
template so that you can run the "Software" application to pick and
choose your required desktop applications. The journalist may not know
how to use DNF at the command line but the Software installer will
clearly let them pick and choose from several decent word processors. If
only the Software application used the same proxy method to search the
repository for packages then turning on the networking would not be
necessary. The average desktop user would have a much easier time
installing what they need.

The main thing for them to *not do* is to run any applications in the
template VM itself. Never test things in the template unless you
absolutely need to pre-configure something, and if so, do it with
networking turned off if you have that choice. Clearly this is not easy
for a non-geek, but it can be made a little easier.

So, I bet this has been talked about before. As I was doing the
upgrade to Fedora 31, I realized a Journalist is not likely to be
very happy doing that. After that, I had to search to find a Text
Editor, (Gedit is what I used) A Journalist would expect that the
things

LibreOffice is what you want for journalists.

Then I tried to watch a Video. Gee guys, a Journalist just expects
this stuff to work. I , on the other hand, am concerned our
mythical investigator not realizing the possible security
implications of opening what kind of app, when.

If you enable rpmfusion repos you will be able to access more video
codecs, but again that is a security trade-off.

Since protecting otherwise naive users is the topic, I would suggest
making a much simpler choice which is to use Debian. That will get you
codec support without messing with repo configs, and the user will have
an OS that is thoroughly tested and stabilized (i.e. meant for
production environments) and properly protected against MITM during
updates the way Fedora is not.

What you can do is have one template with all the DRMed codecs providing
for one or two AppVMs or DVMs that can run the videos, while keeping the
remaining AppVMs for investigations more secure without all the extra
risky additions. You just have to train them how to open the video URLs
in one of the special VMs.

Tech people do not think like Journalists of Human Rights Workers,
nor vice versa.

Perhaps not, but very likely we are trainable.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Me (anon-whonix AppVM) -> Tor -> VPN, settup with Mullvad VPN

2020-05-04 Thread Chris Laprise

On 5/2/20 6:54 AM, unman wrote:

On Sat, May 02, 2020 at 08:22:57AM +, taran1s wrote:

unman:

On Fri, May 01, 2020 at 11:54:27AM +, taran1s wrote:

taran1s:

Chris, I tried now to connect to the kraken.com, which seems to be tor
unfriendly through me->tor->VPN->kraken.com but it returns error on the
site "Disabled".

I learned now that despite I use the above connection model, using VPN
as an exit, I still exit from the tor exit not and not from the VPN. I
am not sure what broke.

If I understand your model: me->tor->VPN->kraken.com
you are running Tor *through* your VPN - this means that your service
provider sees your connection to the VPN, and your VPN provider sees
your connection to the first Tor hop.
Naturally, when you exit the VPN and set up the TOR circuit, it's a Tor
exit node that connects to kraken.
The VPN is NOT an exit in this model. Nothing has broken.

I am actually using mullvad VPN. The idea is to have the possibility to
access websites or services (like kraken.com) that are not tor-friendly.
I would like to connect first to Tor through sys-whonix than connect to
the VPN through VPN AppVM and from that VPN to connect to the clearnet.

I set the AppVMs networking following way: anon-whonix networking set
to -> sys-whonix networking set to -> VPN-AppVM proxy that connects to
the clearnet. Is that right for my model?

No.
Think about it.
anon-whonix creates a request.
sys-whonix takes that request, and builds a circuit.
VPN-AppVM sees the traffic to the first hop, and sends it down the VPN.
The VPN provider gets the Tor traffic, and sends it on to the first
hop.
Then it goes via Tor to the exit node and then to the target.
Your ISP sees traffic to the VPN; the VPN provider sees traffic from you
going to Tor; the target sees traffic coming from Tor network.

*Always* use check.torproject.org to confirm your exit IP in this sort of
case (always) so that actual matches expectations.

What you have built (in packet terms) is:
me - Tor - VPN - target.

What you seem to want is:
me - VPN - Tor - target

To do that you need to build the VPN traffic and send it down a Tor
circuit.
Your Qubes network configuration should be:
client - VPN qube - Tor qube - sys-firewall - sys-net

A good rule of thumb is that whichever proxyVM is directly attached to
your appVM will be the type of network that the remote service sees.

I have no idea if Whonix will let you do this.

This should work for most VPNs, as Patrick and I and others have tested
it (though I haven't tested Whonix specifically with Mullvad). The only
constraint is that the VPN use TCP instead of UDP.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Me (anon-whonix AppVM) -> Tor -> VPN, settup with Mullvad VPN

2020-04-22 Thread Chris Laprise


On 4/21/20 11:30 AM, taran1s wrote:

Thank you, this did the trick ^^ Link is up. I will test it with the
setup me -> sys-whonix -> ProxyVM setup ->
clearnet_Tor_unfriendly_services ;)

If I understand it well, I can select a new VPN country for the
particular session just by executing sudo cp any_country_I_need.ovpn
vpn-client.conf right?



Yes, that will work. To change without restarting the VPN VM, you can do:

sudo service qubes-vpn-handler stop
sudo cp some_location.ovpn vpn-client.conf
sudo service qubes-vpn-handler start

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/23aa6b77-6d12-0043-f826-871adaa48193%40posteo.net.

Re: [qubes-users] Me (anon-whonix AppVM) -> Tor -> VPN, settup with Mullvad VPN

2020-04-21 Thread Chris Laprise

On 4/21/20 7:03 AM, taran1s wrote:

Chris Laprise:

The 'No such file' error is the one to correct. As I said earlier, you
will need to move the files out of the "mullvad_config_linux"
subdirectory into the vpn dir. It can't find the .crt file because its
in the subdirectory.

So it seems like I will need to use the ProxyVM based on debian-10
template instead of fedora-30. In case of Fedora-30 ProxyVM, the error
is different for some mysterious reason, even the process was the same.

I try to unzip the files into the /rw/config/vpn directory, but whatever
I try, the unzip comand still creates the subdirectory. When I try to
get just the files there, without the subdirectory, I don't have enough
permissions. Is there any way how to unzip or somehow get the files into
/rw/config/vpn? Sorry for the noob questions :)

You could try 'sudo unzip -j' to extract without the subdirectory.

Or you could move the existing files with:

'sudo mv /rw/config/vpn/mullvad_config_linux/* /rw/config/vpn'

In any case, I suggest you look at an introduction to Linux command line
to get better acquainted with the OS.

Btw is it enough to have the ProxyVM routed through sys-net instead of
sys-firewall?

Yes.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Me (anon-whonix AppVM) -> Tor -> VPN, settup with Mullvad VPN

2020-04-20 Thread Chris Laprise


On 4/20/20 3:01 PM, taran1s wrote:


Chris Laprise:

You'll need to put the files in the vpn directory, not a subdirectory
like "mullvad_config_linux".


Is there any particular comand, instead of unzip, to not create the
sub-directory but unzip it in the vpn directory directly?



That particular error, however, indicates that the config expects
"update-resolv-conf" to be in "/etc/openvpn". You can copy it there for
the test, but this part of the config is overridden by Qubes-vpn-support
so in the end you won't need it there.


Should the Qubes-vpn-support be unzipped and installed in /home/user/ or
an another path or it doesn't matter?


You can unzip it in any user directory and the installer will know where 
to install the program files.




BTW this is the log from debian-10 based ProxyVM. The error seems to be
different:

user@open:~$ sudo mkdir -p /rw/config/vpn
user@open:~$ cd /rw/config/vpn
user@open:/rw/config/vpn$ sudo unzip ~/mullvad_openvpn_linux_all_all.zip
Archive:  /home/user/mullvad_openvpn_linux_all_all.zip
creating: mullvad_config_linux/
  extracting: mullvad_config_linux/mullvad_ae_all.conf
  extracting: mullvad_config_linux/mullvad_al_all.conf
  extracting: mullvad_config_linux/mullvad_at_all.conf
  extracting: mullvad_config_linux/mullvad_au_all.conf
  extracting: mullvad_config_linux/mullvad_be_all.conf
  extracting: mullvad_config_linux/mullvad_bg_all.conf
  extracting: mullvad_config_linux/mullvad_br_all.conf
  extracting: mullvad_config_linux/mullvad_ca_all.conf
  extracting: mullvad_config_linux/mullvad_ch_all.conf
  extracting: mullvad_config_linux/mullvad_cz_all.conf
  extracting: mullvad_config_linux/mullvad_de_all.conf
  extracting: mullvad_config_linux/mullvad_dk_all.conf
  extracting: mullvad_config_linux/mullvad_es_all.conf
  extracting: mullvad_config_linux/mullvad_fi_all.conf
  extracting: mullvad_config_linux/mullvad_fr_all.conf
  extracting: mullvad_config_linux/mullvad_gb_all.conf
  extracting: mullvad_config_linux/mullvad_gr_all.conf
  extracting: mullvad_config_linux/mullvad_hk_all.conf
  extracting: mullvad_config_linux/mullvad_hu_all.conf
  extracting: mullvad_config_linux/mullvad_ie_all.conf
  extracting: mullvad_config_linux/mullvad_il_all.conf
  extracting: mullvad_config_linux/mullvad_it_all.conf
  extracting: mullvad_config_linux/mullvad_jp_all.conf
  extracting: mullvad_config_linux/mullvad_lu_all.conf
  extracting: mullvad_config_linux/mullvad_lv_all.conf
  extracting: mullvad_config_linux/mullvad_md_all.conf
  extracting: mullvad_config_linux/mullvad_nl_all.conf
  extracting: mullvad_config_linux/mullvad_no_all.conf
  extracting: mullvad_config_linux/mullvad_nz_all.conf
  extracting: mullvad_config_linux/mullvad_pl_all.conf
  extracting: mullvad_config_linux/mullvad_pt_all.conf
  extracting: mullvad_config_linux/mullvad_ro_all.conf
  extracting: mullvad_config_linux/mullvad_rs_all.conf
  extracting: mullvad_config_linux/mullvad_se_all.conf
  extracting: mullvad_config_linux/mullvad_sg_all.conf
  extracting: mullvad_config_linux/mullvad_us_all.conf
  extracting: mullvad_config_linux/mullvad_userpass.txt
  extracting: mullvad_config_linux/mullvad_ca.crt
  extracting: mullvad_config_linux/update-resolv-conf
user@open:/rw/config/vpn$ sudo cp
mullvad_config_linux/mullvad_ch_all.conf vpn-client.conf
user@open:/rw/config/vpn$ sudo openvpn --cd /rw/config/vpn --config
vpn-client.conf --auth-user-pass mullvad_config_linux/mullvad_userpass.txt
Mon Apr 20 16:03:58 2020 Note: option tun-ipv6 is ignored because modern
operating systems do not need special IPv6 tun handling anymore.
Options error: --ca fails with 'mullvad_ca.crt': No such file or
directory (errno=2)
Mon Apr 20 16:03:58 2020 WARNING: file
'mullvad_config_linux/mullvad_userpass.txt' is group or others accessible
Options error: Please correct these errors.
Use --help for more information.



The 'No such file' error is the one to correct. As I said earlier, you 
will need to move the files out of the "mullvad_config_linux" 
subdirectory into the vpn dir. It can't find the .crt file because its 
in the subdirectory.


--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e62e93c1-4619-0966-03c2-68337e794269%40posteo.net.

Re: [qubes-users] Me (anon-whonix AppVM) -> Tor -> VPN, settup with Mullvad VPN

2020-04-20 Thread Chris Laprise


On 4/20/20 9:31 AM, taran1s wrote:



Chris Laprise:

On 4/20/20 8:12 AM, taran1s wrote:



Chris Laprise:

On 4/17/20 7:12 AM, taran1s wrote:



Chris Laprise:

On 4/15/20 6:35 AM, taran1s wrote:

In the point 3 of https://github.com/tasket/Qubes-vpn-support/ guide
there is the cd Qubes-vpn-support command as the first one. This
assumes
that the file is unzipped already, right? So I unzip it in the
/home/user folder, than cd to the unzipped Qubes-vpn-support-1.4.3
and
execute sudo bash ./install. Than proceed to the restart. Is this
how it
was meant?


Yes, if you're installing it in the Proxy VM (VPN VM) itself.
Otherwise,
installing it in a template means you have to do step 4 also.


Yes, I install it in the ProxyVM. Is my procedure right? The



Hmmm. Its not showing the full "Options error" lines. Try redirecting
the output to a text file instead:

sudo journalctl -u qubes-vpn-handler >log.txt



See the log attached please.



It doesn't look like the same error as before. This one says the config
has no "dev" specified. Can you check '/rw/config/vpn/vpn-client.conf'
to see if it has a line like "dev tun"?



If I go to the /rw/config/vpn/ there is no vpn-client.conf file but
vpn-client.conf-example only. This is content of the
vpn-client.conf-example:


OK, it looks like you skipped the part of Step 2 where you copy or link
your config file so that "vpn-client.conf" exists. For example:

sudo cp US_East.ovpn vpn-client.conf


I created another ProxyVM ovpn and do it from the scratch. Can you
please check if this is the right procedure?

[user@ovpn ~]$ sudo mkdir -p /rw/config/vpn
[user@ovpn ~]$ cd /rw/config/vpn
[user@ovpn vpn]$ ls
[user@ovpn vpn]$ sudo unzip ~/mullvad_openvpn_linux_all_all.zip
Archive:  /home/user/mullvad_openvpn_linux_all_all.zip
creating: mullvad_config_linux/
  extracting: mullvad_config_linux/mullvad_ae_all.conf
  extracting: mullvad_config_linux/mullvad_al_all.conf
  extracting: mullvad_config_linux/mullvad_at_all.conf
  extracting: mullvad_config_linux/mullvad_au_all.conf
  extracting: mullvad_config_linux/mullvad_be_all.conf
  extracting: mullvad_config_linux/mullvad_bg_all.conf
  extracting: mullvad_config_linux/mullvad_br_all.conf
  extracting: mullvad_config_linux/mullvad_ca_all.conf
  extracting: mullvad_config_linux/mullvad_ch_all.conf
  extracting: mullvad_config_linux/mullvad_cz_all.conf
  extracting: mullvad_config_linux/mullvad_de_all.conf
  extracting: mullvad_config_linux/mullvad_dk_all.conf
  extracting: mullvad_config_linux/mullvad_es_all.conf
  extracting: mullvad_config_linux/mullvad_fi_all.conf
  extracting: mullvad_config_linux/mullvad_fr_all.conf
  extracting: mullvad_config_linux/mullvad_gb_all.conf
  extracting: mullvad_config_linux/mullvad_gr_all.conf
  extracting: mullvad_config_linux/mullvad_hk_all.conf
  extracting: mullvad_config_linux/mullvad_hu_all.conf
  extracting: mullvad_config_linux/mullvad_ie_all.conf
  extracting: mullvad_config_linux/mullvad_il_all.conf
  extracting: mullvad_config_linux/mullvad_it_all.conf
  extracting: mullvad_config_linux/mullvad_jp_all.conf
  extracting: mullvad_config_linux/mullvad_lu_all.conf
  extracting: mullvad_config_linux/mullvad_lv_all.conf
  extracting: mullvad_config_linux/mullvad_md_all.conf
  extracting: mullvad_config_linux/mullvad_nl_all.conf
  extracting: mullvad_config_linux/mullvad_no_all.conf
  extracting: mullvad_config_linux/mullvad_nz_all.conf
  extracting: mullvad_config_linux/mullvad_pl_all.conf
  extracting: mullvad_config_linux/mullvad_pt_all.conf
  extracting: mullvad_config_linux/mullvad_ro_all.conf
  extracting: mullvad_config_linux/mullvad_rs_all.conf
  extracting: mullvad_config_linux/mullvad_se_all.conf
  extracting: mullvad_config_linux/mullvad_sg_all.conf
  extracting: mullvad_config_linux/mullvad_us_all.conf
  extracting: mullvad_config_linux/mullvad_userpass.txt
  extracting: mullvad_config_linux/mullvad_ca.crt
  extracting: mullvad_config_linux/update-resolv-conf
[user@ovpn vpn]$ sudo cp mullvad_config_linux/mullvad_ch_all.conf
vpn-client.conf
[user@ovpn vpn]$ sudo openvpn --cd /rw/config/vpn --config
vpn-client.conf --auth-user-pass mullvad_config_linux/mullvad_userpass.txt
Mon Apr 20 15:27:43 2020 Note: option tun-ipv6 is ignored because modern
operating systems do not need special IPv6 tun handling anymore.
Options error: --up script fails with '/etc/openvpn/update-resolv-conf':
No such file or directory (errno=2)
Options error: Please correct this error.
Use --help for more information.
[user@ovpn vpn]$ cd ~
[user@ovpn ~]$ sudo openvpn --cd /rw/config/vpn --config vpn-client.conf
--auth-user-pass mullvad_config_linux/mullvad_userpass.txt
Mon Apr 20 15:28:29 2020 Note: option tun-ipv6 is ignored because modern
operating systems do not need special IPv6 tun handling anymore.
Options error: --up script fails with '/etc/openvpn/update-resolv-conf':
No such file or directory (errno=2)
Options error: Please correct this error.
Use --help

Re: [qubes-users] Me (anon-whonix AppVM) -> Tor -> VPN, settup with Mullvad VPN

2020-04-20 Thread Chris Laprise


On 4/20/20 8:12 AM, taran1s wrote:



Chris Laprise:

On 4/17/20 7:12 AM, taran1s wrote:



Chris Laprise:

On 4/15/20 6:35 AM, taran1s wrote:

In the point 3 of https://github.com/tasket/Qubes-vpn-support/ guide
there is the cd Qubes-vpn-support command as the first one. This
assumes
that the file is unzipped already, right? So I unzip it in the
/home/user folder, than cd to the unzipped Qubes-vpn-support-1.4.3 and
execute sudo bash ./install. Than proceed to the restart. Is this
how it
was meant?


Yes, if you're installing it in the Proxy VM (VPN VM) itself. Otherwise,
installing it in a template means you have to do step 4 also.


Yes, I install it in the ProxyVM. Is my procedure right? The



Hmmm. Its not showing the full "Options error" lines. Try redirecting
the output to a text file instead:

sudo journalctl -u qubes-vpn-handler >log.txt



See the log attached please.



It doesn't look like the same error as before. This one says the config
has no "dev" specified. Can you check '/rw/config/vpn/vpn-client.conf'
to see if it has a line like "dev tun"?



If I go to the /rw/config/vpn/ there is no vpn-client.conf file but
vpn-client.conf-example only. This is content of the
vpn-client.conf-example:


OK, it looks like you skipped the part of Step 2 where you copy or link 
your config file so that "vpn-client.conf" exists. For example:


sudo cp US_East.ovpn vpn-client.conf

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c021dc1b-3d41-4326-ca33-3bf6482f6288%40posteo.net.

Re: [qubes-users] KDE Plasma in dom0 under R4.0.3

2020-04-18 Thread Chris Laprise

On 4/11/20 3:10 PM, Sven Semmler wrote:

On Sat, Apr 11, 2020 at 02:48:17PM -0400, Chris Laprise wrote:

I've never had a problem with KDE in dom0 as long as the display manager is
switched to sddm and BIOS is set to integrated graphics. "Discrete graphics"
usually means Nvidia, which is poorly supported in open source operating
systems.

Funny enough, motivated by your comment I went and switched back to
"hybrid" (aka integrated) graphics ... and all my issues came back!

So while I am sure your statement is correct in general, on my
particular setup switching to the discrete graphics makes everything
work. Every rule has an exception I guess.

FWIW, I would have thought that 'hybrid' is the opposite of 'integrated'
in terms of compatibility. That sounds like a config that requires a
dual-driver manager like bumblebee.

The BIOS graphics options I've seen sometimes allow hybrid, but also
include a strict integrated-only option that completely disables the
discrete GPU.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Qubes-vpn-support Tor Browser not working

2020-04-18 Thread Chris Laprise

On 4/18/20 9:26 AM, Anhangá wrote:
But is it possible to somehow make TOR Browser to access clearnet using 
a VPN connection after the TOR routing? Do I have to do some special 
config in the TOR Browser to allow that?

Em sábado, 18 de abril de 2020 10:07:16 UTC-3, Jarrah escreveu:

 > My goal is connect to my VPN after the TOR routing (Bypass the
 > tor censorpship in some websites).
This somewhat defeats the purpose of using TOR. You now have an
identifiable address due to having a (hopefully paid) vpn. They can
track you. Any anonymity provided by TOR is taken away by the VPN.
 > The problem is, when I set mt whonix-workstation to connect to
sys-VPN over
 > whonix-gw, My Tor Browser do not work anymore. If I disconnect
the VPN
 > inside sys-VPN, the Tor Browser start working as usual, but when
my VPN is
 > connected, it stops.

This is by design. TOR browser assumes it can speak TOR protocols and
connect to .onion addresses (etc). However, the VPN will come out onto
the clearnet, rather than TOR's network. TOR browser cannot lookup TOR
addresses, nor can it connect to anything relying on TOR.

If you want to do this to access clearnet sites, you'd have to use a
standard browser. The VPN should work just fine, so long as you're not
trying to connect to TOR specific services through it. Though, please
see above warning about doing so.

The only reason I can think of to do this is if you live in a location
that blocks VPNs, but is fine with TOR. Otherwise, you have exactly the
same security model as just using the VPN, plus the overhead and attack
surface of TOR/Whonix. 

Someone on the Whonix forums might know the definitive answer to your 
question. But I'd guess there is little or no advantage to using 
Torbrowser over Firefox when it can't speak to the Tor router.

Note that Firefox has recently incorporated some Torbrowser features, so 
you could use it with Tracking Protection set to Strict, and 
'privacy.firstparty.isolate' set to True, 'privacy.resistFingerprinting' 
set to True, in addition to using the User-Agent Switcher extension. I 
think these are a good idea whether or not you use a tunnel or proxy.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/166b78ec-c061-dcb9-f6fe-d31a797b6bcb%40posteo.net.

Re: [qubes-users] Me (anon-whonix AppVM) -> Tor -> VPN, settup with Mullvad VPN

2020-04-17 Thread Chris Laprise


On 4/17/20 7:12 AM, taran1s wrote:



Chris Laprise:

On 4/15/20 6:35 AM, taran1s wrote:

In the point 3 of https://github.com/tasket/Qubes-vpn-support/ guide
there is the cd Qubes-vpn-support command as the first one. This assumes
that the file is unzipped already, right? So I unzip it in the
/home/user folder, than cd to the unzipped Qubes-vpn-support-1.4.3 and
execute sudo bash ./install. Than proceed to the restart. Is this how it
was meant?


Yes, if you're installing it in the Proxy VM (VPN VM) itself. Otherwise,
installing it in a template means you have to do step 4 also.


Yes, I install it in the ProxyVM. Is my procedure right? The



Hmmm. Its not showing the full "Options error" lines. Try redirecting
the output to a text file instead:

sudo journalctl -u qubes-vpn-handler >log.txt



See the log attached please.



It doesn't look like the same error as before. This one says the config 
has no "dev" specified. Can you check '/rw/config/vpn/vpn-client.conf' 
to see if it has a line like "dev tun"?


--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/55d034d2-3637-2c49-aafb-9a17a48d6097%40posteo.net.

Re: [qubes-users] Me (anon-whonix AppVM) -> Tor -> VPN, settup with Mullvad VPN

2020-04-17 Thread Chris Laprise


On 4/15/20 6:35 AM, taran1s wrote:

In the point 3 of https://github.com/tasket/Qubes-vpn-support/ guide
there is the cd Qubes-vpn-support command as the first one. This assumes
that the file is unzipped already, right? So I unzip it in the
/home/user folder, than cd to the unzipped Qubes-vpn-support-1.4.3 and
execute sudo bash ./install. Than proceed to the restart. Is this how it
was meant?


Yes, if you're installing it in the Proxy VM (VPN VM) itself. Otherwise, 
installing it in a template means you have to do step 4 also.




This is the output from the sudo journalctl -u qubes-vpn-handler in teh
openvpn VM.

[user@ovpn ~]$ sudo journalctl -u qubes-vpn-handler
-- Logs begin at Tue 2020-02-18 14:58:45 CET, end at Wed 2020-04-15
12:22:55 CE>
Apr 15 12:22:12 ovpn systemd[1]: Starting VPN Client for Qubes proxyVM...
Apr 15 12:22:12 ovpn qubes-vpn-setup[789]: STARTED network forwarding!
Apr 15 12:22:12 ovpn qubes-vpn-setup[788]: EXEC /usr/sbin/openvpn --cd
/rw/conf>
Apr 15 12:22:12 ovpn systemd[1]: Started VPN Client for Qubes proxyVM.
Apr 15 12:22:12 ovpn qubes-vpn-setup[788]: Wed Apr 15 12:22:12 2020
Note: optio>
Apr 15 12:22:12 ovpn qubes-vpn-setup[788]: Options error: --ca fails
with 'mull>
Apr 15 12:22:12 ovpn qubes-vpn-setup[788]: Options error: Please correct
these >


Hmmm. Its not showing the full "Options error" lines. Try redirecting 
the output to a text file instead:


sudo journalctl -u qubes-vpn-handler >log.txt

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5638909e-db69-40f5-5194-df08a884b20d%40posteo.net.

Re: [qubes-users] Help with qubes-vpn-support

2020-04-17 Thread Chris Laprise


On 4/14/20 10:31 PM, l...@firemail.cc wrote:
I'm setting up wireguard, but encountered an issue with 
qubes-vpn-support (https://github.com/tasket/Qubes-vpn-support).


Traffic from my vpn proxyvm ('sys-mullvad') is getting through. Apt 
updates and installations, wget, ping, etc all work from within 
sys-mullvad. I don't think this is expected behavior.


FWIW, I'm on Qubes 4.0.3, with the debian 10 minimal template used for 
this. Tried the debian 10 template too, to the same effect. Did I miss 
anything?


The Wireguard mode uses an egress configuration where traffic initiated 
from inside the VPN VM is permitted (note this is how the Qubes vpn doc 
now does it as well, with Marek's approval).


This doesn't affect the fail-safes for traffic initiated from either 
side of the VPN VM (e.g. nothing can go 'around' the VPN link).


--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e44ab102-871d-9551-bc5d-1169fb2663fb%40posteo.net.

Re: [qubes-users] Is a StandaloneVM equally secure as a AppVM that is created on it's own TemplateVM, and what is the difference between a StandaloneVM and a AppVM ?

2020-04-13 Thread Chris Laprise

On 4/12/20 5:22 PM, Dan Krol wrote:

 > Standalone VMs are good in rare cases when you need to experiment with
 > an app or configuration that might conflict with a template.

Personally, so far I've used it when I want to install something that's 
not in the Debian/Fedora repository (which half the time just means dev 
tools and dependencies). I recently reduced my need there considerably 
with Flatpak user-level installation, but not entirely.

Is there a better way to achieve the same? bind-dirs for normal OS 
packages seems complicated and sort of defeats the purpose of the 
security benefit you just described. Perhaps I ought to clone Debian 10 
Template, install what I want, and then make an AppVM based on that?

That's reasonable and I think its what Qubes users do in most situations.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/36db92af-39fc-6a55-d617-caf010fbe736%40posteo.net.

Re: [qubes-users] KDE Plasma in dom0 under R4.0.3

2020-04-11 Thread Chris Laprise


On 4/11/20 1:12 PM, Sven Semmler wrote:

On Sat, Apr 11, 2020 at 03:01:39PM +0100, unman wrote:

If you want to open a separate topic, perhaps we could troubleshoot your
problems?


By all means. I have a fresh install of dom0 (all qubes restored from
backup) and have switched the graphics in the BIOS from 'hybrid' to
discrete on my Thinkpad P51.

Now running qubes-dom0-update @kde-desktop-qubes again. Will report back
shortly if that changes anything.


I've never had a problem with KDE in dom0 as long as the display manager 
is switched to sddm and BIOS is set to integrated graphics. "Discrete 
graphics" usually means Nvidia, which is poorly supported in open source 
operating systems.


--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/36ac57e4-d92b-590d-ffcb-c27f0a80543d%40posteo.net.

Re: [qubes-users] How to block all non tor traffic

2020-04-11 Thread Chris Laprise


On 4/11/20 8:32 AM, hsfcyxr hsfcyxr wrote:

There’s a second computer to access the Clinet.
How do I completely block traffic bypassing sys-whonix? I don’t know 
much English, so I couldn’t find it myself, I read qubes and whonix 
documentation.
(I marked dom0 updates via tor during installation, prescribed “sudo 
systemctl restart qubes-whonix-torified-updates-proxy-check”, installed 
everything in Qube Manager except sys-firewall, sys-whonix, sys-net and 
Tamplate VM on sys-whonix,

Qubes global settings -> Dom0 UpdateVM -> sys-whonix
Qubes global settings -> ClockV -> sys-whonix
Qubes global settings -> Default netVM -> sys-whonix
Qubes global settings -> Default template -> fedora-30
Qubes global settings -> Default DisposableVM Template -> fedora-30-dvm
)
Maybe there are some guides to setting qubes to anonymity so that the 
browser can’t recognize my time zone (so that it is different on 
different AppVMs). And how to add a different language to the keyboard, 
again, so that it would be visible only on the AppVMs I need.


img: qubes-os[.]org/attachment/wiki/posts/admin-api.png
*I will formulate a more specific question, as in the diagram above, to 
block all connections to sys-net except sys-whonix->sys-firewall->sys-net.*


Its best to ask about Whonix specifics on the whonix.org forums. 
However, I'm pretty sure that sys-whonix is already configured not to 
allow any non-Tor traffic; That is the point of having a Tor VM in the 
first place, to enforce network containment as strongly as possible.


--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/fe6dae00-ff23-a600-539d-38e6cdc92793%40posteo.net.

Re: [qubes-users] Me (anon-whonix AppVM) -> Tor -> VPN, settup with Mullvad VPN

2020-04-09 Thread Chris Laprise

On 4/9/20 3:34 AM, taran1s wrote:

Chris Laprise:

On 4/8/20 6:25 AM, taran1s wrote:

I try to set the VPN in my laest qubes with your guide on
https://github.com/tasket/Qubes-vpn-support. I use the version
1.4.3. and followed the guide.

My setting from mullvad is UDP (default) for Linux. No IPs.

When asked, I entered correct login. The link but doesn't go up,
no popup notification LINK IS UP when restarting the proxy VM.

I also added vpn-handler-openvpn to the proxy VM services as required.

Executing systemctl status returns this:

[user@ovpn ~]$ systemctl status qubes-vpn-handler
● qubes-vpn-handler.service - VPN Client for Qubes proxyVM
Loaded: loaded (/usr/lib/systemd/system/qubes-vpn-handler.service;
enabled; vendor preset: disabled)
Drop-In: /usr/lib/systemd/system/qubes-vpn-handler.service.d
└─00_example.conf
Active: activating (auto-restart) (Result: exit-code) since Tue
2020-04-07 15:30:15 CEST; 4s ago
Process: 3098 ExecStartPre=/usr/lib/qubes/qubes-vpn-setup
--check-firewall (code=exited, status=0/SUCCESS)
Process: 3105 ExecStartPre=/usr/lib/qubes/qubes-vpn-setup
--pre-start (code=exited, status=0/SUCCESS)
Process: 3110 ExecStart=/usr/lib/qubes/qubes-vpn-setup --start-exec
(code=exited, status=1/FAILURE)
Process: 3111 ExecStartPost=/usr/lib/qubes/qubes-vpn-setup
--post-start (code=exited, status=0/SUCCESS)
Process: 3117 ExecStopPost=/usr/lib/qubes/qubes-vpn-setup
--post-stop (code=exited, status=0/SUCCESS)
Main PID: 3110 (code=exited, status=1/FAILURE)

Any idea how to set this up properly?

The one exception I can think of for setting up with a Mullvad account
is that they use a single-character "m" password for everyone. So if you
typed something into the password prompt other than "m" or left it
blank, then it won't connect.

To see a more detailed log you should use 'journalctl -u
qubes-vpn-handler'.

Yes Chris, mullvad uses the "m" for password and I put this in when
asked. I checked this in the pass file from mullvad.

I did the following. I downloaded the default UDP settings for "All
countries" from mullvad as adviced, without ticking the IPs. Than I took
one of the countries from the downloaded list and copied this particular
country to the vpn-client.conf with sudo cp whatver-country.ovpn
vpn-client.conf. But it doesn't connect.

Did you do the link testing suggested in Step 2?

Is this setup ok for me-tor-vpn situation?

These network representations can easily get reversed in people's heads.
Best thing to do is look at your 'Networking' setting for your VPN VM.
If its set to 'sys-whonix' then UDP won't work.

I executed the command in the proxyVM (fedora-30 based) with following
results:

[user@ovpn ~]$ journalctl -u qubes-vpn-handler
Hint: You are currently not seeing messages from other users and the system.
Users in groups 'adm', 'systemd-journal', 'wheel' can see all
messages.
Pass -q to turn off this notice.
-- Logs begin at Tue 2020-02-18 14:58:55 CET, end at Thu 2020-04-09
09:21:21 CE>
-- No entries --
lines 1-2/2 (END)

I tried also the micahflee guide and it connects so the settings should
be ok.

Sorry, you need to put 'sudo' in front of the 'journalctl' command.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Is a StandaloneVM equally secure as a AppVM that is created on it's own TemplateVM, and what is the difference between a StandaloneVM and a AppVM ?

2020-04-08 Thread Chris Laprise


On 4/5/20 3:03 PM, 'M' via qubes-users wrote:
Is a StandaloneVM equally secure as a AppVM that is created on it's own 
TemplateVM ?


What is the "practical" difference between a StandaloneVM and a AppVM, 
and when is it recommended to use a StandaloneVM instead of a AppVM ?


I have read this page: https://www.qubes-os.org/doc/standalone-and-hvm/


Standalone VMs are good in rare cases when you need to experiment with 
an app or configuration that might conflict with a template.


Overall, they are less secure than a regular (template-based) appVM 
because if an attack succeeds with a privilege escalation, then the 
whole OS in the standalone may be compromised permanently. OTOH, an 
appVM's OS would bounce back to a good state when restarting it.


Also, after some time standalone VMs will use more disk space when you 
have multiple instances.


--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5961de1a-bcb9-67f6-23ca-57c9bea8%40posteo.net.

Re: [qubes-users] Me (anon-whonix AppVM) -> Tor -> VPN, settup with Mullvad VPN

2020-04-08 Thread Chris Laprise


On 4/8/20 6:25 AM, taran1s wrote:

I try to set the VPN in my laest qubes with your guide on
https://github.com/tasket/Qubes-vpn-support. I use the version
1.4.3. and followed the guide.

My setting from mullvad is UDP (default) for Linux. No IPs.

When asked, I entered correct login. The link but doesn't go up,
no popup notification LINK IS UP when restarting the proxy VM.

I also added vpn-handler-openvpn to the proxy VM services as required.

Executing systemctl status returns this:

[user@ovpn ~]$ systemctl status qubes-vpn-handler
● qubes-vpn-handler.service - VPN Client for Qubes proxyVM
Loaded: loaded (/usr/lib/systemd/system/qubes-vpn-handler.service;
enabled; vendor preset: disabled)
   Drop-In: /usr/lib/systemd/system/qubes-vpn-handler.service.d
└─00_example.conf
Active: activating (auto-restart) (Result: exit-code) since Tue
2020-04-07 15:30:15 CEST; 4s ago
   Process: 3098 ExecStartPre=/usr/lib/qubes/qubes-vpn-setup
--check-firewall (code=exited, status=0/SUCCESS)
   Process: 3105 ExecStartPre=/usr/lib/qubes/qubes-vpn-setup
--pre-start (code=exited, status=0/SUCCESS)
   Process: 3110 ExecStart=/usr/lib/qubes/qubes-vpn-setup --start-exec
(code=exited, status=1/FAILURE)
   Process: 3111 ExecStartPost=/usr/lib/qubes/qubes-vpn-setup
--post-start (code=exited, status=0/SUCCESS)
   Process: 3117 ExecStopPost=/usr/lib/qubes/qubes-vpn-setup
--post-stop (code=exited, status=0/SUCCESS)
  Main PID: 3110 (code=exited, status=1/FAILURE)

Any idea how to set this up properly?



The one exception I can think of for setting up with a Mullvad account 
is that they use a single-character "m" password for everyone. So if you 
typed something into the password prompt other than "m" or left it 
blank, then it won't connect.


To see a more detailed log you should use 'journalctl -u qubes-vpn-handler'.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/cf0cf304-e995-c4aa-0b5a-e152db48c659%40posteo.net.

Re: [qubes-users] No Match for argument qubes-template-whonix-ws-15-4.0.1-201910102356.noarch ?

2020-03-30 Thread Chris Laprise


On 3/27/20 7:38 PM, Stumpy wrote:

Complete!
[nate@dom0 ~]$ sudo qubes-dom0-update 
--enablerepo=qubes-templates-community \ qubes-template-whonix-ws
Using sys-whonix as UpdateVM to download updates for Dom0; this may take 
some time...

No Match for argument  qubes-template-whonix-ws
Nothing to download
[nate@dom0 ~]$


You can ignore the warnings when removing.

To fix the above, use 'qubes-template-whonix-ws-15' for the package name.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7752ce09-ad08-65df-5cbd-f3550b2f34a8%40posteo.net.

Re: [qubes-users] Me (anon-whonix AppVM) -> Tor -> VPN, settup with Mullvad VPN

2020-03-30 Thread Chris Laprise


On 3/29/20 5:16 AM, scurge1tl wrote:



Chris Laprise:

On 3/27/20 5:02 AM, scurge1tl wrote:




Hello all,

I would like to ask about proper setting of AppVM flow if using
Mullvad VPN. I would like to connect to the clearnet following way: Me
- -> Tor -> VPN -> clearnet.

When setting up mullvad in their web page, I set the parameters for
download here https://mullvad.net/en/download/openvpn-config/ in a
following way:
- - All countries (so that I can change my exit country as needed)
- - Port -> TCP 443 (Tor doesn't use UDP, right?)
- - tick Use IP addresses


Using TCP 443 for the connection helps only if you are running the VPN
on top of Tor. With Tor on top of VPN, you're probably better off with UDP.


Would this mean, if I plan to go with Me -> Tor -> VPN -> clarnet, to go
with UDP mullvad settings? Just to clear the "on top of".


To make it less ambiguous:

AppVM -> sys-whonix -> sys-vpn -> sys-net

The above connection is Tor on top of (or inside of) VPN, so UDP can be 
used for the VPN. If sys-whonix and sys-vpn places were reversed, then 
VPN should switch to TCP mode.


An easy way to remember this is that the sys-* VM attached to the AppVM 
is the one the service sees on the other end.








To set the Mullvad VPN AppVM, I followed this guide from micahflee
https://micahflee.com/2019/11/using-mullvad-in-qubes/ The AppVM with
mullvad is vpn-mullvad. All works fine and connects to the network.

How should I connect Me -> Tor -> VPN -> clearnet? Am I right with
this setup (I didn't launch it yet): anon-whonix -> sys-whonix ->
vpn-mullvad -> sys-firewall, or I should use different setup?


Whonix has a guide that examines the issues of combining Tor and a VPN.
However, I think its better as a 'what-if/why' guide than a Howto...

https://www.whonix.org/wiki/Tunnels/Connecting_to_a_VPN_before_Tor


Thank you I will check it.





Are there any other steps to follow to prevent leaks?


Yes.

The Qubes-vpn-support project is much easier to setup and should work
more smoothly, in addition to providing better protection against leaks:

https://github.com/tasket/Qubes-vpn-support

There is also a VPN setup guide on the Qubes doc page (this is the one
the Whonix page links to). FWIW, I wrote the scripts for both but the
idea for Qubes-vpn-support was to automate the setup and improve the
connection handling of Openvpn so re-connection doesn't take 5 minutes.
It also checks the firewall to make sure leak prevention is in place
before initiating connections.


I will try to set the additional AppVM for this and try this guide. What
would be the linking of the AppVMs, if I would like to go Me -> Tor ->
VPN -> clearnet? Is it like anon-whonix -> sys-whonix -> mullvad-AppVM
-> sys-firewall ?

Also I would like to use different exit countries of choice, so I
downloaded all countries from mullvad. Is there any simple way to switch
countries with this VPN settings?


There is no GUI way to do it when using the Qubes scripts. However, if 
you use the Network Manager method on the Qubes vpn howto, then you can 
import multiple configs (and cross your fingers that they can make 
connections :) ).


For a non-GUI solution, you could create a small script that lets you 
choose which ovpn config to use, and 'cp' or 'ln' that choice to the 
config filename that the scripts use (then restart the vpn). Some people 
have used simple random selection without a prompt, like 'ln -s $( ls 
*ovpn | shuf | head -n1 ) vpn-client.conf'.



Sorry for noob questions, I am new to the VPN stuff, just used Tor only
till now, but I need to use tor-unfriendly services from time to time
and even if it were tor-friendly, ExitNodes {xx} StrictNodes 1 doesn't
work in qubes-whonix and I therefore can't select exit country easily if
I need to. So I need to have the VPN country as a strict exit.


To use Tor-unfriendly services, the service has to see the VPN IP not 
Tor exit node IP. Therefore...


AppVM -> sys-vpn -> sys-whonix -> sys-net

If you add sys-firewall (or similar proxyVM, as you probably don't want 
to change sys-firewall netvm setting) in the mix, it just depends on 
which VM you wish to add 'Qubes firewall' rules to it always goes 
'to the right of' whichever VM you added rules. In my experience, 
however, such rules are not required for securing a VPN link; The 
internal (scripted) rules used by the VPN doc or Qubes-vpn-support 
handle VPN security rather well. IOW, its better to forget placing 
sys-firewall in the loop, at least until you're more used to Qubes 
networking.




Thank you and I will let you know if it works!




--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emai

Re: [qubes-users] Me (anon-whonix AppVM) -> Tor -> VPN, settup with Mullvad VPN

2020-03-27 Thread Chris Laprise

On 3/27/20 5:02 AM, scurge1tl wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello all,

I would like to ask about proper setting of AppVM flow if using
Mullvad VPN. I would like to connect to the clearnet following way: Me
- -> Tor -> VPN -> clearnet.

When setting up mullvad in their web page, I set the parameters for
download here https://mullvad.net/en/download/openvpn-config/ in a
following way:
- - All countries (so that I can change my exit country as needed)
- - Port -> TCP 443 (Tor doesn't use UDP, right?)
- - tick Use IP addresses

Using TCP 443 for the connection helps only if you are running the VPN
on top of Tor. With Tor on top of VPN, you're probably better off with UDP.

To set the Mullvad VPN AppVM, I followed this guide from micahflee
https://micahflee.com/2019/11/using-mullvad-in-qubes/ The AppVM with
mullvad is vpn-mullvad. All works fine and connects to the network.

How should I connect Me -> Tor -> VPN -> clearnet? Am I right with
this setup (I didn't launch it yet): anon-whonix -> sys-whonix ->
vpn-mullvad -> sys-firewall, or I should use different setup?

Whonix has a guide that examines the issues of combining Tor and a VPN.
However, I think its better as a 'what-if/why' guide than a Howto...

https://www.whonix.org/wiki/Tunnels/Connecting_to_a_VPN_before_Tor

Are there any other steps to follow to prevent leaks?

Yes.

The Qubes-vpn-support project is much easier to setup and should work
more smoothly, in addition to providing better protection against leaks:

https://github.com/tasket/Qubes-vpn-support

There is also a VPN setup guide on the Qubes doc page (this is the one
the Whonix page links to). FWIW, I wrote the scripts for both but the
idea for Qubes-vpn-support was to automate the setup and improve the
connection handling of Openvpn so re-connection doesn't take 5 minutes.
It also checks the firewall to make sure leak prevention is in place
before initiating connections.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Increase the size of disk image and root file system

2020-03-24 Thread Chris Laprise


On 3/23/20 4:07 AM, GD rub wrote:

Hi,

How can I increase the size of disk image and root file system whithout 
cutting off the branch on which we are sitting on (umount) ?


[R4.0] -> StandaloneVM -> settings -> increase system storage max size - OK

Unallocated free space (5 GB) at the end of xvda disk :

# fdisk -l
Disk /dev/xvda: *14 GiB*, 15032385536 bytes, 29360128 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xb607ef98

Device     Boot    Start      End  Sectors  Size Id Type
/dev/xvda1          2048 18946047 18944000 *9G* 83 Linux
/dev/xvda2      18946048 20969471  2023424  988M 82 Linux swap / Solaris


Have you tried the 'resize2fs' command?

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2ff61e95-9552-889a-ffe4-5d1f37ad5c00%40posteo.net.

Re: [qubes-users] No Match for argument qubes-template-whonix-ws-15-4.0.1-201910102356.noarch ?

2020-03-24 Thread Chris Laprise

On 3/23/20 7:23 AM, Stumpy wrote:

On 2020-03-22 13:24, Chris Laprise wrote:

On 3/20/20 10:08 PM, Stumpy wrote:
I'm trying to reinstall the whonix ws template but while seems to
find it it then says there is no match?

[zack@dom0 ~]$ sudo qubes-dom0-update --action=reinstall
qubes-template-whonix-ws-15
WARNING: Replacing a template will erase all files in template's
/home and /rw !

Template VM halted
Using sys-whonix as UpdateVM to download updates for Dom0; this may
take some time...
No Match for argument
qubes-template-whonix-ws-15-4.0.1-201910102356.noarch

Nothing to download

That means you have an older template package that was removed from
the Qubes servers, so it can't be reinstalled as the same version.

When that happens, you can use '--action=upgrade' instead and it
should grab the latest available version.

https://www.qubes-os.org/doc/reinstall-template/

Thank you for the suggestion, i tried upgrade instead of reinstall but
got the following:

[bob@dom0 ~]$ sudo qubes-dom0-update --action=upgrade
qubes-template-whonix-ws-15
WARNING: Replacing a template will erase all files in template's /home
and /rw !

Template VM halted
Using sys-whonix as UpdateVM to download updates for Dom0; this may take
some time...

No new updates available
Qubes OS Repository for Dom0
12 MB/s | 26 kB 00:00
Dependencies resolved.
Nothing to do.
Complete!

Then tried reinstall again just for the heck of it and still got the
same response.

I think this has something to do with the update VM (sys-whonix) being
based on Debian. The workaround would be to use the Manual method shown
at the above link.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] How can I recover my Qube'sVM if I cannot boot anymore ?

2020-03-24 Thread Chris Laprise


On 3/23/20 10:13 AM, Peter Funk wrote:

Dear Chris,

Chris Laprise schrieb am Sonntag, den 22.03.2020 um 13:17:
...

The perceived "mess" is actually rather organized, and has nothing
to do with LVM thin pools.

...
I beg your pardon for stealing this discussion thread to ask a somewhat
related question: Can you recommend some text for reading about how
the varying storage demands from the various VMs are handled in Qubes
OS internally for someone who wants to learn more about this?

Best regards, Peter Funk



I don't think its documented, but the relevant code should be here:

https://github.com/QubesOS/qubes-desktop-linux-manager/blob/3f080ae2c01150d75d91bfb39a9ee273b7b6de92/qui/tray/disk_space.py#L37

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0191c7ea-a63e-78ae-75a7-79cf4d3fa857%40posteo.net.

Re: [qubes-users] No Match for argument qubes-template-whonix-ws-15-4.0.1-201910102356.noarch ?

2020-03-22 Thread Chris Laprise


On 3/20/20 10:08 PM, Stumpy wrote:
I'm trying to reinstall the whonix ws template but while seems to find 
it it then says there is no match?



[zack@dom0 ~]$ sudo qubes-dom0-update --action=reinstall 
qubes-template-whonix-ws-15
WARNING: Replacing a template will erase all files in template's /home 
and /rw !

Template VM halted
Using sys-whonix as UpdateVM to download updates for Dom0; this may take 
some time...

No Match for argument qubes-template-whonix-ws-15-4.0.1-201910102356.noarch
Nothing to download


That means you have an older template package that was removed from the 
Qubes servers, so it can't be reinstalled as the same version.


When that happens, you can use '--action=upgrade' instead and it should 
grab the latest available version.


https://www.qubes-os.org/doc/reinstall-template/

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/90145bbb-feff-61a8-9cbe-65fc210da85a%40posteo.net.

Re: [qubes-users] How can I recover my Qube'sVM if I cannot boot anymore ?

2020-03-22 Thread Chris Laprise

On 3/22/20 7:11 AM, dhorf-hfref.4a288...@hashmail.org wrote:

On Sun, Mar 22, 2020 at 11:57:38AM +0100, haaber wrote:

Assuming you didn't make backups before the crash: You need to have a
running Qubes system to backup VMs the normal way.

Does that mean Chris, that in case of a disaster, there is no way to
backup your data "by hand" (booting a live linux, opening the luks ..)
because of a "thin pool" mess? That sounds in first hand like a strong
argument against the use of thin pools! As you know a lot about thin
pools, could you please comment on that, Chris? thx, Bernhard

thin pools are plain linux tech, nothing qubes specific.
and you can back them up in whatever way you want, from whatever
distro/system you want.
or not back them up at all, and simply attach the disk to some
other system.

it is not trivial to use the _qubes_ backup tooling outside
of a qubes system.
but besides that, they are just blockdevices with filesystems inside.

Right. Another way to phrase my advice is that the "vm*-private" volumes
are simply disk images and contain all the data for regular appVMs. For
templates and standalone VMs, the "vm*-root" volumes are also a part of
the VM's data. Backing these up can be pretty simple, since they are
block devices accessible from /dev/qubes_dom0 and you can use 'dd' or
'dd | gzip' or whatever. You could even use my backup tool (wyng).

The perceived "mess" is actually rather organized, and has nothing to do
with LVM thin pools. If you had installed Qubes with non-LVM storage,
you would still have separate disk image files for each VM. You can make
the volume list more readable with 'lvs | grep private' to filter out
non-private volumes.

Of course there is Qubes-specific metadata (i.e. the Settings dialog for
your VM) in /var/lib/qubes/qubes.xml and maybe firewall.xml files in the
subdirs there. But these should only matter if you changed VM settings
in the Settings dialog or via 'qvm-prefs' or 'qvm-firewall' commands,
and even then many settings like 'Memory' and 'Applications' are trivial.

Finally... It should be possible to write a recovery script for this
situation, which presents the user with a list of VMs to recover and
optionally allows you to recover the contents of /var/lib/qubes.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] How can I recover my Qube'sVM if I cannot boot anymore ?

2020-03-21 Thread Chris Laprise

On 3/21/20 9:09 PM, cacaosucre via qubes-users wrote:

Hello,

I cannot boot on Qubes anymore but I can access the file system. When I
mount my qubes partition, it give me a huge mess of small 2g partition
and bigger ones.

My goal is to reinstall qubes and I would like to restore my old VM with
the backup restoration and migration
<https://www.qubes-os.org/doc/backup-restore/> feature of qubes.

Is it possible and if so, which files should I look for ?

If not, what are my other options ?

( this is a clone the following reddit post :
https://www.reddit.com/r/Qubes/comments/fmjr98/how_can_i_recover_my_qubesvm_if_i_cannot_boot/
)

Assuming you didn't make backups before the crash: You need to have a
running Qubes system to backup VMs the normal way.

If you have room to spare on your disk, you may be able to install Qubes
in that space. At that point, you have some options after booting into
the fresh Qubes install. One is to define a Qubes storage pool that
points to the old Qubes partition, but I'm not 100% sure how Qubes will
react in that case.

Another way: In your new Qubes system, create VMs of the same name and
then copy the relevant 'vm*-private' volumes from your old partition/vg
into the current one using 'dd conv=sparse'. Repeat with any 'vm*-root'
volumes for templates or standalone VMs you want to bring over. Lastly,
this method does NOT bring over special VM settings, but if you had some
that were firewall configs you can copy those easily from
/var/lib/qubes/ on the old partition to the same path in the new dom0.
OTOH, if you didn't customize any VM settings then its not really an issue.

One other possibility: There is an unofficial 'Qubes Live' distro you
could use to boot into Qubes from USB stick or DVD. Maybe you could use
it to try the storage pool technique without having to do an install.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Obtaining genuine Qubos installer

2020-03-06 Thread Chris Laprise

On 3/5/20 1:45 PM, Mark Fernandes wrote:

On Thu, 5 Mar 2020 at 18:21, Chris Laprise <mailto:tas...@posteo.net>> wrote:

On 3/5/20 7:31 AM, Mark Fernandes wrote:
 > I want to get a genuine copy of Qubos, from here in the UK
(United Kingdom).
 >
 > The only way described on the Quebos website at present, appears
to be
 > to download the ISO.
 >
 > I have the classic security problem described on the website
 > <https://www.qubes-os.org/doc/install-security/>, where not having a
 > trust-worthy machine, means that I have a never-ending chain of
trust
 > issues for each machine that I use in the obtaining of the software.

Many of us work with a threat model that assumes at least some
computers
available by retail are not compromised "out of the box", or else if
compromised then not at the BIOS/UEFI firmware level. For this model,
verifying the Qubes ISO with gpg is acceptable.

Hello Chris,

I've only heard of gpg as a binary running over an operating system. Is 
it available as something you can run directly off boot-able media?

Gpg is usually available in live DVD or live USB distros. Its also 
incorporated into 'Heads', a firmware boot verification system that's 
compatible with Qubes.

In any case, you still need to ensure that gpg hasn't been compromised. 
If it has to run off an OS, that OS needs to have not been compromised. 
If you need to download gpg, the OS which you use for downloading gpg 
has to be not compromised. The website doesn't appear to address these 
issues. The security Qubes OS offers may be great. But getting from a 
position where you don't have Qubes OS at all, to having Qubes OS 
installed, appears to be a serious security concern.

There is a definite chicken-and-egg aspect to this issue. That's bc what 
we're dealing with at some level is a failure of Computer Science and 
industry to advance computer security in an objective and democratic 
manner. It is mostly a VC culture, even in university settings, and 
selling bling to the masses now sets the tone for everything else. 
That's why things that would have been shocking (like shutting Linux out 
of recent TCG updates & making devices that can't really be 
switched-off) in the 90s-mid 2000s are now commonplace, and the 
"victims" like Linux Foundation don't care anymore bc they are comprised 
of megacorps with staff who go home to their iDevices and surveillance 
tchotskies.

So computing culture became a worst-case scenario and projects like 
Qubes are back-eddies in its wake. Your/our problem can't be solved in a 
fundamental way without PC-type hardware that is open source. I think 
Qubes has expressed a willingness to help make that happen, since they 
are open to the idea of porting Qubes to OpenPOWER architecture.

In the meantime, we have to use hedges and stop-gaps. One is to verify 
ROM (e.g. DVD) media on multiple systems, just as one would try to 
verify a single gpg key from multiple pathways. Another is to use Qubes, 
which reduces the number of components you have to trust down to a 
minimum. Also consider what makes a good hardware distributor. Yet 
another is to realize the biggest adversaries are not omnipotent and 
can't control everything simultaneously; i.e. do random spot checks, 
maintain your sanity.

Finally, we need to be able to question things in philosophical terms 
because that is the basis of relatable information in modernity. If we 
only think about the mechanics, then we remain locked onto the same path 
of transistorized irrationality that has begun to weigh on you. For 
example, a philosophical approach to your question should recognize 
early that its a quandary (or "turtles all the way down") if we keep 
accepting the old parameters (i.e. what industry wants to keep selling 
us); there are even situations when its illogical to use computers (even 
though the above mentioned failed culture still insists its necessary to 
do so).

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ac6a1867-14e1-eec3-c65c-20c82b500925%40posteo.net.

Re: [qubes-users] ANN: Wyng beta, a fast incremental backup tool

2020-03-06 Thread Chris Laprise


On 2/25/20 3:02 PM, Chris Laprise wrote:

Hello Qubers,

'Wyng' is a backup program I've been working on for a while that can 
quickly backup "thin LVM" storage, the kind Qubes uses by default:



Version v0.2beta5 has been released! It includes minor bug fixes and an 
option to use bzip2 compression.


https://github.com/tasket/wyng-backup

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7fdcc232-c6c4-721a-014e-68a5534ecd9d%40posteo.net.

Re: [qubes-users] Obtaining genuine Qubos installer

2020-03-05 Thread Chris Laprise

On 3/5/20 7:31 AM, Mark Fernandes wrote:

I want to get a genuine copy of Qubos, from here in the UK (United Kingdom).

The only way described on the Quebos website at present, appears to be
to download the ISO.

I have the classic security problem described on the website
<https://www.qubes-os.org/doc/install-security/>, where not having a
trust-worthy machine, means that I have a never-ending chain of trust
issues for each machine that I use in the obtaining of the software.

Many of us work with a threat model that assumes at least some computers
available by retail are not compromised "out of the box", or else if
compromised then not at the BIOS/UEFI firmware level. For this model,
verifying the Qubes ISO with gpg is acceptable.

You can also qualify the model somewhat and say that an attacker cannot
successfully infect all of your (hopefully diverse) computers, so that
makes checking a signature on several different computers a form of
reassurance.

OTOH, you may have decided to discard the above threat model because of
some intent or capability known to you. In that case, I think the Qubes
community has only two answers: Find a trusted service that can flash a
known good/uncompromised firmware suite onto one of your machines, or
find a system vendor like Insurgo or NitroKey that sell re-flashed
systems and uses anti-interception measures (like tamper-evident
packaging and signatures) in addition to offering Qubes pre-installed.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] How Qubes / and /home/user mounting as different disks works?

2020-03-04 Thread Chris Laprise

On 3/4/20 10:19 PM, Guerlan wrote:

I'm curious about how Qubes does this:

mounts /home/user and other user-related directories from disk B
mounts the / from disk A, but when VM shutdowns, disk is discarded

I'm curious on how it mounts disk A. I don't think it makes a copy of
disk A to a temporary disk A', because that'd move lots of gigabytes on
every VM startup.
However, it also can't mount disk A as read-only, because I can write to
it, it just gets discarded.
How does this work? And is it exclusive of Xen? Couldn't I do the same
in KVM? It's very useful

As to whether this can be done with KVM, yes you can. But Linux vendors
are very confused about which copy-on-write technologies to promote so
they tend to push the least common denominator, which is partitions or
VMDK files. OTOH, Qubes decided copy-on-write storage was too useful to
ignore and integrated it into VM management functions.

You could use LVM thin pools with KVM, but IIRC you would have to
automate snapshot handling yourself or find an additional package to do
it (if such exists).

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] How Qubes / and /home/user mounting as different disks works?

2020-03-04 Thread Chris Laprise


On 3/4/20 10:19 PM, Guerlan wrote:

I'm curious about how Qubes does this:

mounts /home/user and other user-related directories from disk B
mounts the / from disk A, but when VM shutdowns, disk is discarded

I'm curious on how it mounts disk A. I don't think it makes a copy of 
disk A to a temporary disk A', because that'd move lots of gigabytes on 
every VM startup.
However, it also can't mount disk A as read-only, because I can write to 
it, it just gets discarded.
How does this work? And is it exclusive of Xen? Couldn't I do the same 
in KVM? It's very useful


Qubes uses copy-on-write snapshots to achieve this. With a default 
install, that means an LVM "thin pool" holds all of the VM volumes, and 
when a VM starts a snapshot is taken of both "disk A" and "disk B" (the 
*-root and *-private volumes). With a normal AppVM (base on a template) 
the root and private volumes are treated differently on shutdown: Root 
snapshot is discarded, and private is rotated to replace the persistent 
copy (what appears in the VM as /rw and /home).


A similar snapshot routine is used if you installed Qubes with Btrfs 
format instead of LVM (Btrfs is a copy-on-write filesystem).


Copy-on-write provides the ability to create new representations or 
snapshots of an existing file or volume, instantly. Snapshotting is like 
copying, but using a collection of pointers instead of the data itself. 
Thus, when a new snapshot is changed, the system only needs to write 
some new blocks in a different location and replace some pointers in the 
snapshot's metadata to point to the new location. This all can save a 
lot of time and disk space.


--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/809ee2c9-e860-92cc-4f68-8d965c9eda26%40posteo.net.

Re: [qubes-users] ANN: Wyng beta, a fast incremental backup tool

2020-03-03 Thread Chris Laprise


On 3/3/20 4:03 PM, Eva Star wrote:
Thank you, sounds good! But my main problem and I guess many other Qubes 
users that we don't know what exactly what is LVM and pools :-)


This seems like a Qubes-oriented Howto page could help. It could tell 
the user to check the disk space widget in the systray (if it says "LVM" 
then you're using it). But also, thin LVM is the Qubes default so its 
one of those "if you have to ask, then you've got it" things. :)


Keep in mind that its a new program that currently only works from the 
command line, so its not at a point where its useful to everybody. But 
that could change, maybe even this year.


--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/90eac723-9759-13ce-b83a-c541e175290d%40posteo.net.

Re: [qubes-users] ANN: Wyng beta, a fast incremental backup tool

2020-03-03 Thread Chris Laprise


A gist for extracting volumes with a shell script was just posted here:

https://gist.github.com/tasket/48b30124990e1c78c80c8716f819430a

Its about 80 lines.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0d2575fb-fb8a-fb27-2d81-1c6a30ef2827%40posteo.net.

Re: [qubes-users] Manual VPN installation issues

2020-03-03 Thread Chris Laprise


On 3/3/20 7:36 AM, tetrahe...@danwin1210.me wrote:

On Sun, Feb 16, 2020 at 10:50:55AM -0500, Chris Laprise wrote:
If the process seems too complicated, you can try my VPN support tool, 
which automates most of the steps (you would download the config files 
from the second link to use with this):


https://github.com/tasket/Qubes-vpn-support

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886


Unfortunately the PGP key in your signature doesn't match the GPG key 
used to sign your Git commits for Qubes-vpn-support:


gpg: Signature made Fri 05 Jul 2019 05:15:24 AM UTC
gpg:    using RSA key 0573D1F63412AF043C47B8C8448568C8B281C952

Assuming nothing's terribly wrong, it may be worth posting your public 
key fingerprint used for code signing somewhere!


The B281C952 key is a subkey of F07F1886; Import both and the former 
will be listed under the latter.


--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8b803eec-9505-8269-cdca-482bc5d9a954%40posteo.net.

Re: [qubes-users] ParrotOS template

2020-03-01 Thread Chris Laprise


On 3/1/20 10:20 AM, unman wrote:

If anyone wants to try a Parrot template I've put one up at
https://qubes.3isec.org/Templates
The template is signed with my Qubes signing key - check it with `rpm -K`

The instructions on www.parrotsec.org for creating a template by
upgrading from Debian stable are out of date - I'll fix that.
This package is built with qubes-builder.

bullseye-parrot template is a beast - you'll need to make sure that your
download qube has plenty of space for the 3.8GB download.
It *does* have the full set of Parrot tools.

There's some stuff (parrot-kernel) that isn't there at the moment. I'll
fix that. The tools work fine as it is.


Interesting...

As an aside, is there any work being done to enable Debian's default 
AppArmor setting "out of the box"?


--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3c861243-6b91-19f9-37f5-cf174234668f%40posteo.net.

Re: [qubes-users] What happened to "paranoid mode"?

2020-03-01 Thread Chris Laprise


On 3/1/20 4:00 PM, Eva Star wrote:
Don't forget about instructions for dummies how to use it with Qubes, 
please!!!


A Howto doc for backing up Qubes with Wyng is on the way. Here is a 
Linux Howto referencing the new name & URL:


https://github.com/tasket/wyng-backup/wiki/Making-incredibly-fast-LVM-backups-with-Wyng

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/10bef8c0-2fa7-f428-dfc3-0da906dea589%40posteo.net.

Re: [qubes-users] MAC Address Anonymization and NetworkManager Compatibility

2020-02-28 Thread Chris Laprise


On 2/28/20 11:39 AM, 'sf0IqXUyNLTP22nB3Lpt' via qubes-users wrote:
Thanks for your help! This script is very interesting. What I want to 
ask is how the tasket script compares to the setup with cli and iptables 
in the qubes vpn documentation <https://www.qubes-os.org/doc/vpn/>. I 
tried to do the tasket but because I had trouble I did the cli and 
iptables instead. If tasket is better, surely I will use your script.


If you mean Qubes-vpn-support...

https://github.com/tasket/Qubes-vpn-support

...then its better than the vpn doc in that:

1. Setup is automated; no file editing needed

2. Double-checks the firewall at startup

3. Improves the re-connection behavior of openvpn (doesn't wait very 
long periods after a connection is lost)


What is the problem you were having?

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/4294fa48-3949-f58c-3fb9-26fb8c6efabd%40posteo.net.

Re: [qubes-users] ANN: Wyng beta, a fast incremental backup tool

2020-02-27 Thread Chris Laprise


On 2/26/20 7:38 AM, Bernhard wrote:

'Wyng' is a backup program I've been working on for a while that can
quickly backup "thin LVM" storage, the kind Qubes uses by default:

Link  https://github.com/tasket/wyng-backup  


I like your other scripts, so I had a look. That seems so damn complex
at first glance! Maybe you want to improve your "readme" by some simple
examples of "mise en oeuvre": assume I have a qubes machine and a
backup-harddrive in my hand. What would be the steps to do?  Can you
stock your backup in a luks-container?  Since you use "streams" can
(can't?) there be a -whatever cipher- in the middle of your stream
treatment?
I did not get these informations from your text within reasonable time.
Maybe I am stupid, but maybe I am not alone with that :)



The howto link has been changed to:

https://github.com/tasket/wyng-backup/wiki/Making-incredibly-fast-LVM-backups-with-Wyng

The link to the general wiki is here:

https://github.com/tasket/wyng-backup/wiki

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e9b33e34-da24-14bb-23e0-35a0e27cd310%40posteo.net.

Re: [qubes-users] Re: Relative comparison of Qubes OS, and its multiple VM's versus Boxes.

2020-02-26 Thread Chris Laprise




I should have also linked this, which is a guide for devices:

https://www.qubes-os.org/doc/device-handling-security/#usb-security

Finally, reading the ITL blog from 2010 onward provides a lot of Qubes 
insight:


https://blog.invisiblethings.org/

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c983babf-5e28-e7a8-9a93-9ac1a4de5258%40posteo.net.

Re: [qubes-users] Re: Relative comparison of Qubes OS, and its multiple VM's versus Boxes.

2020-02-26 Thread Chris Laprise

On 2/26/20 2:24 PM, brendan.h...@gmail.com wrote:

On Wednesday, February 26, 2020 at 12:18:48 PM UTC, ggg...@gmail.com wrote:

Boxes being the Sandboxing software available in Linux. It is my
hunch, that the VM's are taking advantage of some hardware feature
that insulates them that might be a security hole for Boxes. I dunno?

Background: Boxes is simply a nice front end for KVM and QEMU, which is
what most Linux virtualization solutions utilize.

Reasons that Qubes project initially chose Xen over KVM+QEMU (probably
better explained on the Qubes website):
1. The hypervisor code baseis substantially smaller in the Xen case.
Smaller generally means less security issues.

2. Xen came with better suited vt-d/IOMMU support at the time.
3. When parts of qemu are needed for certain virtualization scenarios,
Xen supports sandboxing qemu into stub domains.
4. QEMU has been historically problematic when it comes to security
issues, at least relative to Xen or even Xen w/ qemu in a stub domain.

Don't forget all the Qubes bits that make VMs work in concert: qrexec,
vchan, etc. These form a specially hardened VM management system. The
reason why Qubes Whonix exists, for example, is that other hypervisor
OSes don't have this level of security.

Links on the subject:

https://www.qubes-os.org/faq/#how-does-qubes-os-compare-to-running-vms-in-a-conventional-os

https://www.qubes-os.org/doc/security-critical-code/

Also, as I have not gotten a computer to run Qubes OS, I notice that
the App VM seem to be loading a full featured version of a Linux
OS. I am guessing that in reality you guys are using a smallish
Limited version of a Linux Distro.

Generally standard fedora and standard debian come as VM templates under
Qubes, yes. With caveats, Qubes also provides slimmer versions of the
template distros as well as optional downloads.

I was expecting to see some advice about how to uninstall the module
that runs the camera, and the microphone. I know I rarely use
them, so it would seem like a good idea. OR I guess, it is left to
the individual with the individual distro.

Assuming your camera is USB based (generally the case, even for internal
camera devices).

Generally, the default installation:
1. Hides all USB devices from dom0, making them unusable.
2. Puts all USB devices into device sandbox called sys-usb (this part is
optional, but useful if you want USB devices to work).
Generally, you can use command line or the devices widget to assign the
devices, including the microphone, to a VM if you choose (some
limitations on usbip support being broken for certain device types).

I was looking for a list of; If you want to be secure, "Never do
this." Another check list, like a pilot uses before taking off,
that is what the proper procedure is for some of the types of things
one might routinely do with Qubes OS.

This would vary by threat model. Without a threat model, a general
checklist would be impossible to provide.

Yes. Although the security faq linked above and additional security
guides exist here:

https://www.qubes-os.org/doc/#security-guides

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] ANN: Wyng beta, a fast incremental backup tool

2020-02-26 Thread Chris Laprise

On 2/26/20 7:38 AM, Bernhard wrote:

'Wyng' is a backup program I've been working on for a while that can
quickly backup "thin LVM" storage, the kind Qubes uses by default:

Link https://github.com/tasket/wyng-backup

I like your other scripts, so I had a look. That seems so damn complex
at first glance! Maybe you want to improve your "readme" by some simple
examples of "mise en oeuvre": assume I have a qubes machine and a
backup-harddrive in my hand. What would be the steps to do? Can you
stock your backup in a luks-container? Since you use "streams" can
(can't?) there be a -whatever cipher- in the middle of your stream
treatment?
I did not get these informations from your text within reasonable time.
Maybe I am stupid, but maybe I am not alone with that :)

Under Requirements & Setup there is a brief example of initializing a
Wyng archive and adding a volume.

I don't yet have a walk through specifically for Qubes, but I have a
draft howto that is geared toward a regular Linux system:

https://github.com/tasket/wyng-backup/wiki/Using-Wyng-for-incredibly-fast-incremental-backups-from-LVM

Deciding how to use it in dom0 depends on several factors, such as
whether you need to add encryption to the archive (Wyng v0.2 does not
encrypt data). The Readme suggests a general method for Qubes that sets
up a net-accessible encrypted container, but you can also simply mount a
LUKS volume from sys-usb local storage (i.e. attach a sys-usb partition
to dom0, then in dom0 format/use it as a LUKS volume).

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] MAC Address Anonymization and NetworkManager Compatibility

2020-02-26 Thread Chris Laprise

On 2/26/20 1:12 AM, 'sf0IqXUyNLTP22nB3Lpt' via qubes-users wrote:
I have recently set up a vpn gateway qube according to the instructions
as listed here <https://www.qubes-os.org/doc/vpn/>. I have now gone to
set up the MAC Anonymization and have a question and a problem both.

Firstly the linked page wrote specifically not to include the network
manager. But at the same time the page on anonymizing the MAC address
says that you must begin by installing the network manager. Is this safe
to do?

There are two main setup options in that VPN doc: The first one tells
you to enable Network Manager in the VPN VM. The second one is
script-based and tells you not to enable NM in the VPN VM.

The "don't include NM" part refers only to setting up the VPN VM, which
is separate from sys-net. In other words, the VPN instructions don't
affect sys-net, so you can keep using NM (in sys-net) after you setup
your VPN.

The second is that I only have NetworkManager 1.16.4. When I try to
update or reinstall with sudo dnf install NetworkManager I get

'
Last metadata expiration check: 0:21:07 ago on Wed Feb 26 00:45:32 2020.
Package NetworkManager-1:1.16.4-1.fc30.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!

Nothing wrong there. 1.16 is a much later version than the minimum 1.4.2
listed in the doc.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Error attemtping to reinstall Debian 10 templateVM

2020-02-25 Thread Chris Laprise


On 2/25/20 4:12 PM, donov...@unseen.is wrote:
Specifically, I issue the "|$ sudo qubes-dom0-update 
qubes-template-debian-10"and I get red lettering and "error could not 
delete old database at 
/var/lib/qubes/dom0-updates/home/user/.rpmold." where  changes 
if I repeat the command and that error appears. Other times I get red 
lettering without that specific error and (via sys-whonix) it downloads 
the info it needs and then I get "No Match for argument 
qubes-template-debian-10 nothing to download".

|
|
|
|If I try "|$ sudo qubes-dom0-update qubes-template-debian-9"||- same 
thing "No Match for argument qubes-template-debian-9 nothing to download".|


Hi donovan,

Those qubes-dom0-update commands should work. However, dnf occasionally 
forgets about packages bc of problems in its cache. To clear dnf caches, 
run this in dom0:


sudo qubes-dom0-update --action="clean all"

Then re-run your template install:

sudo qubes-dom0-update qubes-template-debian-10

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1f300cbb-9773-bc8d-1a9c-47b2e6f6b708%40posteo.net.

[qubes-users] ANN: Wyng beta, a fast incremental backup tool

2020-02-25 Thread Chris Laprise

Hello Qubers,

'Wyng' is a backup program I've been working on for a while that can
quickly backup "thin LVM" storage, the kind Qubes uses by default:

Link -
https://github.com/tasket/wyng-backup

Some ideas behind Wyng are:

* Backups shouldn't require re-scanning all data to find changes.

* Ability to push new backups to an archive indefinitely on a frequent
basis.

* Low exposure to risk for admin VMs like dom0.

* No special matching filesystem (Btrfs, ZFS, LVM, etc.) needed to store
the backup copy.

The intent is to enable similar use cases as OS X Time Machine does
(frequent, convenient backups) but for Linux and Qubes.

Wyng runs in the admin VM and deals with data volumes such as
"vm-personal-private" or "vm-fedora-30-root" at the block level. I
should point out that version 0.2 does not have a concept of backing up
and restoring whole Qubes VMs, as it doesn't process VM settings. If you
do not have many specific custom VM settings, this shouldn't be an
obstacle. However, Wyng does have special Qubes transport modes that
allow backing up data from dom0 to wherever via a VM.

The README at the above link has more info about Wyng's capabilities,
command line examples and the current beta testing status. If you have
questions, feel free to post here.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] How to set the screensaver to either show keyboard language or not to lock screen ?

2020-02-18 Thread Chris Laprise

On 2/18/20 10:05 AM, unman wrote:

On Tue, Feb 18, 2020 at 02:07:56PM +0100, A E wrote:

I have tried to install KDE in dom0 by using this command:

sudo qubes-dom0-update @kde-desktop-qubes

Then the terminal returned an error on the first line: As far as I remember
(I can only see the last 1.000 lines in the terminal), it returned
something like it couldn???t find or edit a specific xml file.

And then the installation process continued and got completed. I then
restarted the pc, and the only change I can see, is that there appear some
more program icons under Qubes menu -> System Tools.

For example ???KDE System Settings???.

So as the desktop environment seems to look almost as before, I guess the
installation haven???t run properly, or am I wrong... ?

But in either case, I would like to know what I should do now.

Log out.
At login screen, find the chooser that allows you to select KDE.
Select KDE
Log in.

Yes, that doc page should also mention something about choosing KDE or
removing XFCE. Now I remember I setup /etc/sddm.conf with the following
which takes me directly to KDE:

[Autologin]
User=user
Session=plasma.desktop

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Wireguard on Debian 10 from Qubes-vpn-support

2020-02-17 Thread Chris Laprise


On 2/17/20 6:09 PM, Daniil Travnikov wrote:
I am looking right now on this guide: 
https://github.com/tasket/Qubes-vpn-support/wiki/Wireguard-VPN-connections-in-Qubes-OS


So have a question: is it possible to do this on Debian 10 ?


Debian 10 now has wireguard packages in 'testing', not just 'unstable'. 
So that is different.


TBH the one time I remember testing this on Debian 10, I did something 
like this:


1. Install the 'kernel-latest-qubes-vm' package in dom0. This will 
provide a 5.x kernel with wireguard module built-in. Set your VPN VM to 
use this kernel.


2. Install only the 'wireguard-tools' package (from testing) in Debian 
10. Otherwise, there may be a conflict between the built-in and DKMS 
modules.


3. Given the above, it may now be possible to skip using HVM mode 
altogether.


--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9986fe3c-f3e8-f336-b8ea-2b025077b03a%40posteo.net.

Re: [qubes-users] How to set the screensaver to either show keyboard language or not to lock screen ?

2020-02-16 Thread Chris Laprise

On 2/16/20 10:32 AM, A E wrote:
søn. 16. feb. 2020 kl. 16.18 skrev Chris Laprise <mailto:tas...@posteo.net>>:

On 2/15/20 10:20 AM, A E wrote:
> If it isn’t possible to change the settings of the screensaver that
> Qubes OS is actually using, then I would like to hear how I can
either
> disable or delete it in Qubes ?

The setting to disable screensaver does work for KDE in dom0. Switching
to KDE has fixed a number of GUI problems for me.

--
Chris Laprise, tas...@posteo.net <mailto:tas...@posteo.net>

https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Okay, how do I switch to KDE ?

And what are the cons with switching to KDE... ?

I shall probably mention that I’m a Linux and Qubes newbie.

This guide only requires a few steps in the dom0 terminal:

https://www.qubes-os.org/doc/kde/

Make sure you also do the lightdm->sddm changes because lightdm is where
some of the problems originate.

The downsides to KDE are that it uses about 200MB more RAM (IMO, very
much worth it) and the Network Manager applet icon appears blank (its
still easy to use once you know its there in the systray).

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Reattaching firewall vm to untrusted vm without killing the untrusted vm.

2020-02-16 Thread Chris Laprise

On 2/16/20 12:34 PM, billol...@gmail.com wrote:

Qubes folk,

So, I have a debian-based untrusted vm that is attached to a mullvad
vpn through Sweden; the mullvad vpn gets its networking from sys-
firewall (i.e. sys-net -> sys-firewall -> mullvad-vpn -> untrusted vm.

I have another "local" vm that is directly attached to sys-firewall
(i.e sys-net -> sys-firewall -> local vm). Nothing other than sys-usb
starts automatically on boot.

The mullvad-vpn is a standalone vm, set up per the Qubes mullvad
instructions, while the untrusted and local vms are based on the
debian-10 template.

I'm running Qubes release 4.0.2.

When I change locations without rebooting the box and switch wireless
networks, the sys-net, sys-firewall, and local vms automatically
update. Unfortunately, the mullvad-vpn vm does *not* update
automatically. In order to get networking on the untrusted vm, I have
to kill it *and* the mullvad-vpn vm, and restart them -- which means I
have to kill any running apps, which is a pain when I'm doing big image
tasks in the background.

Is there a way to tell a standaloneVM like my mullvad-vm to either
update automatically, or a command to get it to re-set its networking
to a changed sys-firewall vm?

This refusal to change in the mullvad vm could be due to a common
openvpn behavior where it tries to revive the current connection over a
5 minute period. This is good for a VPN server, but for a PC it will
look like it is unable to re-connect.

The Qubes-VPN-support tool sets a max openvpn timeout of 40 seconds; on
average it will re-connect in about 20 sec. after losing the old connection:

https://github.com/tasket/Qubes-vpn-support

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Disk image backup - dd / partclone / clonezilla?

2020-02-16 Thread Chris Laprise

On 2/15/20 6:39 AM, General wrote:

Many thanks for your helpful reply Chris.

You also have to configure Qubes not to disable USB at boot time if

your boot drive is USB.

Ah, this is why it was not working for me! I shall try installing the OS
directly onto the USB drive and then make the clones from there. It
occurs that the USB isolation in Qubes is valuable and therefore running
a USB boot drive may not be sensible.

If backup speed is the main issue, take a look at Wyng

I have installed this in Dom0 and made a backup, also using your helpful
instruction:

file: /lib/systemd/system-shutdown/10_root_snapshot.shutdown
```
#!/bin/sh
/usr/sbin/lvremove --noudevsync --force -An qubes_dom0/root-autosnap || true
/usr/sbin/lvcreate --noudevsync --ignoremonitoring -An -kn -pr -s
qubes_dom0/root -n root-autosnap
```

to enable snapshots of the root volume.

Incremental backups are indeed very fast and this is what I was looking
for. I need to build another box to run a test restore procedure.
Perhaps this could be scripted now.

Thanks again.

Glad I could help!

FWIW, the root-autosnap is not strictly necessary since Linux does allow
snapshots to be taken of live LVs (e.g. you could point wyng to 'root'
and it would make its own snapshot of 'root' while it is live) but I
guess the above method is a bit safer.

Since Wyng doesn't yet handle Qubes config for individual VMs, restoring
a full Qubes system state with Wyng would require at least restoring
Qubes configuration (such as qubes.xml and firewall.xml) but that is
covered if you backup/restore the 'root' volume. OTOH, if your Qubes VM
settings are default or you made notes about them, then the xml files
aren't needed and you can restore the data volumes into freshly created
VMs (e.g. after reinstalling Qubes).

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Manual VPN installation issues

2020-02-16 Thread Chris Laprise

On 2/14/20 6:40 PM, 'e.sparks15' via qubes-users wrote:

Hello,
Sorry that this is a bit long, but I've been working on the problem for
awhile, and even though I've tried to give the most succinct explanation
I can of what I've tried so far, it still takes up some space.

I'm attempting to install expressvpn in a qube designated specifically
for that purpose. When I try to install it manually as per the
instructions in step two of the Qubes VPN documentation
<https://github.com/tasket/Qubes-vpn-support>, but the config files I
can get from expressvpn don't seem to be in that format. I tried using
their manual config process instead, but it's for ubuntu, and since I'm
a total linux newb I wasn't able to figure out how to convert it.

I did get as far with express' config as to get the config files in the
right place so that I had a vpn connection listed in network manager but
it can't connect, probably because when i tried 'sudo dnf-install
network-manager-openvpn-gnome' it always said that
network-manager-openvpn-gnome was not a valid target. I then contacted
expressvpn's tech support and they asked me to reboot and try again.
When I did, I found that everything had disappeared. I found some stuff
online about a bug on Fedora 24 with non-persistence, but that was
awhile ago and it doesn't seem to apply.

That sounds like you installed to an AppVM instead of a template; that
can make something you installed disappear. In Qubes, you would go into
the template to have an app installation persist, but for user data to
persist you would add it to an AppVM.

There are two things I'll add that might be helpful to people smarter
than me. First, I've been getting the following error on startup since I
last performed upgrades:

Also, I haven't been able to perform any upgrades since then.

And second, it seems like there are a couple of different places that
talk about vpn setup. The documentation above, expressvpn's page, and
more Qubes documentation <https://www.qubes-os.org/doc/vpn/>. I think
I've kept them all separate and not done myself in by combining multiple
methods, but at this point I'm not sure.

Thanks so much for taking the time to read! I greatly appreciate it, and
if you can think of anything I should try, I'd greatly appreciate you
letting me know that, as well!

There are two expressvpn links you should look at, which correspond to
the two different configuration methods you can choose from in the Qubes
vpn doc. The first is using Network Manager, and the second is for using
shell scripts:

https://www.expressvpn.com/support/vpn-setup/manual-config-for-linux-ubuntu-with-openvpn/

https://www.expressvpn.com/support/vpn-setup/manual-config-for-linux-with-openvpn/#download

If the process seems too complicated, you can try my VPN support tool,
which automates most of the steps (you would download the config files
from the second link to use with this):

https://github.com/tasket/Qubes-vpn-support

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] How to set the screensaver to either show keyboard language or not to lock screen ?

2020-02-16 Thread Chris Laprise


On 2/15/20 10:20 AM, A E wrote:
If it isn’t possible to change the settings of the screensaver that 
Qubes OS is actually using, then I would like to hear how I can either 
disable or delete it in Qubes ?


The setting to disable screensaver does work for KDE in dom0. Switching 
to KDE has fixed a number of GUI problems for me.


--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ccbf8322-a585-738b-560d-6a957f0e2e1e%40posteo.net.

Re: [qubes-users] Scary Systemd Security Report

2020-02-13 Thread Chris Laprise

On 2/13/20 7:04 PM, unman wrote:

On Thu, Feb 13, 2020 at 10:38:33AM +0100, Bernhard wrote:

Also, I see that you have many services that need not be there - some
of these will be disabled by Qubes- some you do not need in every qube
(cups-browsed, exim4, tinyproxy etc).

how do get rid of them? exim for example looks to me like a virus. I
found no way to uninstall it without destroying debian ... the trick is
maybe to keep them, but disabled? Cheers, Bernhard

I could be wrong but I don't think that tool takes any notice of the
*state* of the service, which is why I suggested that op should actually
dig in to the results.
Many of these services can be disabled - I prefer to mask or remove them
all together.
A reasonable alternative would be to start with a micro template and
only add the services/tools that you need.

As far as exim is concerned you should be able to remove it quite
easily.
exim is "recommended" by cron, but can be removed without breaking the
system. If you use a tool like aptitude it becomes easy to see and
overcome dependencies when removing packages.

That's odd. I use a regular debian-10 template for most things and
exim4* removal only takes out 2 other exim packages.

Bernhard should look into that; it would be great if this discussion
prompted the detection and removal of an actual malware.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Scary Systemd Security Report

2020-02-13 Thread Chris Laprise

On 2/12/20 7:27 AM, Claudia wrote:

I'm not sure if you'll agree, but my conclusion from this experiment is
that the Qubes Team have some work to do in hardening Qubes? Like you
say,"I see that you have many services that need not be there"; so my
question is, why are they present in a vanilla version of Qubes?

My impression of the official Qubes developers' stance on this is "security by
isolation," i.e. Xen is the only component they actually consider secure. This is
the rationale for passwordless sudo for example. In practice, I can agree, it's difficult
enough to develop and maintain an OS as sophisticated as Qubes in the first place, let
alone if they had to also harden guest OSes at various levels. In principle, I say fair
enough, I suppose it's not really Qubes' concern what goes on within VMs. Qubes just
polices the border.

It does present an interesting angle for hardening (there *always* is
another one, isn't there?).

You might be interested in Chris's Qubes hardening tools, however I don't know
it uses the systemd security features at all so it may not improve systemd's
report.

Qubes-VM-hardening probably wouldn't improve the report. The former is
mainly about restoring the guest's normal permissions-based security,
and helping ensure the startup state is uncompromised.

The analysis appears to be a measurement of a service's level of
sandboxing, according the the man page. It seems to look for
capabilities management of some kind(s). An example it gives is that a
service with the ability to mount/unmount volumes may be labeled UNSAFE.
This would imply that most of a system's services will never attain an
OK rating. So I think we're looking at another one of systemd's immature
pilots. It may even be a tool for scaring gratis CentOS/Fedora users
into purchasing RHEL (yes, my usual uncharitable assessment of Red Hat),
since systemd originates from Fedora/RHEL.

When I see stuff like this, I also ask whether the authors make any
distinctions about things like 'guardian' components... Does a
crypto-based verification tool or something doing little more than toss
data blocks from one port to another deserve the same steep (even
hyperbolic) grade scale that, say, CUPS or something even more complex
and less security-minded gets?

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Re: [qubes-users] Encrypt disk after installation

2020-02-13 Thread Chris Laprise

On 2/13/20 1:30 AM, 'ukernel' via qubes-users wrote:
For some reason despite the fact that during installation I selected the
encryption checkbox and set a password but the partition where I
installed Qubes OS was not encrypted. I found a command to encrypt on
the same page of Qubes OS however it says that it overwrite all the
information. I need to know how to encrypt my disk without reinstalling
everything.

Could you help me please?

cryptsetup -v --hash sha512 --cipher aes-xts-plain64 --key-size 512
--use-random --iter-time 1 --verify-passphrase luksFormat /dev/sda2

https://www.qubes-os.org/doc/custom-install/

Those are not instructions for encrypting after installation, but before
before installation.

Overall, the best approach is probably to backup your data and
re-install Qubes. If you think the installer isn't encrypting your
custom configuration due to a bug, then you can follow the
custom-install example you linked to just before install (I'm pretty
sure that doc exists bc other users encountered the same problem you did).

In-place conversion to LUKS encryption is rare and not supported by LUKS
itself, however a tool called 'luksipc' exists to do this. However I
don't think it works with LVM which is what Qubes uses for storage.

Another method requires allocating an unused partition, setting it up
with cryptsetup and LVM, then copying from old volumes to new and
adjusting the boot parameters to use the new setup. The following is
*loosely* how it might be done, although it does not setup a thin pool
for LVM so you would need to combine it with instructions from step 5 of
the Qubes custom-install doc...

https://askubuntu.com/questions/366749/enable-disk-encryption-after-installation/1107295#1107295

Its rather complicated so I suggest re-installing instead.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 1144 matches

Mail list logo