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] Does the latest Linux kernel improve security for qubes?

2020-01-06 Thread Chris Laprise

On 1/6/20 4:11 PM, Claudia wrote:

January 6, 2020 8:20 PM, "Chris Laprise"  wrote:


On 1/5/20 11:30 PM, Claudia wrote:


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. This was 
even before the recent
Intel shit show.


Indeed. These management engines are ubiquitous, so I think we should
try to answer the question: Can they be properly deactivated?

Given everything else, its possible the answer is 'no' for Intel (we
already know this) and 'yes' for AMD.


Plus, I got a really good deal on this particular machine (so admittedly a bit 
of an impulse buy).
And I have to say, despite a lot of troubleshooting and a few remaining 
glitches, it actually runs
Qubes surprisingly well, all things considered. But... yeah, kids, don't try 
this at home.


I tend to shy away from 'consumer' models, bc they almost always
misconfigure advanced features like the IOMMU as the firmware isn't
carefully managed. Dell describes Inspiron models as "Home and Home Office".


On top of that, though, IOMMU problems and ACPI bugs and such appear to be 
widespread in the Ryzen family, across different computer makes and models, 
including higher-end ones and motherboards. I think there are some links about 
it in some of my other threads. That's what makes me think Ryzen itself has 
some problems of its own, or at least certain generations or something. Bad 
firmware can break good hardware, but good firmware can't fix bad hardware. 
Other AMD product lines though like Threadripper for example don't seem to be 
any worse than Intel from what I've heard. But like I said, it's really not 
that bad, all things considered -- I now have fully working suspend/resume 
which is more than a lot of Qubes users can say.



That's good to know. I just noticed your long HCL update thread for the 
AMD Inspiron. Since I'm behind with the HCL list and you put so much 
work into your report, I'll move yours to the top of my queue. It should 
get listed sometime this week. Thanks for the detailed reporting!


--

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

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


[qubes-users] Qubes 4 starts, but no VMs will load.

2020-01-06 Thread aisteruannanorna
Dear Fellows,

I can boot into Qubes normally, except I get some scary looking boot 
messages (see boot.log contents below.) No VMs will start. After some 
digging in logs, I found that there was a syntax error on trying to load 
/usr/lib/tmpfiles.d/qubes.conf. The file seemed to be corrupted, so I 
renamed it and made a new qubes.conf based on what I found on a working 
qubes install (I typed it line-by-line, no intentional alterations.) This 
seems to have fixed the syntax error, but I still can't get qubesd to load, 
and so can't start any VMs or even start a backup.

I'm not sure what to try next. I strongly suspect more corrupt files are to 
blame. 

As always, any help will be appreciated.

Thanks in advance,


  T. S. P. Capehart



 %G %G %G[ [0;32m  OK   [0m] Started Cryptography Setup for 
luks-e79f0b60-d59c-4caa-b422-fbca72c62f31.
[ [0;32m  OK   [0m] Found device 
/dev/mapper/luks-e79f0b60-d59c-4caa-b422-fbca72c62f31.
[ [0;32m  OK   [0m] Reached target Encrypted Volumes.
[ [0;32m  OK   [0m] Reached target System Initialization.
[ [0;32m  OK   [0m] Reached target Basic System.
[ [0;32m  OK   [0m] Found device /dev/mapper/qubes_dom0-root.
[ [0;32m  OK   [0m] Reached target Initrd Root Device.
[ [0;32m  OK   [0m] Started dracut initqueue hook.
 Starting File System Check on /dev/mapper/qubes_dom0-root...
[ [0;32m  OK   [0m] Reached target Remote File Systems (Pre).
[ [0;32m  OK   [0m] Reached target Remote File Systems.
[ [0;32m  OK   [0m] Started File System Check on 
/dev/mapper/qubes_dom0-root.
 Mounting /sysroot...
[ [0;32m  OK   [0m] Mounted /sysroot.
[ [0;32m  OK   [0m] Reached target Initrd Root File System.
 Starting Reload Configuration from the Real Root...
[ [0;32m  OK   [0m] Started Reload Configuration from the Real Root.
[ [0;32m  OK   [0m] Reached target Initrd File Systems.
[ [0;32m  OK   [0m] Reached target Initrd Default Target.
 Starting Cleaning Up and Shutting Down Daemons...
 Starting Plymouth switch root service...
[ [0;32m  OK   [0m] Stopped target Timers.
 Stopping Forward Password Requests to Plymouth...
[ [0;32m  OK   [0m] Stopped target Remote File Systems.
[ [0;32m  OK   [0m] Stopped target Remote File Systems (Pre).
[ [0;32m  OK   [0m] Stopped dracut initqueue hook.
[ [0;32m  OK   [0m] Stopped dracut cmdline hook.
[ [0;32m  OK   [0m] Stopped Forward Password Requests to Plymouth.
[ [0;32m  OK   [0m] Stopped Cleaning Up and Shutting Down Daemons.
[ [0;32m  OK   [0m] Stopped target Initrd Default Target.
[ [0;32m  OK   [0m] Stopped target Basic System.
[ [0;32m  OK   [0m] Stopped target Sockets.
[ [0;32m  OK   [0m] Stopped target System Initialization.
[ [0;32m  OK   [0m] Stopped Create Volatile Files and Directories.
[ [0;32m  OK   [0m] Stopped Apply Kernel Variables.
[ [0;32m  OK   [0m] Stopped target Local File Systems.
[ [0;32m  OK   [0m] Stopped Load Kernel Modules.
[ [0;32m  OK   [0m] Stopped target Encrypted Volumes.
 Stopping udev Kernel Device Manager...
[ [0;32m  OK   [0m] Stopped udev Coldplug all Devices.
[ [0;32m  OK   [0m] Stopped target Swap.
[ [0;32m  OK   [0m] Stopped target Slices.
[ [0;32m  OK   [0m] Stopped target Paths.
[ [0;32m  OK   [0m] Stopped target Initrd Root Device.
[ [0;32m  OK   [0m] Started Plymouth switch root service.
[ [0;32m  OK   [0m] Stopped udev Kernel Device Manager.
[ [0;32m  OK   [0m] Stopped Create Static Device Nodes in /dev.
[ [0;32m  OK   [0m] Stopped Create list of required static device nodes for 
the current kernel.
[ [0;32m  OK   [0m] Closed udev Kernel Socket.
[ [0;32m  OK   [0m] Closed udev Control Socket.
 Starting Cleanup udevd DB...
[ [0;32m  OK   [0m] Started Cleanup udevd DB.
[ [0;32m  OK   [0m] Reached target Switch Root.
 Starting Switch Root...
 %G %G[ [0;1;31mFAILED [0m] Failed to start Qubes DB agent.
See 'systemctl status qubes-db-dom0.service' for details.
[ [0;32m  OK   [0m] Started Login Service.
[ [0;32m  OK   [0m] Started The Xen xenstore.
 Starting Virtualization daemon...
 Starting Xenconsoled - handles logging from guest consoles and 
hypervisor...
 Starting xen-init-dom0, initialise Dom0 configuration (xenstore 
nodes, JSON configuration stub)...
[ [0;32m  OK   [0m] Started Xenconsoled - handles logging from guest 
consoles and hypervisor.
[ [0;32m  OK   [0m] Started xen-init-dom0, initialise Dom0 configuration 
(xenstore nodes, JSON configuration stub).
[ [0;32m  OK   [0m] Started Daemon for power management.
[ [0;32m  OK   [0m] Started Virtualization daemon.
[ [0;1;31mFAILED [0m] Failed to start Qubes memory management daemon.
See 'systemctl status qubes-qmemman.service' for details.
[ [0;1;31mFAILED [0m] Failed to start Qubes OS daemon.
See 'systemctl status qubesd.service' for details.
 Starting Qubes Dom0 startup setup...
[ [0;32m  OK   [0m] Started Qubes Dom0 startup setup.
 Starting Start Qubes VM sys-usb...
 Starting Start Qubes VM sys-usb-input...
[ [0;1;31mFAILED 

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

2020-01-06 Thread Claudia
January 6, 2020 8:45 PM, "Chris Laprise"  wrote:

> On 1/6/20 3:22 PM, Claudia wrote:
> 
> I think s/he is really using a "minimal" template here. That would cause
> sudo to be disabled by default. On these minimal templates, you can only
> gain root privs by using 'qvm-run -u root' in dom0 or by using that
> qvm-run command to install the 'qubes-core-agent-passwordless-root'
> package which adds the no-password sudo capability back.

Oh, that's possible.

>>> 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?
>> 
>> This came up a while back. I'll try to find the thread for you. In short, I 
>> remember reading in the
>> Tor documentation that anyone with access to your SOCKSPort can potentially 
>> learn information about
>> what sites you're visiting. So in that case, yes, separate whonix gateways 
>> would be beneficial. On
>> the other hand, the Whonix developers know more about this than I do, and 
>> I'm assuming they did
>> everything right. I never got around to investigating though. You might have 
>> better luck asking on
>> the Whonix forum or Tor stack exchange.
> 
> I think you'll find different opinions about this. IMO, as with adding
> extra firewall to VPN VMs, it just wastes resources. The VPN or Tor gw
> already has 'low' attack surface and firewall capability, and they
> typically filter which external gateways they do and don't talk to based
> on crypto-enforced identification.

Well, to me there's a difference between theoretical attack surfaces and stuff 
like that, versus official documentation telling you it's not safe to share 
SOCKSPorts. If that's the case, that is. It was a really long time ago and I 
don't remember what it said exactly. But yeah, I agree, I wouldn't necessarily 
go adding redundant VMs just out of paranoia. Personally I only run one whonix 
gateway even though I probably have enough ram to run a dozen.

-- 
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/14769721819d68b68ee1815ab4a1a10d%40disroot.org.


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

2020-01-06 Thread Claudia
January 6, 2020 8:20 PM, "Chris Laprise"  wrote:

> On 1/5/20 11:30 PM, Claudia wrote:
> 
>> 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. This was 
>> even before the recent
>> Intel shit show.
> 
> Indeed. These management engines are ubiquitous, so I think we should
> try to answer the question: Can they be properly deactivated?
> 
> Given everything else, its possible the answer is 'no' for Intel (we
> already know this) and 'yes' for AMD.
> 
>> Plus, I got a really good deal on this particular machine (so admittedly a 
>> bit of an impulse buy).
>> And I have to say, despite a lot of troubleshooting and a few remaining 
>> glitches, it actually runs
>> Qubes surprisingly well, all things considered. But... yeah, kids, don't try 
>> this at home.
> 
> I tend to shy away from 'consumer' models, bc they almost always
> misconfigure advanced features like the IOMMU as the firmware isn't
> carefully managed. Dell describes Inspiron models as "Home and Home Office".

On top of that, though, IOMMU problems and ACPI bugs and such appear to be 
widespread in the Ryzen family, across different computer makes and models, 
including higher-end ones and motherboards. I think there are some links about 
it in some of my other threads. That's what makes me think Ryzen itself has 
some problems of its own, or at least certain generations or something. Bad 
firmware can break good hardware, but good firmware can't fix bad hardware. 
Other AMD product lines though like Threadripper for example don't seem to be 
any worse than Intel from what I've heard. But like I said, it's really not 
that bad, all things considered -- I now have fully working suspend/resume 
which is more than a lot of Qubes users can say.

-- 
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/7b61a202c5a8f480ed8a0fb10c59c529%40disroot.org.


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

2020-01-06 Thread Chris Laprise

On 1/6/20 3:22 PM, Claudia wrote:

January 6, 2020 5:02 AM, fiftyfourthparal...@gmail.com wrote:


Hello,


Oops, I forgot to reply to this. Sorry.


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


If running as user, you'll get "Permission denied" but it won't ask for a 
password as far as I know. You need to put sudo in front of the command. This is when it 
would normally ask you for a password, but it *should* just work without asking for a 
password. Also, try using `su` with no arguments and see if that asks for a password also.

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

Run `sudo -l`, you should see
User user may run the following commands on fedora-30:
 (ALL) NOPASSWD: ALL
 (root) NOPASSWD: /bin/udevadm trigger --action\=add 
--sysname-match\=event[0-9]

When you're prompted for the password, check /var/log/xen/console/gues-fedora-30.log (on 
dom0) for any problems. You should see an audit line about the su or sudo command. 
Normally it should say "res=success" towards the end.


I think s/he is really using a "minimal" template here. That would cause 
sudo to be disabled by default. On these minimal templates, you can only 
gain root privs by using 'qvm-run -u root' in dom0 or by using that 
qvm-run command to install the 'qubes-core-agent-passwordless-root' 
package which adds the no-password sudo capability back.


You can also tie sudo to a secure yes/no prompt:

https://www.qubes-os.org/doc/vm-sudo/#replacing-passwordless-root-access-with-dom0-user-prompt

https://github.com/tasket/Qubes-VM-hardening/blob/master/configure-sudo-prompt




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?


This came up a while back. I'll try to find the thread for you. In short, I 
remember reading in the Tor documentation that anyone with access to your 
SOCKSPort can potentially learn information about what sites you're visiting. 
So in that case, yes, separate whonix gateways would be beneficial. On the 
other hand, the Whonix developers know more about this than I do, and I'm 
assuming they did everything right. I never got around to investigating though. 
You might have better luck asking on the Whonix forum or Tor stack exchange.


I think you'll find different opinions about this. IMO, as with adding 
extra firewall to VPN VMs, it just wastes resources. The VPN or Tor gw 
already has 'low' attack surface and firewall capability, and they 
typically filter which external gateways they do and don't talk to based 
on crypto-enforced identification.


--

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

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


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

2020-01-06 Thread Claudia
January 6, 2020 5:02 AM, fiftyfourthparal...@gmail.com wrote:

> Hello,

Oops, I forgot to reply to this. Sorry.

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

If running as user, you'll get "Permission denied" but it won't ask for a 
password as far as I know. You need to put sudo in front of the command. This 
is when it would normally ask you for a password, but it *should* just work 
without asking for a password. Also, try using `su` with no arguments and see 
if that asks for a password also.

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

Run `sudo -l`, you should see
User user may run the following commands on fedora-30:
(ALL) NOPASSWD: ALL
(root) NOPASSWD: /bin/udevadm trigger --action\=add 
--sysname-match\=event[0-9]

When you're prompted for the password, check 
/var/log/xen/console/gues-fedora-30.log (on dom0) for any problems. You should 
see an audit line about the su or sudo command. Normally it should say 
"res=success" towards the end.

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

This came up a while back. I'll try to find the thread for you. In short, I 
remember reading in the Tor documentation that anyone with access to your 
SOCKSPort can potentially learn information about what sites you're visiting. 
So in that case, yes, separate whonix gateways would be beneficial. On the 
other hand, the Whonix developers know more about this than I do, and I'm 
assuming they did everything right. I never got around to investigating though. 
You might have better luck asking on the Whonix forum or Tor stack exchange.

-- 
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/de8a36d828a4d7af38bc4f9b1525c345%40disroot.org.


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

2020-01-06 Thread Chris Laprise

On 1/5/20 11:30 PM, Claudia wrote:

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. This was even before the recent Intel shit show.


Indeed. These management engines are ubiquitous, so I think we should 
try to answer the question: Can they be properly deactivated?


Given everything else, its possible the answer is 'no' for Intel (we 
already know this) and 'yes' for AMD.



Plus, I got a really good deal on this particular machine (so admittedly a bit 
of an impulse buy). And I have to say, despite a lot of troubleshooting and a 
few remaining glitches, it actually runs Qubes surprisingly well, all things 
considered. But... yeah, kids, don't try this at home.


I tend to shy away from 'consumer' models, bc they almost always 
misconfigure advanced features like the IOMMU as the firmware isn't 
carefully managed. Dell describes Inspiron models as "Home and Home Office".


The Lenovo G505s I have is also consumer grade and can't easily run 
Qubes bc they stopped updating the firmware in 2015(!) and IOMMU is 
present but won't work. Only thing that will fix this is flashing it 
with Coreboot.


--

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

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


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

2020-01-06 Thread Chris Laprise

On 1/6/20 9:20 AM, gorked wrote:
Thanks for replying.   I will keep what you say in mind in using Debian 
when I get into a position to try out QUBES.  Apparently I made a 
mistake in that, I thought I read on the CentOS Forum that if I did 
updates, it would receive the same security updates as Red Hat.   
Perhaps Red Hat is not always the most secure?  Or maybe it is that what 
they really market is support, since that is what a business requires to 
use Linux?


I wouldn't say CentOS security updates were any poorer than RHEL. RH 
does them bc they reluctantly had to save CentOS from disbanding, even 
though it is counter to their stated business model. This is one of 
those "complicated history" issues.


BTW, there is a community-maintained CentOS template for Qubes.



To Morph this post a bit, being a lot of intrusions are now coming in 
with the Web Browser, which Web Browser is now the recommended one for 
Security?   I have been using Firefox, with a lot of Addons, but I had 
to turn off the Java Script to buy items online.


This is not such a worry on Qubes if you keep things in separate VMs. 
But if you must worry about app-level security, I would stick with 
Firefox on Debian 10 and enable AppArmor (Debian 10 normally has AA 
enabled, but the Qubes configuration has an unfortunate side-effect 
where the default is disabled).


To enable AppArmor on Debian VMs, you can change the 'kernelopts' VM 
pref for the template to add two parameters to the default 'nopat':


[dom0]$ qvm-prefs debian-10 kernelopts 'nopat apparmor=1 security=apparmor'

This will automatically carry over to all VMs based on that template 
that do not have their own customized kernelopts setting. (If a VM has a 
custom kernelopts setting, you'll have to add the AA params to it manually.)


Also, Firefox is not the only program that benefits from AppArmor. IMO 
its easy to do and a win-win. Philosophically, I think Qubes users and 
devs should hold the point of view that while guest VM code shouldn't be 
relied-on as primary defense, it is best to let the guest OS use all of 
its own defenses as long as they are default or easy to enable + use.


Another thing that can improve security inside a VM is my 
Qubes-VM-hardening project, which restores user-auth security in VMs 
(but with yes/no prompts, not passwords) and prevents malware from 
hijacking the VM startup environment...


https://github.com/tasket/Qubes-VM-hardening

A note about Whonix templates: The developer for Whonix is already 
making efforts to include this kind of defense (and more). But for 
AppArmor, the last time I checked you still had to turn it on yourself. 
Since Whonix is based on Debian, the procedure is the same as above (use 
'kernelopts' setting).




Is there a movement to create a standard about what a Web Page should 
never be allowed to do, to facilitate security on the internet?


Yes, there is a movement and tech project headed by Tim Berners-Lee:

https://betanews.com/2018/09/29/tim-berners-lee-solid/

https://www.theguardian.com/technology/2019/nov/24/tim-berners-lee-unveils-global-plan-to-save-the-internet

I should also mention the I2P project, which over time has developed a 
different yet comparable approach to security and privacy. Tor (and by 
extension, Whonix) is also evolving into this approach but Tor's 
outproxy default is a snag.




    Surveillance Capitalism now rules.



--

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

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/536676a4-da0d-3570-83bc-ab31c36c3a74%40posteo.net.


Re: [qubes-users] Qubes/Xen doesn't comply with IOMMU grouping rules for PCI passthru

2020-01-06 Thread Claudia
December 30, 2019 7:12 PM, "qubes123"  wrote:

>> The improper grouping is probably somewhere in AGESA, which is provided
> 
>>> to the manufacturers by AMD. It could be because of hardware related
>>> limitations, which again are supplied by AMD. Sometimes vendors take
>>> liberties (cost cutting measures) with both and break functionality, as
>>> their primary/sole concern is that Windows boots. This can especially be
>>> the case with consumer class machines such as Ryzen. Agree it would be
>>> nice if Xen handled this failure mode more gracefully. Not sure there is
>>> much Qubes can do here, though. On the other hand, my older AMD
>>> (pre-Ryzen) consumer laptop running Coreboot has correct groupings.
> 
> I could be wrong, but aren't these PCI assignments and hierarchies coded 
> within the ACPI DSDT table
> in BIOS?

I guess in some cases they are, and in other cases they're in hardware. For 
example if you have two devices between a physical PCI bridge, communication 
between those two devices might be sent across the bridge without ever making 
it to the IOMMU. I don't think there's any software approach could do anything 
about that kind of situation.

In my case, the USB controllers and most of the other devices are functions of 
the same PCI device, 00:03.0{1,2,3,4,6}. Therefore most likely any 
communication between them is happening within the device and not going to the 
IOMMU (00:00.2). However I don't know if this is because of the physical 
structure, or if it could be changed by modifying ACPI tables. I guess the only 
way to know would be to try it.

> I remember as if in UEFI the ACPI tables could be overridden somehow...
> 
> Or - since kernel 5.3.x(?) you can supply certain ACPI tables (as files, 
> stored in initrd) to the
> kernel using commandline parameters* (some additional acpi manipulations are 
> needed to extract the
> current dsdt to see what is in there and make changes in aml...)

I understand the part about uploading the ACPI tables via initrd, but I would 
have no idea how to extract them, what they mean, or what changes to make to 
them.

Also, I haven't figured out if ACPI override actually changes the behavior of 
PCI devices, or if it just spoofs the information provided to the 
kernel/hypervisor (which would make it unnecessary/ineffective on Xen). 
According to the OSDev wiki: "AML interpreter can build up a database of all 
devices within a system and the properties and functions they support (in 
reference to configuration and power management)."

> Or - before all - you can simply try to boot the kernel with cmdline: 
> acpi=nocrs (or off) and let
> the kernel "enroll" the PCI devices. Maybe worth to try - just one reboot...

I did some tests by playing sound in a VM and then binding pciback to the USB 
controllers to simulate passthru. None of them were successful. At the time of 
the bind command, audio stopped, and the screen would freeze unless nomodeset 
was on. I did the testing in the 4.1 pre-release.

I tested four combinations of parameters: (none), acpi=off, acpi=nocrs, and 
acpi=nocrs pci=nocrs, each with and without Xen. In the non-Xen tests, 
iommu_groups was the same every time. In the Xen tests, xl dmesg and xl info 
were identical every time. In all tests, lspci and lspci -t were identical. 
Kernel logs and lspci -kvvnn had some differences each time, but nothing that 
looked important. If I should look for anything specific please let me know. 
Note, the data was collected right after I logged in, before I performed the 
passthru. Not one of my better decisions. 

However the only thing I recall seeing in the logs at the time of the passthru 
was this, with acpi=nocrs pci=nocrs:
xhci_hcd :03:00.4: Host halt failed, -110
xhci_hcd :03:00.4: Host controller not halted, aborting reset.
xhci_hcd :03:00.4: USB bus 3 deregistered
pciback :03:00.3: seizing device
xen: registering gsi 55 triggering 0 polarity 1
Already setup the GSI :55
pciback :03:00.4: seizing device
xen: registering gsi 52 triggering 0 polarity 1
Already setup the GSI :52

Could it be a PCI reset related problem?



Finally, a possible workaround I thought of is putting sys-usb into PV mode, 
since PV passthru doesn't use the IOMMU. It wouldn't be quite as secure as HVM, 
as it wouldn't prevent a DMA attack, but it would still be better than having 
USB in dom0. However it looks like Qubes 4.1 isn't going to support any kind of 
passthru for PVs, so I'll ultimately end up back where I started. I don't 
currently have sys-usb installed, but I might try it when I have some time.

-- 
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/b88a85b62f2e84c57ec5fbf87f14b9ec%40disroot.org.


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

2020-01-06 Thread dhorf-hfref . 4a288f10
On Mon, Jan 06, 2020 at 08:35:07PM +0100, Diederik de Haas wrote:
> On vrijdag 3 januari 2020 03:21:07 CET Andrew David Wong wrote:
> > Qubes 4.0.2 is available on the Downloads page:
> I'm only seeing 4.0.2-rc3, but not the final one on that page.

retracted because a critical kernel bug made it past all testing.
if 4.0.2 or the rc3 work for you, all is well. 
if not, go with 4.0.1 for now.

whichever you install, please make sure to update both dom0 and
all templates after install.


-- 
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/20200106194041.GF8973%40priv-mua.


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

2020-01-06 Thread Diederik de Haas
On vrijdag 3 januari 2020 03:21:07 CET Andrew David Wong wrote:
> Qubes 4.0.2 is available on the Downloads page:
> 
> https://www.qubes-os.org/downloads/

I'm only seeing 4.0.2-rc3, but not the final one on that page.

The files are on https://ftp.qubes-os.org/iso/ so I assume it's also on other 
mirrors, but the primary download page doesn't list 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/4127259.ZEVRj4yrUH%40bagend.


signature.asc
Description: This is a digitally signed message part.


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

2020-01-06 Thread Claudia
January 6, 2020 2:20 PM, "gorked"  wrote:


> To Morph this post a bit, being a lot of intrusions are now coming in with 
> the Web Browser, which
> Web Browser is now the recommended one for Security? I have been using 
> Firefox, with a lot of
> Addons, but I had to turn off the Java Script to buy items online.


I would definitely not say Firefox is the most secure (though it is among the 
best for privacy). But the good news is that, that doesn't really matter in 
Qubes. Qubes always assumes the browser is compromised. As long as you use 
Qubes correctly (use different VMs for different tasks/identities, use DispVMs 
where possible, etc), you can mostly rely on the hypervisor instead of the 
browser for security. For example, use a different VM for buying things online 
with JS enabled, than for your regular browsing. Arguably there should be 
security/hardening at all levels and not just the hypervisor, but the Qubes 
core principle is security by isolation.

> Is there a movement to create a standard about what a Web Page should never 
> be allowed to do, to
> facilitate security on the internet?

Not sure what you mean. In terms of JS functions and permissions and things 
like that? The w3c is who decides the standards for what web pages should be 
allowed to do and access, and even that is not totally standard: ultimately 
each browser, and each user, makes their own decisions. I don't think there 
will ever be a universal list of rules that suits all users and all websites. 
This is more a matter of privacy than security. I.e. no rules or standards are 
going to prevent a heap overflow vulnerability or something like that.

> Surveillance Capitalism now rules.

-- 
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/b37fd87705416e6d4b1864b283f3e45b%40disroot.org.


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.


[qubes-users] Standalone Win10VM with private networt

2020-01-06 Thread Hayden Tim

I finally was able to get some time to install qubes on an HP laptop that 
became free to play with. I installed version 4.0 and have updated it a few 
times. Everything works at this point, except having a USB-VM. I ended up 
having to let dom0 handle the USB hardware. This is not a problem.

My problem is that I set up a Win10 StandaloneVM that works fine by itself, but 
I am trying to set up a private network between my WorkVM and the Win10VM. I 
set up a new NetVMx without hardware, a new FirewallVMx, and am using the 
FirewallVMx for networking the WorkVM and the Win10VM. I followed the qubes 
instructions for Enabling networking between two qubes 
(https://www.qubes-os.org/doc/firewall/). My intention is to use the new 
network to transfer files between the two VMs and to make sure Windows cannot 
get to the Internet.

I can ping the IPs for the FirewallVMx, the gateway, and the Win10VM from my 
WorkVM, but neither the FirewallVMx nor the Win10VM can ping the WorkVM. Also, 
after installing a couple of different Remote Desktop tools on my WorkVM, they 
both fail to connect to the Win10VM.

Is there a reason I cannot ping the WorkVM? Can that also be the reason for the 
Remote Desktop tools to fail connections?
Tim

-- 
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/cbb75e13d92d50a1e3769324ebb596ae%40jamadots.com.


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

2020-01-06 Thread gorked
Thanks for replying.   I will keep what you say in mind in using Debian 
when I get into a position to try out QUBES.  Apparently I made a mistake 
in that, I thought I read on the CentOS Forum that if I did updates, it 
would receive the same security updates as Red Hat.   Perhaps Red Hat is 
not always the most secure?  Or maybe it is that what they really market is 
support, since that is what a business requires to use Linux?

To Morph this post a bit, being a lot of intrusions are now coming in with 
the Web Browser, which Web Browser is now the recommended one for Security? 
  I have been using Firefox, with a lot of Addons, but I had to turn off 
the Java Script to buy items online.  

Is there a movement to create a standard about what a Web Page should never 
be allowed to do, to facilitate security on the internet?

   Surveillance Capitalism now rules.   

-- 
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/83b4921a-b7a7-4aed-a685-5bee989bb68d%40googlegroups.com.


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

2020-01-06 Thread Claudia
January 6, 2020 5:16 AM, fiftyfourthparal...@gmail.com wrote:

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

Looking at it that way, you have a good point. I'm certainly no expert though. 
I've only been using Qubes about three years, and only tinkering with it less 
than a year at most. I've learned a *lot* in the last six months, and I still 
haven't even scratched the surface. I wouldn't have been able to do it without 
the help from the mailing list.

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

Non-Intel/AMD x86 machines suitable for Qubes are probably just as hard to come 
by, I would imagine. But besides the issue of trust/transparency with regards 
to AMD and Intel, I think much of the problem is also rooted in the design and 
cruft of the x86 architecture itself (read Joanna's "x86 Considered Harmful").

There has been some talk about porting Qubes to other architectures like ARM 
and POWER9, both historically and recently, but I haven't been following it at 
all and I don't know how realistic any of it is. For example: 
https://www.mail-archive.com/qubes-users@googlegroups.com/msg31704.html

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. But yeah, I don't 
think ARM desktop/laptop computers are going to catch on any time soon. And 
from what I understand porting to ARM is a little more complicated due to lack 
of ACPI and all that stuff. Even if there were ARM options, I don't know if the 
Qubes development community could really handle 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/141ae179fd5994e307e8150be547157c%40disroot.org.