from:"Chris"


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?


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

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?


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

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

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


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

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

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


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

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 ?

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 ?

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


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

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

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