from:"fiftyfourthparallel"

Hi Dominique,

Thanks for the reply. So I take it you chose Mirage because a unikernel 
firewall has a smaller attack surface compared to full-blown Linux? 

I'm a newbie, so I'm not even sure if these are IDS/IPS, but I'm thinking 
of installing the tried-and-true trio of rkhunter, lynis, chkrootkit.

I see the point in changing your mac address (already did it myself), but 
why the hostname as well? Since it's not covered in that link, did you just 
edit the config files of the template?


On Wednesday, 10 June 2020 00:26:01 UTC+8, Dominique wrote:
>
> Hi,
>
> First step for me was to install the minimal template and use them instead 
> of the complete template for service qubes (sys-net, sys-USB and 
> sys-firewall). Information on minimal template can be found here: 
> https://www.qubes-os.org/doc/templates/minimal/
>
> Second step for me was building and using the mirage firewall instead of 
> sys-firewall. Information on mirage can be found here: 
> https://github.com/mirage/qubes-mirage-firewall/
>
> Third step for me was random mac address and hostname. 
> https://www.qubes-os.org/doc/anonymizing-your-mac-address/
>
> That are things that I do on all my qubes laptop installation. After that, 
> you can play with firewall rules, apparmor and other things.
>
> I would love to see a way to add IDS/IPS in qubes easily but did not have 
> time to even check if someone did try to add IDS/IPS
>
> Have fun!
>
> Dominique
>
> On Tuesday, June 9, 2020 at 11:26:22 AM UTC-4, fiftyfour...@gmail.com 
> wrote:
>>
>> Hi all,
>>
>> I took a break from setting up my Qubes OS machine and now I'm looking to 
>> finish the job and actually settle in. I am familiar with the overall 
>> layout and functions of the OS as a whole, but want to shore up the 
>> security of my individual VMs, with Debian running everything except for 
>> dom0. I know that isolation should do most of the work, but if further 
>> hardening my VMs will add more hurdles for attackers while being of minimal 
>> cost to me, why not?
>>
>> For now, I plan on proper firewalling, activating apparmor, installing 
>> taskett-hardening, and reducing attack surfaces where possible.
>>
>> Specific question: how would one strip down non-app VMs (sys-net, 
>> sys-USB, sys-firewall, whonix-gw) to minimize their attack surfaces? Aside 
>> from common-sense hardening and operation of app VMs, these seem to be the 
>> most exposed and therefore most vulnerable.
>>
>> More generally: what steps have you taken to harden your VMs?
>>
>

-- 
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/470cf3c5-87f7-4637-9819-03532b737f8co%40googlegroups.com.

[qubes-users] Re: How do you maximize your VM security?

On Wednesday, 10 June 2020 00:26:01 UTC+8, Dominique wrote:
>
> Hi,
>
> First step for me was to install the minimal template and use them instead 
> of the complete template for service qubes (sys-net, sys-USB and 
> sys-firewall). Information on minimal template can be found here: 
> https://www.qubes-os.org/doc/templates/minimal/
>
> Second step for me was building and using the mirage firewall instead of 
> sys-firewall. Information on mirage can be found here: 
> https://github.com/mirage/qubes-mirage-firewall/
>
> Third step for me was random mac address and hostname. 
> https://www.qubes-os.org/doc/anonymizing-your-mac-address/
>
> That are things that I do on all my qubes laptop installation. After that, 
> you can play with firewall rules, apparmor and other things.
>
> I would love to see a way to add IDS/IPS in qubes easily but did not have 
> time to even check if someone did try to add IDS/IPS
>
> Have fun!
>
> Dominique
>
> On Tuesday, June 9, 2020 at 11:26:22 AM UTC-4, fiftyfour...@gmail.com 
> wrote:
>>
>> Hi all,
>>
>> I took a break from setting up my Qubes OS machine and now I'm looking to 
>> finish the job and actually settle in. I am familiar with the overall 
>> layout and functions of the OS as a whole, but want to shore up the 
>> security of my individual VMs, with Debian running everything except for 
>> dom0. I know that isolation should do most of the work, but if further 
>> hardening my VMs will add more hurdles for attackers while being of minimal 
>> cost to me, why not?
>>
>> For now, I plan on proper firewalling, activating apparmor, installing 
>> taskett-hardening, and reducing attack surfaces where possible.
>>
>> Specific question: how would one strip down non-app VMs (sys-net, 
>> sys-USB, sys-firewall, whonix-gw) to minimize their attack surfaces? Aside 
>> from common-sense hardening and operation of app VMs, these seem to be the 
>> most exposed and therefore most vulnerable.
>>
>> More generally: what steps have you taken to harden your VMs?
>>
>
Hi Dominique,

Thanks for the reply. So I take it you chose Mirage because a unikernel 
firewall has a smaller attack surface compared to full-blown Linux? 

I'm a newbie, so I'm not even sure if these are IDS/IPS, but I'm thinking 
of installing the tried-and-true trio of rkhunter, lynis, chkrootkit.

I see the point in changing your mac address (already did it myself), but 
why the hostname as well? Since it's not covered in that link, did you just 
edit the config files of the template?

(Re-posted since I committed the cardinal sin of top posting) 

-- 
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/35d2e1c8-fce4-4fe8-84fe-d1f6a62bd90co%40googlegroups.com.

Re: [qubes-users] Re: How do you maximize your VM security?


>
> 1st, I second all of this.
> 2nd, I run a VPN off of the minimal template (technically a double vpn, 
> but it's probably overkill)
> 3rd, on my todo list, create a scratch template with even less than the 
> minimal for these functions
> 4th, only wired networking bc all the insecurity regarding wifi.
> 5th, any applications I don't trust (like Zoom) I run off disposable vms.
> 6th, don't have any hardware VMs running if you aren't actively using them
> 7th, add a root password to all VMs
> 8th, make sure your firewall disallows connections between VMs (granted 
> this is qubes default)
> 9th, add outbound firewall rules to each VM as appropriate
> 10th, don't tell people your qubes configuration (I'm kinda fucking up 
> that one right now :p)
> 11th, use tor if you're seriously concerned about privacy (even though 
> that double vpn was overkill, and this probably moreso)
> 12th, use both DNSSec and DNS over TLS
> 13th, test dns leak with regards to vpn
> 14th, reply in line and don't top post... Okay, not security, just good 
> manners
> 15th, also strip down bios surface (remove possibilities of remote 
> connections, disable any hardware you aren't likely to use, etc.)
>
> Codially, 
> Emlay
>

Hi Emlay,

Thanks for sticking your neck out to help a newbie like me! Your list is 
very helpful and I'm grateful for it. I have two questions:

1) Is there a resource out there that teaches newbies how to configure 
minimal templates for different uses? e.g. For VPN, services, apps, etc. 

2) If you're using a VPN (or two), wouldn't they provide DNS encryption 
services by default?

-- 
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/64c3d3c0-c625-47b3-bf02-f5c2024a48c1o%40googlegroups.com.

[qubes-users] Re: How do you maximize your VM security?


>
> Hi
>
> Changing the hostname is interesting especially for laptop. When you are 
> connecting to any network, your hostname is sent with your MAC address to 
> the DHCP server thus leaving a trace in the log of your presence on that 
> network. Also, the sys-net hostname is very unique and stands out of a list 
> of computer name like the default Windows computer name.
>
> Concerning the IDS/IPS (Intrustion Detection System/Intrusion Prevention 
> System) I would be interesting to analyzing the traffic with a qubes and 
> being able to alert or even create firewall rules on alert at one point. 
> This is probably a big projet to do!!!
>
> And sorry for top posting, I am sending a lot of email and I am so used to 
> click reply and start typing!!!
>
> Regards,
>  
>
Dominique
>

I use groups.google.com so top posting doesn't bother me. I can't speak for 
everyone else though. Thank you again for all the useful information, 
Dominique! 

-- 
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/5388f39c-86a2-43b6-9b2f-a80f331d3533o%40googlegroups.com.

[qubes-users] Re: DisposableVM Help

2020-07-12 Thread fiftyfourthparallel


On Sunday, 12 July 2020 07:40:58 UTC+8, Robert Spigler wrote:
>
> I have a debian-10-dvm and a whonix-ws-15-dvm.  I also had a 
> fedora-30-dvm, but when upgrading to fedora-32, I followed "Creating a New 
> DisposableVM Template" here: (
> https://www.qubes-os.org/doc/disposablevm-customization/), so no longer 
> have the fedora-30-dvm. Instead, I have a custom-disposablevm-template 
> based on fedora-32. I would prefer to rename this to 
> fedora-32-dvm-template, but renaming fails with 'Failed to clone appmenus'.
>
> My main question/problem is that unlike the debian-10-dvm and 
> whonix-ws-15-dvm, opening an application in fedora-32-dvm-template does not 
> open a disposableVM (disp), instead it opens 
> 'custom-disposablevm-template'.  IIUC, that is because I am supposed to 
> create fedora-32-dvm from the dvm-template.  But I cannot figure out how to 
> do that.  It is set as the default disposableVM template, so opening files 
> through the GUI in a disposableVM will open them in a disposableVM based on 
> fedora-32, but I would still like to be able to open an application through 
> the GUI/start menu in a fedora-32-dvm.
>
> What I am also having trouble understanding is what dvm-template is the 
> debian-10-dvm and whonix-ws-15-dvm based on? I know Qubes4.0 introduced 
> multiple DVMTemplates, but I don't see any other DVMTemplates listed under 
> the start menu.  In Qubes Manager, debian-10-dvm and whonix-ws-15-dvm are 
> marked as being their own DVMTemplates? But also DVM's themselves?
>
> Thank you,
>
> Robert
>

I read about this particular bug in whonix DVM that's possibly relevant: 

>Use caution when spawning a DispVM for the first time when it is based on 
a freshly created DVM Template. This Qubes bug 
 [archive] 

 can 
lead to the DVM Template starting instead of the DispVM. [29] 
 [30] 
 There could 
be serious consequences if an application like Tor Browser was started in a 
DVM Template and used extensively for web browsing. Compromise of the DVM 
Template would mean all DispVMs spawned from it would be similarly 
compromised; see Running Tor Browser in Qubes TemplateVM 

.

https://www.whonix.org/wiki/Qubes/DisposableVM

-- 
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/d524eb3c-79bc-4428-af34-da08f4a2955do%40googlegroups.com.

[qubes-users] Fetching updates after disabling qubes-update-check in clearnet qubes

2020-07-13 Thread fiftyfourthparallel

I came across this reply by unman while reading through the Qubes Whonix 
security 

page:

>It is the qubes that perform  update checks and then notify dom0
accordingly. So if you have a qube connected to clearnet it will check
over clearnet.
>You can disable this in clearnet connected qubes - it's the
qubes-update-check service.
>Or you can disable globally in qubes-global-settings.

https://www.mail-archive.com/qubes-users@googlegroups.com/msg27567.html

While the Whonix Wiki maintainer thinks its enough of an issue to include 
on the Whonix security page, Marek doesn't think time-based correlation is 
an issue ("When you actually download and install those updates (over Tor) 
in the template is up to you, it isn't immediately after checking if 
something is available, so time based correlation isn't really an issue here 

").

Though it's not clear to me whether this is actually an issue, I figured 
I'd do it anyways. My question is, if I wanted to disable 
qubes-update-check service, how would I go about updating my templates over 
tor? Do I create debian and fedora templates linked to sys-whonix just to 
get updates?

-- 
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/eadac1c4-f3df-4559-a2f1-edf58f7bb09fo%40googlegroups.com.

Re: [qubes-users] Fetching updates after disabling qubes-update-check in clearnet qubes

2020-07-14 Thread fiftyfourthparallel



On Wednesday, 15 July 2020 05:10:30 UTC+8, awokd wrote:
>
>
> In either case, don't forget to have a line in 
> /etc/qubes-rpc/policy/qubes.UpdatesProxy like: 
>
> $type:TemplateVM $default allow,target=sys-whonix 
>
>
I didn't know about this, so this helps haaber's comment make a lot more 
sense. Thank you both 

-- 
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/75498f0d-c982-4d57-a989-35062a88eaf8o%40googlegroups.com.

[qubes-users] Security advantages of static DVMs for sys-VMs?

2020-07-16 Thread fiftyfourthparallel

Hi there,

I read about running sys-vms as static disposable VMs on the Qubes 
documentation site 
,
 
then on the Whonix guide to Qubes security 
. I have my reservations 
about this (but then I'm no expert) and it feels like the outcome will be 
unstable and hard to use. However, since this is on both the Qubes and 
Whonix sites, this is probably worth looking at. 

What do you think about using static DVMs as sys-VMs?


-- 
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/206940d9-3dca-4621-9e25-78505730f662o%40googlegroups.com.

Re: [qubes-users] Security advantages of static DVMs for sys-VMs?

2020-07-17 Thread fiftyfourthparallel



On Thursday, 16 July 2020 20:48:52 UTC+8, unman wrote:
>
> 54th - static disposableVMS are neither unstable nor hard to use. They 
> are as stable as a normal sys-VM and transparent in use. 
>

Unman, you're right. I was being overly cautious and, to be frank, scared 
of making my OS more complicated, but it's worth it.

Peter Funk wrote:

> Throwing everything away will also delete any evidence that
> something bad might have happened to this part of your digital
> life and will make later analysis of the events harder.


Logs aren't really a concern for me, but it's still something that I should 
look at for DispVMs. Thanks 

-- 
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/712c3816-31a9-4437-9c61-cd93f9284ebco%40googlegroups.com.

[qubes-users] Qubes possibly not detecting ethernet PCI (Dell Inspiron 5593)

2020-07-17 Thread fiftyfourthparallel

Hi all,

I ran into an issue while configuring my disposable sysVMs:

It turns out my sys-net is set to PVH by default instead of HVM, which 
allows for PCI passthrough. This led me to look around, and it turns out 
there are no devices attached to my sys-net despite there being an ethernet 
jack in my laptop.

Using qvm-pci in dom0 revealed that there are no network interfaces, but 
three "Unknown", two "PCI bridge" one "ISA bridge" and one "Communication 
controller", all from Intel Corporation. Is it possible that one of these 
is my ethernet interface? 


   - If so, how would I go about figuring out which one and restoring it? 
   Or do I just test them one by one?
   - If not, how would I get Qubes to look for my missing ethernet?


Thanks in advance

-- 
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/4c14638a-1b3a-42e1-97f9-43838cbef311o%40googlegroups.com.

[qubes-users] Re: Qubes possibly not detecting ethernet PCI (Dell Inspiron 5593)

2020-07-19 Thread fiftyfourthparallel

On 18/07/2020, Tobias Gilberg  wrote:
> One of the Unknown devices is you ethernet interface.
> With lspci -v or lspci -vv in a dom0 terminal you can get more detailt
> information about the pci-devices to determin witch one is the ethernet
> interface.
> If you still didn't find it out, post the output of lspci -vv to the
> mailinglist.

Hi Tobias,

Thanks for your response via email. I'm replying here in case others have 
thoughts to contribute. 

I tried lspci -v and -vv and found out a little more about the four 
unknowns in qvm-pci. They're all serial bus controllers, with the first 
three basically the same--they use kernel driver 'intel-lpss', which 
doesn't seem to be what I'm looking for. The last one that I missed earlier 
doesn't have a kernel driver in use and isn't , so I guess 
this is most likely to be the ethernet device.

Is it safe to test it by connecting it to sys-net?

-- 
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/6ebcd644-57ca-4c9e-b126-b3e7e43eb861o%40googlegroups.com.

Re: [qubes-users] Re: Qubes possibly not detecting ethernet PCI (Dell Inspiron 5593)

2020-07-20 Thread fiftyfourthparallel

On Sunday, 19 July 2020 20:13:46 UTC+8, Tobias Gilberg wrote:
>
> If you disable autostart on sys-net and have no important unsaved files 
> open, then it's "save". 
> The worst thing that could happen is, if you passtrough some devices that 
> are needed by dom0 for running the system, 
> like gpu, host bridge ore something else, you system will shutdown or 
> restart. 
>

After attaching the device to sys-net, it refuses to start. Error message:

>Start failed: internal error: Unable to reset PCI device :00:xx,x: no 
FLR, PM reset or bus reset available, see 
/var/log/libvirt/libxl/libxl-driver.log for details.

Is there any easy way for me to copy the lspci -v output and other logs 
from my unconnected Qubes PC to the one I'm using right now? 

-- 
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/71dc8482-38b7-4f42-86b2-ce630937ad08o%40googlegroups.com.

Re: [qubes-users] Re: Qubes possibly not detecting ethernet PCI (Dell Inspiron 5593)

2020-07-20 Thread fiftyfourthparallel

On Monday, 20 July 2020 15:40:28 UTC+8, 54th Parallel wrote:
>
> On Sunday, 19 July 2020 20:13:46 UTC+8, Tobias Gilberg wrote:
>>
>> If you disable autostart on sys-net and have no important unsaved files 
>> open, then it's "save". 
>> The worst thing that could happen is, if you passtrough some devices that 
>> are needed by dom0 for running the system, 
>> like gpu, host bridge ore something else, you system will shutdown or 
>> restart. 
>>
>
> After attaching the device to sys-net, it refuses to start. Error message:
>
> >Start failed: internal error: Unable to reset PCI device :00:xx,x: no 
> FLR, PM reset or bus reset available, see 
> /var/log/libvirt/libxl/libxl-driver.log for details.
>
> Is there any easy way for me to copy the lspci -v output and other logs 
> from my unconnected Qubes PC to the one I'm using right now? 
>
 

Issue resolved

Cause of issue: User is a moron and disabled network interfaces in BIOS

Thanks for putting up with me Tobias

-- 
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/aedaf96a-ea94-4c43-abf8-9c31e907808ao%40googlegroups.com.

[qubes-users] XScreensaver randomly popping up

2020-07-26 Thread fiftyfourthparallel

Has anyone else experienced the screensaver/lock-screen popping up in the 
middle of typing? 

I had this happen to me twice while typing in dom0 (the second time, I was 
in the middle of typing 'qvm-shutdown debian-10'), so I went and checked 
all of the XFCE and Qubes shortcuts to ensure that I didn't hit some 
shortcut by accident. The default keys were ctrl-alt-del and ctrl-alt-L, 
along with some xf86 shortcuts, so my fingers were nowhere near the keys.

-- 
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/57836ef0-698a-47dc-a4b1-7144342a9924o%40googlegroups.com.

[qubes-users] Re: XScreensaver randomly popping up

2020-07-26 Thread fiftyfourthparallel

Also, since I started a thread, I also want to ask whether SHA1 or other 
deprecated algorithms are used in the PGP verification of dom0 and domu 
updates. This is somewhat related to my original question.

https://arstechnica.com/information-technology/2020/01/pgp-keys-software-security-and-much-more-threatened-by-new-sha1-exploit/

-- 
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/b9dcca44-ef1a-454f-ba3a-4e6b6c036251o%40googlegroups.com.

[qubes-users] Re: Fwd: Audio not working: "snd_hda_intel: No response from codec, resetting bus"

2020-07-27 Thread fiftyfourthparallel



On Monday, 16 December 2019 01:11:25 UTC+8, Claudia wrote:
>
> Claudia: 
> > [...] 
> > So, to recap what I've found so far: 
> > Fedora 25 live cd: works 
> > Qubes without Xen: works 
> > Qubes with Xen: codec probe error 
> > Qubes with Xen, VT-x & VT-d disabled: codec probe error 
> > Qubes with Xen, single_cmd=1: codec detected, but no sound 
> > 
> > [...] 
>
> Just following up. Audio works flawlessly out of the box in 
> R4.1-20181013 with kernel 4.19.76-1. Didn't work in R4.0.2 with 4.19 or 
> even 5.0 kernels even after days of tinkering with it. So it could be 
> due to the Xen version (4.8 -> 4.12), Fedora userland version (25 -> 
> 29), or changes to qubes-specific code/config (4.0 -> 4.1). I was hoping 
> to get it working in stable, but I'll probably just keep using 4.1 for 
> now. 
>
> - 
> This free account was provided by VFEmail.net - report spam to 
> ab...@vfemail.net  
>   
> ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of 
> the NSA's hands! 
> $24.95 ONETIME Lifetime accounts with Privacy Features!   
> 15GB disk! No bandwidth quotas! 
> Commercial and Bulk Mail Options!   
>

Hi Claudia,

I'm suffering from the same problem as you, and 'dmesg | grep -i 
snd_hda_intel' brought me to this thread. 

My sound was originally working fine after I updated dom0 and domus (tested 
via Youtube) but somewhere along the line something broke and the next time 
I did the same thing, no sound. I did everything in my non-technical power 
but it's dead, bub. No idea what caused it.

dmesg output in short:

snd_hda_intel [Audio device PCI code thing]: azx_get_response timeout, 
switching to polling mode: last cmd=0xX

snd_hda_intel [Audio device PCI code thing]: No response from codec, 
resetting bus: last cmd=0xX(this line keeps repeating)

snd_hda_intel [Audio device PCI code thing]: azx_get_response timeout, 
switching to single_cmd mode: last cmd=0xX

snd_hda_codec_realtek hdaudioC0D0: Unable to sync to register 0xXXX. -5
snd_hda_codc_hdmi hdaudioC0D2: HDMI: invalid ELD buf size   (note I'm not 
using HDMI)


-- 
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/ab53b185-c661-4493-bb16-8a126fed1b99o%40googlegroups.com.

[qubes-users] Re: XScreensaver randomly popping up

2020-07-27 Thread fiftyfourthparallel

On Tuesday, 28 July 2020 00:13:16 UTC+8, ludwig...@gmail.com wrote:
>
> Hi I had/had the problem with qubes 3.2, which is very annoying.
> Funny thing: you can trick xscreensaver by switching the desktop 
> if you have multiple desktops, which leads to odd/funny user
> experience of locked screen, that shows desktop and is usable,
> if you force it to redraw windows by moving windows and the like
>
> Does ist feel the same?
>
>
Not quite, but multiple desktops might possibly have something to do with 
it.

In my situation I'm actively using whatever desktop is on the screen and 
the screensaver pops up or the screen locks (can't tell, since both are the 
same)

Just earlier it did it again--this time when I was reading the output of 
xentop maximized with another terminal on top of it (i.e. not typing 
anything)

-- 
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/3fe08b0d-1b8c-47a1-a1fd-df92dc797d5fo%40googlegroups.com.

[qubes-users] Barebones templates (stripping down minimal templates)

2020-07-30 Thread fiftyfourthparallel

Hi all,

I was fiddling with minimal templates and found them much less complicated 
than I feared. For example, converting a debian-10-minimal to a 
sys-net-minimal only involved installing two packages, attaching the pci, 
and fiddling with some preferences and services. Because of this, I'm 
tempted to take things a step further--Inspired by a line from this post 
 by emily ("*3rd, on my todo list, create a 
scratch template with even less than the minimal for these functions*"), 
I'd like to explore the idea of a *barebones* or *minimum viable template*. 

Some questions I have for the community:

   - How much more can one strip from minimal templates while allowing them 
   to start and retain basic Qubes functions? 
   - Are the current minimal templates really the absolute minimum? 
   - Are there diminishing returns to increases in security by reduction 
   that make this simply not worth the time or effort?  
   - How would you go about probing which packages/functions to remove? 
   (especially since I'm not technical--tech-savvy, but not technical)


-- 
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/27c04493-6f5e-46d6-b226-59949312198ao%40googlegroups.com.

[qubes-users] Re: Available Templates

2020-07-30 Thread fiftyfourthparallel

On Friday, 31 July 2020 03:37:00 UTC+8, Qubes wrote:
>
> Where would one look to see what templates are all currently available 
> for installation. 
>
> Whether that would be in Current, Testing, Development. 
>
> Is there a list maintained somewhere? 


 
In dom0:

sudo qubes-dom0-updates --enablerepo=qubes-templates-community --action=list 
qubes-template-*

or

sudo qubes-dom0-updates --enablerepo=qubes-templates-community-testing --
action=list qubes-template-*

Can't remember if there's a development repo off the top of my head

-- 
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/17f1a517-5d31-445b-8e6c-1ccf3dde1f5bo%40googlegroups.com.

[qubes-users] Re: add-ons in torbrowser

2020-07-30 Thread fiftyfourthparallel

On Friday, 31 July 2020 04:58:48 UTC+8, haaber wrote:
>
> Hi this may be a double-post, but I could not find an appropiate help 
> page. I like to add an adblocker (u-block) to my TBB, since I consider 
> any browser without adblocking useless, meaning that I will not use it 
> anyways. So here is my approach: 
>
> download .xpi file in anon-whonix, qvm-move it to whonix-gw and there I 
> would (have liked to) install it. But the torbrowser does not want to be 
> run in  the template-VM. How procede then? Re-Install the .xpi file at 
> each reboot   Cheers! 
>
 
Tor browser comes with noscript, which should do a similar job. I suggest 
using it in combination with Tor's internal safety settings (the shield 
icon). 

As Qubes said, you shouldn't customize the browser. 

-- 
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/f9d73b86-3b31-4f00-a8be-f5be02dfe820o%40googlegroups.com.

[qubes-users] Re: Available Templates

2020-07-31 Thread fiftyfourthparallel


On Friday, 31 July 2020 07:36:22 UTC+8, 54th Parallel wrote:
>
> In dom0:
>
> sudo qubes-dom0-updates --enablerepo=qubes-templates-community --action=list 
> qubes-template-*
>
> or
>
> sudo qubes-dom0-updates --enablerepo=qubes-templates-community-testing --
> action=list qubes-template-*
>
> Can't remember if there's a development repo off the top of my head
>

Also, remove "--enablerepo=qubes-templates-community"  for a list of 
official templates (and mind the typo in 'qubes-dom0-update*s*')

-- 
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/220834a1-2165-403c-ac94-eeb820df1882o%40googlegroups.com.

Re: [qubes-users] Update templates in parallel

2020-08-02 Thread fiftyfourthparallel

On Sunday, 2 August 2020 22:42:31 UTC+8, Chris Laprise wrote:
>
> 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 
>

Hi Chris,

After testing, the m7i solution works, but isn't ideal--it sometimes fails 
due to pipe errors and attempts to update all my appVMs as well, which 
might be problematic from a security standpoint. I looked in man qubesctl 
and didn't see anything for parallelizing updates, but since I'm hesitatnt 
to install salt management in my minimal templates to begin with, that's 
beside the point.

I noticed that you have a qubes4-multi-update tool which I'm likely going 
to switch to, since parallelizing isn't my true concern, but clearing 10+ 
dom0 prompts for sudo authentication every time I update. Since 
qubes4-multi-update looks cleaner and also uses -u root, this seems to be 
promising. I'll report back.

halt-vm-by-window and system-stats-xen seem incredibly promising since I 
constantly have xentop running and I'm looking to simplify my system to one 
app per VM. 

On that topic, I'm having huge difficulties making it so starting a qube, 
say app-firefox, automatically starts a program, like firefox. I've tried 
rc.local but that's pre-boot, before X11. Others have suggested something 
related to /etc/config or something, but that involves fiddling with 
templates and implies an ungodly amount of templates. Would you happen to 
have any suggestions?

-- 
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/282c1640-fe56-491a-8390-2bbf940adb55o%40googlegroups.com.

Re: [qubes-users] Update templates in parallel

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.

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

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

-- 
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/9909dcfd-4b72-4f7f-b44a-4152b837fe0eo%40googlegroups.com.

Re: [qubes-users] Update templates in parallel



On Monday, 3 August 2020 16:11:40 UTC+8, 54th Parallel wrote:
>
>
> 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.
>
>  
Now that I've actually read the documentation, my problems can be solved by 
using the -atu option--a classic case of RTFM.

-- 
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/4b514065-4b61-4f61-bbc7-46aaf9033011o%40googlegroups.com.

Re: [qubes-users] Update templates in parallel

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 respond right before you posted 
, 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.

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

Tested and confirmed working. When combined with your halt-vm-by-window 
script, my Qube Manager is now basically my start menu. Who said security 
doesn't mix well with useability? Now, if only there were a modification 
that allowed you to start VMs by double-clicking on them in the Qube 
Manager...

On Monday, 3 August 2020 19:05:29 UTC+8, Chris Laprise wrote:
>
> 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. 
>

Tested and confirmed to persist across reboots. Thanks a bunch! 

-- 
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/9a80e647-4e3b-43a6-8673-b727b641155bo%40googlegroups.com.

Re: [qubes-users] Update templates in parallel

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/

-- 
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/b929c78a-780a-46c2-aa5e-61ec5e9e7fdco%40googlegroups.com.

Re: [qubes-users] Update templates in parallel



On Tuesday, 4 August 2020 00:03:08 UTC+8, Chris Laprise wrote:
>
> 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. 
>

I forgot to mention that I was following your latest instructions via this 
thread and still wasn't able to get it 
working: https://groups.google.com/d/msg/qubes-users/f974-MsbZyM/xh93RU7NAQAJ

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. 

-- 
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/81236671-e78a-47be-be3e-915c1a954449o%40googlegroups.com.

[qubes-users] qubes-dom0-update "No Match for argument"

Hi all,

Every time I use qubes-dom0-update in a fresh installation (which I've done 
around ten times now), I get strange outputs where the repositories aren't 
shown being queried but the update proceeds. It looks something like this:

error:could not delete old database at /var/lib/qubes/dom0-updates/home/user
/.rpmdbold.965
https://mirrors.phx.ms/qubes/repo/yum/r4.0/current/dom0/fc25/repodata/repomd.xml:[Errno
 
14]curl#6-"Could not resolve host:mirror.phx.ms"
Trying other mirror.
https://mirror.linux.pizza/qubes-os.org/repo/yum/r4.0/current/dom0/fc25/repodata/repomd.xml:[Errno14]HTTPS
 
Error 404 -Not Found
Trying other mirror.
https://mirror.linux.pizza/qubes-os.org/repo/yum/r4.0/templates-til/repodata/repomd.xml:[Errno
 
14] HTTPS Error 404 - Not Found
Trying other mirror.
No Match for argument
No Match for argument
No Match for argument
No Match for argument
No Match for argument
No Match for argument
No Match for argument
No Match for argument
-->Running transaction check
--->Package kernel[...] will be installed

[...]

--->Finished Dependency Resolution

[Starts downloading]

This is consistent even when updating over tor, and has been bugging me. 
Does anyone else see this when they first update dom0?

-- 
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/df06c12c-a0ad-45b9-ab0b-65e68fc8e22fo%40googlegroups.com.

[qubes-users] Re: qubes-dom0-update "No Match for argument"

Oh, and while I'm at it, the "Is this ok [y/N]" prompt often appears twice, 
requiring two 'y's. This isn't consistent, but it's raising red flags when 
combined with the above. Anyone else have this issue?

-- 
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/b01b1e8b-c2f5-422a-a6bb-91247c46748co%40googlegroups.com.

[qubes-users] Re: fedora 32 pdf converter

I have the same problem and this is on Debian 10. I tried looking up the 
error code for ImageMagick (which the converter is based on) and fixing it 
using their solution (which involves editing policies) but it still doesn't 
work, so I've temporarily given up on it altogether. 

-- 
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/36513023-b91b-4797-970c-7f0873ce7b20o%40googlegroups.com.

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

Hi all,

Sorry for the recent spam--I've been spending a lot more time with Qubes 
and coming across issues that I haven't seen mentioned here yet. 

Here's another one:

If you disable passwordless root access in whonix-gw, tor control panel 
(accessed by right clicking the sw-date tray icon) stops working entirely, 
and whonix-ws will cause whonix-gw to continually spam you with dom0 sudo 
prompts if you enabled that. Ignoring them and dragging them off to another 
workspace hasn't caused any issues, but it's still annoying to deal with. 

Has anyone else had this experience or have any suggestions?

-- 
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/8b14fef5-031d-42d9-a7f4-b7f8563cb101o%40googlegroups.com.

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


On Wednesday, 5 August 2020 05:29:49 UTC+8, Qubes wrote:
>
> On 8/4/20 8:29 PM, fiftyfour...@gmail.com  wrote: 
> > Hi all, 
> > 
> > Sorry for the recent spam--I've been spending a lot more time with Qubes 
> > and coming across issues that I haven't seen mentioned here yet. 
> > 
> > Here's another one: 
> > 
> > If you disable passwordless root access in whonix-gw, tor control panel 
> > (accessed by right clicking the sw-date tray icon) stops working 
> entirely, 
> > and whonix-ws will cause whonix-gw to continually spam you with dom0 
> sudo 
> > prompts if you enabled that. Ignoring them and dragging them off to 
> another 
> > workspace hasn't caused any issues, but it's still annoying to deal 
> with. 
> > 
> > Has anyone else had this experience or have any suggestions? 
> > 
> Leave passwordless root enabled on whonix-gw? 
>

I had a feeling someone would give that answer, but let's assume that's not 
an option. 

-- 
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/28665ff5-6445-429d-8a11-6db938c6a515o%40googlegroups.com.

Re: [qubes-users] Barebones templates (stripping down minimal templates)



On Wednesday, 5 August 2020 06:15:12 UTC+8, awokd wrote:
>
> > Tried it a number of years ago. Building a Debian template with 
> -no-install-recommends (something like that) initially resulted in fewer 
> packages, but installing required qubes packages pulled many of them 
> back in. That way you start with the absolute minimum, and only add back 
> in what you need. However, the delta between minimal and my custom 
> template wasn't big enough for me to continue using/maintaining it. 
>
> -- 
> - don't top post 
> Mailing list etiquette: 
> - trim quoted reply to only relevant portions 
> - when possible, copy and paste text instead of screenshots 
>

I suspected that, given the already-tiny size of minimal templates. Good to 
know--thanks. 

-- 
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/e6ae8843-c957-4a90-a8f4-8a32edbb8c1bo%40googlegroups.com.

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

On Wednesday, 5 August 2020 07:08:04 UTC+8, Ulrich Windl wrote:
>
> Actually instead of parallel updates (assuming limited bandwidth) I'd 
> vote for a more verbose progress indicator (in the graphical update app): 
> Currently the VMs start, update starts, and then ...long time 
> nothing..., then the list of packages updated. 
>
> Regards, 
> Ulrich 
>

Check out Chris' qubes4-multi-update 
 script--it gives you *exactly* 
what you want, alone with some more options.

-- 
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/1e0ca5f7-cfe3-40e2-9155-ddf2d66d400co%40googlegroups.com.

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

2020-08-05 Thread fiftyfourthparallel



On Wednesday, 5 August 2020 02:29:46 UTC+8, 54th Parallel wrote:
>
> Hi all,
>
> Sorry for the recent spam--I've been spending a lot more time with Qubes 
> and coming across issues that I haven't seen mentioned here yet. 
>
> Here's another one:
>
> If you disable passwordless root access in whonix-gw, tor control panel 
> (accessed by right clicking the sw-date tray icon) stops working entirely, 
> and whonix-ws will cause whonix-gw to continually spam you with dom0 sudo 
> prompts if you enabled that. Ignoring them and dragging them off to another 
> workspace hasn't caused any issues, but it's still annoying to deal with. 
>
> Has anyone else had this experience or have any suggestions?
>

Problem seems to have gone away after using configure-sudo-prompt from 
tasket's qubes-vm-hardening on a fresh installation of 
qubes-template-whonix-gw-15

-- 
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/e7c475aa-206e-4f5c-bf09-8d6f24e344cao%40googlegroups.com.

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

2020-08-05 Thread fiftyfourthparallel

On Thursday, 6 August 2020 09:03:31 UTC+8, unman wrote:
>
> The security isnt to be found at the proxy level, but at the package 
> management level. It's there that verification is (and should be) done. 
>

Unman, speaking of verification at the package management level, would you 
happen to know the algorithm that's used to verify dom0 and domu packages? 
I've been looking for this info since I'm worried that it might be the 
now-deprecated SHA1 (like Github) but I haven't found anything yet. 

-- 
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/fe72cccb-d589-498b-ab50-ebeb7319a08do%40googlegroups.com.

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

2020-08-05 Thread fiftyfourthparallel

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)

-- 
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/65c66143-b92a-4846-a6e9-a62f86c8e213o%40googlegroups.com.

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

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

-- 
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/e4058562-8112-4264-9de2-cc4e45eb5e6co%40googlegroups.com.

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

On Thursday, 6 August 2020 17:36:05 UTC+8, Chris Laprise wrote:
>
> IIRC she gave some indication that guest VMs shouldn't be defenseless 
> internally. 
>
> -- 
> Chris Laprise, tas...@posteo.net  
> https://github.com/tasket 
> https://twitter.com/ttaskett 
> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886 
>

Found it!

There might be potential attacks against the hypervisor or daemons/backends 
in dom0 that require root access. Qubes founder Joanna Rutkowska initially 
assessed there was limited benefit from isolating the root account from the 
user account, because all user data is already accessible from the latter 

[archive] 
.

However, she later changed her opinion on the matter; see here 

 [archive] 

.

https://www.whonix.org/wiki/Qubes-Whonix_Security#cite_note-11 

https://web.archive.org/web/20200323113623/https://github.com/QubesOS/qubes-issues/issues/2695#issuecomment-301316132

The Whonix documentation for Qubes is actually generally applicable beyond 
Whonix--I highly recommend anyone interested in securing their computers 
look around the Whonix wiki (i.e. basically everyone reading this). The 
page I linked is a good starting point. Kudos to the Whonix Wiki maintainer.

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

This is what baffles me about some people's mindsets--if they prize 
security so much that thet take the time and trouble to install and learn 
Qubes --no small feat for most of us-- why not go a bit further and batton 
down the hatches of their VMs? It's usually a one-time investment that 
requires little to no maintenance with a huge payoff with regard to their 
goal (which I presume is secure computing). Kudos to you for making this 
process a heck of a lot easier for non-technical people, like me.

-- 
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/222144ba-abd7-41c8-a68e-2a4aa88dff0eo%40googlegroups.com.

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

On Thursday, 6 August 2020 18:05:25 UTC+8, Chris Laprise 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. 
>
> 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. 
>
> -- 
> Chris Laprise, tas...@posteo.net  
> https://github.com/tasket 
> https://twitter.com/ttaskett 
> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886 
>

That's highly concerning and might put me off from using Qubes for 
sensitive work, which defeats the entire purpose of installing Qubes. This 
is a massive gaping whole that, to me, invalidates all the other security 
strengths of Qubes, since dom0 is the key to the kingdom.

The reason why I'm anxious about the security of packages is because my 
dom0 has exhibited strange behavior not present before my dom0 update (and 
I know because I spent a lot of time with my OS before connecting it for 
the first time). My dom0 update itself has been behaving strangely and I 
made a post about it earlier, where I also asked about package 
verification, but received no response.

>
> Hi all,
>  
> Every time I use qubes-dom0-update in a fresh installation (which I've 
> done around ten times now), I get strange outputs where the repositories 
> aren't shown being queried but the update proceeds. It looks something like 
> this: 

error:could not delete old database at /var/lib/qubes/dom0-updates/home/user
> /.rpmdbold.965
> https://
> mirrors.phx.ms/qubes/repo/yum/r4.0/current/dom0/fc25/repodata/repomd.xml:[Errno
>  
> 
>  14]curl#6-"Could 
> not resolve host:mirror.phx.ms"
> Trying other mirror.
> https://mirror.linux.pizza/
> qubes-os.org/repo/yum/r4.0/current/dom0/fc25/repodata/repomd.xml:[Errno14]HTTPS
>  
> 
>  Error 
> 404 -Not Found
> Trying other mirror.
> https://mirror.linux.pizza/
> qubes-os.org/repo/yum/r4.0/templates-til/repodata/repomd.xml:[Errno 
> 
>  14] 
> HTTPS Error 404 - Not Found
> Trying other mirror.
> No Match for argument
> No Match for argument
> No Match for argument
> No Match for argument
> No Match for argument
> No Match for argument
> No Match for argument
> No Match for argument
> -->Running transaction check
> --->Package kernel[...] will be installed
>
>
> [...]
> --->Finished Dependency Resolution
> [Starts downloading]
> This is consistent even when updating over tor, and has been bugging me. 
> Does anyone else see this when they first update dom0? 


 Also, it dom0 update consistently gives me two [Y/n] prompts in a row 
before installation, which seems very strange.

-- 
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/3ffe-d63d-4247-a548-eb2b7731bd9do%40googlegroups.com.

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


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

-- 
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/0950de97-2bf0-44ad-9c06-fb1be34a93e7o%40googlegroups.com.

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

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? 

-- 
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/7dc6bda2-e90f-47d1-a8c2-809cf1d996dco%40googlegroups.com.

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

On Friday, 7 August 2020 02:40:58 UTC+8, Chris Laprise wrote:
>
> 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 
>

That's great to know. I was worried my efforts at secure computing have 
been in vain. I suppose those who need to use Fedora should stick with 
CentOS. Thanks a bunch, Chris! 

-- 
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/dca34216-c0f4-44c5-892a-be53d3ab4c77o%40googlegroups.com.

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

2020-08-07 Thread fiftyfourthparallel

Informed by a recent post
,
I've decided to start writing a script that takes a Qubes installation's
list of packages installed in dom0 and compare them to the list of
available packages in the chosen repo (e.g. 'current') to ensure that the
update process hasn't been interfered with by an adversary that has taken
advantage of Fedora's insecure updating mechanism (detailed in the thread
linked earlier). I'm motivated to do this because this seems to be a flaw
that can give attackers the key to the kingdom by blocking patches to dom0
or Xen.

Since I'm not a programmer (I know *basic* Python), this will be a learning
experience for me, so stay tuned and please point out any issues/errors you
spot in my updates. I'd appreciate it if someone felt charitable enough to
point me towards useful commands/functions, but I'd be fine learning the
hard way too--I need to start learning programming *somewhere*, and this
seems to be a good place to start.

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.

--
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/8df94b46-4dc1-445f-b994-47419a2ac797o%40googlegroups.com.

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

2020-08-07 Thread fiftyfourthparallel

On Thursday, 6 August 2020 22:24:38 UTC+8, 54th Parallel wrote:
>
>
> There might be potential attacks against the hypervisor or 
> daemons/backends in dom0 that require root access. Qubes founder Joanna 
> Rutkowska initially assessed there was limited benefit from isolating the 
> root account from the user account, because all user data is already 
> accessible from the latter 
>  
> [archive] 
> .
>  
> However, she later changed her opinion on the matter; see here 
> 
>  [archive] 
> 
> .
>
>
Upon reading that more carefully, I realized that it's explicitly about 
dom0, but I think the general concept applies to other VMs as well. 

-- 
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/88dd8065-2729-421f-81e0-0fac66ac5f73o%40googlegroups.com.

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

2020-08-07 Thread fiftyfourthparallel

On Saturday, 8 August 2020 06:38:38 UTC+8, Chris Laprise wrote:
>
> 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 
>

Since dom0 can be updated via tor, is there an onion address? If not, what 
would it take to make one or convince someone to make one? Without this 
(since i2p is a whole can of worms I don't want to touch), the whole 
exercise is meaningless. 

-- 
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/4d0a2044-3f8b-449f-8201-b70104e55838o%40googlegroups.com.

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

2020-08-08 Thread fiftyfourthparallel

On Saturday, 8 August 2020 20:51:25 UTC+8, unman wrote:
>
> Onion? Of course. 
> Check /etc/yum.repos.d/qubes-dom0.repo 
> Also, it's on mirror list at https://www.qubes-os.org/downloads, and has 
> been referenced on this list. 
> The repo is: 
> http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion 
>
> What you should do is grab a few of those mirror sites, and compare the 
> metadata downloaded through Tor. i.e don't trust *any one* site, but look 
> at 
> them in the mass . 
> Just as you would with an iso or pgp key. 
>
> unman 
>

I have Awokd, Chris, *and* Unman replying to my post--I feel pampered.  

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.

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

-- 
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/7cbe0823-78ff-4b71-b4ef-6a276a001805o%40googlegroups.com.

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

2020-08-08 Thread fiftyfourthparallel

On Sunday, 9 August 2020 04:22:02 UTC+8, awokd wrote:
>
> To stay in keeping with Qubes philosophy, at most dom0 should only run 
> jobs inside VMs and copy files between VMs. You don't want it to parse 
> results, but you could let dom0 copy/move output files to a separate VM, 
> then kick off a job to handle the parsing inside the destination VM. 
>
> -- 
> - don't top post 
> Mailing list etiquette: 
> - trim quoted reply to only relevant portions 
> - when possible, copy and paste text instead of screenshots 
>

So I'll have the users create an offline AppVM based on a clean Debian 
template, then have users point the script to it. Dom0 will copy the data 
from its 'rpm -qa' or 'yum list installed' to it, and also copy the Tor 
repodata from Whonix after it has been cross-checked there. The offline 
AppVM will then parse and cross-check the dom0 list and the repodata and 
return a result to dom0. 

Another option is to have the offline AppVM handle cross-checking between 
Tor and HTTPS repodata as well, so all Whonix does is fetch. Which sounds 
better?

-- 
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/e06fa923-9382-4823-bf03-7f511fabd0d3o%40googlegroups.com.

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

2020-08-10 Thread fiftyfourthparallel

On Monday, 10 August 2020 18:39:53 UTC+8, Andrew David Wong wrote:
>
> The QSB formats are actually pretty standardized already, though our 
> expectation has been that they'd be read by humans rather than 
> programmatically. We use a template [1] for the overall structure, and 
> in particular, the "Patching" section always follows this format: 
>

Chris, Andrew,

I'm grateful for your pointers. As a newcomer to programming, I don't think 
I'm ready to integrate bulletin parsing and PGP verification into my 
script. As of right now I'm trying to figure out whether I should use bash, 
sh, or Python to write the script and using Chris' qubes-scripts and 
qubes-vm-hardening as reference on how I should proceed. Maybe I'll get 
around to integrating PGP verification into the process, but for now I want 
to focus on the basics.

Besides, don't the bulletins cover only a tiny (though critical) portion of 
the updates dom0 receives? The PGP verification will provide a strong 
additional layer of assurances, but I think cross-checking 'rpm -qa' 
against the onion repodata, which itself has been cross-checked with at 
least three other HTTPS repodata, should suffice for now, given my 
abilities.

Oh, and if someone more proficient at programming than I am (probably > 90% 
of the people here) would like to write the script, then by all means--I'll 
take my time and will likely come up with something substandard and in need 
of multiple major revisions. I can still practice even though someone else 
has written it, so please don't think of this little project as 'mine' or 
anything--I'd hate to get in the way of others improving Qubes' security.

-- 
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/0dbe073f-6bac-4133-a82f-32cafff3d31fo%40googlegroups.com.

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

2020-08-13 Thread fiftyfourthparallel

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. 

-- 
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/7bb49647-afea-4471-b6f1-c9e0b7cdda7ao%40googlegroups.com.

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

2020-08-13 Thread fiftyfourthparallel

On Thursday, 13 August 2020 23:09:04 UTC+8, disrupt_the_flow wrote:
>
> On August 13, 2020 2:59:37 PM UTC, "fiftyfour...@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. 
>>
>>
> Or maybe you want to actually hack a computer with Qubesos but you don't 
> know how. I highly doubt you can write patches.
>

That strikes me as an unnecessarily paranoid way of thinking. White hat 
hackers are an important part of security.

Also, I don't understand what you mean about me being unable to write 
patches. It should be clear from my recent posting history that I can't 
write patches--or any code beyond the most basic Python.

-- 
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/906024f7-1942-4d34-a344-b526025193ado%40googlegroups.com.

[qubes-users] Installation fails in many different ways

2019-12-31 Thread fiftyfourthparallel

Happy new year, fellow Qubers!

Well, I'm not really a Quber --not yet-- but maybe you can help me join 
your ranks.

I went out and bought a Dell Inspiron 5593 --a shiny new laptop with an 
i7-1065G7*-- for the express purpose of installing Qubes on it, but found 
out during BIOS setup that the CPU simply doesn't support legacy boot. This 
may or may not be relevant to my problem installing via USB:

Using 4.0.2-rc3, I managed to get all the way to actual installation after 
battling several major issues (like m.2 not appearing), but it seems like 
I've hit a brick wall. Installation freezes/fails during installation, but 
where and how varied among all attempts. 

*Attempt 1: *Slowly set a root password and username during installation. 
Cursor freezes during the end of setting these, but the keyboard stayed 
alive. Tabbed and entered my way back out, only to be greeted with a prompt 
saying that the installation encountered a fatal error: "DNF error: Error 
unpacking rpm package webkitgtk4.2.18.3-1.fc25.X86_64". (9xx/1025, I 
think). Keyboard still useable. Hard reset.

*Attempt 2:* Quickly set passwords. Cursor still alive when done. 7xx/1025, 
cursor freezes, but keyboard remained alive. Kept tabbing to verify that 
keyboard was still alive. 9xx/1025, installation stalls but the pinwheel 
(?) kept spinning and keyboard was still alive. Waited twenty minutes--no 
joy. Hard reset.

*Attempt 3:* Didn't set any passwords as an experiment. Walked away, and 
came back to a completely frozen installation. (Early installation; no 
number). Hard reset.

*Attempt 4: *Quickly set passwords. Kept wiggling cursor to find out when 
it freezes. Observed increasing cursor lag starting at 804/1025. Cursor and 
pinwheel freezes at 808/1025. Dead keyboard. Dead installation. Hurt 
feelings. Hard liquor. Hard reset.

*Attempt 5:* Didn't set any passwords. Cursor lag 815/1025. Cursor frozen 
at 834/1025. A wild fatal error appeared: "DNF error: Error unpacking rpm 
package kbg-2.0.3-3.fc24.x86_64". Keyboard alive.

*Attempt 6:* Booted from the ANACONDA partition. Quickly set passwords. 
Cursor lag at 826/1025. Cursor frozen at 830/1025, pinwheel spinning. A 
wild fatal error appeared: "DNF error: Error unpacking rpm package 
mesa-dri-drivers-17.05-3.fc25.x86_64". Keyboard alive. Pride, barely.


Not sure what's going on here or how to resolve this, so I'd appreciate any 
ideas.



**Since I wanted hardware-level Spectre mitigation*

-- 
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/94e988dd-c0e3-4370-b644-e38b74e3e8ba%40googlegroups.com.

[qubes-users] Re: Installation fails in many different ways

Tl;dr--Installation successful; Nvidia was the culprit.

Follow up:

*Attempt n *(some large number)*:* Disabled SpeedStep. Passwords quickly 
entered. Cursor lag 819/1025. Cursor freeze 836/1025. "DNF error: Error 
unpacking rpm package anaconda-core-1000:25.20.9-16.fc25.x86_64".

*Attempt n+1:* Kept SpeedStep disabled. Booted ANACONDA. Passwords quickly 
entered.  Cursor lag ~830/1025. Cursor freeze 840/1025. "DNF error: Error 
unpacking rpm package gtk3-3.22.17-2.fc25.x86_64".

*Attempt n+2:* Kept SpeedStep disabled. Disabled C-State Control. Passwords 
quickly set. Cursor lag 808/1025. Cursor freeze 812/1025. *Installation 
proceeds*. At 839/1025: "DNF error: Error unpacking rpm package 
adwaita-icon-theme3.22.0-1.fc25.noarch"

*Attempt n+3:* Same setup as before, but didn't set languages or time. 
Didn't set passwords. Complete freeze 809/1025. CPU fans at max for 5 mins 
before hard reset. Hard doubts about approach.

*Attempt n+4:* Re-enabled SpeedStep and C-State Control. Edited BOOTX64.cfg 
to add "nouveau.modeset=0" param to kernel config keys. Booted ANACONDA. 
Passwords quickly set. Installation succeeded. Nvidia was the culprit here 
(no option to disable in BIOS).


Installation booted, configured, and setup without issues--thanks for the 
great start to a new decade! * Will definitely see some of you around here 
as I poke around.

**Yes, I know it's technically not the start of a new decade.*

-- 
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/bf5600b3-0214-421d-a888-6b66827b7632%40googlegroups.com.

Re: [qubes-users] Installation fails in many different ways

It was Nvidia--adding "nouveau.modeset=0" did the trick. 

Thank you!

-- 
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/7b576d6b-fb4f-49bf-ad0a-0eb7c56e122c%40googlegroups.com.

Re: [qubes-users] Installation fails in many different ways

awokd,

It was Nvidia--adding "nouveau.modeset=0" to BOOTX64.cfg did the trick.

Thank you!

-- 
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/955d5e5d-ee2b-4df6-aa80-8ad599b7c1f1%40googlegroups.com.

[qubes-users] Re: Installation fails in many different ways

Thanks for sharing, trueriver,

I finally got past the introductory boss of Qubes--now I get to roam the 
sandbox world. 

It wasn't so much an issue with the trackpad as it was the Nvidia GPU that 
can't be disabled.

Since you seem to be a dev who's interested in Qubes' compatibility with 
this particular 10th gen Dell, I can keep you posted (privately) about my 
experiences if you want.

-- 
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/abc949ac-e7bb-4ec6-9f90-fc5aa015c2f1%40googlegroups.com.

[qubes-users] Does the latest Linux kernel improve security for qubes?

2020-01-04 Thread fiftyfourthparallel

Happy new decade!*

Quick question: In terms of security, does it matter if I install and use 
the latest Linux kernel (5.4) or not? If security is increased, is it worth 
the potential instability, if there is any?

Also, is there a quick diagnostic tool to check if a new installation on a 
new laptop have all functions working? (like sound, SLAT, TPM, etc.)

**Please don't get pedantic on me*

-- 
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/49254b0f-5bb7-42ac-b918-471d0d2bd141%40googlegroups.com.

Re: [qubes-users] Does the latest Linux kernel improve security for qubes?

2020-01-04 Thread fiftyfourthparallel

Many thanks for the lightning-fast reply.

I'm going to use the TPM for Anti Evil Maid. 

On that note, would you happen to know how to downgrade TPM firmware from 
2.0 to 1.2 within Qubes? Will I have to reinstall windows just to do this?

On Sunday, 5 January 2020 01:19:46 UTC+8, dhorf-hfr...@hashmail.org wrote:
>
> On Sat, Jan 04, 2020 at 09:01:35AM -0800, fiftyfour...@gmail.com 
>  wrote: 
> > Quick question: In terms of security, does it matter if I install and 
> use 
> > the latest Linux kernel (5.4) or not? 
>
> quick answer: not different wrt security. 
>
>
> > the potential instability, if there is any? 
>
> quick answer: not different wrt stability. 
>
> see the current 4.0.2 discard drama. 
> even a stable branch kernel can be a lemon. 
> make sure to always keep some back versions installed. 
> so the newest kernel doesnt work in some way? 
> just boot the one from last week, and file an issue report and/or complain 
> on mailinglist and/or irc. 
>
>
> > Also, is there a quick diagnostic tool to check if a new installation on 
> a 
> > new laptop have all functions working? (like sound, SLAT, TPM, etc.) 
>
> quick answer: just boot the installer. 
> if it doesnt like your hardware, it will tell you. 
> that covers at least slat(+iommu). 
>
> "sound" and "tpm" are simply a question of "is this supported by linux", 
> nothing qubes-specific about it. 
>
> tpm has the additional problem of ... 
> aeh, what do you want to use a tpm for anyways? 
> unless you have an actual usecase in mind, just ignore the tpm entirely. 
>
>
>

-- 
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/26e1dbff-e153-467b-9bdf-802b3ddcae8c%40googlegroups.com.

Re: [qubes-users] Does the latest Linux kernel improve security for qubes?

2020-01-04 Thread fiftyfourthparallel


>
> However there's probably no way to fully automate it.


As someone somewhat knowledgeable about tech, but without deep knowledge, 
this is annoying but manageable. Should someone write a "First Boot 
Checklist" for the wiki, if only to increase the accessibility of Qubes?

 

-- 
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/8ecbdf0d-37f9-41e9-910d-c3cac341c060%40googlegroups.com.

Re: [qubes-users] Does the latest Linux kernel improve security for qubes?


>
> My HCL report for this machine is now almost six months in the making, all 
> told.


If an HCL report is taking someone with your level of knowledge six months 
to compile, then it's probably incredibly discouraging for many, if not 
most, would-be contributors. I know I'm discouraged, despite the fact that 
my new Inspiron 5593 (Ice Lake) is almost unbelievably compatible with 
Qubes once some minor obstacles during installation have been overcome 
based on what I've experienced so far.

Is there a simplified HCL report process for someone that's not as 
technically inclined as someone like you are?

>

-- 
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/b3a21f7d-7eb8-4845-988d-9fcd9eea326c%40googlegroups.com.

Re: [qubes-users] Does the latest Linux kernel improve security for qubes?

Seems like you're taking the super-comprehensive route (including flashing 
Coreboot) on a low-compatibility machine. Maybe one day I'll have enough 
proficiency to really make a machine *mine*.Out of curiousity, what model 
are you working on?

I'll give the Youtube Suspension Test a try once I connect my machine to 
the net. I'm one step away from that, but I'm stuck--I'm trying to follow 
the instructions on the Qubes site to randomize my MAC address, but the 
fedora-30 template seems to be locked with a password that isn't mine. From 
all that I've read (including Joanna's explanation in the sudoers folder), 
I'm not supposed to be prompted for a password, yet here I am.

Don't want to make a thread for what could be a trivial Linux mistake that 
isn't specific to Qubes. Would you happen to know anything about this?

-- 
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/94975636-4947-40b3-9043-b796b1e7c973%40googlegroups.com.

Re: [qubes-users] Does the latest Linux kernel improve security for qubes?


>
> Inspiron 5575, AMD 2500U
>

A newly-released machine with an AMD CPU and GPU? Are you a masochist or 
someone who's looking to perform feats of strength? (Like climbing 
Everest). Or is Intel really that unpalatable for you? From what I've read, 
AMD's PSP is much more opaque and questionable compared to Intel's ME. Is 
this true?

Sorry for the barrage of questions--your choice of laptop really piqued my 
curiousity.

Hmm, that's odd. I would recommend starting a new thread.


Thanks--I'll get onto that soon. 

-- 
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/cb7a921e-7b38-4477-9097-08abc0224993%40googlegroups.com.

[qubes-users] Default fedora-30 template asking for password that I don't have

Hello,

I have a fresh installation of Qubes 4.0.2 on a Dell Inspiron 5593 with an 
untouched fedora-30 template. Aside from some minor hiccups during 
installation, no compatibility issues have been detected. (Note: I know 
more about tech than the layperson, but not enough to call myself a 
'techie').

Following the instructions on the Qubes guide to randomizing my MAC address 
, I cloned the 
template and attempted to modify it for my netVMs. When creating the 
'00-macrandomizer.conf' file in the '/etc/NetworkManager/conf.d' folder, I 
was told that I don't have permission to do so. This struck me as odd, 
since I recently read Joanna's message in the sudoers' folder about 
passwordless root. I tried every password that I've set on the machine 
(including the root password set during installation), but nothing works. 

Anyone have any idea what's going on? In case it's relevant, the command 
line starts with "user".


P.S. Does creating a firewallVM just for TOR connection (i.e. proxy between 
whonix/TAILS appVM and whonix-15-gw netVM) increase security or just waste 
computational resources?

-- 
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/bc63be86-1c0f-41ea-9294-04c379c6bf7c%40googlegroups.com.

Re: [qubes-users] Does the latest Linux kernel improve security for qubes?


>
> What can I say, I like doing things the hard way.
>

Some might say it's good for character building--like climbing Everest with 
minimal assistance when you can instead just hire a bunch of Sherpas to 
carry you.


I don't know much about PSP, or ME for that matter, but it seems to me 
> you're mostly screwed either way, so I figured I might as well save some 
> money while I'm at it.


Well, if the motivation is money then I think the amount of time someone 
with your level of knowledge has put into fixing the machine has gone way 
past $200 by now. I think you're in it for the journey.

I was going to say "why not an ARM computer" when I realised that a) there 
isn't a single non-Intel or AMD PC on the HCL, and b) ARM computers are 
hard to come by.


-- 
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/7fb4145d-1b71-4096-911f-37c54679c177%40googlegroups.com.

Re: [qubes-users] Does the latest Linux kernel improve security for qubes?

2020-01-06 Thread fiftyfourthparallel


>
> I'm certainly no expert though.


I meant that you seem to be an expert in technology, maybe with a formal 
background in some form of engineering. I didn't mean to say that you were 
a Qubes expert, though three years of use and a year of in-depth tinkering 
does sound like an expert qualification.


 I wouldn't have been able to do it without the help from the mailing list.


My shiny new laptop would've turned into a shiny new projectile if not for 
the mailing list.


I seem to remember an FSF-approved ARM laptop made by some Chinese company 
> with a funny name a long time ago that ran Debian or something. 


I remember coming across something like that (memorable, since Chinese 
laptop companies in the privacy scene are a rarity), but couldn't find any 
trace of it on the FSF site. I did come across Pine64, though, which offers 
cheap ARM laptops.


Even if there were ARM options, I don't know if the Qubes development 
> community could really handle it.
>
 
I think the biggest obstacle for users is availability, as non-Intel/AMD 
PCs must be shipped and exposed to the possibility of interdiction for 
virtually all users. I can't speak for everyone, but I'd feel like my 
laptop is tainted or just unclean if I didn't buy an off-the-shelf item. 
Also, non-Intel/AMD Qubes would only serve a very select niche of the Qubes 
community, which is already a very select niche. Maybe a good stepping 
stone for enterprise products though (software + hardware offerings--the 
Apple of privacy and security? One can dream).


-- 
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/961b7f82-2c10-4b59-8450-99cecad68afb%40googlegroups.com.

Re: [qubes-users] Default fedora-30 template asking for password that I don't have

2020-01-06 Thread fiftyfourthparallel

>Also, try using `su` with no arguments and see if that asks for a password
also.

The problem was resolved by using the "su" command on its own (as opposed
to "su user", which prompted me for a password), which brought me straight
into "bash-5.0#", where I used the "cat > 00-macrandomizer.conf" command.

Typing "sudo cat > test.txt" into the user (non-su) prompt returned "bash:
test.txt: Permission denied".

>Also, don't type your dom0 passwords or disk password into VMs. You may
want to change them just to be safe.

My machine has never been connected to the internet when I typed in the
passwords (like, in the lifetime of the machine), so I figured they'll be
safe unless a verified iso has been compromised, but I'll do things the
Qubes way and change them anyways.

Not a minimal template because it was cloned from the default fedora-30 and
left unmolested by my fat fingers. I might play around with minimals in the
future, so the info provided might come in handy.

>Re: TOR firewall

I have the computational resources to spare, so I'll take the paranoid
route and firewall my Whonix-15-gw while keeping an eye on SOCKSPorts.

This thread has been resolved--thank you, Claudia and Chris.

--
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/fff7fd0e-1630-437e-bb0f-ae6b5c2f97a3%40googlegroups.com.

Re: [qubes-users] Re: Perplexed, why do so many here seem to prefer Fedora instead of ?

2020-01-07 Thread fiftyfourthparallel

>Enabling AppArmor in Debian + Qubes hardening

Glad I came across this post. Thanks for this and the hardening tool, Chris.

-- 
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/861db556-2c4d-4154-ab54-12582035b976%40googlegroups.com.

Re: [qubes-users] Default fedora-30 template asking for password that I don't have

2020-01-07 Thread fiftyfourthparallel

Uh... how do I mark a thread as 'complete'? Been looking all over for it.

-- 
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/2aefa96c-b484-4ebb-b644-3c1cb61b2c8c%40googlegroups.com.

Re: [qubes-users] Default fedora-30 template asking for password that I don't have

2020-01-07 Thread fiftyfourthparallel

This embarrassing episode reminded me that I really ought to take the 
Introduction to Linux course on EdX before venturing further.

-- 
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/f16eec8e-baf8-454a-a07b-d9b8e4edc9f5%40googlegroups.com.

[qubes-users] Re: Qubes OS 4.0.2 has been released!

2020-01-08 Thread fiftyfourthparallel

Hi Andrew,

I installed 4.0.2 on my Dell Inspiron 5593 without new issues.

The answer to the following question seems to have been implied in earlier 
responses, but I'd just like an explicit clarification: Can the "critical 
kernel bug" affect my security in any way?

-- 
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/b02ac1a2-ea36-481a-a83c-b85d56eb467c%40googlegroups.com.

[qubes-users] Re: Are there any security benefits of setting up standalonevm instead of appvm?

2020-01-08 Thread fiftyfourthparallel

Not an expert (or even technically inclined), but here's my suggestion:

I get how you feel because I've wondered about the exact same thing as you. 
Why not create multiple templates, with each containing programs you're 
comfortable grouping together? If your system supports it, you can put an 
app in each template.

I don't know whether this will increase your system's security, but I don't 
see why it would hurt as long as your system can handle it. More 
importantly, this configuration will make you feel more secure while not 
harming your security.


-- 
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/c4f6696d-cef6-4b32-86e6-9b3bae53bfaa%40googlegroups.com.

Re: [qubes-users] Re: Qubes OS 4.0.2 has been released!

2020-01-09 Thread fiftyfourthparallel

Thanks, and keep up the good work!

-- 
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/757f6e1b-d174-41a4-a4ec-d32f1c6fede0%40googlegroups.com.

[qubes-users] Which TemplateOS is more

If I were looking to maximize security, which would you say is more 
secure--Debian, Fedora, or some other distro, like Gentoo or Arch? If 
you've changed your sys-net, sys-usb templates to something other than 
Fedora, why, and to what?

I've read that Debian is generally considered more secure than Fedora 
because of, among other things, AppArmor and tighter oversight of packages. 
This makes me wonder why it is that Fedora is the default template for 
basically everything while Debian has its default AppArmor disabled. Are 
there any downsides to basically removing Fedora from my Qubes?

I've also considered that the nature of Qubes makes this discussion seem 
moot to some, but my stance is that I should increase security where 
feasible.

-- 
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/5223367f-9a05-4bae-bad2-a96e50d3bed6%40googlegroups.com.

[qubes-users] Choosing a TemplateOS for security

If I were looking to maximize security, which would you say is 
better--Debian, Fedora, or some other distro, like Gentoo or Arch? If 
you've changed your sys-net, sys-usb, or other templates to something other 
than Fedora, why? And to what?

I've read that Debian is generally considered more secure than Fedora 
because of, among other things, AppArmor and tighter oversight of packages. 
This makes me wonder why it is that Fedora is the default template for 
basically everything while Debian has its default AppArmor disabled. Are 
there any downsides to basically removing Fedora from my Qubes?

I've also considered that the nature of Qubes makes this discussion seem 
moot to some, but my stance is that I should increase security where 
feasible.

-- 
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/99638cb4-4e83-4d4c-9cf2-5cf1ae2e2f9a%40googlegroups.com.

Re: [qubes-users] Choosing a TemplateOS for security

Many thanks for the swift and detailed response. 

I'll enable AppArmor (using your instructions from another thread 
) and 
install your qubes hardening project. I was slightly hesitant before, but I 
did some quick Googling and realised you're on the Qubes team. Would you 
happen to have any other major security tips? Are there any ways to secure 
my booting process without a TPM?

I feel like this sort of information can be compiled into a handy-dandy 
security hardening guide for the documentation section. I wouldn't mind 
writing it up if you provide the technical details (I'm not very technical, 
but I can write).

-- 
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/b7b5b3af-bf85-4864-a573-3f9fd70db885%40googlegroups.com.

Re: [qubes-users] Choosing a TemplateOS for security