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

2020-08-17 Thread 54th Parallel 
While working on the script, I realized that a much simpler way of 
achieving the goal of verifying that repomd hasn't been tampered with is to 
just verify that the repomd.xml used for updating matches the onion version 
(itself cross-checked against multiple HTTPS copies) before the update, 
instead of comparing a list of installed packages against a parsed list of 
available packages. This means I won't have to write something to parse 
that list and makes the script much more compact. 

Unfortunately, this seems to mean tinkering with qubes-dom0-update itself 
and mandating the use of sys-whonix as the dom0 update VM instead of 
writing a separate script to be run after the fact.

On Friday, 14 August 2020 at 22:38:33 UTC+8 54th Parallel wrote:

> On Friday, 14 August 2020 at 19:24:11 UTC+8 disrupt_the_flow wrote:
>
>> I am so confused. Please explain what you want to do, but no like in a 
>> pseudo-script method.
>>
>
> The thread above contains all the pertinent information--if you're using 
> Google Groups, try 'expanding all' and reading through them. 
>

-- 
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/4d86b885-d756-480b-b43f-b3e95ca9547dn%40googlegroups.com.

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

2020-08-14 Thread 54th Parallel 
On Friday, 14 August 2020 at 19:24:11 UTC+8 disrupt_the_flow wrote:

> I am so confused. Please explain what you want to do, but no like in a 
> pseudo-script method.
>

The thread above contains all the pertinent information--if you're using 
Google Groups, try 'expanding all' and reading through them. 

-- 
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/fcd6bd80-5962-4502-8ce6-4bd9eb8536fen%40googlegroups.com.

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

2020-08-14 Thread 'disrupt_the_flow' via qubes-users 
On August 14, 2020 11:12:13 AM UTC, 54th Parallel 
 wrote:
>How does this look?
>
>*Outline of qubes-dom0-update-guard*
>
>*Usage: Use in conjunction with manual dom0 update*
>*sudo qubes-dom0-update -y && qubes-dom0-update-guard*
>
>
>Prompt 1: "Please enter the name of a clean VM with access to Tor (e.g.
>
>anon-whonix): "
>Check if entered name is a VM
>If false, alert and prompt again
>If true, proceed
>Check if VM has Tor access
>If Tor inaccessible, alert and prompt again
>If Tor accessible, enter input into variable 'VM1' and proceed
>
>Prompt 2: "Please enter the name of a clean, Debian-based disposable VM
>
>template with no assigned NetVM: "
>Check if enter name is a VM
>If false, alert and prompt again
>If true, proceed
>Check if VM is a disposable VM template (via qvm-prefs)
>If false, alert and prompt again
>If true, proceed
>Check if VM is based on Debian (via qvm-prefs)
>If false, alert and prompt again
>If true, proceed
>Check if VM has no NetVM assigned (via qvm-prefs)
>If false, alert and prompt again
>If true, enter input into variable 'VM1' and proceed
>
>Start VM1
>Retreive repodata from Onion and HTTPS mirrors
>Alert if less than 3 mirrors accessible
>Maybe halt process or give choice to continue?
>Maybe instead alert if low proportion (predefined) of mirrors 
>available
>Since that might indicate trouble
>Move repodata files to VM2 (starts VM2)
>
>In VM2
>Cross-check Onion and HTTPS repodata
>If any are different, alert, list differences, 
>If all match, proceed
>
>Write output of dom0 'rpm -qa' or 'yum list installed' to a file, 
>overwriting old version
>Copy into VM2 (same folder as repodata)
>
>In VM2, parse and re-write cross-checked Onion repodata into same
>format as 
>'rpm -qa' or 'yum list installed' output
>Include newest version of each package only
>  Cross-check output against dom0 output using same method for repodata
>  If one or more differences, alert (loudly) and list differences, 
>then 
>If both match, notify and 
>
>
>I think the part that will pose the biggest challenge to my almost 
>non-existence programming skills is the last part, where I have to
>write a 
>program that will parse and repackage Onion repodata into a list of
>most 
>recent packages. The rest seems workable, especially since I'm using
>Chris' 
>qubes4-multi-update as reference for the script, which will be in
>Python.
>On Monday, 10 August 2020 at 21:13:46 UTC+8 fiftyfour...@gmail.com
>wrote:
>
>> 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/2b0d3b92-7c9b-4595-860f-18bf4561f57dn%40googlegroups.com.

I am so confused. Please explain what you want to do, but no like in a 
pseudo-script method.

-- 
You received this message because you are subscribed to the Goog

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

2020-08-14 Thread 54th Parallel 
How does this look?

*Outline of qubes-dom0-update-guard*

*Usage: Use in conjunction with manual dom0 update*
*sudo qubes-dom0-update -y && qubes-dom0-update-guard*


Prompt 1: "Please enter the name of a clean VM with access to Tor (e.g. 
anon-whonix): "
Check if entered name is a VM
If false, alert and prompt again
If true, proceed
Check if VM has Tor access
If Tor inaccessible, alert and prompt again
If Tor accessible, enter input into variable 'VM1' and proceed

Prompt 2: "Please enter the name of a clean, Debian-based disposable VM 
template with no assigned NetVM: "
Check if enter name is a VM
If false, alert and prompt again
If true, proceed
Check if VM is a disposable VM template (via qvm-prefs)
If false, alert and prompt again
If true, proceed
Check if VM is based on Debian (via qvm-prefs)
If false, alert and prompt again
If true, proceed
Check if VM has no NetVM assigned (via qvm-prefs)
If false, alert and prompt again
If true, enter input into variable 'VM1' and proceed

Start VM1
Retreive repodata from Onion and HTTPS mirrors
Alert if less than 3 mirrors accessible
Maybe halt process or give choice to continue?
Maybe instead alert if low proportion (predefined) of mirrors 
available
Since that might indicate trouble
Move repodata files to VM2 (starts VM2)

In VM2
Cross-check Onion and HTTPS repodata
If any are different, alert, list differences, 
If all match, proceed

Write output of dom0 'rpm -qa' or 'yum list installed' to a file, 
overwriting old version
Copy into VM2 (same folder as repodata)

In VM2, parse and re-write cross-checked Onion repodata into same format as 
'rpm -qa' or 'yum list installed' output
Include newest version of each package only
Cross-check output against dom0 output using same method for repodata
If one or more differences, alert (loudly) and list differences, 
then 
If both match, notify and 


I think the part that will pose the biggest challenge to my almost 
non-existence programming skills is the last part, where I have to write a 
program that will parse and repackage Onion repodata into a list of most 
recent packages. The rest seems workable, especially since I'm using Chris' 
qubes4-multi-update as reference for the script, which will be in Python.
On Monday, 10 August 2020 at 21:13:46 UTC+8 fiftyfour...@gmail.com wrote:

> 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/2b0d3b92-7c9b-4595-860f-18bf4561f57dn%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.

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

2020-08-10 Thread Andrew David Wong 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2020-08-09 3:05 PM, Chris Laprise wrote:
> On 8/8/20 10:20 AM, fiftyfourthparal...@gmail.com wrote:
>> So the new overview of the script is: have a dedicated (and
>> hardened?) tor VM --basically, whonix-ws-- download the metadata
>> from a few mirror sites, compare them to the metadata from Tor,
>> and if all checks out, compare the tor version to the packages
>> installed in dom0. If it doesn't check out, alert user and ask
>> whether to proceed. To do this entirely in dom0 (keeping it safe
>> and simple for a newbie at programming), I'm going to use qvm-run
>> with --pass-io somewhere in my script, along with something to
>> read the whonix output and run cross checks.
>
> Just an idea: Use the Qubes Security Bulletins as your reference
> for checking package versions:
>
> https://www.qubes-os.org/security/pack/
>
> These bulletins are signed txt files, which makes them secure. The
> difficult part would be parsing the QSBs themselves but I wonder
> if Qubes devs would agree to a standard format going forward to
> make it easier + reliable.
>

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:

```
Patching
=

The specific packages that resolve the problems discussed in this
bulletin are as follows:

  For Qubes :
  - 
  - 
  - 
  - 

  For Qubes :
  - 
  - 
  - 
  - 

The packages are to be installed in dom0 via the Qube Manager or via
the qubes-dom0-update command as follows:

  For updates from the stable repository (not immediately available):
  $ sudo qubes-dom0-update

  For updates from the security-testing repository:
  $ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing

A system restart will be required afterwards.

These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community.

If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.
```

Feel free to take a look at any QSBs for specific examples. [2] I'm sure
it wouldn't be a problem to change the syntax slightly if that would
make things easier, as long as it doesn't harm human readability.


[1] https://www.qubes-os.org/security/bulletins/template/
[2] https://www.qubes-os.org/security/bulletins/

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAl8xI+QACgkQ203TvDlQ
MDBOyg//T0/mxeE+pVlF7LIUuShy1B55Fjxxi35JhlkfX9Ws7fLT7hLh6172cxGQ
55E1WXlZ19AE9OZFeIUNX08ov5X6/OelAy8qFdtAmXFI3dEDzdjDVRk8naRpdtu6
hxqsnP4zsHLj0WQEYnsuPyjfgFuIZCy5TfXRlxm8u4l9oorK/IB6sqhBftwnT078
U37Sls/fPlKpnZ0rPJ6Kv/cGbXG1wKpxuui2LAsTis/IY/3TsRpEY8CLa1oIKX53
okQCY8GXnp7ova+8LEyhHBdoDK4iT1Fl8ohfJ+JzekE2SaR/7CnFGO2XrwyiFyXw
Zz9Huu+UIJl+ygIGK80HBBmUNSF+/sSoMSo0SYKZP96JnV0Vka54EEppH5Ctzexy
8yVIpYSwmavHOUO2+GVXh4ykETgkpC0UKg+QLoWacNTRqihT5XTCY3J7SqNLn93Z
21OHE5bAy7/cXNtq0rrnw/BeIzgmrHuaKMrOuW9HExoWIrroyb4a+rpEPbQfsCrb
G09/1A5uOt04ZQXKVhly2UYBA8Zzlld6vh4mKlCYBRBFBzAgJ69yHt3gubWcMAVV
f42Za2qpOZsNharvb6lvHI/7E0XY7FpqvOHZuVfX1c0UiTifTm5ZLwN0IDpGgw0f
1K26/H7GriIU4MZlC4qjToRGGXf40jV6l9zHZUzUzbdSGxEF20A=
=Gs9V
-END PGP SIGNATURE-

-- 
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/1074ec2f-3146-f1d6-7c73-6aaefdafd200%40qubes-os.org.

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

2020-08-09 Thread Chris Laprise 

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


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


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

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




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



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

--
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/9c464f30-6ae5-9ace-3168-6d2cc9daf8e6%40posteo.net.

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

2020-08-09 Thread 'awokd' via qubes-users 
fiftyfourthparal...@gmail.com:

> 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?
> 
Probably this option, mostly because it seems simpler to copy both data
sources to the same AppVM responsible for cross-checking.

-- 
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

-- 
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/a356d79b-e5a8-71c5-6571-437ca7b216ca%40danwin1210.me.

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-08 Thread 'awokd' via qubes-users 
fiftyfourthparal...@gmail.com:

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

It's an interesting security exercise; but agree, don't think our open
source availability syncs up very often. :)

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

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.

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

Probably want your script to alert if under 3 reporting.

-- 
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

-- 
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/a705282f-bb56-3383-a840-bb9077b61a9c%40danwin1210.me.

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 unman 
On Fri, Aug 07, 2020 at 09:07:39PM -0700, fiftyfourthparal...@gmail.com wrote:
> 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. 
> 
> -- 

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

-- 
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/20200808125121.GA14753%40thirdeyesecurity.org.

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-07 Thread Chris Laprise 

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

fiftyfourthparal...@gmail.com:


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


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


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


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


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

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

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

2020-08-07 Thread 'awokd' via qubes-users 
fiftyfourthparal...@gmail.com:

> Right now my plan is to take the output of 'rpm -qa' or 'yum list 
> installed' and compare it via some sort of 'match' or 'crosscheck' function 
> to a repo list pulled from somewhere secure (i.e. not tampered with by 
> potential adversaries) and maybe imported into dom0 from a specialized 
> secure appVM, creating a security tradeoff.
> 
"[P]ulled from somewhere secure"- if the concern is someone tampering
with your HTTPS traffic in particular, you will probably want to use a
different method of obtaining the repo list. Tor might work.

-- 
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

-- 
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/fa2e1c89-c057-55f7-3a2c-abff63f1cdc5%40danwin1210.me.

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