[qubes-users] R4.0.4 Wiin10: block device dom0:loop1 not available

2021-04-12 Thread Steve Coleman
I have been having problems with starting a Win10 VM for a while now.
Previously Qubes would always timeout and shut it down even though the VM
was up and running fine. My impression is that once the VM was forcibly
terminated/killed due to a timeout, usually the next time it would start up
normally. I could spend as much as an hour just trying to get it startup
properly, and now it doesn't even get that far.

Now after enough forced terminations it is unable to even begin starting
and no logs are being created at all. The only symptom is the popup message
"block device dom0:loop1 not available". I don't see anything significant
from journalctl or dmesg. Running in debug mode does absolutely nothing.
Restoring from backup just gives the same loop error message when
attempting to start the restored VM.

Q: What is this loop1 supposed to point at, and is there a way to recreate
it?

I would hate to have to rebuild this VM from scratch because I had to fight
with Microsoft just to get the license activated the first time around. II
need this VM to run my document scanner.

thanks,

Steve

-- 
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/CAJ5FDnhuBCAC24qRd-xrMxf3pRE8FBy8be7wO_W24U%3DFih2%2BvA%40mail.gmail.com.


Re: [qubes-users] Help creating menu entry in a template based AppVM where the App itself is not installed in the template

2021-04-03 Thread Steve Coleman
On Sat, Apr 3, 2021, 3:58 PM one7two99  wrote:

> Hello,
>
> I am running Crossover (to start Office 2010) within Qubes and have some
> trouble with the App-shortcuts.
>
> The setup:
>
> - I have a template VM ("t-debian-10-crossover") which is based on
> debian-10-minimal and which has crossover installed
>
> - I have an AppVM ("my-crossover") which is based on the above template VM
>
> - I have installed some windows apps (Notepad++ / Office 2010) in the
> AppVM. The application are installed in ~/.cxoffice
>
> - I can launch the windows apps from the crossover menu or from an AppVM
> terminal (for example to launch MS Word from the AppVM Terminal
>
> I would like to add a menu entry to the Qubes AppVM menu and tried to
> follow the directions from the Qubes docs, but the menu didn't show up.
> While the Crossover App itself is installed in a template VM, the
> windows application are installed in a folder ~/.cxoffice in the AppVM
> (which based on the crossover template).
>
> The following command will launch a windows app via Crossover in the AppVM:
>
> qvm-run --auto my-crossover
>
> '/home/user/.cxoffice/Microsoft_Office_2010/desktopdata/cxmenu/StartMenu.C^5E3A_users_crossover_Start^2BMenu/Programs/Microsoft+Office/Microsoft+Word+2010.lnk'
>
> I have followed the Qubes docs from this link:
>
>
> /home/user/.cxoffice/Microsoft_Office_2010/desktopdata/cxmenu/StartMenu.C^5E3A_users_crossover_Start^2BMenu/Programs/Microsoft+Office/Microsoft+Word+2010.lnk
>
> I have therefore:
>
> 1) created a new .desktop file:
>
> [user@dom0 ~]$ nano
> ~/.local/share/applications/my-crossover-ms-word.desktop
>
> [Desktop Entry]
> Version=1.0
> Type=Application
> Terminal=false
> X-Qubes-VmName=my-crossover
>
> Icon=/home/user/.local/share/qubes-appmenus/my-crossover/apps.icons/cxmenu-cxoffice-0-29ra4ke-CrossOver.png
> Name=my-crossover: MS-Word
> Comment=Run Microsoft Word with CrossOver Linux
> Categories=;X-Qubes-VM;
> Exec=qvm-run --auto my-crossover
>
> /home/user/.cxoffice/Microsoft_Office_2010/desktopdata/cxmenu/StartMenu.C^5E3A_users_crossover_Start^2BMenu/Programs/Microsoft+Office/Microsoft+Word+2010.lnk
>
>
> 2) added the newly creaed my-crossover-ms-word.desktop file to a new
> .menu file (as mentioned in the Qubes docs)
>
> [user@dom0 ~]$ cat
> ~/.config/menus/applications-merged/my-crossover-vm.menu
> 
>  MS-Word
>  
> my-crossover-ms-word.desktop
>  
> 
>
>
> BUT ... doing so, is _not_ adding anything the applications menu of my
> AppVM.
>
> Any ideas what I am missing?
>
>
>
You can try this a different way. Try creating a basic
my-crossover-ms-word.desktop with the command you would run in that AppVM.
Then copy that to the template in /usr/share/applications. Force a sync of
the menus in that template, and finally go to the AppVM qubes dialog and
add your app to your AppVM menu. As long as you know to only run the
program in that one VM then you are OK if it's not actually installed in
that template.

Once it is in the menu you can always go back and diff the changes and see
what edits you should have done manually. I find it's just easier to let
the system edit the menus, because otherwise it will just get overwritten
sometime anyway. As long as you remember to copy those desktop files to the
next template upgrade version,  it should just work like any other standard
application.



>

-- 
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/CAJ5FDnjQdZEZKngTOK4069cDKCdk6Bk4XjgrmK5rf0tBVUgn1Q%40mail.gmail.com.


Re: [qubes-users] Salt updates fails on Fedora-33

2021-03-03 Thread Steve Coleman
On Wed, Mar 3, 2021, 9:28 AM lok...@gmail.com  wrote:

> On Wednesday, 3 March 2021 at 18:18:09 UTC+8 Mike Keehan wrote:
>
> I could not clone the fedora 33 templates, with a similar error message
>> about "not clean", until I started and stopped the template. It's been
>> OK since then.
>>
>
> I don't think that's the problem I'm facing, as I have restarted the
> template several times in order to do manual updates.
>

In the F33 template announcement there were some mention about the update
control dvm needing to be updated to fedora-33 for the qubes update process
to work correctly. Updates will work right out of the box from the dnf
command line even without that change. Did you already follow this guidance?

>

-- 
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/CAJ5FDng6reuYQAt-tBk2oAjk0kZKqXA6S71Ss76M%2Boih_o0Yig%40mail.gmail.com.


Re: [qubes-users] trouble with apt-get on dabian

2021-02-28 Thread Steve Coleman
On Wed, Feb 24, 2021 at 5:49 AM 'awokd' via qubes-users <
qubes-users@googlegroups.com> wrote:

> Steve Coleman:
>
> > I installed the stock Debian-10 rpm yesterday and it also fails to update
> > using the default proxy. The whonix templates based on Debian work
> because
> > they are using a different update vm.
> >
> > I really don't have a clue how all the Fedora templates work using the
> > exact same default update proxy while the Debian ones do not. I have not
> > made any deliberate custom modifications to any of the update settings,
> but
> > something obviously changed.
> >
> > My suspicion is on the receiving side proxy configuration in sys-firewall
> > but I don't know how to debug that. With the TERM setting being
> complained
> > about I am wondering how this proxy is being launched without a full set
> of
> > environment variables. This error text is in red, as coming through the
> > pipe, so its on the other side, not in the template itself. The update
> pipe
> > is not a terminal afaik so I don't know why the proxy would be
> complaining
> > it doesn't know the terminal type. But then why does the Fedora update
> > still work and Debian not using the exact same update gateway. Very odd.
> >
> I agree, sounds like something broken in sys-firewall given your other
> UpdateVM is working. You could change your templates to use the same
> UpdateVM as Whonix if you wanted to confirm. Otherwise, there's nothing
> special about the sys-firewall AppVM. If you don't mind recreating any
> firewall rules, try creating a new AppVM and confirm you don't get that
> TERM warning at the terminal. Next, change anything that points to
> sys-firewall for networking to the new one, and make it your new UpdateVM?
>
>
There is a package in the Fedora distribution that is causing this problem.
I switched both my sys-net and sys-firewall to use the new fedora-33
template that was just released and suddenly my Debian-10 could update
again. Then I started installing all the packages that I previously had in
my fedora-32 template and suddenly my Debian-10 update is broken again.

I then tried to revert back by switching both sys-net/sys-firewall vm's to
the fedora-33-minimal I had available but sys-net would not even boot up
using minimal. Switching it again to a default fedora-32 allowed it to boot
again. And sys-firewall blocked all network traffic using fedora-33-minimal
so again I needed to revert that back to a default fedora-32 to get back
online just to write this email.

Apparently, I need to reinstall a new fedora-33 template baseline and
painstakingly install all these packages one at a time while restarting
Debian-10 to try an 'apt-get update' between package installs. Somewhere
along the way, it will break and whatever I just installed will be the
culprit. I think I'll be doing a lot of cloning of templates creating
checkpoints along the way.

Steve

-- 
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/CAJ5FDniYnZXOsB3-u7xJyxoPRapK0LD%3DA-TqmVj%2BBxa%2BbJi_XQ%40mail.gmail.com.


Re: [qubes-users] Re: Howto grab/capture sound of one VM

2021-02-23 Thread Steve Coleman
On Tue, Feb 23, 2021, 6:02 AM evado...@gmail.com 
wrote:

> interesting. bump
>
> суббота, 13 февраля 2021 г. в 17:15:19 UTC, qu...@ixls.eu:
>
>> Dear Qubes-Users,
>>
>> how can I grab/capture the audio-output of one VM?
>>
>
Not sure exactly what you mean by capture. To play the audio, or record it?

Look at the pulse audio configuration apps inside that VM. You should be
able to figure out what device channels are processing sound by looking at
the audio volume meters inside that VM.

If recording it is what you want then look for a sound recorder app in that
VM. If playing the sound is what you want then look at the pulseaudio
controls in dom0.

It should be possible in Dom0 somehow.
>>
>

-- 
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/CAJ5FDngSg2M5j%2BUZcrtU0kvsKq6WmzW_5TsDP7R86N69za13Zg%40mail.gmail.com.


Re: [qubes-users] trouble with apt-get on dabian

2021-02-23 Thread Steve Coleman
On Tue, Feb 23, 2021, 4:17 AM 'awokd' via qubes-users <
qubes-users@googlegroups.com> wrote:

> Steve Coleman:
> > I have a somewhat confusing issue with debian-10 updates and would like
> any
> > suggestions on where to look.
> >
> > All my fedora templates update just fine. Dom0 updates but it gives some
> > errors through the return pipe.
> >
> > can't get terminal type, defaulting to vt100.
> > please set the TERM env variable.
>
> I wonder if your Debian template is messed up somehow, and/or your
> Updatevm (can be determined by looking at qubes-prefs). If you open a
> regular terminal session on either, do you get that same warning?


It gives this warning/failure from both the qubes manager update and from
the command line in the template.

If so,
> you could temporarily switch your UpdateVM's template to Fedora and
> attempt an update.


It's already using the default Fedora temolate, and all the Fedora
templates work just fine using the exact same update VM (sys-firewall)


itself, there's probably a more subtle fix but I would switch my AppVMs
> over to Fedora, delete & reinstall a fresh copy of the Debian template,
> then switch them back.
>

I installed the stock Debian-10 rpm yesterday and it also fails to update
using the default proxy. The whonix templates based on Debian work because
they are using a different update vm.

I really don't have a clue how all the Fedora templates work using the
exact same default update proxy while the Debian ones do not. I have not
made any deliberate custom modifications to any of the update settings, but
something obviously changed.

My suspicion is on the receiving side proxy configuration in sys-firewall
but I don't know how to debug that. With the TERM setting being complained
about I am wondering how this proxy is being launched without a full set of
environment variables. This error text is in red, as coming through the
pipe, so its on the other side, not in the template itself. The update pipe
is not a terminal afaik so I don't know why the proxy would be complaining
it doesn't know the terminal type. But then why does the Fedora update
still work and Debian not using the exact same update gateway. Very odd.

-- 
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/CAJ5FDnjSpG3DsuQ83bDvQ67SCOoqKF6M3hAat3VYTNkYJ7xtXg%40mail.gmail.com.


[qubes-users] trouble with apt-get on dabian

2021-02-22 Thread Steve Coleman
I have a somewhat confusing issue with debian-10 updates and would like any
suggestions on where to look.

All my fedora templates update just fine. Dom0 updates but it gives some
errors through the return pipe.

can't get terminal type, defaulting to vt100.
please set the TERM env variable.
can't get terminal type, defaulting to vt100.
please set the TERM env variable.

Debian-10 does not update and gives even more errors:
sudo apt-get update
Err:1 https://deb.debian.org/debian buster InRelease
  Invalid response from proxy: can't get terminal type, defaulting to
vt100. please set the TERM env variable. HTTP/1.0 200 Connection
established  Proxy-agent: tinyproxy/1.10.0 [IP: 127.0.0.1 8082]
Err:2 https://deb.qubes-os.org/r4.0/vm buster InRelease
  Invalid response from proxy: can't get terminal type, defaulting to
vt100. please set the TERM env variable. HTTP/1.0 200 Connection
established  Proxy-agent: tinyproxy/1.10.0 [IP: 127.0.0.1 8082]
Err:3 https://deb.debian.org/debian-security buster/updates InRelease
  Invalid response from proxy: can't get terminal type, defaulting to
vt100. please set the TERM env variable. HTTP/1.0 200 Connection
established  Proxy-agent: tinyproxy/1.10.0 [IP: 127.0.0.1 8082]
Reading package lists... Done
W: Failed to fetch https://deb.debian.org/debian/dists/buster/InRelease
 Invalid response from proxy: can't get terminal type, defaulting to vt100.
please set the TERM env variable. HTTP/1.0 200 Connection established
 Proxy-agent: tinyproxy/1.10.0 [IP: 127.0.0.1 8082]
W: Failed to fetch
https://deb.debian.org/debian-security/dists/buster/updates/InRelease
 Invalid response from proxy: can't get terminal type, defaulting to vt100.
please set the TERM env variable. HTTP/1.0 200 Connection established
 Proxy-agent: tinyproxy/1.10.0 [IP: 127.0.0.1 8082]
W: Failed to fetch https://deb.qubes-os.org/r4.0/vm/dists/buster/InRelease
 Invalid response from proxy: can't get terminal type, defaulting to vt100.
please set the TERM env variable. HTTP/1.0 200 Connection established
 Proxy-agent: tinyproxy/1.10.0 [IP: 127.0.0.1 8082]
W: Some index files failed to download. They have been ignored, or old ones
used instead.

And whonix updates without any warnings, which is based on debian but uses
a different gateway for its downloads, so my suspicion is that somehow
sys-firewall is to blame. But what exactly is wrong I am not sure, because
fedora uses the same proxy doesn't it?

Any clues?

Steve

-- 
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/CAJ5FDnjFzNaZTZYCOr9s_0KztOGSyiQp4teG2v3C5Mc2GeU2qQ%40mail.gmail.com.


Re: [qubes-users] Win10VM: User name or password incorrect at startup

2021-01-29 Thread Steve Coleman
On Fri, Jan 29, 2021 at 4:43 PM 'awokd' via qubes-users <
qubes-users@googlegroups.com> wrote:

> Steve Coleman:
>
> > Q: Where is this other supposed/incorrect password being passed into it
> > from, and is there any way to go back to not needing this login
> > requirement?
>
>
> https://docs.microsoft.com/en-us/troubleshoot/windows-server/user-profiles-and-logon/turn-on-automatic-logon
>
>
Thanks awokd!

Just to follow up in case this happens to anyone else, the registry entry '
*DefaultPassword'* disappeared completely yet the 'AutoAdminLogon' was
still set to '1', unlike what the documentation says should happen.

I still need to figure out why a) the DefaultPassword entry disappeared, or
b) why the password was expiring and thus the system forced me to set an
actual password instead of what the qvm script had originally set up.  This
will likely remain a mystery but at least it's working again.

Steve

-- 
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/CAJ5FDnh7Ygh1_q1xg7b02%2BbYrUhQn0ugYteGOnCr%2BX-pbt9gXg%40mail.gmail.com.


[qubes-users] Win10VM: User name or password incorrect at startup

2021-01-29 Thread Steve Coleman
I have a situation with a Windows 10 AppVM that I am hoping someone with
more experience might be able to answer. I created my first Windows 10 VM a
few months ago using the qvm-create-windows-cube.sh script and it seemed to
work well enough.

But just recently when I just wanted to start it to update the OS software
it started up fine but claimed that my password had expired and it forced
me to change it. I do know what I set it to but now each time it starts it
says "Username or password incorrect" and then prompts me to login with a
valid password. I don't remember it ever prompting me before, and I don't
know what is even trying this other password that is evidently incorrect.

Q: Where is this other supposed/incorrect password being passed into it
from, and is there any way to go back to not needing this login
requirement?

thanks,

Steve

-- 
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/CAJ5FDniOsCzHBxkBRbmp2Ogorea2GoeY%3DHF24opGwUCdSFPfCw%40mail.gmail.com.


Re: [qubes-users] Can't access flash drive

2021-01-18 Thread Steve Coleman
On Mon, Jan 18, 2021 at 11:42 AM 'awokd' via qubes-users <
qubes-users@googlegroups.com> wrote:

> Shawn Creighton:
> >
> > I have a Sandisk Cruzer 8GB flash drive I've had for a few years, when I
> > plug it in to Qubes it shows up in the available devices but when I
> connect
> > it to any appvm it's not rshowing up in the file manager. Other newer
> flash
> > drives work fine. Any ideas?
> >
> NTFS format vs. ExFAT possibly.
>

I stumbled into the ExFAT issue a few years ago and had simply dismissed my
own problem as not important until this thread showed up. I thought I might
be able to help with this SanDisk thread so I pulled my Sandisk back out to
take another closer look.

But that old ExFAT problem certainly is not the case here with my SanDisk
Ultra_Fit because it turns out they are not even formatted with a Windows
file system. I have three of four SanDisk in front of me, and none of them
work with my fedora-32 based sys-usb, but all work perfectly fine with dom0
(fedora-25). They don't show up in GParted in sys-usb but by inspecting
them with GParted in dom0 I can see that two of them are iso9660 (Qubes
4.0.1 and 4.0.4) Install iso's that were DD'ed directly to the device and
both had been successfully booted and used to install my current Qubes
system. I just keep them around in case of an emergency. The third SanDisk
is formatted ext4 and at the moment is completely blank, because *I can't
see it* to even use it through my normal sys-usb. I have lots of other USB
thumb drives that all work just fine but there is something different about
these SanDisk drives. I also have a fourth SanDisk that I used without
issue on a tails system but it simply could not be read by sys-usb and
there is no way I'm even plugging that one into dom0. I ultimately used
tails to re-transfer the files to yet another USB stick so I could finally
transfer those files over and RE the binaries.

Bottom line, all four SanDisk Ultra_Fit 64gb are pretty much useless on a
fedora-32 templated AppVM. Now I'm really curious to see what happens when
using a different template for my sys-usb. For the moment I'm blaming the
template or some missing driver, but I can't really say for sure.

-- 
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/CAJ5FDniDJoxEC8_deXPdhfbOT3iaNb00JxEKYrXRrEnw6UJWNA%40mail.gmail.com.


Re: [qubes-users] Qubes not reading flash drive

2021-01-17 Thread Steve Coleman
I have several Sandisk Ultra_Fit 32Gb which refuse to even be seen by my
sys-usb (fedora-32 based template) but works just fine passing the device
if I were to use dom0, which obviously I don't like to do but the devices
are useless otherwise.

Are you using a sys-usb vm with its own controller? What templates are you
using?


On Sun, Jan 17, 2021 at 12:57 PM Mike Keehan  wrote:

> On 1/16/21 3:44 PM, Shawn Creighton wrote:
> > I have a Sandisk Cruzer 8GB flash drive with some older documents on it
> > that I need to access, when I plug it in to Qubes it shows up in the
> > available devices but when I connect it to any appvm it is not showing
> > up in the file manager. Other newer flash drives work fine.
> > Any way to get the system to read it?
> >
>
> File managers will only see a whole disk that is passed to the VM,
> not a single partition.  Are you passing the whole disk?
>
> --
> 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/f579c645-5ed0-9ca6-62bf-a26a95bb701f%40keehan.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/CAJ5FDnjWM2QAjbmku94ZqVqOJ1%2B0zgksZ9NE47strJC5YVZiLA%40mail.gmail.com.


Re: [qubes-users] How do you think about the clipboard inter-VMs

2021-01-06 Thread Steve Coleman
On Tue, Jan 5, 2021, 11:04 PM pillule  wrote:

>
> Hello,
>
> I wonder how do you manage your computing life with the problem of
> the clipboard / file sharing.
>
>
>
> I guess most of us cheats theses rules sometimes ;
> if one deploys post-installation scripts in dom0,
> or takes notes in a vault and wants to copy in that URL,
> or maybe wants to take that snippet into that template ...
>
> I am curious to know how you think about it.
>

My take on it is to weigh the risk. For instance, I have a 'Purchasing' vm
and an Internet vm. I'll do all my searching of what I want to buy in the
Internet VM and then copy the specific URL over to the Purchasing VM,
rather than using the Purchasing vm to peruse the internet. I feel there is
much more likelihood of picking up malware by visiting random internet
sites than if I copy and paste a single url from a site that I have already
inspected its URL. I'll do the same kind of checks when moving receipts and
data from Purchasing to my Banking VM.

For the really paranoid you can create a dvm text editor, paste the
URL/text data there for inspection before finally copying it to the real
destination VM.

If the theoretical copy buffer attack is against Qubes itself I may still
be screwed, but that would have to be done by an adversary that both knows
what site I will be visiting and also know in advance that I use Qubes. We
are talking Nation State adversary,  who clearly already knows an awful lot
about me. At that level of the game its only a matter of time since clearly
I am a already a defined target of theirs. Pulling the plug would be the
only effective defence at that point.

So, weigh the risks and take precautions where possible. Always try to
double check what you are copying/moving across VM's and be appropriately
paranoid when moving data to a higher security domain.

>

-- 
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/CAJ5FDnh-TtuH%2BorAbAx-cPuP2wcDfvpdQJrwPU46%3DTH-%2BW0j%3DQ%40mail.gmail.com.


Re: [qubes-users] Re: qvm-run multimedia nautilus nothing happens

2020-12-25 Thread Steve Coleman
On Tue, Dec 22, 2020, 5:12 AM Franz <169...@gmail.com> wrote:

>
> > No, checking again if I put multimedia dependent from another template
>> > works, so the problem is the template.
>> >
>> > Last thing I did with the template was install a custom disposable VM
>> > connected with the template. I did not know that this may end damaging
>> the
>> > template.
>> >
>> Disposable VM settings shouldn't affect the template. What happens if
>> you try to run nautilus from a terminal session to "multimedia"? If it
>> doesn't start, that's the issue.
>>
>>
> Cannot test it because neither gnome-terminal nor term start, so?  Anyway
> I prepared a new template, reinstalled everything, even the printer, and it
> works, but now I am scared by the custom dvm thing.
>

The way to test things like this is to use "qvm-run -p 
program-name" and watch what errors bome back through that pipe. Usually
you will see something like "program not found" or some error finding some
basic resource that is required.

With dvm's this *is* more of a problem, but doing that same command against
its base templatevm might also give some insightful clues.

-- 
> 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/CAPzH-qCZMSR8rkbk_Uf6nzgxQ4VfwaQ5ZtDrd6EqUJD3HrwEVg%40mail.gmail.com
> 
> .
>

-- 
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/CAJ5FDnjYVack%2BW--Z8SBVMLJAUOFLO2JAOxHrOcDD60FwDedzQ%40mail.gmail.com.


Re: [qubes-users] Are "smart" monitors/TVs a security issue?

2020-11-27 Thread Steve Coleman
On Fri, Nov 27, 2020, 6:01 PM Alex Smirnoff  wrote:

> Assuming poor software quality of typical TV firmware and codecs, DVB
> should be pretty easy exploitable. However, I doubt a compromised TV could
> do serious harm to your computer via HDMI. Speaking on your demo.. there is
> a lot of factors to be involved. Chaining a Xen exploit to Chrome might be
> possible.. but unprobable, for a multitude of reasons.
>

My reasoning about the WiFi was three fold.

1. TV's are often encoded to deliberately export use intelligence data to
be utilized by the advertisers and ratings organizations. The camera and
microphone, if installed, are actually designed and used to watch and
listen to the family watching the programs. Zero privacy, and you may even
have no way to disconnect it, so denying it any network access is your only
hope to stop exfiltration.
2. Having a presence on any network leaves it open to external exploit
where the above sensors are available for surveillance of the target family.
3. More recent sets are actually programmable, from the network, and can
have software (e.g. android) apps or plugins installed by the adversary
which that app then has complete access to all the features of the set
including the display buffers,  sensors, and network. Its a computer in its
own right and should be treated as such.

If the TV set programmers coded the it to auto connect to any available
open WiFi then that set is actually dangerous, as it can give a foothold
from which to attack other machines on that network. If its your own
network that is doubly bad news.

The question remaining is what can the adversary then do to communicate
back through the video connection. Hdmi is bidirectional so buffer overflow
exploits are clearly possible. But no matter what, one simply has to assume
the adversary already has what is displayed on the screen.

Denial of network access is the key to keeping *most* adversaries out.
Testing the sets WiFi situation would be the absolute bare minimum to be
sure you are safe (enough?). But if you think you are being targeted by
some advanced adversary for some reason then I would simply not use one of
these as a monitor. There are just too many ways to hack one.

I can not discuss that specific demo I previously spoke about other than to
say, I know exactly what they did, and they can not use that same trick
today. I have worked with people quite capable of waltzing through your
system and you wouldn't know they were there. They reverse engineer
hardware and play a form of "capture the flag(the file contents stored on
some chosen hardware/machine)" for fun and recognition, and the choice of
hardware is often quite amusing. Spooks like to have fun too. I'm retired
now, but the stories I could tell if I were only allowed to.

I'll just say there is a reason I use 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/CAJ5FDngisj%3Dk5phFVYhbO_89uK4grDDdDRb-xEbhYNyZYsswnw%40mail.gmail.com.


Re: [qubes-users] Are "smart" monitors/TVs a security issue?

2020-11-27 Thread Steve Coleman
Without a Nation State being involved, the most likely threat would come
from a permiscuous WiFi in the TV auto-connecting to any open networks in
your area. If you are sure that is not the case then it should be 'safe
enough' for most people.

Side channel attacks take tools, skills, and physical location that isn’t
going to happen without you already being a target of some kind. It you are
a target then no monitor is going to help and its time to unplug your
computer. I once saw one demo years ago where the target machine with no
known public vulnerabilities at the time was rooted in less than 15s. They
don't play around.

On Wed, Nov 25, 2020, 9:31 AM River~~  wrote:

> Hi all
>
> In the days of CRT monitors one way the security of a computer system
> could be compromised non-intrusively (ie without amending the
> installed code) was by picking up the radio-frequency leakage from the
> tube in the monitor. This could only be done from near by, but where
> possible it enabled the spy to see what was on the screen -- almost
> everything that you typed (aprt from passwords that were blanked or
> starred out). This was a remote form of shoulder surfing, where
> someone looks over your shoulder in an environent like an internet
> cafe.
>
> Nowadays we do not have to worry about CRT monitors. But TVs are
> increasingly delivered with their own internet connection, making it
> easy to watch You-Tube (etc) without needing a separate computer or
> phone. Clearly there is a computer inside which can be hacked, and if
> so a remote shoulder surfing attack would be very possible.
>
> Is the same true of monitors and of TVs that do not have an apparent
> internet link? The digital tech to draw a picture from the input is
> unlikely to be done by traditional electronics, but being all digital
> is likely done by a miniporcessor of some kind in all digital
> displays.
>
> To put my question in the most provocative way on this forum: if there
> much point securing the OS when the monitor might be an easier target
> for those out to (umm) monitor our reading and our keystrokes?
>
> This thught has only just come to me, and I wonder if there is already
> some available mitigation? Any ideas?
>
> Or am I being overly cautious?
>
> R~~
>
> Any ideas?
>
> --
> 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/CAK3jUKoDK8kX2jhx3J-m%3D-%3DrRdVxpX7uaJCa5emwpXdSm-CWxg%40mail.gmail.com
> .
>

-- 
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/CAJ5FDngOV7EN4Vu4LT0bpPiRUKd01X-kCZZUD7OgRng634hLUw%40mail.gmail.com.


Re: [qubes-users] Xfburn not seeing usb

2020-11-24 Thread Steve Coleman
You may need to run the software in the VM which contains the physical
hardware (e.g. the USB controller}. Passing a memory device generally works
but when you need special access to the physical hardware such as burning a
DVD then this pass-through method may not work correctly.

If your USB controller is in sys-usb then running Xfburn or Brasero there
is the best option. If not, and you have several USB controllers, you might
want to investigate creating a sys-usb for that purpose. Otherwise then you
may need to decide if you want to install a DvD burning package directly in
dom0, which generally should be avoided if possible.

Steve


On Tue, Nov 24, 2020 at 2:26 PM Shawn Creighton  wrote:

> Trying to create a bootable usb, installed Xfburn and connected the usb to
> the AppVM but when I open Xfburn as root it doesn't see the usb and says:
>
> "no burners currently available, possibly the discs are in use and cannot
> get accessed"
>
> Also tried installing Brasero which won't burn to usb
>
> --
> 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/9d137cef-525f-48bf-bd49-85c17ad02b9an%40googlegroups.com
> 
> .
>

-- 
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/CAJ5FDnjkOTrXf0c%3DMzwV_5u_e%3DrqK5ASNCDTY2jUNKU0eeQfwg%40mail.gmail.com.


Re: [qubes-users] HCA reports - some advice please

2020-11-23 Thread Steve Coleman
On Mon, Nov 23, 2020 at 2:31 PM Andrew David Wong  wrote:

> On 11/23/20 10:06 AM, Steve Coleman wrote:
> > On Mon, Nov 23, 2020 at 9:33 AM Andrew David Wong 
> wrote:
>
> > I have a question about the HCL process and page display that I have been
> > wondering about.
> >
> > I was for the longest time copying and pasting the HCL web page into a
> > spreadsheet just so I could sort and delete out all the old information,
> as
> > I was looking to replace my desktop system with something more up to
> date.
> > I can't tell you how many times in the last three years I copied the HCL
> to
> > this spreadsheet, and when my old desktop finally died I had to give up
> > hope and just bought a new system sight unseen that was not on the list
> and
> > I just hoped for the best. Fortunately, it worked out Ok.
> >
> > As it is right now it is difficult and getting increasingly harder to
> find
> > just the latest hardware on the list as it seems that by the time
> something
> > appears on the list it is no longer even available for purchase.
>
> Remember that these are almost all reports voluntarily submitted by
> users. If it's mostly old hardware, that's because few people with new
> hardware are submitting reports for that hardware.

Agreed. But it is certainly possible to make this more of a discussion on
how to give back to the community. The Qubes patriotic thing to do is to
submit your successes so others can follow without so much fear and
hesitation.

We can't force anyone
> to submit reports, and we usually can't get new hardware to generate
> reports on ourselves.

No, but a well-placed note/request at the end of the Qubes install process
could go a long way to actually encourage them to submit the report to help
others. The "how you can help" could also suggest this as a way to give
back which is easy even for novices who were just introduced to Qubes. Make
it a badge of honor. In fact, one could encourage people with questions to
include a report link/ID where the fundamentals of their basic machine
configuration would be available online for the experts to better
understand the problem. Not everyone would necessarily want to give their
anonymity away, but for some questions, this link could provide some
valuable information about the hardware that would be easy to share.

> Though, to be fair, the reports from the mailing
> list haven't been added in a while, so that might also be part of it.
>

Very true, unfortunately. I submitted my "Dell XPS 8930" but it has not
shown up yet. With 8 cores and 64GB of memory, it is already out of
production but it is still available through other retailers. Somebody who
is looking for a new beefy desktop may not see this on the HCL until it is
no longer available anywhere. That is the same boat I was in when my
desktop up and died and I had no choice but to draw straws and pick one
almost at random. Yes, there were other *very old* XPS's on the HCL and
some did *not* work properly, but based on the hardware in this one I
figured it might just work. Unfortunately, this only has a "firmware TPM"
that is disabled in BIOS when using the legacy boot settings and there is
no header on the motherboard to even add a physical TPM. I may just dabble
with the idea of a qubes auditable software-based vTPM (qTPM) and see if I
can find a way to make something work for the contributor's packages. Not
sure about that yet, but it's an idea that might even allow for locking
down the boot partition by making it read-only until after a successful
boot/login. Evil maids can't change what they can't edit.

> However,
> > there are LOTS of machines that you could only find on eBay and many/most
> > lack sufficient memory, BIOS, or current chipset support for the current
> > Qubes R4.x system being developed. Old systems on the HCL are seemingly
> > never updated, so you can't tell which ones are still working and which
> > ones have retired years ago. There are many items on that list even in
> the
> > wrong categories (e.g. DIY System boards in the Desktop section when
> there
> > is a separate section just for those) and I see no defined process by
> which
> > to help change that.
> >
> > My question is this: What would it take to get a set of simple filter
> > options on that HCL webpage?
>
> This open issue is very similar to what you're asking:
>
> https://github.com/QubesOS/qubes-issues/issues/3795
>
> I've just opened two PRs (linked to this issue) that make the HCL tables
> sortable. However, some rows break on sorting. Please see the issue
> comments for more details and an image showing exactly how it breaks. If
> you can help with this, please let me know on that issue.
>
> > Or, is there

Re: [qubes-users] HCA reports - some advice please

2020-11-23 Thread Steve Coleman
On Mon, Nov 23, 2020 at 9:33 AM Andrew David Wong  wrote:

>
> If you can fix them first, that would be a great help! I think it would
> make things easier for our HCL maintainer. :)
>
> Usually, it's just the model number for that product, e.g., "FX-8320" is
> short for "AMD FX(tm)-8320 Eight-Core Processor". Take a look at the
> existing entries for examples:
>
> https://github.com/QubesOS/qubes-hcl/tree/master
>
> > I am thinking of including the cpio files, but do not want to share a
> > serial number that they contain. WOuld those files be useful to others
> > if I edited them so that the serial number reads "Redacted"?
> >
>
> Sure, feel free to redact whatever you like. :)
>
> If you prefer, you can send the cpio files directly to Marek
> PGP-encrypted (instead of the to the mailing list). See here for more info:
>
> https://www.qubes-os.org/doc/hcl/#generating-and-submitting-new-reports
>
>
I have a question about the HCL process and page display that I have been
wondering about.

I was for the longest time copying and pasting the HCL web page into a
spreadsheet just so I could sort and delete out all the old information, as
I was looking to replace my desktop system with something more up to date.
I can't tell you how many times in the last three years I copied the HCL to
this spreadsheet, and when my old desktop finally died I had to give up
hope and just bought a new system sight unseen that was not on the list and
I just hoped for the best. Fortunately, it worked out Ok.

As it is right now it is difficult and getting increasingly harder to find
just the latest hardware on the list as it seems that by the time something
appears on the list it is no longer even available for purchase. However,
there are LOTS of machines that you could only find on eBay and many/most
lack sufficient memory, BIOS, or current chipset support for the current
Qubes R4.x system being developed. Old systems on the HCL are seemingly
never updated, so you can't tell which ones are still working and which
ones have retired years ago. There are many items on that list even in the
wrong categories (e.g. DIY System boards in the Desktop section when there
is a separate section just for those) and I see no defined process by which
to help change that.

My question is this: What would it take to get a set of simple filter
options on that HCL webpage? Or, is there a way for someone to help clean
up and better organize this list?

Going forward it is not all that helpful to see what was historically
running, years ago, if they are no longer adequate for the current Qubes
R4.x baseline. My inclination is this lists' primary function should be to
support those who are looking for some adequate hardware that could run the
current baseline, and failing that test, it should be filtered out by
default. Or maybe just filter by date added/updated?

Another thought is we should actively request those who successfully
upgrade their systems to the latest baseline to resubmit their HCL thus
showing that the same system is still capable of running the latest
baseline number. I know matching old and new HCL reports would require some
work, but I think if you want Qubes to be more popular this is a must.

At the very least the list should have a way to display only those
currently running R4.x.x by default, but then let someone tweak the filter
settings to look at older hardware if they choose to do so.

thanks,

Steve

-- 
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/CAJ5FDng7sc9LTtm11jJDzwHEopQ7F9m2QE_YmtC_oVc5GV_iCQ%40mail.gmail.com.


Re: [qubes-users] Automatic updating of extra RPMs from add-on repos in Fedora template-based VMs?

2020-11-15 Thread Steve Coleman
On Sun, Nov 15, 2020 at 1:36 PM Matt McCutchen 
wrote:

>
> I have a bunch of VMs based on one Fedora TemplateVM.  In most cases,
> I'm willing to install any Fedora package needed by any of the VMs in
> the TemplateVM.  However, due to security concerns, I have one VM that
> runs Zoom, one that runs Skype, one that runs Google Chrome, and one
> that runs Visual Studio Code... you get the idea.  Each of those
> applications offers its own dnf repository, but I don't want to add
> those repositories to the TemplateVM.  And I don't want to use
> StandaloneVMs because that will multiply my management work; even if
> there are management tools that could handle most of my needs, I'd
> still have to learn and configure them.
>
> So far, I've been manually downloading the RPMs and extracting them
> into the user home directory.  (Fortunately, none of them have had
> dependencies on absolute paths that would break this approach.)  This
> is enough of a pain that I rarely update the applications, which may be
> bad for security.
>
> Does anyone know of a better but still convenient solution?
>
>
My way of dealing with it is to just clone your pristine fedora-32
template and add the required packages to that template clone, then create
an AppVM that uses that template. This way you limit any potential data
loss or damage to just that one AppVM which you then use whenever you need
one of those proprietary apps. The question now is what data would they
share in that AppVM and is it reasonable for them to share the same AppVM?
If the answer is yes then there is no problem. If no, then create another
AppVM based on the same template for the other app.

The downside is you now have to update two templates instead of one, but
that of course can be automated.

How many specialized AppVMs you create is then based on your own
risk/benefit analysis. I would think it's reasonable for instance to have
Zoom and Skype share the same memory space unless the topics discussed in
each app are highly confidential. If so, you could also just launch a
Disposable VM based on that one template, but for each and every instance
of conversation, and then nothing is ever shared since each instance starts
up with no user data. You just need to move any presentations between
AppVMs to support those conversations.

Steve

-- 
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/CAJ5FDnjiVg%3Dg0TTsb8RrjXTMtwOiYZRn7e4U2UxjA3_XtvVYVw%40mail.gmail.com.


Re: [qubes-users] unable to start gnome-terminal or terminal on fedora-32 template

2020-11-15 Thread Steve Coleman
On Sun, Nov 15, 2020 at 2:49 AM Franz <169...@gmail.com> wrote:

>
> qvm-run -a fedora-32 gnome-terminal
> fedora-32: command failed with code: 1
>
>
Try adding the -p option so you can see any error message coming from that
command on the other side. Whatever comes back will give you a clue as to
why it is not starting the terminal.
qvm-run -a -p fedora-32 gnome-terminal

Steve

-- 
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/CAJ5FDngE%3DdbXLB0hGZLW4gKwZfyZ%2B5ARqa5Nf%2B%3DCaWpQLiziaA%40mail.gmail.com.


Re: [Qubes OS Community Forum] [Mailing Lists/qubes-users] [qubes-users] R4.0.4 RC1 Unable to delete or backup certain qubes

2020-11-15 Thread Steve Coleman
On Sat, Nov 14, 2020 at 12:51 PM Mike Keehan via Qubes OS Community Forum <
qubes...@discoursemail.com> wrote:

> Mike_Keehan 
> November 14
>
> Well, the thin pool is LVM, but if the VM is offline, there should not be
> a problem. Guess you'll have to investigate all the logs you can
> find.
>
I finally have the answer!

Thankfully this problem has nothing to do with R4.0.4 but rather a brand
new disk drive failing (MTBF<=5.2 days, likely earlier)  in a rather odd
way. What had me stumped is why the VMs would would seem to run fine but
completely hung the backup process while reading the exact same volumes. It
appears that all the VMs that were acting odd were all allocated on the
same physical drive, but nothing ever gave any kind of an error when they
were reading the drive. It was likely the per-VM metadata needed for the
backup system that failed first.

Fortunatly the drives built in "smart" log holds the records for the last 4
errors, which can be easilly checked, and this allowed me to identify which
physical drive needed to be yanked and replaced. Being a brand new system I
did not yet know which logical drive mapped to which physical drive. To
analyse the problem I used a "smartctl" tool variant on another system to
check the logs that are stored physically within the drive.

Since checking each drive in this way is relatively efficient and easy it
seems to me that there must be an automated way to check these error logs
and notify the user when a drive is starting to fail. My Qubes system was
completely silent and it was only because of the odd behaviour of the
backup system that I was forced to investigate. If the backup process
didn't just hang then all my future backups could have been trash, and I
would have not even noticed the issue until it was too late. Why wait until
the system is completely unusable?

So, my question to the Qubes community is, has anyone out there set up this
kind of "smart" disk check up on Qubes? What are the best tools for a quick
check, say upon each boot, or one that could easilly be put in cron for a
periodic/daily go-no-go health check?

Thanks,

Steve

> --
>
> Visit Topic
> 
> or reply to this email to respond.
>
> To unsubscribe from these emails, click here
> 
> .
>
>

-- 
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/CAJ5FDniPDdysU6isxXotQvdkPWgkZ9LFCRVLVbkRwp12%2BMacVA%40mail.gmail.com.


Re: [qubes-users] R4.0.4 RC1 Unable to delete or backup certain qubes

2020-11-14 Thread Steve Coleman
On Sat, Nov 14, 2020, 4:48 AM Mike Keehan  wrote:

> On 11/14/20 3:29 AM, Steve Coleman wrote:
> > I installed R4.0.4 RC1 and have been having some very odd issues with
> > just a few of the VM's I restored from backups, thus I have been
> > restoring, cloning, testing, and deleting clones while trying to figure
> > out a few things.
> >
> > The first problem I was originally chasing was why one VM in particular
> > never completes a backup and just hangs at 0% while the file grows only
> > to about 40kb (the header info?). That specific VM starts and runs just
> > fine but just won't complete a backup. A Clone of it runs fine as well.
> >
>
> > The backup not completing can occur if the VM is online, and you are not
> using LVM.
>
> The VM is definitely not online/running, and it is not using LVM but
> rather the default thin pool mechanism set up by the R4.0.4 RC1 default
> installer options. This is a brand new install, and backups were working
> just fine for about three days without any issues.
>
>

-- 
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/CAJ5FDni-AjV4Fq76K9itYo48pkE%2B4QKms_HEaPDxb_qXciJX7w%40mail.gmail.com.


[qubes-users] R4.0.4 RC1 Unable to delete or backup certain qubes

2020-11-13 Thread Steve Coleman
I installed R4.0.4 RC1 and have been having some very odd issues with just
a few of the VM's I restored from backups, thus I have been restoring,
cloning, testing, and deleting clones while trying to figure out a few
things.

The first problem I was originally chasing was why one VM in particular
never completes a backup and just hangs at 0% while the file grows only to
about 40kb (the header info?). That specific VM starts and runs just fine
but just won't complete a backup. A Clone of it runs fine as well.

At present, I now have a few VM's that I am unable to delete for some
reason. Both the command line tool and Qube manager fail to remove these
VM's. From the command line tool I get a "qvm-remove: error: Got empty
response from qubesd." message. In the journalctl I see a "domain not
found" error, when it gets a second exception and then terminates.

I'm guessing that these two problems are likely related, but I'm not sure
how. I'm guessing there is something wrong with qubesd. I have attached the
relevant logs for the delete problem.

Any ideas?

thanks,

Steve Coleman

-- 
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/CAJ5FDngd4MhiA_VzL0CGWmWUvu9gsCtOQ-FdhmNJs%3D8QrK76fw%40mail.gmail.com.

Nov 13 21:55:29 dom0 qubesd[3019]: unhandled exception while calling 
src=b'dom0' meth=b'admin.vm.Remove' dest=b'Win10-clone-1' arg=b'' 
len(untrusted_payload)=0
Nov 13 21:55:29 dom0 qubesd[3019]: Traceback (most recent call last):
Nov 13 21:55:29 dom0 qubesd[3019]:   File 
"/usr/lib/python3.5/site-packages/qubes/vm/qubesvm.py", line 691, in 
libvirt_domain
Nov 13 21:55:29 dom0 qubesd[3019]: self.uuid.bytes)
Nov 13 21:55:29 dom0 qubesd[3019]:   File 
"/usr/lib/python3.5/site-packages/qubes/app.py", line 142, in wrapper
Nov 13 21:55:29 dom0 qubesd[3019]: return self._wrap_domain(attr(*args, 
**kwargs))
Nov 13 21:55:29 dom0 qubesd[3019]:   File 
"/usr/lib64/python3.5/site-packages/libvirt.py", line 4047, in lookupByUUID
Nov 13 21:55:29 dom0 qubesd[3019]: if ret is None:raise 
libvirtError('virDomainLookupByUUID() failed', conn=self)
Nov 13 21:55:29 dom0 qubesd[3019]: libvirt.libvirtError: Domain not found
Nov 13 21:55:29 dom0 qubesd[3019]: During handling of the above exception, 
another exception occurred:
Nov 13 21:55:29 dom0 qubesd[3019]: Traceback (most recent call last):
Nov 13 21:55:29 dom0 qubesd[3019]:   File 
"/usr/lib/python3.5/site-packages/qubes/api/__init__.py", line 275, in respond
Nov 13 21:55:29 dom0 qubesd[3019]: untrusted_payload=untrusted_payload)
Nov 13 21:55:29 dom0 qubesd[3019]:   File 
"/usr/lib64/python3.5/asyncio/futures.py", line 381, in __iter__
Nov 13 21:55:29 dom0 qubesd[3019]: yield self  # This tells Task to wait 
for completion.
Nov 13 21:55:29 dom0 qubesd[3019]:   File 
"/usr/lib64/python3.5/asyncio/tasks.py", line 310, in _wakeup
Nov 13 21:55:29 dom0 qubesd[3019]: future.result()
Nov 13 21:55:29 dom0 qubesd[3019]:   File 
"/usr/lib64/python3.5/asyncio/futures.py", line 294, in result
Nov 13 21:55:29 dom0 qubesd[3019]: raise self._exception
Nov 13 21:55:29 dom0 qubesd[3019]:   File 
"/usr/lib64/python3.5/asyncio/tasks.py", line 240, in _step
Nov 13 21:55:29 dom0 qubesd[3019]: result = coro.send(None)
Nov 13 21:55:29 dom0 qubesd[3019]:   File 
"/usr/lib/python3.5/site-packages/qubes/api/admin.py", line 1144, in vm_remove
Nov 13 21:55:29 dom0 qubesd[3019]: del self.app.domains[self.dest]
Nov 13 21:55:29 dom0 qubesd[3019]:   File 
"/usr/lib/python3.5/site-packages/qubes/app.py", line 537, in __delitem__
Nov 13 21:55:29 dom0 qubesd[3019]: if vm.libvirt_domain:
Nov 13 21:55:29 dom0 qubesd[3019]:   File 
"/usr/lib/python3.5/site-packages/qubes/vm/qubesvm.py", line 694, in 
libvirt_domain
Nov 13 21:55:29 dom0 qubesd[3019]: self._update_libvirt_domain()
Nov 13 21:55:29 dom0 qubesd[3019]:   File 
"/usr/lib/python3.5/site-packages/qubes/vm/qubesvm.py", line 2126, in 
_update_libvirt_domain
Nov 13 21:55:29 dom0 qubesd[3019]: domain_config = self.create_config_file()
Nov 13 21:55:29 dom0 qubesd[3019]:   File 
"/usr/lib/python3.5/site-packages/qubes/vm/__init__.py", line 373, in 
create_config_file
Nov 13 21:55:29 dom0 qubesd[3019]: ]).render(vm=self)
Nov 13 21:55:29 dom0 qubesd[3019]:   File 
"/usr/lib/python3.5/site-packages/jinja2/environment.py", line 989, in render
Nov 13 21:55:29 dom0 qubesd[3019]: return 
self.environment.handle_exception(exc_info, True)
Nov 13 21:55:29 dom0 qubesd[3019]:   File 
"/usr/lib/python3.5/site-packages/jinja2/environment.py", line 754, in 
handle_exception
Nov 13 21:55:29

[qubes-users] HCL Dell XPS 8930

2020-11-11 Thread Steve Coleman
I had been looking for years for a new Qubes desktop system but nothing
that was still available ever showed up on the HCL. My old desktop died
last week so I had no alternative but to take a chance on something. While
the Dell XPS 8930 is no longer in production it is still available through
retailers.

My new machine is an 8-core i7-9700K w 64GB ram desktop tower, and I added
3 3-TB drives, so it should be ample for the forthcoming future with R4.1 I
hope. It will be nice to not have to worry about having too many VM's
running concurrently.

The Secure Boot needed to be disabled and Legacy boot mode turned on. This
had the nasty side effect of disabling the option to [re]enable the
Firmware TPM. I called Dell Support and went round and round and nobody
could tell me which BIOS option was in direct opposition to having the TPM
activated, and they just wanted me to use paid support to have somebody
else walk me through changing all the same options I had already gone
through. That is why I called for support, and you would think this would
be documented somewhere (AMI BIOS). My suspicion is that it is tied into
the M$ Secure boot logic which I *had* to turn off to get it to boot
anything non-M$ related. I guess if I can get the proper keys for the Xen
boot image then I may be able to look at this further.

Does anyone know of any PCIe TPM add-in card that works in Qubes? Or better
yet, has anyone been able to get the Xen vTPM system working under Qubes? I
looked at that a while back but didn't have the memory to run so many VM's
needed to support that architecture. It should be doable now.

thanks,

Steve Coleman

-- 
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/CAJ5FDnhRcy1-7FseU0kUc6v1Pe3DGLxVZCyPUDw7pRaDRh9V%3Dw%40mail.gmail.com.


Qubes-HCL-Dell_Inc_-XPS_8930-20201110-152526.yml
Description: application/yaml


[qubes-users] R4.0.4 RC1 "cannot execute qubesdb-daemon"

2020-11-11 Thread Steve Coleman
I installed R4.0.4 RC1 on a new machine and restored my VM's from a backup.
Somewhere along the way, I started getting "cannot execute qubesdb-daemon"
errors and could not start some VM's that I had not yet run since the
restore process.

After a bit of sleuthing, I found that some of the log files in
/var/log/qubes/qubesdb. .log had the ownership of root.qubes rather
than .qubes. Once I did a chown to correct this problem
everything was back up and running.

I don't know how these logs got the root ownership applied to them, but
when the logfile could not be opened in the current user context from the
menu, qubes panel, or qvm-run command, the qubesdb-daemon was just quitting
without being able to log anything. The popup message was the only feedback
information to go by for chasing this down to the source of the error.
While this isn't a big deal for me it might be wise to do a permissions
check and a more useful message on failure since there is no logfile at
that point.

thanks!

Steve

-- 
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/CAJ5FDngnTZdnYA6U7JpLw%2BHtivNWd7vkxDSPP12nPnpY9s-%2BxA%40mail.gmail.com.


Re: [qubes-users] Signal app doesn't start (Fedora)

2020-08-26 Thread Steve Coleman
On Wed, Aug 26, 2020, 11:00 PM Crowphale  wrote:

> Thank you so much! It's working. Installing libXScrnSaver fixed the issue.
> (Sent a PR to fix the issue:
> https://github.com/luminoso/fedora-copr-signal-desktop/pull/4)
>
> I'm puzzled though, does anyone know why did running the `qvm-run` command
> in dom0 terminal gave me 127, instead of the missing dependency?
>

qvm-run basically only knows the error code from the command line executed
in the vm. It knows nothing about what the command is supposed to do or any
specifics on why it failed. The return code itself can be looked up or
googled to get an idea, but even that won't tell you which resource.

Note: When you use the -p option with qvm-run you can see whatever text and
errors the command being run generated. Thats a quick way to see what might
be wrong.



> Sent with ProtonMail <https://protonmail.com> Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, August 26, 2020 6:42 PM, Steve Coleman <
> stevenlcolema...@gmail.com> wrote:
>
>
>
> On Wed, Aug 26, 2020, 5:53 PM Crowphale  wrote:
>
>> Making progress...
>>
>> Found the Signal binary:
>> [user@crowphale ~]$ ls -l /usr/bin/signal-desktop
>> lrwxrwxrwx 1 root root 40 Aug  6 11:17 /usr/bin/signal-desktop ->
>> /usr/lib64/signal-desktop/signal-desktop
>>
>> [user@crowphale ~]$ ls -l /usr/lib64/signal-desktop/signal-desktop
>> -rwxr-xr-x 1 root root 116480632 Aug  6 11:17
>> /usr/lib64/signal-desktop/signal-desktop
>>
>> But trying to run it gives me 127:
>> [user@dom0 ~]$ qvm-run -a crowphale
>> /usr/lib64/signal-desktop/signal-desktop
>> Running '/usr/lib64/signal-desktop/signal-desktop' on crowphale
>> crowphale: command failed with code: 127
>>
>> Trying to run it directly in the AppVM terminal (probably wrong thing to
>> do), gives me:
>> [user@crowphale ~]$ signal-desktop
>> signal-desktop: error while loading shared libraries: libXss.so.1: cannot
>> open shared object file: No such file or directory
>>
>> I'm stuck. Any ideas?
>>
>
> You need to install libXss
>
> $ sudo dnf what provides '*/libXss.so.1'
>
> Will tell you what package is required.
>
>
>
>>
>>
>> Sent with ProtonMail <https://protonmail.com> Secure Email.
>>
>> ‐‐‐ Original Message ‐‐‐
>> On Sunday, August 23, 2020 12:38 AM, Steve Coleman <
>> stevenlcolema...@gmail.com> wrote:
>>
>>
>>
>> On Sat, Aug 22, 2020 at 10:50 PM 'Crowphale' via qubes-users <
>> qubes-users@googlegroups.com> wrote:
>>
>>> Sorry for stupid question, but how do I start Signal (or any app) from
>>> terminal? Is there some qvm-* command? Or how do I find the Signal binary?
>>>
>> I have not installed signal but I'll at least try to help.
>>
>> Open a terminal in your AppVM.
>> At the prompt type "signal" then press enter.
>> If it doesn't start then try:
>>"whereis signal"
>>or
>>"man -k signal" for help.
>>
>> If it installed normally in your template it is likely installed and
>> mounted as /usr/bin/signal
>>
>> If you find it, then you can start the app from dom0 with the qvm-run
>> command:
>> dom0> qvm-run -a  
>> Just replace the <> in the above with the appropriate info.
>>
>>
>>
>

-- 
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/CAJ5FDnhxcm3XsZiLh0dzLv3yFhftF3ktH_c%2BJ8RLrLq1WjyxoA%40mail.gmail.com.


Re: [qubes-users] Signal app doesn't start (Fedora)

2020-08-26 Thread Steve Coleman
On Wed, Aug 26, 2020, 5:53 PM Crowphale  wrote:

> Making progress...
>
> Found the Signal binary:
> [user@crowphale ~]$ ls -l /usr/bin/signal-desktop
> lrwxrwxrwx 1 root root 40 Aug  6 11:17 /usr/bin/signal-desktop ->
> /usr/lib64/signal-desktop/signal-desktop
>
> [user@crowphale ~]$ ls -l /usr/lib64/signal-desktop/signal-desktop
> -rwxr-xr-x 1 root root 116480632 Aug  6 11:17
> /usr/lib64/signal-desktop/signal-desktop
>
> But trying to run it gives me 127:
> [user@dom0 ~]$ qvm-run -a crowphale
> /usr/lib64/signal-desktop/signal-desktop
> Running '/usr/lib64/signal-desktop/signal-desktop' on crowphale
> crowphale: command failed with code: 127
>
> Trying to run it directly in the AppVM terminal (probably wrong thing to
> do), gives me:
> [user@crowphale ~]$ signal-desktop
> signal-desktop: error while loading shared libraries: libXss.so.1: cannot
> open shared object file: No such file or directory
>
> I'm stuck. Any ideas?
>

You need to install libXss

$ sudo dnf what provides '*/libXss.so.1'

Will tell you what package is required.



>
> Sent with ProtonMail <https://protonmail.com> Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Sunday, August 23, 2020 12:38 AM, Steve Coleman <
> stevenlcolema...@gmail.com> wrote:
>
>
>
> On Sat, Aug 22, 2020 at 10:50 PM 'Crowphale' via qubes-users <
> qubes-users@googlegroups.com> wrote:
>
>> Sorry for stupid question, but how do I start Signal (or any app) from
>> terminal? Is there some qvm-* command? Or how do I find the Signal binary?
>>
> I have not installed signal but I'll at least try to help.
>
> Open a terminal in your AppVM.
> At the prompt type "signal" then press enter.
> If it doesn't start then try:
>"whereis signal"
>or
>"man -k signal" for help.
>
> If it installed normally in your template it is likely installed and
> mounted as /usr/bin/signal
>
> If you find it, then you can start the app from dom0 with the qvm-run
> command:
> dom0> qvm-run -a  
> Just replace the <> in the above with the appropriate info.
>
>
>

-- 
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/CAJ5FDnjAwgHCOV-DYzqbzgSv8LUjsdA5BnSD9Xp5LpW5TOO4EA%40mail.gmail.com.


Re: [qubes-users] Signal app doesn't start (Fedora)

2020-08-22 Thread Steve Coleman
On Sat, Aug 22, 2020 at 10:50 PM 'Crowphale' via qubes-users <
qubes-users@googlegroups.com> wrote:

> Sorry for stupid question, but how do I start Signal (or any app) from
> terminal? Is there some qvm-* command? Or how do I find the Signal binary?
>
> I have not installed signal but I'll at least try to help.

Open a terminal in your AppVM.
At the prompt type "signal" then press enter.
If it doesn't start then try:
   "whereis signal"
   or
   "man -k signal" for help.

If it installed normally in your template it is likely installed and
mounted as /usr/bin/signal

If you find it, then you can start the app from dom0 with the qvm-run
command:
dom0> qvm-run -a  
Just replace the <> in the above with the appropriate info.

-- 
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/CAJ5FDnjvZwBY-Lw4Tu3vYOyKe0PWJG7ODLf-EGtPofoJ_hTwWw%40mail.gmail.com.


Re: [qubes-users] Can’t download large files

2020-08-08 Thread Steve Coleman
On Sat, Aug 8, 2020, 1:50 PM  wrote:

> Thanks for the reply. The system still prioritizes the tmp file even after
> I change the settings and use a usb. Do you know any other command that can
> disable the tmp folder?
>

Strange, I have never had any problem telling firefox where to download
anything. You do have enough free space before starting the download? (e.g.
df -H ) any volume has less than say 85% then you might want to grow that
volume a little first.

What you could try is to manually mount the USB volume on top of the
Firefox tmp folder instead. Then that one directory will have that whole
volume for that one temp directory/file.

Alternately you can Google how to create a temp file in dom0 with
'truncate', create a loop device for it, and pass that device into the
AppVM, format the volume ext4, and mount it where you need that extra space
temporarily. If you look up how to upgrade a fedora template you can find
the general instructions there to use as an example,  only where you mount
it will be different.

-- 
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/CAJ5FDniH5CgNPXApSO4L5c%3DP3RC2nBF8NKZ2Pq2_Ynt28b2zDA%40mail.gmail.com.


Re: [qubes-users] Can’t download large files

2020-08-07 Thread Steve Coleman
On Fri, Aug 7, 2020, 4:22 PM  wrote:

> I’m trying to download a 1.6gb file but after it’s complete I get:
>
> there is not enough room on the disk to save
> /tmp/mozilla_user0/fN+pjzFx.part
>
> I made sure the download was directed to another file after download in
> Firefox but it still keeps prioritizing the tmp folder. I then attempt to
> unmount:
> sudo umount /tmp  - -force
> Device is busy
> I tried deleting the mozilla_user0 and the system created the folder
> that’s only 1gb
>
> Is there any other way to fix this?
>

Under settings just set firefox to ask where to save files and then choose
a place where you have room for it.

If the file will only be needed temporarily you can try passing a USB to
the VM, mount it using the files app, and set Firefox to download it to
there. This works well if you just need to burn a DVD and remove the image
when done.

-- 
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/CAJ5FDnjyCEtXH9v4oWJuLYwnEKi0-M4%2B_Hpx1ZVAz44i11yO%2Bg%40mail.gmail.com.


Re: [qubes-users] Update templates in parallel

2020-08-02 Thread Steve Coleman
On Sun, Aug 2, 2020, 10:26 PM  wrote:

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

To start an app automatically in a appvm when the vm starts you can copy
the app.desktop file into (from my vague memory) your .config/autostart (?)
directory. Each time that vm starts that application will be launched just
as if you started it manually from the menu.

But if that vm starts on system startup, and before you login, this still
may not work any better than the rc.local method. You might then create a
.desktop to call a script that sleeps until the x11 is available, and have
that script launch the app when the system is ready.

-- 
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/CAJ5FDnhE4UpTD_iHSNjkaOtJQcFy4EzpW57YwTg28VfAVBgHFQ%40mail.gmail.com.


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

2020-07-29 Thread Steve Coleman
On Wed, Jul 29, 2020, 2:33 AM Qubes  wrote:

> On 7/29/20 1:56 AM, ludwig...@gmail.com wrote:
> > *What if it saves a spare set of encryption keys somewhere in its flash
> for
> > the "lawful investigator" to find?*
>  >
> I am not aware of any proof to support this line of thinking.
>

In the case of an Opal 2.0 encrypted drive the key is *never* stored on the
device. That is a requirement in oder to meet the defined Opal standard,
and any manufacturer needs to prove that they meet that standard by
submitting to a gauntlet of independently run certification tests. They
can't fake passing these tests.

The key(s) are generated at runtime by combining some internally generated
entropy plus the user supplied 256 bit password. If you reset the drive
then the internal entropy is regenerated as well, so even when having the
users old password one can not dynamically generate the origional
decryption key.

This basically means that if you build in a failsafe mechanism into your
software, to detect tampering, and flip the bits of your key and reset the
drive, that data is not recoverable even when provided the prior password.
Good luck at ever recovering that data even for your own purposes. Your
"lawfull investigator" has no better chance than the KGB at ever
recovering/seeing your data.

For a dead man's kill switch, Just reset the device and force a power down
and that data is no longer recoverable.

If you do not fully reset the device and only powered down, then the data
is only recoverable using the users 256 bit (hopefully randomized)
password. Even then the drives internal logic will add an increasing delay
with each invalid passrord attempt is made thus making even brute forcing
the password completely impractical.

Adding software encryption on top of that hardware layer encryption is a
good belt and suspenders approach if you really don't trust the device
itself to fully protect you.

I had the pleasure of working with one of the origional designers of this
standard, for almost a year while developing some very custom solutions
with these devices. While the first Opal 1.0 devices certainly had some
quirks, I trust the current line of Opal 2.0 SSD Sed devices to keep your
data both safe and confidential.



-- 
> 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/0a24d013-6bca-4d66-3e4c-1d6ab13fd3e8%40ak47.co.za
> .
>

-- 
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/CAJ5FDnhmpeygJPvp1UQax2ji2jz7oW13xfW4QDZ1aB_HUtNk8Q%40mail.gmail.com.


Re: [qubes-users] Re: Does qubes protect against all firmware viruses ?

2020-06-12 Thread Steve Coleman
On Fri, Jun 12, 2020 at 2:35 PM  wrote:

> Well that's the problem indeed, knowing if you are clean from firmware
> viruses in the first place. But i don't suspect i have firmware viruses and
> i have new pc. It takes a lot of time and money and no one would bother to
> infect specific user. I am no one. It could be used in attacks on multi
> peoples, or if already some firmware virus existed someone could use it i
> guess, i don't really know. Even probability is low. I am just acting
> responsibly about this. If i can use Qubes, than why not right. So if i use
> Qubes, using ROM optical disk in external mechanic. So i should be
> generally safe, (nothing is perfect), even if i got firmware viruses
> afterwards ? I can't unplug disks and disable all of them in BIOS, i am
> using NVME and it is blocked by GPU vertical mount and it was insane to
> plug it in the first place and doing that each time, it is not feasible. So
> if i boot from live CD, not sure if viruses on hard disks could do
> anything. And i won't be booting from Windows when live CD is in and it
> would be ROM and i'll use external CD mechanic.
>
> Also i don't know what i was saying previously, but i can't dedicate old
> pc for banking at least with Qubes, it doesn't work there. So i would be
> using it on my main PC. But if i used other Linux on my old pc and
> dedicated it only for online banking, that should be safe right ? Even if i
> had it long time, so i could have potentially some firmware viruses, that
> could impact security in future. Even if i had them and they didn't do
> anything so far. I don't know.
>

There is not much one can do to protect against firmware viruses other than
to try and prevent situations where someone can reflash your BIOS in the
first place. Since the BIOS is initialized even before the software/OS
gains control the malware code would already be resident in memory before
the DVD booted that read-only media. The DVD drive can not even operate
until the system initializes the BIOS that understands how the DVD drive
even works, so if someone was able to reflash the eeprom then game-over
even before the OS is even loaded. Any software loaded after the malicious
code is in memory is of course subject to what that code wants to do with
your system in the first place.

That being said, it is extremely difficult to reflash your BIOS when
running a general OS in the normal user context, and even more difficult
when running a virtualized system such as Qubes. So, if you can prevent the
machine from booting from any external devices then you have just raised
the bar for that adversary.  If you can prevent them from gaining physical
access to the computer internals, as to attach a JTAG device, then that
raises the bar even higher. Chances are the adversary would need physical
access to the machine to pull this off, which means that any three letter
agency or forign government would have to want you really really bad before
they put someone to task to rig your physical machine like that. yes it's
possible, but there are easier ways to do what they want than reflashing
BIOS so this scenario is unlikely unless you are one very important person.

-- 
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/CAJ5FDni_eF-YtLtxNHMWh-o08-EaLNd3mLJsfhz_1u6roMJnPQ%40mail.gmail.com.


Re: [qubes-users] Re: Libreoffice Calc windowsize is 1x1 cm ..

2020-05-29 Thread Steve Coleman
I loved the idea of the macros to manage the desktop in general as I would
really like to pin Qubes Manager to desktop 1 and not have it start on
whatever desktop the person last logged out from.  But that is obviously
fixable now.

I did do a little digging into this LO window size issue just because I
wanted to understand what was actually happening. I have had several VMs
act up, but not all of them in the same way, so I dug deeper to see what
the differences might be.

The answer is  that window size information is stored in the file:
.config/libreoffice/4/user/registrymodifications.xcu

> grep
ooSetupFactoryWindowAttributes
.config/libreoffice/4/user/registrymodifications.xcu


This will give you several lines like:

*61,61,1807,982;5;38,56,1807,982;*


By opening any Libreoffice app you can navigate to see/edit the same values
from the Tools menu:
Tools
   Advanced
  click [Open Expert Configuration]
 Search for: "ooSetupFactoryWindowAttributes"
Then scroll right to see the values set for each component as a string
value, eg:  "*61,61,1807,982;5;38,56,1807,982;*"

The window position values are specified as:
x-pos,y-pos,*width,height ;* window-state *;*
maximized-x-pos,maximized-y-pos,maximized-width,maximized-height *;*

In my VMs that were broken (two pixel window size) this file was missing
all but one ooSetupFactoryWindowAttributes line in this file, where as
there were many lines, one for each libraOffice app in the working VMs. As
a test, I cut-n-pasted the group of lines from a working VM into the broken
xcu file using gedit and saved, and tried again. Everything worked! The
window size problem was gone. So then I started looking more closely with
gedit and meld to watch what was changeing.

As each LO app is run it adds its line to the xcu file with x-pos,y-pos,
*2,2*,... as the default width,height values of only two pixels. Changing
those values to any valid set of Width,Height numbers will make the window
open with that predefined size. Upon exiting the app with any manually
adjusted size does not save that new value back to the xcu file. Its
width,height values are apparently read at the start and completely ignored
on exit, even though the xcu file will be rewritten with many other
modified values.  For instance if you open and manually resize the window
and then click maximize just before before exiting then the *0,0* for the
*maximized-width,maximized-height* will be updated to that new set of
values but the origional *width,height* values will remain unchanged. It
appears that manually editing these width,height values from 2,2 to
'something more reasonable' is the only way to perminantly change them.

Steve.






On Thu, May 28, 2020 at 3:27 PM  wrote:

>
>
> Am Donnerstag, 28. Mai 2020 20:34:45 UTC+2 schrieb Dave:
>>
>> Ok thanks for the tip, i just tested you suggestion and it resizes the
>> window perfectly.
>> Do you autostart devilspie2 at boot .. or how do you use it ..?
>>
>>
>  I start it via .desktop file in .config/autostart.
>
> It really is a handy tool. I use it for other things like mapping domains
> to certain workspaces.
>
> --
> 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/3e39d011-8d2b-474e-818a-ed0b6058ef40%40googlegroups.com
> 
> .
>

-- 
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/CAJ5FDnj7Z%3DcL%2BCA3RO2DfRWjpd%3DvKDr3N618uNmVmUVKpXHfYA%40mail.gmail.com.


Re: [qubes-users] QUBES Friendly Version

2020-05-13 Thread Steve Coleman
On Wed, May 13, 2020, 6:35 AM Eva Star  wrote:

>
>
>> Personally, I consider systemd both a mistake & a security hazard,
>>
>>
> Can you please share more details about this? Personally, I don't use both
> of them, but wan't to know.
>

You use systems if you use almost any flavor of Linux. The systemd is a
process that controls so many things on a system that some people joke
about it being a second operating system on top of the Linux kernel. The
"security hazard" part comes from the sheer complexity of that code,
because it is hard to verify and audit the a system.

Just like the old init scripts used to do, systemd basically controls the
startup, initialization, and then manages many daemons behind the scenes.
You have to just trust that it is going to do the right thing under any
particular circumstance.

If a rogue actor changed your configuration it could be difficult to detect
in some cases. Gaining a persistent foothold on your system would be a
common goal for an adversary and system gives them several ways to do that.

Qubes however uses a read-only system volume so simply adding extra
processes to your system is rather difficult to do by using systemd. They
really need either dom0 or template access to do 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/b40a5604-efe8-4049-8dff-36d5817a438a%40googlegroups.com
> 
> .
>

-- 
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/CAJ5FDnjLC3ecF6Z9C00pruaHXp45OD7AD%3DjnyB-_B0BDJH1cBg%40mail.gmail.com.


Re: [qubes-users] What's your flow for new templateVM?

2020-05-11 Thread Steve Coleman
On Mon, May 11, 2020, 10:26 AM 'Ryan Tate' via qubes-users <
qubes-users@googlegroups.com> wrote:

> I manually maintain this big text list of packages and just use
> that to manually update the fresh templateVM to what I
> need. There's typically also some non package installs, which I
> include basic pointers for (think downloaded rpms and so forth),
> as well as some outside repos to add (e.g. keybase). There's also
> typically some packages I forgot to put on the list, which I can
> usually suss out by going through the bash history for the old
> template, although often there's one or two that slip through the
> cracks, which I find out about eventually and it's not a huge
> deal.
>

I'm particularly curious if anyone does anything more
> sophisticated than that, using salt or some other automated deploy
> system to prep new template images.

I was just playing with creating a domain bash script that runs "qvm-run
-p"  in one template to extract the list of packages (dnf list), then
subtracts the list from the second template, pulls that difference list up
in an editor, and then pushes the manually edited list to the next template
( dnf install $list). Then I found there were so many packages I did not
particularly want to carry forward without proper investigation that I
essentially put that script on hold.

I obviously need to take my time to decide what I want to bring forward.
Things like python2 packages need to be weeded out, as well as other
packages that I was merely investigating for use at work but don't have any
need for now that I am retired.

I think the general script/process has merit but I have far too many
packages to evaluate in a single session. Simply pushing everything in one
go would merely add a lot of stuff I did not need. When I have time I may
just delete most of the packages from the editor and do this in chunks as I
find time to work on 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/CAJ5FDnjUHU_XoWewpbjbMdWGWJzUbZHqeK_n%3DvUTZqDVHfBrrg%40mail.gmail.com.


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

2020-05-09 Thread Steve Coleman
On Fri, May 8, 2020 at 7:13 PM Catacombs  wrote:

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

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

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

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

LibreOffice is what you want for journalists.

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

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

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


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

Perhaps not, but very likely we are trainable.

-- 
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/CAJ5FDnh2HXSmn1CZM%3D7DN9McvtTWUHw%2BcEtVRGeQa_f68bpFyA%40mail.gmail.com.


Re: [qubes-users] Anyone here try VMware in place of QUBES?

2020-04-30 Thread Steve Coleman
On Wed, Apr 29, 2020, 11:03 PM Catacombs  wrote:

> I have used VMware on a Mac.  I do not the idea of OS X being the base of
> my security,  however like they say about a lot of Apple, it just works.
>

I have to ask why you reject  OSX for being the base of your security?
Because you can not audit the code? No way to be sure if you can trust it?
Then there is no difference then between OSX and VMware.

Xen was chosen because it is both small in size (comparatively) and open
source and is therefore auditable. You know what it will do when you use
it. With VMware its just you trusting a black box, and you have no way to
know what its doing under the hood without reverse engineering the binary
code.

That is why Qubes uses Xen instead.


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/fc43c85d-4cde-4607-927d-5adc8d057b8e%40googlegroups.com
> .
>

-- 
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/CAJ5FDng5sfpCE3iEi5mYN8_5yBzzTpZbJSpjWHAZEPGX34%3DLbg%40mail.gmail.com.


Re: [qubes-users] Q: LV (disk) as fake USB stick?

2020-04-21 Thread Steve Coleman
Spoofing the hardware information (e.g. lshw, hdparam, lspci, etc) of a
virtual drive is going to be difficult. As an alternative you might want to
play with installing it on an actual USB stick and then clone that
partition over to your virtual drive. If the software then refuses to run
because it realizes that the volume identifiers changed then you may be out
of luck, unless you are up to patching the binary. But you will never know
unless you try.

-- 
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/CAJ5FDnj8m1qKpfFR0TGSnk6SSwkbNPdsJiwt3sy-fT-HrPMCFQ%40mail.gmail.com.


Re: [qubes-users] What does ISP see when my computer connects?

2020-04-06 Thread Steve Coleman
On 4/5/20, Catacombs  wrote:
> And what the ISP sees after I start a Qube?
>
> How can I see what my MAC is on a receiving website.  Documentation suggests
> that it would see a spoofed MAC.  But that spoofed MAC needs to be
> unpredictable and look normal.

Nobody but your local router will ever see your MAC address. If your
machine is behind a firewall then they will only see the IP address of
your cable modem or firewall, depending on how you connect to the
Internet. Very likely you have no control over the IP address that
your Internet provider assigned to your own equipment.

People who spoof/randomize their MAC address are generally concerned
with use-cases where the need to connect to a public WiFi where the
MAC address is announced on that untrusted WiFi router such as at an
internet cafe or coffee shop.  In that case randomization of the MAC
can help to somewhat hide your identity, or at least make it less
predictable as to which MAC address connection is actually yours. Any
logging of session would only have captured some random MAC address
which is not in any way tied to your physical WiFi card NIC.

If you care about your assigned IP address being visible to the
websites that you visit then you should look into setting up a VPN, in
which case your address on the internet will always appear as a random
address at your VPN provider, or one of the hosts that they rent for
network services. In other words, it will never be your own IP
address, or internet providers, but rather one that is shared with
many thousands of other people on a rotational basis.

-- 
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/CAJ5FDnjG8sXOqKmf7YjqYTf6ga3JLw5U9fSdEyudK8sKa_-85Q%40mail.gmail.com.


Re: [qubes-users] Cloning Qubes onto a USB flash drive.

2020-04-06 Thread Steve Coleman
On 4/5/20, Catacombs  wrote:

> Could the cloned version of Qubes on the USB  Flash drive be used on another
> hardware to actually run Qubes?

Why not simply boot from The Qubes install media and install Qubes
onto the USB drive, and then restore your choice of AppVM's from an
existing backup of your main system? This will have the added benefit
of actually testing your 'disaster recovery plan' without having to
change or modify your main installation. You will then be more
confident in your own ability to recover from an actual disaster and
will have a way to boot your computer to correct any damage done
during future software upgrades.

-- 
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/CAJ5FDngNBB9er%3DgmkxCayp3fySjoqZBS0gyu_bwN77enkTGKpw%40mail.gmail.com.


Re: [qubes-users] Where to find the directory of a attached mobile phone ?

2020-02-28 Thread Steve Coleman
On 2/28/20, A E  wrote:
> fre. 28. feb. 2020 kl. 21.07 skrev :
>
>> On Fri, Feb 28, 2020 at 12:01:04PM -0800, A wrote:
>> > I have attached my mobile phone to a VM, but can’t find its directory
>> > in the file manager of that VM.
>>
>> in which way did you attach it?
>> do qvm-block or qvm-usb show it as attached to the right vm?
>> does it show up in /proc/partitions or lsusb in the target vm?
>>
>> and does whatever you are trying to do work in sys-usb?
>>
>>
>>
>>
> Thank you for your very quick response.
>
> The mobile phone is listed as two devices:
>
> 1)  sys-usb: sda - Disk ()
>
> 2)  sys-usb: 1-3 - ..._Mass_Storage_Device_...
>
> I have tried to attach both - one at a time - in the following way.
>
> I attached it by clicking on the device icon -> The device (mobile phone
> storage) -> The VM that I would like it to be attached to.
>
> When attached, they both appear as such according to qvm-block and qvm-usb
> in dom0.
>
> When I attached the second one, and execute lsusb in the VM terminal where
> it is attached to, it show up.
>
> I don’t know how to check the attachment of the first device in the VM
> terminal.
>
> In the file manager of the attached VM under /proc/partitions, I find a
> file that only displays partitions with xvd... I don’t know if the attached
> partitions is some of these.
>
> No, I haven’t been able to locate the directory of the mobile phone in the
> file manager of the sys-usb VM either.
>
> Any ideas on how to proceed... ?

If using your file manager in the AppVM does not display the new
device you can always use qvm-block in dom0 to tell you where the
device is currently assigned, and under what name.
Once you have attached the device to your AppVM you can run qvm-block
in dom0 with no arguments and it will display the device name in the
results. You will see it as "frontend-dev=" on that
line on the right. Probably "xvdi" or something close to that.

Then you can then use the mount command in the AppVM to mount the
device (e.g. "/dev/xvdi" ) wherever you like.

-- 
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/CAJ5FDnhQshg%2BnDmTGGB8OCT%3DXLt4oVnhqO9OnY_sZxMLDUjbTA%40mail.gmail.com.


Re: [qubes-users] SSD and safety.

2020-02-26 Thread Steve Coleman
On 2/26/20, ggg...@gmail.com  wrote:

> I discovered there is no program to clear an SSD.

If you are using an Opal 2 compliant SSD and had created an encrypted
range before formatting your partition then all that data disappears
instantly when you reset the SSD. The one requirement is the SSD drive
must be functional in oder to reset it, and it won't matter much if
there are unuseable blocks or file corruption as all the bits on the
drive, good or bad, get flipped all at once.

Any used, free space, or damaged memory blocks get reset right along
with the user data.  The entropy values stored internally on that
drive get reset so even someone having the prior password can still
not regenerate the same encryption key to unlock the drive. All memory
blocks that ever had your data will be meaningless 1's and 0's.

On the label of the Opal 2 SSD drive there would be a long hex PSID
number printed on it, and if you supply that # to the sedutil-cli
command:

# sedutil-cli --yesIreallywanttoERASEALLmydatausingthePSID MYPSID /dev/sdc

then everything previously stored on that drive becomes unrecoverable
in an instant. If you think you need a non-recoverable "panic-button"
then the above command will do nicely. Nobody, not even you, is ever
going to see that data again. If you also used software based
encryption on top of that partition then you can be doublly sure that
your personal information can never be recovered.

If you install the "Pre-Boot Authentication" (PBA) to unlock the
encrypted drive during the initial boot cycle then you have the
additional advantage that the boot partition locking range can even be
made read-only while the data is at rest. When doing this even an
Evil-Maid system admin won't be messing with your system. Just
remember to make it writable again before trying to apply any updates
to your boot partition.

Note: With enabling these SED capabilities on your primary drive you
will likely be giving up laptop "suspend" capability. If you
absolutely need to protect your data then this is a fair trade-off
since the suspended memory image would be far too dangerous to leave
laying around anyway.  A hot-plug attack is the achillies heel to an
Opal drive, so powering down is important anyway.

https://github.com/Drive-Trust-Alliance/sedutil/wiki/Encrypting-your-drive
https://github.com/Drive-Trust-Alliance/sedutil/tree/master/LinuxPBA
http://chrisarges.net/2018/02/16/using-sed-encryption-on-disks.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/CAJ5FDnj0v3gJFwoaw816PN%2BFkv5nSVF5mmyK4%3D2pS_vYz0r1yw%40mail.gmail.com.


Re: [qubes-users] Running sshd on an AppVM

2020-02-24 Thread Steve Coleman
On 2/24/20, tetrahedra via qubes-users  wrote:
> On Mon, Feb 17, 2020 at 10:03:26AM +0100, dhorf-hfref.4a288...@hashmail.org
> wrote:
>>On Mon, Feb 17, 2020 at 08:59:18AM +, tetrahedra via qubes-users
>> wrote:
>>> like only debian's `apt-search` will search the binary names, fedora's
>>> `dnf search` appears not to.

Fyi - The dnf command does search for binaries, but you need to use
the full path, or a wildcard path, for it to work correctly.

e.g.
$ sudo dnf search '*/sshd'

will return the package that will install the 'sshd' binary.

-- 
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/CAJ5FDngkPA9OhioZ3v3ncaS%3Dxbkc%2BRRqOZRiVWzD5FCjhVKsRg%40mail.gmail.com.


Re: Re: [qubes-users] Scary Systemd Security Report

2020-02-15 Thread Steve Coleman

On 2020-02-12 01:09, ronp...@riseup.net wrote:

APL external email warning: Verify sender 
qubes-users+bncbci3h2v54mhrbjnnr3zakgqe4jht...@googlegroups.com before clicking 
links or attachments

On 2020-02-11 11:39, unman wrote:

On Tue, Feb 11, 2020 at 01:34:15AM -0800, ronp...@riseup.net wrote:

I've been reading a blog from the renowned Daniel Aleksandersen at
https://www.ctrl.blog/entry/systemd-service-hardening.html

The output from a Debian-10 based Appvm looks a little scary!! Should I
be concerned?

user@tmp3:~$ systemd-analyze security
UNIT EXPOSURE PREDICATE HAPPY
ModemManager.service  5.6 MEDIUM
NetworkManager.service7.6 EXPOSED   
avahi-daemon.service  9.5 UNSAFE
cron.service  9.5 UNSAFE
cups-browsed.service  9.5 UNSAFE
cups.service  9.5 UNSAFE
dbus.service  9.5 UNSAFE
dm-event.service  9.5 UNSAFE
emergency.service 9.5 UNSAFE
exim4.service 9.5 UNSAFE
getty@tty1.service9.5 UNSAFE
haveged.service   5.6 MEDIUM
lvm2-lvmpolld.service 9.5 UNSAFE
polkit.service9.5 UNSAFE
qubes-db.service  9.5 UNSAFE
qubes-firewall.service9.5 UNSAFE
qubes-gui-agent.service   9.5 UNSAFE
qubes-meminfo-writer.service  9.5 UNSAFE
qubes-qrexec-agent.service9.5 UNSAFE
qubes-sync-time.service   9.5 UNSAFE
qubes-updates-proxy.service   9.5 UNSAFE
rc-local.service  9.5 UNSAFE

rescue.service9.5 UNSAFE
rsyslog.service   9.5 UNSAFE
rtkit-daemon.service  6.9 MEDIUM
serial-getty@hvc0.service 9.5 UNSAFE
systemd-ask-password-console.service  9.3 UNSAFE
systemd-ask-password-wall.service 9.3 UNSAFE
systemd-fsckd.service 9.5 UNSAFE
systemd-initctl.service   9.3 UNSAFE
systemd-journald.service  4.3 OK
systemd-logind.service4.1 OK
systemd-networkd.service  2.8 OK
systemd-timesyncd.service 2.0 OK
systemd-udevd.service 8.3 EXPOSED   
tinyproxy.service 8.7 EXPOSED   
udisks2.service   9.5 UNSAFE
user@1000.service 9.1 UNSAFE
wpa_supplicant.service9.5 UNSAFE
xendriverdomain.service   9.5 UNSAFE



It does look scary.
The output from a Fedora based qube looks much the same..
You should run the analysis against each service and see where you think
they could be hardened. Post back your conclusions here.
Also, I see that you have many services that need not be there - some
of these will be disabled by Qubes- some you do not need in every qube
(cups-browsed, exim4, tinyproxy etc).
You need to review what services you are running, and disable those you
do not want. My list in an ordinary qube looks rather different from
yours. Those are steps you should be taking in any case.
Also, bear in mind that the analysis doesn't take in to account any
security features in the programs themselves, or other mitigations.
So you need to do a good deal more work before reaching any conclusions
about your system.
Look forward to hearing from you
unman


As I read it, your suggesting that the output is influence by User
preferences as opposed to default system settings? To test that theory,
I loaded a vanilla version of Qubes 4.0.3 onto a spare box and ran the
command systemd-analyze security against the virgin Debian-10 Template.
The output is identical to the one I originally posted. As you inferred,
the output from Fedora Template is similar.

I'm not sure if you'll agree, but my conclusion from this experiment is
that the Qubes Team have some work to do in hardening Qubes? Like you
say,"I see that you have many services that need not be there"; so my
question is, why are they present in a vanilla version of Qubes?



I ran the report on my fedora-30, but then scripted up a test to see 
what services listed in this report were actually running.


atd.service - Deferred execution scheduler
cups.service - CUPS Scheduler
getty@tty1.service - Getty on tty1
haveged.service - Entropy Daemon based on the HAVEGE algorithm
polkit.service - Authorization Manager
qubes-db.service - Qubes DB agent
qubes-gui-agent.service - Qubes 

Re: [qubes-users] Trouble Accessing Network Manage

2020-02-07 Thread Steve Coleman

On 2020-02-07 02:43, 'e.sparks15' via qubes-users wrote:
*APL external email warning: *Verify sender 
qubes-users+bncbcy5z3pfy4frbqfk6tyqkgqewhij...@googlegroups.com before 
clicking links or attachments


Hello!
I am having trouble anonymizing my MAC address -- the documentation says 
that I need to go into the Network Manager in the tray on my sys-net 
Qube, but I can't find NM anywhere. I can access it via the terminal, 
and have been able to use [[sudo NetworkManager -V]] in both sys-net and 
dom0, so I know it's there, but I don't know how to access it.


If it's of any help, when I check the version in dom0 it gives 
1.4.6-1fc25, but in sys-net it gives 1.15.4-1fc30. Also, I added 
"network-manager" into the net-sys qube via the "Services" tab in that 
Qube's settings, but that didn't seem to change anything.


Take a look for "nmcli" in sys-net which allows you to perform command 
line operations on the NetworkManager service.


There should also be a icon/control on your tasksbar that looks like two 
computers. Right click that icon to get the menu and select "edit 
connections".


I've looked through the FAQs, I've searched the web, and I've phoned a 
friend. I've looked over the documentation, too, but I'm sorry to say 
that it's beyond my ability to understand at this point*. I've played 
around with it on my own for a number hours, but I'm just out of my 
depth here. Any help would be greatly appreciated!


Thanks so much!


--
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/8ed0d18a-a284-0d99-760f-89eef70de136%40jhuapl.edu.


Re: Re: [qubes-users] How to use the USB modem HUAWEI E3372h to connect to the internet in Qubes OS 4.0.3 ?

2020-02-05 Thread Steve Coleman

On 2020-02-04 16:00, M E wrote:
*APL external email warning: *Verify sender 
qubes-users+bncbdzmb4gysmcbbf5x47yqkgqetesd...@googlegroups.com before 
clicking links or attachments


tir. 4. feb. 2020 kl. 20.15 skrev M E >:


tir. 4. feb. 2020 kl. 00.26 skrev Frank mailto:q5wrm4n...@snkmail.com>>:



On 3. Feb 2020, at 19:10, M E anneeyr...@gmail.com
 wrote:
man. 3. feb. 2020 kl. 06.59 skrev Frank
mailto:q5wrm4n...@snkmail.com>>:



On 3. Feb 2020, at 01:07, M E anneeyr...@gmail.com
 wrote:

<7A330E21-63FF-420D-9745-EF562F243634.jpeg>
If you can’t see the picture, here is a link to it:


https://13366229192823780453.googlegroups.com/attach/100126185e473c/4B89147B-20D5-40EE-A9BB-C71175811C5E.jpeg?part=0.1=1=ANaJVrECT01L2y8o5GwqdnJROLrBq8aKok0PabHMta-x2aY0Ob1KwhJoE_Snqv2pAtXYHNzEbvoZ7nyYlTG0CRXzUxozMo_uhBFSozVSFPdSHxms06amRS4

I got the “dmesg”-output by logging in to the root account and
use the dom0-terminal. I couldn’t run the command in a dom0
terminal when I logged in as a user.

I got this answer at “www.draisberghof.de
”:

“The cdc_ether driver has bound to your dongle, has created an
eth0 device which immediately got auto renamed to enp0s20f0u10
and this device should be visible under Mobile Broadband in
NetworkManager.
There are 3 required setting in NetworkManager for a Mobile
Broadband connection and they are Country, Provider, APN where
after you will get a connection.
If you don't then it is not a question for this forum,
usb_modeswitch has done what it should do.”

Then the problem seems to be related to either ModemManager,
NetworkManager or Qubes OS as I know the USB modem works.

According to this page (link:

https://distrowatch.com/table.php?distribution=qubes=true=4.0.3#pkglist
 )
Qubes OS 4.0.3 comes with these packages:

  • ModemManager-glib-1.6.4-1.fc25.x86_64.rpm

  •  NetworkManager-1.4.6-1.fc25.x86_64.rpm
  •  NetworkManager-glib-1.4.6-1.fc25.x86_64.rpm
  •  NetworkManager-libnm-1.4.6-1.fc25.x86_64.rpm
  •  NetworkManager-team-1.4.6-1.fc25.x86_64.rpm
  •  NetworkManager-wifi-1.4.6-1.fc25.x86_64.rpm

The latest version of:
     ModemManager is 1.12.0
     NetworkManager is 1.22.4


Here we are with a basic problem in your understanding of how
Qubes works... ;-)

If you got this dmesg output in a dom0 terminal, this is the
worst place possible this USB stick can show up.

A Qubes system usually has a sys-net VM that gets all network
devices assigned, so they won‘t show up in dom0 and pose a
security risk there, since dom0 controls everything and you
don’t want to give anybody a chance to get into dom0 and take
control of it. That is - by the way - also the reason, why there
is no network connection available in dom0, even in fully
functional systems.

Most Qubes systems also have a sys-usb VM that will get assigned
all the USB controllers to get those away from dom0 as well. To
use any of those assigned devices, the VM having those devices
assigned to must be running.

There is also the possibility to combine sys-usb and sys-net
into one VM. Having an USB-Stick providing a network interface,
this might be a good idea.

Anyway, once you assigned the USB controller :00:14.1 to one
of those VMs, your modem will show up in that VM and not anymore
in dom0. This VM will have a far newer version of Linux running
(i.e. Fedora 30 or Debian 10) than dom0 (Fedora 25 in Qubes
4.0.3) and thus far newer versions of NetworkManager and
ModemManager available than in dom0.

If any of the above is completely over your head, I suggest that
you read some of the Qubes OS documentation before going on,
since the above is the fundamental concept of Qubes...

Regards, Frank

-- 
You received this message because you are subscribed to a topic

in the Google Groups "qubes-users" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/qubes-users/LRZzJfkHER0/unsubscribe.
To unsubscribe from this group and all its topics, 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/17122-1580772359-818194%40sneakemail.com


Re: [qubes-users] How to open a text editor in qubes after installation when sys-firewall configuration failed ?

2020-01-28 Thread Steve Coleman

On 2020-01-28 14:59, M wrote:


How can I open a text editor in Qubes to view logs and edit xen.cfg file ?


You can usually count on vi being on any linux distribution

> sudo vi /boot/efi/EFI/wubes/xen.cfg


And I can’t get internet access from the pc as sys-firewall failed.


To trouble shoot that, you can open Qube Manager and right click on 
sys-firewall, then you will see "logs" at the bottom of the dropdown 
menu. if you don't find the problem in there then you might try:


dom0> sudo dmesg

or

dom0> sudo systemctl

and look for your errors.

--
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/9260d5f4-35a3-f998-86dd-898b41be6ea8%40jhuapl.edu.


Re: [qubes-users] "Qubes Domains": Add tools/commands to the tray icon (for DVM)

2020-01-23 Thread Steve Coleman

On 2020-01-23 09:42, 'awokd' via qubes-users wrote:


Major Lazor:

Am 23.01.20 um 15:26 schrieb 'awokd' via qubes-users:

Major Lazor:

Is it possible to add tools or commands to the tray icon "Qubes Domains" ?


Its not exactly the same thing as adding a permanent menu for dispVm's 
but I have an launch icon which calls my qvm-add-disp script in dom0.


It's simple and it works for me. You just start as many dispvm's as you 
like and then click the desktop launcher icon when you need to add 
another app to some dispvm instance. You could put the launcher itself 
in the menu if you like, or the toolbar.


The bash script simply enumerates the currently running DispVM instances 
and generates a zenity GUI listbox with check boxes, one for each 
combination of dispVM/application. The script hard-codes a list of 
available applications in the  APPS=() list variable.


When the GUI appears I can then check off which apps I want to launch in 
which specific dispVMs. When I click the Ok button it will roll through 
those selected combinations and launch whatever I had selected from that 
listbox in the requested dispvm instances.


All you have to do is edit the APPS=( prog1 prog1 ) list to allow for 
selecting your specific applications instead of my current set of apps.


Note: I believe I had to add zenity application to my dom0, so this 
script does of course have some minor security implications. But I'm ok 
with that risk given the convenience that it gives me to graphically 
prompt myself for little utilities like this, and where a full blown 
python gui app is just too much trouble. Its simple and it works well 
for the little things.


Steve


--
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/97500b65-85ee-a28f-a198-c0a2e8f1bd66%40jhuapl.edu.
#!/bin/bash -xv

# list of running disp vm's
DISPNUMS=`qvm-ls --raw-list | grep -oP '(?<=disp)[0-9]+'`
idx=0
for num in `echo ${DISPNUMS[@]}`
do
   VMLIST[$idx]="disp$num"
   n=`expr $idx + 1`
done

#echo $VMLIST

applist=[]
applistsize=0
APPS=( nautilus firefox gedit google-chrome gnome-terminal )

# build list of disp VM's
for vm in `echo ${VMLIST[@]}`
do
   for app in ${APPS[@]} 
   do
  applist[$applistsize]="false $applistsize $vm $app"
  let applistsize++
   done 
done

if [ $applistsize -gt 0 ] ; then
   SELECTED=`zenity --list --checklist --title="What app would you like to 
add?" --hide-column=2 --column="Run" --column="lineno" --column="VM" 
--column="App"   ${applist[@]} `

   for row in `echo ${SELECTED[@]} | sed -e 's/|/ /g'`
   do
  #echo $row ${applist[$row]} | awk '{print $0}'
  DISPVM=`echo ${applist[$row]} | awk '{print $3}'`
  EXEC=`echo ${applist[$row]} | awk '{print $4}'`
  qvm-run $DISPVM $EXEC &
   done
else
   echo No disp VMs running
fi



Re: Re: [qubes-users] Re: Write-error on swap-device after having a full storage

2020-01-23 Thread Steve Coleman

On 2020-01-23 04:08, Vít Šesták wrote:
*APL external email warning: *Verify sender 
qubes-users+bncbct5hvg33eerbeofuxyqkgqeaao4...@googlegroups.com before 
clicking links or attachments


Thank you! This has allowed me to mount the volume to a DVM, which has 
allowed me to fix the issue. Just running fsck in the DVM was enough to 
fix the issue.


Maybe I should create an issue (or find an existing one) for that.


Maybe we should just wrap that set of commands into a script to make it 
quick and easy?


Something like:

$ qvm-mount-lvm-image AppVM remote-mount-point thin-pool-volume-name1

Being a belt and suspenders kind, I would use it on a regular basis just 
to grab a diff for any changes to the persistent areas like /rw/usrLocal 
in specific internet facing VMs after shutdown.


If you ever have an AppVM get hacked, there are only so many places that 
offer persistence within an AppVM, so I would like to launch a dispvm 
every so often just to roll through each private volume to hash check 
that set of directories and compare the new checksums to any prior 
stored values.  This way when something touches the /usr/local I will 
know about it.


It would also be a good idea to measure places like the users special 
areas like .config/ .local/bin looking specifically for executables that 
might be launched automatically without the users own knowledge.



Regards,
Vít Šesták 'v6ak'


--
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/3c01c7e5-1c42-4b7d-5ff8-631c7fde37e0%40jhuapl.edu.


Re: [qubes-users] Re: Write-error on swap-device after having a full storage

2020-01-22 Thread Steve Coleman

On 2020-01-22 12:22, Vít Šesták wrote:
*APL external email warning: *Verify sender 
qubes-users+bncbct5hvg33eerbs4julyqkgqezk4s...@googlegroups.com before 
clicking links or attachments


I have tried to debug it further. Unfortunately, I am unable to attach 
the VM's drive to a DVM:


$ qvm-block attach disp1163 dom0:mapper/qubes_dom0-vm--debian--10n--root
qvm-block: error: backend vm 'dom0' doesn't expose device 
'mapper/qubes_dom0-vm--debian--10n--root'


How can I do that?


Would this help?

How to mount LVM image
https://www.qubes-os.org/doc/mount-lvm-image/



Regards,
Vít Šesták 'v6ak'

--
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/6e388d39-6ef4-4035-80be-23b7e9d1eab6%40googlegroups.com 
.


--
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/c1083eec-9f7e-df0a-3af0-c8dd5a56b67f%40jhuapl.edu.


Re: Re: [qubes-users] Open several files in THE SAME dispVM

2020-01-21 Thread Steve Coleman

On 2020-01-21 05:38, Major Lazor wrote:

APL external email warning: Verify sender r.wiesb...@web.de before clicking 
links or attachments

Thank you for your ideas. From my understanding all your ideas that
would mean to open a Terminal and run

./script.sh a.ext b.ext c.ext d.ext

typing this is not much simpler than

1. start dispvm with nautilus
2. send files from source-vm nautilus
3. open files in destination-vm nautilus

in my opinion. This would only be useful if this could be added to
nautilus context menu. I guess this can be integrated using nautilus
actions.


I was curious so I explored how to do the context menu in Gnome/Files 
app for kicking this off. Here is what I did:


I first wrote a bash script to test:

$ cat open_multiple
#!/bin/bash
zenity --list --column="Column name 1"  $@


I copied a desktop file to my .local/share/applications/ and edited it 
to look like:


[Desktop Entry]
Name=OpenMultiple
Exec=/home/user/bin/open_multiple %U
Icon=utilities-terminal
Type=Application

Then I edited my .local/share/applications/mimeapps.list and added:

[Default Applications]
x-scheme-handler/file=open_multiple.desktop

Then when right clicking on a group of files and selecting "Open With 
Other Application" I selected my "OpenMultiple" entry and up pops a 
zenity dialog box with the names of the files I had selected. You should 
be able to do something similar with nautilus if you like.


The script you write of course will be very different than mine.



--
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/d43364ab-092a-9044-6b8c-fcc35f8b1311%40jhuapl.edu.


Re: [qubes-users] Open several files in THE SAME dispVM

2020-01-17 Thread Steve Coleman

On 2020-01-17 11:40, r.wiesb...@web.de wrote:


Hey,

Is there a way to open a bunch of files in the same dispVM ? Yes, I can
copy/move those files and open them in the dispVM, that is what I do
right now - but it would be nice if there was a simpler way to do so.


You could write a set of scripts for that fairly easily, depending on 
your personal use-case.


Option A
One possibility is to have your local script first start the DispVM 
instance spawning a File Manager, then figure out the new DispVM name, 
and in a loop send all the files to that DispVM instance. Then Use the 
File Manager to open the documents, and when you close the file manager 
the DispVM goes away. If you need to retain the documents use the file 
manager to send them back first.




Option B
1) The first script adds all the files to a single tarfile and then 
calls qvm-open-in-dvm for that one archive file. You can try playing 
with using "Open With Other Application" from your File Manager to kick 
off the script, but that might just call the script multiple times.


2) Then in the DispVM and have the default app for '*.tgz' be your 
script set to extract and open the individual documents with their 
respective applications.


Both the sending and receiving scripts could live in the respective 
templates so that all AppVMs could send multiple files and the DispVM 
could extract and deal with them according to the xdg default 
applications for the document types. If you don't like assigning the 
*.tgz to have a special handler you can always create the tgz file and 
rename it to use a unique extension not assigned to any current application.


Mime/XDG association
https://superuser.com/questions/162092/how-can-i-register-a-custom-protocol-with-xdg



Option C
Create a temporary file system in a file and then use qvm-block to clone 
the files and attach and mount that fs into the DispVM. When finished 
delete/wipe the temporary file.





--
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/191cc953-0469-53c9-efe3-f319280bff49%40jhuapl.edu.


Re:[qubes-users] Xen Orchestra installation on Qubes-OS possible?

2020-01-13 Thread Steve Coleman

On 2020-01-13 09:50, n1ete wrote:

I recently played with xcp-ng in my lab and discovered the "Xen 
Orchestra Unified Appliance". its an xen-ready vm to manage and 
orchestrate xcp-ng backends.


is it possible to deploy the disk image on qubes aswell? this would be 
realy great, since i dont have a free xen-hypervisor in my lab, but qubes.


From reading the docs, I don't think you can do both Qubes and the "Xen 
Orchestra" (XO) simultaneously. Both apparently need to be on the bare 
metal and in control of the hardware. XO requires a webserver running on 
dom0 to control XenServer and Qubes denys any apps with network access 
by design. They are intended for different audiences. Qubes purpose is 
security, XO's is not.


You could however investigate a dual-boot configuration in which you 
choose which system to boot at any point in time, but you would need a 
lot of extra disk space to support that.


For testing purposes you can simply install XO on a USB stick and use 
the BIOS boot menu to boot and play with XO, but I would strongly 
caution you against trying to mix the two. They are intended for two 
very different purposes and their architecture is quite different even 
though they both use Xen under the hood.


The question I would ask is why do you feel you need a webserver to 
control your guest VMs? Perhaps you like the fancy graphing and 
statistics displays? What exactly is your goal, because there may be a 
way to add those specific capabilities while retaining the security of 
the system that Qubes is designed to protect.


Steve

--
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/d7dae92e-1ad2-adc4-1188-45cdbe15dc05%40jhuapl.edu.


Re: [qubes-users] Renesas uPD720202 uPD720201 usb controllers

2020-01-10 Thread Steve Coleman

On 2020-01-09 09:27, David Hobach wrote:



I can confirm the issue for that chipset.

Maybe the firmware loading fails, because it's not shipped with the 
kernel? I don't know...


Ah...

https://www.startpage.com/do/dsearch?query=uPD720202+firmware

-->

https://mjott.de/blog/881-renesas-usb-3-0-controllers-vs-linux/



Thanks for the references! I'll have to check this out this weekend.

So possibly it claims to have the firmware in the EEPROM, but it in fact 
doesn't and requires it from the kernel.


It was my understanding that the setpci statements in my original email 
say there is no EEPROM/BIOS on the card, but then your references say 
that I should have been using the "f6.w" argument for that.


I'll have to try and see this "f6.w" parameter returns (e.g. setpci -s 
00:0[x].0 f6.w ) I'm just learning about this setpci command that I had 
never heard of before this problem forced me to investigate. Your 
referenced blog eventually landed me here:


http://billauer.co.il/blog/2015/11/renesas-rom-setpci/

Some good information on using this setpci command can be found there. I 
guess I'll need to spend some time reading up on this, since I have been 
very interested in how to go about reading and validating EPROMS and 
BIOS lately, but didn't know quite where to start.


Not sure why yours ever worked then. I just got mine, so I can't claim 
that. Maybe I'll try the stuff mentioned in the blog post.


It definitely did work, as I had my system so that whenever I was ready 
to shutdown, I just clicked on a desktop icon and my scripts found all 
non-running AppVM that had not yet been backed up, and it would 
automatically kick off a job to back up those VMs to the sys-usb 
attached device, and then shut itself down. It made it very easy for my 
wife that way. But then after some kernel update it just stopped 
working. I don't know which update killed it, and if I did, I would 
certainly go look to see if there were drivers in that package prior to 
that specific update. In hind sight I should have been much more 
proactive when it first stopped working, but somehow life got in the way.


Now that I have some loader software, that you kindly pointed me to, 
I'll have to look at some of the Live-CD's that previously worked with 
the card in the past, to see if I can steal a copy of the drivers from 
one of them.  I don't remember specifically which ones worked other than 
I do remember that one of the prior versions of the Tor Live-cd's did work.


Many thanks! I now have something to try out and experiment with.

Steve

--
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/ac761e7d-6a8d-2809-4db3-d16af7c9f836%40jhuapl.edu.


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

2020-01-08 Thread Steve Coleman

On 2020-01-08 12:30, Vasiliy wrote:

Are there any security benefits of setting up standalonevm instead of appvm?


1. Thunderbird and other communication tools sometimes can be 
compromised and malicious code can affect all programs installed. I am 
scared that even if I don't use a program in an appvm, it can indirectly 
reduce my security.


If this happens in an HVM you are already toast. If it gets pulled into 
a template while passing the signature test it lies dormant until you 
run that app in the AppVM, and the system volume is non-persistent 
there, so the binary blob that the hack downloads onto your system will 
not stay resident on the system volume. It will likely have to repeat 
the download each time the AppVM is launched, or recognize that its a 
Qubes system and find an alternate way to maintain persistence. That is 
a much higher bar to hurdle than simply installing that binary blob.


2. If an attacker will successfully replace packages while updating the 
template, they will have full access to all my appvms. I know that Tor 
somewhat protects from it, but it can still happen.


It only gains access if it is run, and if run in an AppVM it only has 
temporary access to that one AppVM. While that does not keep it from 
phoning home to the mother ship and sending all your stuff, it still 
will have a hard time becoming persistent. If the sending your stuff 
bothers you then think carefully about locking down the firewall rules 
for each AppVM so long as you know what each AppVM is supposedly for.


Example: I have an AppVM called Email. Its only job is to protect the 
rest of my system from external threats. The networking is set up with a 
default deny firewall and only the authentication and mail servers are 
permitted access. Anything else raises a red flag and my system informs 
me of the problem. If I click on anything malicious like a hacked PDF 
its opened in a one-time-use DispVM. Anything else is blocked from 
downloading its payload.


Steve

--
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/aabbf6e4-f82f-19df-bcaf-0ed3994e9627%40jhuapl.edu.


[qubes-users] Renesas uPD720202 uPD720201 usb controllers

2020-01-07 Thread Steve Coleman
A number of months ago I was happily backing up my system at home using 
my sys-usb with a dedicated USB controller that worked right out of the 
box. I didn't need any drivers or anything special. It just worked.


Then something happened, likely during an update, which could be like 6 
months ago, so I switched back to using dom0 for my updates until I 
could find the time to look into it. It appeared to me that the USB 
controller was simply malfunctioning, so I searched for a new card from 
a different manufacturer which claimed it had native Linux support.


But after installing this new card and booting up qubes, nothing. The 
new card didn't work either. Booting other OS's both cards work just 
fine. But with qubes neither one works, and as luck would have it both 
cards have chip-sets from Renesas (uPD720201 uPD720202).


I know that I have received a couple of qubes-vm kernel updates over 
that time, and I can't say for certain which one broke it, but it 
appears that other people on some other OS's are also having some 
similar issues:


e.g. circa 2018-05-05
https://bugzilla.kernel.org/show_bug.cgi?id=199627

and in 2016 there was a patch to xhci-pci
https://lore.kernel.org/patchwork/patch/686290/

and some more recent indecision and push back:
https://lore.kernel.org/linux-usb/cancmjzdqx6-+nagebbiym+1czs6jfmop9bm5uk4zup_mw5a...@mail.gmail.com/
https://lore.kernel.org/linux-usb/20191106083843.1718437-2-vk...@kernel.org/


So my question to this forum is; Short of buying yet another "new" USB 
card and taking a chance of getting the exact same flunky Renesas 
chipset, what other options are there for resolving this? It seems 
Kernel.org/linux-usb isn't exactly making haste in fixing this issue, 
and reverting back to an older and less secure qubes-vm kernel would be 
a definite mistake given some recent vulnerabilities.


Thoughts? Do I need to trash them and just move on? I do have one that 
is working in my machine here at work, but I'll have to disassemble it 
to find out what brand/model number it is. I hate breaking tamper seals 
if I can avoid it.


Thanks,

Steve


My hardware info:

$ sudo dmesg | grep xhci
[   16.516802] xhci_hcd :00:07.0: xHCI Host Controller
[   16.516893] xhci_hcd :00:07.0: new USB bus registered, assigned
bus number 2
[   26.517096] xhci_hcd :00:07.0: can't setup: -110
[   26.517199] xhci_hcd :00:07.0: USB bus 2 deregistered
[   26.520823] xhci_hcd :00:07.0: init :00:07.0 fail, -110
[   26.520857] xhci_hcd: probe of :00:07.0 failed with error -110
[   26.522239] xhci_hcd :00:08.0: xHCI Host Controller
[   26.522332] xhci_hcd :00:08.0: new USB bus registered, assigned
bus number 2
[   36.522522] xhci_hcd :00:08.0: can't setup: -110
[   36.522567] xhci_hcd :00:08.0: USB bus 2 deregistered
[   36.524235] xhci_hcd :00:08.0: init :00:08.0 fail, -110
[   36.524268] xhci_hcd: probe of :00:08.0 failed with error -110

$ lspci
...
00:07.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0
Host Controller (rev 02)
00:08.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0
Host Controller (rev 03)

Both controllers are using similar chipsets...


> setpci -v -s 00:07.0 f0.l
:00:07.0 @f0 = 
> setpci -v -s 00:07.0 ec.l
:00:07.0 @ec = 

> setpci -v -s 00:08.0 ec.l
:00:08.0 @ec = 
> setpci -v -s 00:08.0 f0.l
:00:08.0 @f0 = 

Hmmm, no bios I can flash...


> sudo lspci -vvv
00:07.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0
Host Controller (rev 02) (prog-if 30 [XHCI])
Physical Slot: 7
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR- Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)

Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [70] MSI: Enable- Count=1/1 Maskable- 64bit+
Address:   Data: 
Capabilities: [a0] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 
unlimited, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- 
SlotPowerLimit 0.000W

DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- 
AuxPwr+ TransPend-
LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, 
Exit Latency

L0s <4us, L1 unlimited
ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s (downgraded), 

Re: [qubes-users] deb or rpm for download and installation?

2020-01-07 Thread Steve Coleman

On 2020-01-07 16:43, M wrote:

Then, how to install for example Libreoffice ?



Assuming this is fedora rpm based Template/VM:

Start the software template VM that your AppVM is based on, and then at 
the command prompt type:


> sudo dnf install libreoffice

...answer "y" at the prompt to continue and when done shutdown the 
template.


When the template is stopped you can then open the Qube Manager 
properties 'applications tab' on your AppVM, and add the libreoffice 
menu entries to that AppVM.


For updating your template software:

> sudo dnf update

...and again enter 'y' at the prompt, and when done shutdown the template.

In general if you need to update you will see a widget on the taskbar 
and you can launch an updater from there and it will automate the update 
process for you. I choose to do it from the command line so I can see 
what it is doing, because it something happens I generally have a better 
clue what needs to be fixed.


Steve



--
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/be19f190-4e5e-909f-8a2e-4c8229bca4d1%40jhuapl.edu.


Re: [qubes-users] Troubleshooting Qubes graphical slowness

2019-12-30 Thread Steve Coleman

On 2019-12-30 11:28, Steve Coleman wrote:

On 2019-12-29 23:32, tetrahedra via qubes-users wrote:

On Sun, Dec 29, 2019 at 01:44:28PM +, 'awokd' via qubes-users wrote:

tetrahedra via qubes-users:
On Fri, Dec 27, 2019 at 09:57:16AM +0100, tetrahedra via qubes-users 
wrote:
Unfortunately I need to get work done so have to reboot to "just 
make it
go away" but I am still interested in troubleshooting ideas (for 
when it

happens next).


Investigate xl top more thoroughly. You can identify offending VMs with
it, and see if all your RAM is in use which triggers swapping to (slow)
disk.


My disk is a pretty fast SSD, and I did use xentop (`xl top` is just an
alias for xentop) and it didn't show anything unusual as far as I can
recall. Perusing the xentop man page doesn't show any potentially
relevant options except for `--full-name` and that option doesn't seem
to do anything. Pressing "B" (for "vBds") seems to list a number of
devices for each VM but none of them have any 2-digit unique identifying
number (as `iotop` seems to display).



I have had graphics slowdown issues in the past on two occasions that 
acted like this, so here are some things to try:


1) Add the 'nopat' argument to the 'kernel opts:' boot command line.

 > qvm-prefs  -s kernelopts nopat

2) The second, I can not seem to locate that email exchange at the 
moment, but it was a option on the graphics subsystem that needed to be 
turned off. Something like backing store, but I'm sure that is not the 
correct name for it. I'll keep looking for that one until I hear back if 
#1 above fixed your problem or not.


Ok, I still could not find that email exchange, but the second thing to 
try is in the XFCE "Window Manager Tweaks" Compositor tab, and try to 
disable the "Enable display compositing" entry.


Let us know if either if these works for you. Both worked for me for 
their respective graphics performance issue.


Steve

--
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/83a5e759-1ba7-999d-adb9-ccdfe1453cad%40jhuapl.edu.


Re: [qubes-users] Troubleshooting Qubes graphical slowness

2019-12-30 Thread Steve Coleman

On 2019-12-29 23:32, tetrahedra via qubes-users wrote:

On Sun, Dec 29, 2019 at 01:44:28PM +, 'awokd' via qubes-users wrote:

tetrahedra via qubes-users:
On Fri, Dec 27, 2019 at 09:57:16AM +0100, tetrahedra via qubes-users 
wrote:
Unfortunately I need to get work done so have to reboot to "just 
make it
go away" but I am still interested in troubleshooting ideas (for 
when it

happens next).


Investigate xl top more thoroughly. You can identify offending VMs with
it, and see if all your RAM is in use which triggers swapping to (slow)
disk.


My disk is a pretty fast SSD, and I did use xentop (`xl top` is just an
alias for xentop) and it didn't show anything unusual as far as I can
recall. Perusing the xentop man page doesn't show any potentially
relevant options except for `--full-name` and that option doesn't seem
to do anything. Pressing "B" (for "vBds") seems to list a number of
devices for each VM but none of them have any 2-digit unique identifying
number (as `iotop` seems to display).



I have had graphics slowdown issues in the past on two occasions that 
acted like this, so here are some things to try:


1) Add the 'nopat' argument to the 'kernel opts:' boot command line.

> qvm-prefs  -s kernelopts nopat

2) The second, I can not seem to locate that email exchange at the 
moment, but it was a option on the graphics subsystem that needed to be 
turned off. Something like backing store, but I'm sure that is not the 
correct name for it. I'll keep looking for that one until I hear back if 
#1 above fixed your problem or not.


Steve


--
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/61f368b2-9623-4177-99d2-7aa395c45fab%40jhuapl.edu.


Re: [qubes-users] AppVMs start but zero of the apps are starting? (with logs)

2019-12-19 Thread Steve Coleman

On 2019-12-18 18:47, Stumpy wrote:

On 2019-12-19 01:16, Stumpy wrote:

On 2019-12-18 19:08, Steve Coleman wrote:

On 2019-12-18 07:57, Stumpy wrote:
Last night I noticed that I was not able to start an appvm via dom0 
(qvm-run appvm programname) so then tried to start another app in 
another appvm, nothing.
I had a bunch of things open still from earlier in the afternoon so 
figured I needed to reboot, did, and still nothing, except I dont 
have any previous apps open up so my system is barely usable.


When i try to run an app, say from the xfce menu (or directly from 
the dom0 terminal) I get the little pop up that the VM is starting, 
and it shows up in zentop and the qubes manager, but no app. I tried 
to start apps from the right click "run" option in the qubes manager 
but nothing, doesnt matter if the appvm is already running or not.


The only thing i have done in dom0 in terms of "messing around" was 
to modify the sudo vi /etc/qubes/quid.conf so that one of my appvms 
would open w/o a border (which I since undid in attempts to get 
things working) i cant think of anything else i have done in dom0?


This is killing me as I am not working on my work/win comp :( so any 
help would really really really be appreciated. Please let me know 
if there are any logs or something i should be posting?




This sounds very similar to a problem I have been having (at home and
at work), only your issue sounds like a much worse case of it.

Ref: Qubes 4.0.1, Fedora-30 template

When I come into work in the morning, or upon booting my workstation
at home, if I launch an app in a non-running VM (sometimes subsequent
re-launches of a VM) the app I used to initiate that VM does not come
up. The pop-up message of the starting VM appears, then nothing. The
VM gets started and the disk is whirring away, but the app never
appears. If I launch the same app again sometimes both instances of
that app appear one right after they other. Between those two
invocations I might even wait until all the disk activity settles down
and everything works fine.

If for instance I use Qubes Manager to "update qube" the window almost
never comes up the first time. The second time it will. If I start the
template first and then select "update qube" it almost always comes up
correctly, unless something is chewing up all the CPU or hitting the
disk pretty hard.

My issue seems to be related to too much activity of the AppVM's
services creating enough lag to the system that the qrexec either
times out or gets slowed down to the point of not completing the
launching of the app. This is frustrating because after the first
launch it seems to work better, so testing of why it isn't starting
clearly needs to be planned in advance. Perhaps some resources get
cached in memory the firt time so it starts that VM quicker, and thus
the qrexec doesn't time out?

I would suggest turning on the "Run in debug mode" option in the Qubes
Manager's AppVM configuration so you can collect better logging
information and see if that tells you anything. That is what I am
planning to do tomorrow morning before launching anything. I had just
turned it on for one VM this morning that sometimes acts up, and
wouldn't you know it, it has not repeated that problem launching that
VM the second time. Maybe tomorrow, or if I leave the machine alone
for a while I might get it to repeat again. I think I will make a
habit of turning on the debugging before launching any new VM's just
in case I can catch it in the act of not acting properly.


Thanks for pointing out where to turn the logging on.
Questions though, I was attempting to look through the three logs of
two different appvms but was not really sure where to start (was just
shy of 6k lines).
1) Would posting the output to like a pastebin be useful/appropriate?
2) How sensitive is the info in the logs? (In looking through them it
didnt seem like I was giving much info away but at the same time I am
barely able to make sense of most of it).

Thanks for the help, I of course want to get this figured out... I
love my qubes box, all my friends live inside it :P


Well as I have not been able to find (understand) anything wrote I 
thought I'd cross my fingers and post logs from two different appvms 
(debian and fedora). It occured to me though that if this is happening 
with all appvms, which it is, then perhaps its an issue with dom0 but 
anyway, am posting just in case. If there are dom0 logs that would be of 
use then please let me know.


https://pastebin.com/LAXPSyBc


What I see in the log that looks suspicious is:

   domain dead
   Failed to connect to gui-agent

if it connected you would have seen something like:

[   18.849522] audit: type=1130 audit(1576676114.676:22): pid=1 uid=0 
auid=4294967295 ses=4294967295 msg='unit=qubes-gui-agent comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'


And that &

Re: [qubes-users] AppVMs start but zero of the apps are starting?

2019-12-18 Thread Steve Coleman

On 2019-12-18 07:57, Stumpy wrote:
Last night I noticed that I was not able to start an appvm via dom0 
(qvm-run appvm programname) so then tried to start another app in 
another appvm, nothing.
I had a bunch of things open still from earlier in the afternoon so 
figured I needed to reboot, did, and still nothing, except I dont have 
any previous apps open up so my system is barely usable.


When i try to run an app, say from the xfce menu (or directly from the 
dom0 terminal) I get the little pop up that the VM is starting, and it 
shows up in zentop and the qubes manager, but no app. I tried to start 
apps from the right click "run" option in the qubes manager but nothing, 
doesnt matter if the appvm is already running or not.


The only thing i have done in dom0 in terms of "messing around" was to 
modify the sudo vi /etc/qubes/quid.conf so that one of my appvms would 
open w/o a border (which I since undid in attempts to get things 
working) i cant think of anything else i have done in dom0?


This is killing me as I am not working on my work/win comp :( so any 
help would really really really be appreciated. Please let me know if 
there are any logs or something i should be posting?




This sounds very similar to a problem I have been having (at home and at 
work), only your issue sounds like a much worse case of it.


Ref: Qubes 4.0.1, Fedora-30 template

When I come into work in the morning, or upon booting my workstation at 
home, if I launch an app in a non-running VM (sometimes subsequent 
re-launches of a VM) the app I used to initiate that VM does not come 
up. The pop-up message of the starting VM appears, then nothing. The VM 
gets started and the disk is whirring away, but the app never appears. 
If I launch the same app again sometimes both instances of that app 
appear one right after they other. Between those two invocations I might 
even wait until all the disk activity settles down and everything works 
fine.


If for instance I use Qubes Manager to "update qube" the window almost 
never comes up the first time. The second time it will. If I start the 
template first and then select "update qube" it almost always comes up 
correctly, unless something is chewing up all the CPU or hitting the 
disk pretty hard.


My issue seems to be related to too much activity of the AppVM's 
services creating enough lag to the system that the qrexec either times 
out or gets slowed down to the point of not completing the launching of 
the app. This is frustrating because after the first launch it seems to 
work better, so testing of why it isn't starting clearly needs to be 
planned in advance. Perhaps some resources get cached in memory the firt 
time so it starts that VM quicker, and thus the qrexec doesn't time out?


I would suggest turning on the "Run in debug mode" option in the Qubes 
Manager's AppVM configuration so you can collect better logging 
information and see if that tells you anything. That is what I am 
planning to do tomorrow morning before launching anything. I had just 
turned it on for one VM this morning that sometimes acts up, and 
wouldn't you know it, it has not repeated that problem launching that VM 
the second time. Maybe tomorrow, or if I leave the machine alone for a 
while I might get it to repeat again. I think I will make a habit of 
turning on the debugging before launching any new VM's just in case I 
can catch it in the act of not acting properly.







--
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/4448b0a1-e5d6-ebf1-c5da-acab964c12fb%40jhuapl.edu.


Re: [qubes-users] unsupported hardware detected with the installation of qubes 4.0.1, and 4.0.2-rc2

2019-12-10 Thread Steve Coleman

On 2019-12-10 10:26, rickey wrote:

Good morning Everyone,
I have installed previously Qubes 3.2.1 on a Dell small form factor 
desktop pc, and lenovo x120e, and I was able to use them.
When I tried to install the Qubes versions mentioned above on the same 
hardware, it is showing the message into the attached screenshot. If I 
proceed despite it, I cannot finish the installation of the thinkpad, 
and Dell's doesn't allow Tor to start.


You have two separate problems here apparently, and not really enough 
detail for us to go by to help much.


- For the Lenovo x120e I would start by checking your BIOS version to 
see if you are up to date. You can find that information here:


https://pcsupport.lenovo.com/si/en/products/laptops-and-netbooks/thinkpad-x-series-laptops/thinkpad-x120e/downloads/driver-list/component?name=BIOS%2FUEFI

If you are not up to date then download the bootable CD version, reflash 
your bios to the latest and try again. You also may have to play with 
the UEFI settings to be able to continue the installation, if its 
rebooting that isn't working. You have not told us what error you are 
getting or where in the install process it stops working. There are no 
x120e's in the HCL list yet but somebody might have some experience with 
something similar.



- For the Dell, we don't even know what system model you have yet. Are 
you talking about the whonix system for Tor? Have the whonix service 
VM's been started?  What VM logs are available? We need more information 
in order to be able to help.


Note: Since you have two separate system problems I would suggest 
splitting this email thread into two separate threads so the people 
familiar with each kind of system can focus better on that particular 
issue. We will try to help if we can.





--
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/4add3ef3-3249-4206-8f0e-8bc292071314%40googlegroups.com 
.


--
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/e6f1682d-55a3-fd73-69a6-f14f1db3091a%40jhuapl.edu.


Re: [qubes-users] Shutting down a VM when applications close

2019-11-27 Thread Steve Coleman

On 2019-11-27 07:52, tetrahedra via qubes-users wrote:

DispVMs shut down automatically when the launched application closes.

Is it possible to enable this for certain applications in certain AppVMs
as well?

For example I may not want my "resource-heavy-apps-vm" to keep running
after MemoryHungryApp closes, because that ties up half my system RAM.

How would I configure "resource-heavy-apps-vm" to shutdown automatically
when MemoryHungryApp closes?



You can try this trick when starting your app/vm:

dom0> qvm-run -a AppVM "resource-heavy-app;shutdown -h now"

When the application closes the next command in line is the shutdown 
command, and the VM will simply exit. As long as the app does not 
background itself by forking a new process to demonize this will likely 
work.


If in testing that command works for you, then you can create a 
specialized AppVM.desktop file, and set the Exec= entry to 
"resource-heavy-app;shutdown -h now". Once that is done then add that 
custom desktop file to your template VM in /usr/share/applications and 
you should then be able to add the application directly to your qubes 
menu for that specific VM.






--
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/d13279eb-29d0-83d9-21d3-512bcdbe0e55%40jhuapl.edu.


Re: [qubes-users] Lenovo Precision 7540 available without vPro OR with Intel ME Disabled

2019-11-26 Thread Steve Coleman

On 2019-11-26 16:05, Lambda wrote:
Lenovo's 2019 laptop is currently on sale and their CPU selection[1] 
includes:

- i7-9750H: no vPro, No Out-of-Band Systems Management
- i7-9850H: vPro, Intel ME Disabled
Strangely enough in Europe[2] they list it as:
- i7-9750H: no vPro, No Out-of-Band Systems Management (so no option to 
fully disable ME)

- i7-9850H: vPro, No Out-of-Band Systems Management
I don't know if it's a website bug or if they simply don't disable ME in 
the EU!


It's not clear what the implication of each option is.
For example vPro is an umbrella term for ME, SGX, TXT, Boot Guard, VT-x, 
VT-d.
So by choosing a CPU without vPro would that mean it would be impossible 
to use virtualization? Doubtful I would guess.


If I choose the non-vPro CPU without ME, SGX, TXT, Boot Guard; what 
exactly do I lose?
I'm aware that for AEM support I would need to have ME and TXT 1.2. But 
those CPUs have TPM 2.x
And it seems SGX is also a security hazard. Not sure if problems have 
been fixed with the latest CPUs.
It looks the only advantage of the the i7-9850H is that it has software 
and hardware patches for most of the security vulnerabilities [3]. While 
the i7-9750H does not


This link might make it 'a little' clearer about the difference:

https://www.intel.com/content/www/us/en/products/compare-products.html/processors?productIds=191045,191047

Look at the "Advanced Technologies" and "Security & Reliability" drop downs.

They both have VT-x, VT-d, EPT, OS Guard, and SGX/ME

The i7-9850H adds on the vPro, TSX-NI, Trusted Execution, and SIPP, none 
of which you need as far as I can tell.



Am I wrong in my analysis? Which CPU would you recommend?
Would that recommendation change if I was running Linux instead?

Thank you.

[1] 
https://www.dell.com/en-us/work/shop/cty/pdp/spd/precision-15-7540-laptop/xctop754015us
[2] 
https://www.dell.com/en-uk/work/shop/workstations/precision-7540-build-your-own/spd/precision-15-7540-laptop/xctop7540emea
[3] 
https://www.intel.com/content/www/us/en/architecture-and-technology/engineering-new-protections-into-hardware.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/2973fa8f-f761-4520-b969-3dbbbd40a948%40googlegroups.com 
.


--
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/7b09fce6-59e9-dd6c-6260-8ca987b4ff27%40jhuapl.edu.


Re: [qubes-users] Days since last backup

2019-11-22 Thread Steve Coleman
On 2019-11-22 04:41, Bernhard wrote:
> However, I am stuck on how to determine how many days it has actually
 been since the last backup.
>>>
>>> What you are looking for is this command:
>>>
>>> qvm-prefs --get $vm backup_timestamp
> 
> Nice. In case of a "manual backup", can you also set the variable that
> way? Like
> 
> qvm-prefs --set $vm backup_timestamp  2019.11.22-00:00:00
> 
> (or some other time format) ?
> 

I believe it requires the Unix timestamp as a long int, but represented
as a string, so you would need to first convert your string to the Unix
long int representation.

The example command below is untested, but this should work to set the
backup_timestamp to the time value of some archive file taken from some
other non-qubes backup solution.

$ backup_timestamp=`date --reference=/path/to/my_backup.tgz +%s`
$ qvm-prefs --set $vm backup_timestamp $backup_timestamp

Or like you asked, you can just use the date command to convert any
standard time format string to the required unix timestamp value. If you
are using the qvm-backuprestore command like I am, then this is always
done for you for free, and you need not worry about managing the backup
timestamps yourself.

As a part of my backup script I also need to deal with freeing up enough
removable disk space for the pending backup session. My backup target
disk is managed as a set of folders, one per VM, and based on the
predicted backup size I roll though all the VM folders, sort that vm's
backup directory based on time, and remove only however many old backup
archive files from each directory that I need in order to free up that
required amount of space. This way I am guaranteed to have at least N
backups of each VM and only the older archives are removed as newer ones
are created.

Its a great feature that Qubes keeps tabs on the previous backup
timestamps in its VM database. That makes the complexity of custom
backups easy to manage using very simple bash/python scripting.

Steve

-- 
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/c426f037-095d-c90f-6fec-4dfb14c90fbc%40jhuapl.edu.


Re: [qubes-users] Days since last backup

2019-11-21 Thread Steve Coleman
On 2019-11-20 22:12, tetrahedra via qubes-users wrote:
> The built-in Qubes backup functionality is great but it's very easy to
> forget to run a backup and end up going days (or weeks, or months...)
> without it.
> 

> However, I am stuck on how to determine how many days it has actually
> been since the last backup.

What you are looking for is this command:

qvm-prefs --get $vm backup_timestamp

I have a script that when it runs, it queries all VM's that have not
been backed up since the last time they were run, and if they are not
currently running, it kicks off backup to sys-usb to back it up, each to
its own file. If I were to put this script in cron all I would have to
do is shut down a VM and it would automatically be backed up, though
that would likley cause problems if I restarted one that was gettign
backed up, so I don't generally leave it running in the background. So,
 at the end of my work day I just shutdown what VM's I can and kick off
my script and my work for that day is always archived on a local LUKS
volume.

This works pretty well for me on a the local drive, but then I still
need to deal with issues with getting the "corporate backup software" to
spool those huge files off to the server farm at night in order to
fulfill my required retention policy.

> Potential options:
> 1) Assume all backups are done by a shell script, and that shell script
> somehow saves the date to disk. How do we do this in an easy-to-parse
> way?
> 
> 2) Assume backups may happen by command line or GUI (assume we don't
> know). Where can we find the date of the last backup on disk, and parse
> it into an integer value that can be checked by a notification script?
> 

-- 
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/488a70ad-c676-0873-b1b9-0890c2cf36ea%40jhuapl.edu.


Re: [qubes-users] QSB #053: TSX Asynchronous Abort speculative side channel (XSA-305)

2019-11-15 Thread Steve Coleman

On 2019-11-15 05:28, Chris Laprise wrote:

On 11/15/19 3:01 AM, Andrew David Wong wrote:



On 2019-11-14 8:50 AM, Chris Laprise wrote:

One of the packages came down with an incorrect signature:

*** ERROR while receiving updates: Error while verifing
kernel-4.19.82-1.pvops.qubes.x86_64.rpm signature:
/var/lib/qubes/updates/rpm/kernel-4.19.82-1.pvops.qubes.x86_64.rpm:
rsa sha1 (MD5) PGP MD5 NOT OK



I was not able to reproduce this when updating over clearnet. Have you
tried restarting your UpdateVM and trying again?


Thanks. It worked after I did an 'action=clear all'.


Not sure if it is the exact same issue as here, but I had a similar 
problem on my home Qubes4 system just last night.


My GPG issue has to do with the sys-firewall / system disk volume 
filling up during the download phase, thus the GPG check on the kernel 
package was failing. This is likely just a coincidence only because the 
kernel package is a fairly large one, and more likely to run out of 
space when downloading it.


I have since bumped up both the sys-firewall private and system storage 
size,cleared the cached packages using the dom0 --action="clear all", 
used sys-firewall local dnf "clear all",  restarted networking vm's, 
even restarted the physical machine,  and yet all that still did not 
resolve my update issues. My sys-firewall VM / is still around 98% full, 
with not enough room for completing any of my required updates.


I'll be looking into this later tonight to see if I can't figure out 
what is filling that volume and why that / volume does not seem to be 
expanding properly. I have not added anything to that sys-firewall 
volume myself so I have no clue why it suddenly filled up to that point 
and thus broke _all_ my 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/6a2d714f-9733-71f2-b8ec-13c430005989%40jhuapl.edu.


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

2019-11-05 Thread Steve Coleman

On 2019-11-04 22:12, Andrew David Wong wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2019-11-04 6:05 AM, Anac wrote:

Hi all,

Is it just me or does the iso really not fit onto a regular DVD? I
tried several burn programs - same result. The 4.8 GB iso doesn't
fit onto a 4.7 GB DVD. Is a double-layer DVD required or is it
possible to delete some seldomly needed parts from the iso? Or did
I catch a [three-digits-agency]-in-the-middle version?

Cheers, Anac



Please see the discussion on this issue:

https://github.com/QubesOS/qubes-issues/issues/5367

Basically, making this release small enough to fit on a DVD would have
required too many other sacrifices. In the end, we decided that this
was the least bad option.


I would like to make a suggestion here.

If you know at the time of a release that the ISO will not fit on a 
regular DVD then it would make sense to mention that up front, and then 
use a link to point the potential user directly at the instructions for 
using/creating a bootable USB thumb drive.


The installation instructions do mention this USB option, but that 
"option" should be front and center at the top, as it is probably the 
best/only option for those without a dual-layer DVD drive installed in 
their machine. The DVD installation instructions should also say "dual 
layer DVD" just to be clear about this known size problem.



- -- 
Andrew David Wong (Axon)

Community Manager, Qubes OS
https://www.qubes-os.org

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAl3A6IsACgkQ203TvDlQ
MDCrAhAAzYKrlBFPTNl04ddecyeBfxQqQ+8q5MAZfJkLVq6CyS8zSz8ObrcVgbju
sbuGCGPJCBQ7bCVNt8kHSgLxKcK9CXS0p/kGvfDKnyyU1dafFl008GDlNG6sRI0G
7iqLdUK5gl9tccg9L3M/oNgN31YvnYqdRKxFsV9kgcnemt1DvB/6w8+ygex0d4Id
CaqpITbUXJfza78Nm8I4dORhvzkMEojyvSUduAx0a1Hx1RDhAfIy416aRn622kAa
/Pk3q1vJAcJn8jmaqoqJV/OnBnqLbSAK/5vWk3SElACRsZBTEAwrCQFNtLrPZQw3
tLKrBd8AZQCURkWLE6zrKzZLdtilXszmcu4mrCDy9UbdU7P9ZJy83cPXDgIiFQQV
5Mj3x6EpsL0kOCqEk8aKvTS6OlzSZzQJQGKaOvut8SoFoPj7nYYP2cC0ysmm+e83
CXVLzZ4ecyZuxklVmGg25nEFjRJDUwaRu5MdCU+O1mGCBg4I2Wmrp+0Z3ncclHZu
rYQMsvDquVhUQktfO1c9YktIQcITMeptKj8VUEjOFzI5EblWhoKZGh3SnfnDIA66
tTO1gcUOHRvBBR3fMBirxXOs3qArPjl7NGyZLddbqNJmYnhClEPE1Fg6ZoJ3WvIz
U9lnalfIqm/23jzeFnwejmDgQ1jxQa14BIYcSlgXUSG6YLTPdzI=
=HvSt
-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/a9795fb7-2815-df5a-8af8-6857e81253b0%40jhuapl.edu.


Re: [qubes-users] Dell Optiplex 7060 Mini - Qubes 4.0.2-rc1

2019-10-23 Thread Steve Coleman

On 2019-10-22 16:58, Peter wrote:
I've installed qubes on a dell desktop that has no PS2 support, and only 
one USB controller.  So it uses a USB keyboard & mouse.  During 
installation I saw no prompt for creating a sys-usb, which I understand 
is the default when you boot with a USB keyboard.


Here is the output of qvm-pci

dom0:00_00.0  Host bridge: Intel Corporation
dom0:00_02.0  VGA compatible controller: Intel Corporation
dom0:00_08.0  System peripheral: Intel Corporation Xeon E3-1200 v5/v6 / 
E3-1500 v5 / 6th/7th Gen Core Processor Gaussian Mixture Model

dom0:00_12.0  Signal processing controller: Intel Corporation
dom0:00_14.0  USB controller: Intel Corporation
dom0:00_14.2  RAM memory: Intel Corporation
dom0:00_14.3  Network controller: Intel Corporation     sys-net 
(no-strict-reset=True)

dom0:00_15.0  Unknown: Intel Corporation
dom0:00_16.0  Communication controller: Intel Corporation
dom0:00_16.3  Serial controller: Intel Corporation
dom0:00_17.0  SATA controller: Intel Corporation
dom0:00_1d.0  PCI bridge: Intel Corporation
dom0:00_1f.0  ISA bridge: Intel Corporation
dom0:00_1f.3  Audio device: Intel Corporation
dom0:00_1f.4  SMBus: Intel Corporation
dom0:00_1f.5  Unknown: Intel Corporation
dom0:00_1f.6  Ethernet controller: Intel Corporation Ethernet Connection 
(7) I219-LM        sys-net (no-strict-reset=True)


I've ready through the USB related documentation, but I'd like to 
understand my usb options better.


I believe if I try to create a sys-usb for this PC I'll loose my 
connection to keyboard and mouse in dom0 in that case.  Is that correct?


If so, is my only option then to either:

use USB insecurely
don't use USB at all except for the keyboard & mouse attached to dom0


Or you can install another USB card and dedicate it to sys-usb.


Thanks,

Peter


--
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/2df20042-5a18-42c9-9895-d3071c12c1b2%40googlegroups.com 
.


--
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/d668481e-4a34-711e-f255-aff0171e1360%40jhuapl.edu.


Re: [qubes-users] Anyone tried Anbox ('Android in a box') under Qubes

2019-10-16 Thread Steve Coleman

On 2019-10-16 11:57, Jin-oh Kang wrote:

Sorry I might be out of touch, but can't you just install Android directly on 
your HVM without a container? Anbox is meant to run Android *without* a 
hypervisor like Xen which is the whole point of using Qubes.  Anbox does allow 
you to run Android under PV/PVH but that sounds just as absurd.  Plus if the 
Android system you're trying to emulate is ARM-based there's no advantage over 
running a plain Android emulator on QEMU.


There is an issue, at least with the Andoroid-x86 distribution when used 
under Xen, in that the Android installer can't even see the Qubes disk 
space as to partition and install the android system. This is due to the 
specific Xen driver support not being recognized by the Android 
installer, so the fix required is not within Qubes. Likewise qemu isn't 
going to work to resolve a missing system disk. As I see it, one can can 
either recompile Xen to provide a different disk type, or recompile the 
Android-x86/installer to recognize a new disk type. The funny thing is 
they used to work together before Xen changed how they did this 
particular driver. I actually had one running under Qubes 3.0 but lost 
it around the R3.1 time frame.


Anbox looks like it might be worth a shot if someone really wants to 
work with android apps, and having a disassembler/debugger within the 
same AppVM would be possible as well. At one point I was wanting to do 
some security analysis of a few specific android apps in my free time, 
but figuring out how to get Android to install again took too way too 
much of my time, and it just was not worth it.


At least with Anbox you are starting from a bootable system and simply 
adding executables to it, so that is a much more reasonable approach 
rather than perhaps recompiling Xen and causing all kinds of potential 
issues with Qubes general security model. Since the Qube that Anbox runs 
in is confined to just that AppVM its still isolated from the rest of 
the Qubes system and doesn't break that security model. I may just dust 
off that old project and take another stab at it using Anbox when I find 
some 'extra' time on my hands.





--
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/95e97e1b-6035-7157-6273-860d4aec103e%40jhuapl.edu.


Re: [qubes-users] Does installing things with sudo affect my template and therefore all VMs that use this template?

2019-10-11 Thread Steve Coleman

On 2019-10-11 14:16, Guerlan wrote:
The root folder is shared, only the /home is unique for each VM. Does 
that mean that is I instal anything with sudo in one VM, it will affect 
the template and therefore all other VMs?


When you install software in /usr or /opt in the template VM it will be 
visible in all the user VM's that use that template. The settings to 
automatically launch daemon processes may need to be enabled for each 
AppVM depending on both yours and the particular software package 
requirements. You may not necessarily need a cron job or a daemon to run 
in every AppVM instance, for example.


If you instead install software in the AppVM's /home/user/* or 
/usr/local/* (basically any directory automatically remapped from the 
private volume /rw/* ), then the software will be available only within 
that single AppVM.


Where it makes sense to install a particular third-party software 
package depends highly on what that specific software needs in order to 
function properly. If the software is installed locally in /usr/local 
but then still wants its configuration files to be in /etc, or needs 
cron, then you may need to work around that specific problem with either 
copying the configuration file separately into the template VM /etc, or 
else using some magic scripting during the AppVM startup to copy the 
config file into the right location before the software that needs it is 
actually started. There is usually a workaround that will get the job 
done, but you may need to learn a bit more about how each software 
package works than you normally would on some other less secure system.


--
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/d50d6db0-f759-1631-14a5-8daa9f5d4555%40jhuapl.edu.


[qubes-users] fyi - System76 Will Ship 2 Linux Laptops w Coreboot

2019-10-10 Thread Steve Coleman
No need to even install your own coreboot, and risk bricking your brand 
new system.


1) Galago Pro is apparently already on the Qubes HCL

2) Darter Pro - not yet on the HCL
   Currently on preorder, so I doubt anyone has tried this one with
   Qubes yet (32 GB DDR4, Intel UHD Graphics, i7-10510U)


https://www.forbes.com/sites/jasonevangelho/2019/10/10/system76-will-begin-shipping-2-linux-laptops-with-coreboot-based-open-source-firmware/

Just wish they had docking station options. Unfortunately the 'Thelio 
Massive' desktop systems still have no coreboot 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/69b92830-ee22-c3c7-e55c-1b65f6a01202%40jhuapl.edu.


Re: [qubes-users] Easiest way to redirect USB to a VM?

2019-10-08 Thread Steve Coleman

On 2019-10-08 17:35, Guerlan wrote:
On Ubuntu it always worked out of th ebox,I only had to choose the rigth 
USB option in Android.


How can I install things in dom0? Is it posible?


To search what is available:

   dom0$ sudo qubes-dom0-update --action=search 

then:

   dom0$ sudo qubes-dom0-update 

Be careful not to install any dangerous software that you don't actually 
need in dom0. Its best to leave that to the VM's that will be mounting 
the phone USB.



I tried all USB modes on 2 phones and I get nothing on both qvm-usb and 
qvm-block


I also plugged an Yubikey and it appears in lsusb (the phones appear 
too) but they don't appear in the devices tray icon.


On Tuesday, October 8, 2019 at 6:14:39 PM UTC-3, steve.coleman wrote:

On 2019-10-08 16:44, Guerlan wrote:
 > I tried that too, but when I run qvm-usb I get an empty list of usb
 > devices. Running lsusb obviously gives me a lot of usb devices (on
 > dom0). So I thought sys-usb is needed for USB to work. What am I
doing
 > wrong?

I think the trick is to:

1) Make sure your Android device presents itself as a USB drive, so
that
you can copy/move files between the device and the VM.

Q: Have you used the phone with any other Linux/Windows machine such
that you know it is configured to present the USB drive interface? I'm
pretty sure you need to configure that on the phone first.

2) Then Dom0 needs to have the proper tools/drivers to see that USB
device as a drive, so that it can be passed/attached via the command
line tools or the toolbar applet. I know that fedora-25 has a
"android-tools" package that might be needed for this.

Once you can see it in dom0 using qvm-usb/qvm-block you should be able
to pass it through to your VM with the toolbar applet or qvm-block
attach.

Its been a long while since I have done this, and I have not yet
done it
with either Qubes4.x nor my current Android phone, so your mileage may
vary greatly.




--
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/cbbed5fa-400a-44e6-8efc-832a5157af76%40googlegroups.com 
.


--
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/60760709-8647-d9ad-f818-4701e54a9dce%40jhuapl.edu.


Re: [qubes-users] Easiest way to redirect USB to a VM?

2019-10-08 Thread Steve Coleman

On 2019-10-08 16:44, Guerlan wrote:
I tried that too, but when I run qvm-usb I get an empty list of usb 
devices. Running lsusb obviously gives me a lot of usb devices (on 
dom0). So I thought sys-usb is needed for USB to work. What am I doing 
wrong?


I think the trick is to:

1) Make sure your Android device presents itself as a USB drive, so that 
you can copy/move files between the device and the VM.


Q: Have you used the phone with any other Linux/Windows machine such 
that you know it is configured to present the USB drive interface? I'm 
pretty sure you need to configure that on the phone first.


2) Then Dom0 needs to have the proper tools/drivers to see that USB 
device as a drive, so that it can be passed/attached via the command 
line tools or the toolbar applet. I know that fedora-25 has a 
"android-tools" package that might be needed for this.


Once you can see it in dom0 using qvm-usb/qvm-block you should be able 
to pass it through to your VM with the toolbar applet or qvm-block attach.


Its been a long while since I have done this, and I have not yet done it 
with either Qubes4.x nor my current Android phone, so your mileage may 
vary greatly.





--
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/edf300dc-d189-62d7-0cb5-78586ec10e09%40jhuapl.edu.


Re: [qubes-users] Making a DispVM permanent

2019-09-23 Thread Steve Coleman

On 2019-09-21 07:27, tetrahedra via qubes-users wrote:

Is there a way to turn currently-running DispVM instance into a regular 
permanent AppVM, which I can delete later?




I'm not sure it this helps or not, but you could try pausing the dispvm 
and restart it when you need it. I don't know what happens if the 
machine reboots in the mean time, but that paused vm should stop using 
memory and cpu thus allowing you to use those resources elsewhere.


For a more long term storage you might look at the new backup software 
that is in development (Sparsebak). The current qubes backup will only 
save the starting state of a running dispvm, but the new backup system 
might possibly store the current state. You could try to pause the 
dispvm, make a hot backup with sparsebak, and then if you loose your 
dispvm due to an inadvertent shutdown, then try restoring the prior 
state from that backup.


Another possibility, pause the dispvm then clone it. I was successful at 
restarting the clone by running gnome-terminal from the Qubes Manager, 
but when I exited the terminal app the clone shutdown and disappeared 
like a normal dispvm.  You could also pause the clone rather than 
shutting it down, and simply try playing the shell game by cloning as a 
checkpoint, and only start the clone if you loose the original dispvm 
due to power failure, etc.


Perhaps there is a qubes property that could change that dispvm 
auto-remove behavior?


--
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/2e6d2f6e-67a8-78c2-5c66-ceeb776eaa91%40jhuapl.edu.


Re: [qubes-users] sys-net

2019-09-18 Thread Steve Coleman

On 2019-09-18 08:43, unman wrote:

On Wed, Sep 18, 2019 at 02:04:53PM +0200, haaber wrote:

today I had a look in logs of my router, and discovered that it logs my
qubes machine as "sys-net". I did not change anything in my
"out-of-the-box" sys-net, so I presume that the observed behaviour is
common to all standard qubes installs.
Q: is it a wanted feature that all wireless networks immediately know
that I use qubes? I think that this is a bad idea, and that some "dummy
name" suggesting a standard linux system would be a better choice. That
keeps an epsilon more anonymity and reduces attack surface about
epsilon^2 (since target system unclear). Some comments? Hints how to
change that?

Cheers, Bernhard



It's a long standing bug in NetworkManager.
You *should* be able to disable this globally - you cant.
What you can do is set "ipv4.dhcp-send-hostname no" for EACH connection.
You would, of course, have to do this before connecting for the first
time to avoid leaving trace.

Some Alternatives :
Dont use NM - its' horrible anyway.
Dont use Qubes default names for system qubes - good practice in any
case.
Use a throwaway random name (like Windows-PC-2456) for whatever you use
for sys-net. You can set up a simple script to do this each time you
start your Qubes box,providing you have disabled relevant autostarts. I
think this is best practice.



How about just adding:

sudo nmci general hostname 

to the /rw/config/rc.local script in the sys-net vm. Then that script 
should kick off before the network interface comes up, and so nm should 
use that setting as the system hostname.


If needed/desired you can also add some randomizing function to create a 
different hostname each time you boot.


NUMBER=$(cat /dev/urandom | tr -dc '0-9' | fold -w 8 | head -n 1 )
sudo nmci general hostname PC-${NUMBER}

e.g.
PC-88815209

--
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/c784ead3-7ddf-8a9f-4721-1d85cae633f8%40jhuapl.edu.


Re: [qubes-users] HCL - Purism Librem 15 v3 w/ TPM module

2019-09-16 Thread Steve Coleman

On 2019-09-15 02:38, Jeff Warner wrote:
I am brand new to QubesOS and hope to be able to update this entry over 
time. I'm happy to start with this HCL report. The prospects look quite 
promising.


Welcome to Qubes! Let us know if you have any questions


--
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/CAK4unLo38xunz4DE0DSrZP9_zznjWT%2BSX1dBhvzqySYHV8sVZw%40mail.gmail.com 
.


--
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/0a309abb-85c7-a401-28ad-93f534086470%40jhuapl.edu.


Re: [qubes-users] No network

2019-09-16 Thread Steve Coleman

On 2019-09-15 12:45, kegd...@gmail.com wrote:


Networking is enabled by state file, and WiFi enabled by radio killswitch; 
enabled by state file.
It se es no network ando manually adding a WiFi does not connect.
Sys-net networkmanager[520] has a new ethernet device detected (vif2.0) but 
network icono says Ethernet: device not managed.



I didn't see where you mentioned what system/model you are using. I had 
a similar WiFi issue just this weekend with an old Lenovo. In my case 
there was a physical RF kill switch that prevented the WiFi interface 
from "being managed" properly by network manager.



--
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/381da61e-b680-e006-5045-5bbd34f36f66%40jhuapl.edu.


Re: [qubes-users] best and less expensive Lenovo think pad

2019-08-13 Thread Steve Coleman

On 8/13/19 6:28 AM, 799 wrote:

Hello

<27casanov...@gmail.com > schrieb am Di., 



https://github.com/one7two99/my-qubes/blob/master/docs/coreboot/README.md

Let me know if you need any help.


I do have a few questions for anyone experienced with the x230

Q1: Does the ThinkPad x230 have a separate USB controller available for 
use as a sys-usb?


Q2: Also, how would a docking station work with this setup, given that 
the keyboard would likely be connected via some internal docking station 
USB interface?


The PrivacyBeast info claims there is both USB3 and USB2 connector but 
it does not specifically mention any sys-usb capability, nor does the 
Qubes certified hardware announcement. The Lenovo documentation does not 
give any level of detail with respect to Qubes, obviously. When pricing 
out a new x230 with the needed memory/SSD upgrades, it isn't too much 
cheaper that PB, but rolling my own I would at least get more room for 
hosting VM's. But then I would still be stuck with the Intel ME problem. 
I would think that moving the pre-installed PB OS configuration to a new 
SSD could be problematic, given its claimed bios/heads and 
per-partitioned disk configuration, and so I might as well just start 
with a clean slate and roll my own with coreboot, if I were to proceed 
down this path.


Having a laptop at home with Qubes would certainly be nice, but if so, I 
hope to be able to run some third party software that requires direct 
control of some CNC/gcode hardware via a USB serial interface, plus a 
USB camera for layout and coordinate registration. I'm not sure if this 
is possible, but I am thinking it might be if the USB controller can be 
assigned to that particular VM. Right now I am stuck with Windows, which 
I would be happy to trade in for Qubes if it can work. Either way just 
having a mobile machine as a backup in case my home office machine goes 
down would be great.


thanks,

Steve.

--
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/89767608-2b27-2218-7d3f-5f64f21c5ec0%40jhuapl.edu.


Re: [qubes-users] Receive-only email VM

2019-08-07 Thread Steve Coleman

On 8/2/19 1:24 PM, reddit@vfemail.net wrote:
In Qubes, is it possible to set up a VM that can receive email, but not 
send information out, via email or otherwise?


The motivation is: Many online accounts rely on an email address to 
reset passwords. However, the VM that handles inbound emails, processes 
a lot of untrusted input. If the VM gets compromised by an attacker, the 
attacker can then send password reset emails and read them. So to defend 
against this, I want to prevent the compromised VM from communicating 
out the contents of these password reset emails.


Specifically:
1. Assume the VM is compromised (can't rely on in-VM enforcement 
mechanisms).

2. Assume the email provider is not compromised

To further illustrate the problem, here are example setups and why they 
don't work:


Setup 1: Use qubes firewall to restrict to the email provider's server 
and IMAP port. Block UDP requests using qvm-firewall.
Why it doesn't work: Attacker can create an account on the same email 
provider and connect to their account (the firewall rules will not 
prevent this). They can then sync emails containing any data, to their 
account.


Setup 2: Like Setup 1, but use POP3.
Why it doesn't work: Attacker creates account at provider, transmits 
data via POP3 delete operations.


How about setup the firewall to black hole the entire IP range of the 
email service company, then set up a proxy on the firewall which you 
then control, and you set their email program to use the proxy. If need 
be you can black hole all the pop/smtp/imap ports for all Internet 
traffic forcing them to use the proxy for any email no matter what email 
program or provider they use. When they try to send any email the proxy 
simply closes that connection.


Controlling HTTP/s traffic might be more difficult, but if necessary you 
can proxy all that as well. If its just one service provider you care 
about then the black hole IP trick should do the job.


You put any custom logic for your specific requirements into the proxy 
which then controls their access accordingly. Basically its a default 
deny gateway which needs to match on the permitted rules before they are 
ever granted access. The downside is you will likely need to write your 
own proxy for 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/bd97b81b-5b13-ff22-42b5-21505054e34c%40jhuapl.edu.


Re: [qubes-users] Can't sudo in unman's qubes.3isec.org Ubuntu-14.04 template

2019-07-12 Thread Steve Coleman

On 7/11/19 9:36 PM, list.w...@gmail.com wrote:

On Wednesday, 10 July 2019 17:13:42 UTC, steve.coleman  wrote:

On 7/10/19 2:02 AM,  wrote:

On Tuesday, 9 July 2019 12:31:23 UTC, steve.coleman  wrote:

On 7/9/19 7:25 AM,  wrote:

Hi, I installed a Ubuntu-14.04 minimal template from qubes.3isec.org using

$ sudo dnf install qubes-template-stretch-minimal-4.0.1-201812230252.noarch.rpm

and that works 'fabelhaft' (German for 'fabulously' :), but inside the running 
template I'm asked for a password when I try to sudo my way into apt-get update.

Does anyone know the password for 'user'?

Thanks.



If you can not sudo, you can always try running your command from Dom0
as user root:

$ qvm-run -a --user root  "apt-get update"


Thanks.
I not only want to update, I also want to run all other kinds of commands as 
sudo. Do you think I can run any command like this inside the qube from within 
dom0?


You can also run any other command as root, like "passwd user" to set
the password to a know value, or "gedit /etc/sudoers" and modify who can
sudo, add yourself to the wheel group, etc... I can't say why your
particular appvm prevents you from sudoing without testing the vm
myself, but whatever the problem is, you now have a way to get a root
shell to fix it.

hope this helps


It did, thanks for your help.
The funny thing is,

[user@dom0 ~]$ qvm-run -p --user root stretch-minimal "usermod -a -G sudo user"

didn't work, even after

[user@dom0 ~]$ qvm-run -p --user root stretch-minimal "service sudo restart"

although 'user' was added to the sudo group as could be seen from

user@stretch-minimal:~$  cat /etc/group | grep sudo
sudo:x:27:user

so I had to edit the sudoers file directly, then restarted the sudo service:

[user@dom0 ~]$ qvm-run -p --user root stretch-minimal "service sudo restart"

and that worked, so I wrote a little script to more or less automate and 
explain the process: https://pastebin.com/UcJa0DvC

For what it is worth, you might just find it easier to start a root 
terminal (e.g. gnome-terminal, xterm, etc) so that you can run all those 
commands as root interactively at a command line. Chances are your 
"stretch-minimal" may not have many choices of terminals, but then you 
can always just add one to make your life a little easier. I don't know 
stretch, but I would guess that the 'xterm' application is likely 
already installed.


$ qvm-run -a --user root stretch-minimal xterm

'gnome-terminal' is execelent if that is already installed.

--
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9f201d68-e9b0-d3ab-a60d-e78b50d545db%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Can't sudo in unman's qubes.3isec.org Ubuntu-14.04 template

2019-07-10 Thread Steve Coleman

On 7/10/19 2:02 AM, list.w...@gmail.com wrote:

On Tuesday, 9 July 2019 12:31:23 UTC, steve.coleman  wrote:

On 7/9/19 7:25 AM,  wrote:

Hi, I installed a Ubuntu-14.04 minimal template from qubes.3isec.org using

$ sudo dnf install qubes-template-stretch-minimal-4.0.1-201812230252.noarch.rpm

and that works 'fabelhaft' (German for 'fabulously' :), but inside the running 
template I'm asked for a password when I try to sudo my way into apt-get update.

Does anyone know the password for 'user'?

Thanks.



If you can not sudo, you can always try running your command from Dom0
as user root:

$ qvm-run -a --user root  "apt-get update"


Thanks.
I not only want to update, I also want to run all other kinds of commands as 
sudo. Do you think I can run any command like this inside the qube from within 
dom0?


You can also run any other command as root, like "passwd user" to set 
the password to a know value, or "gedit /etc/sudoers" and modify who can 
sudo, add yourself to the wheel group, etc... I can't say why your 
particular appvm prevents you from sudoing without testing the vm 
myself, but whatever the problem is, you now have a way to get a root 
shell to fix it.


hope this helps




--
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7aef641a-2065-ad04-8279-0de94d0c97de%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Can't sudo in unman's qubes.3isec.org Ubuntu-14.04 template

2019-07-09 Thread Steve Coleman

On 7/9/19 7:25 AM, list.w...@gmail.com wrote:

Hi, I installed a Ubuntu-14.04 minimal template from qubes.3isec.org using

$ sudo dnf install qubes-template-stretch-minimal-4.0.1-201812230252.noarch.rpm

and that works 'fabelhaft' (German for 'fabulously' :), but inside the running 
template I'm asked for a password when I try to sudo my way into apt-get update.

Does anyone know the password for 'user'?

Thanks.



If you can not sudo, you can always try running your command from Dom0 
as user root:


$ qvm-run -a --user root  "apt-get update"


--
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2f5edfbc-0129-7d61-50c2-7060434cef85%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.


Re: VS: [qubes-users] Re: Update: HCL - LENOVO Thinkpad P51 (20hjs0bx00) for R4.0

2019-07-02 Thread Steve Coleman

On 7/1/19 5:09 AM, Michael Andersson wrote:



I am almost certainly about to buy 
https://smile.amazon.com/gp/product/B075TH6GBT/ , a ThinkPad P51 with an 
i7-7820HQ -- just like your machine above.


I have been wanting a second Qubes system for home use, so I took a look 
at this laptop and noticed that it comes with "4G LTE WLAN" 
capabilities. Interesting idea, but when googling this group I only 
found "issues" with it, and one HCL comment "passed through to sys-net", 
but then that Q4.0RC1 install failed for other reasons. There were no 
clear signs of success with LTE networking in either qubes-user or 
qube-devel groups.


Q: Does does anyone have this Lenovo LTE WLAN working under Qubes 4? As 
a separate sys-lte, or in running in the same sys-net? How do you 
(auto-)switch between the two interfaces?


Then I started thinking about the complications of the use-case of using 
Qubes as a Hot-Spot for networking other devices while on the road. And 
how one would even architecturally set that up? I would guess that both 
the Wifi (and/or Bluetooth) adapter and the LTE hardware would need to 
be contained in the same HVM, with some type of bridge-like software to 
control that connectivity. This is just just a mental  exercise at this 
point, but it would be awesome to hear if anyone had ever done this.



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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0c9575b3-406a-f2cb-aed1-7123c56d62ca%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Quick question please, need help!

2019-07-02 Thread Steve Coleman

On 6/21/19 6:37 PM, ljul8...@gmail.com wrote:

I was told that if dom0 gets infected, everything in the laptop can be found and read. 


While this is a true statement, you then have to think about exactly 
what it would take for someone to do this given the Qubes logical 
architecture and the physical hardware enforced memory separation that 
Qubes is built upon. For an adversary to circumvent your dom0 you will 
likely have needed to have helped them do so, by first doing something 
to deliberately break your security model.


Note to self: Don't do stupid things in dom0.

Since dom0 has no networking, just to get into dom0, the adversary would 
have to first breach the sys-net VM and then somehow circumvent or 
leverage a flaw in the Xen hypervisor to establish a communications 
channel into Dom0 to take control. That is exactly why Dom0 has no 
networking nor any user applications, so its actually *hard* to do 
stupid things. The attack surface of dom0 purposefully is kept to the 
absolute bare minimum. For this reason I use a separate stripped down OS 
template for sys-net, just to make this VM as a stepping stone, a little 
more challenging for the adversary. Faux hacker tools, process 
instrumentation, and lots of land mines.


Or, you yourself would have to introduce some APT agent (e.g. inserting 
an infected USB device) into Dom0, so that this APT agent can later 
reach back out to the adversary, as to establish a back-channel, and 
permit their gain of control over the machine. You would have to 
unwittingly be their accomplice in the crime that you yourself are 
wanting to prevent.


Neither of the above circumventions are easy, and thus the only sure way 
for an adversary to get into your system is for them to have personal 
physical access to your hardware, an alternate bootable OS on a CD/USB, 
along with the LVM encryption passwords. That is where Qubes AEM comes 
in. I have had to breach my own systems on occasion, while I already 
know the passwords, and I have found that it can still be a challenge to 
take control over a Qubes system without leaving some kind of obvious 
evidence behind.


Note to self: Don't over-harden your desktop system if you want to 
actually get your work done.



The ip is not a problem but I’m not sure about the MAC address? If they found 
out the latter by infecting dom0, what are the possibilities to trace that MAC 
address to the laptop owner?



What you are asking for is called "MAC randomization". You can google 
this phrase in this news group or the Qubes site and find out how to do 
it. Basically, each time you boot you can script up the modification of 
the MAC address to another value, so that, statistically at least, you 
are never using the same MAC address.


Since the majority of networks assign the actual IP address to you, you 
likely won't have much control over that address, and logically the IP 
address belongs to the network, not you. Chances are that with a 
different MAC address you will not likely be getting the same IP address 
each time either, depending of course on how they actually allocate 
their addresses.





--
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/32e60342-e935-7fee-19a7-5d400e6028a4%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Full proper backup of Dom0 possible?

2019-06-11 Thread Steve Coleman

On 6/10/19 4:04 PM, Otto Kratik wrote:

For both Template and AppVM's it's easy enough to backup and restore the entire 
thing as needed using the built-in tools from Qubes Manager, Qmenu or command 
line. Anything goes wrong, just restore a backup.

But for dom0, all that seems to get backed up is the /home directory, meaning 
that any changes to other system areas such as /etc/qubes-rpc/policy/ for 
example would not get restored in the event of a reversion to a previously made 
backup after a fresh system install.

Is there any way to make a full proper backup of Dom0 that would include 
absolutely everything outside of the other VM's on the system, obviously? So 
that after performing a fresh system install and then restoring all backups 
(dom0, templates, appvms) you would end up with a complete byte-for-byte 
replica of the previous system that existed?

This could be done with external tools like DD of course, but that produces a 
gigantic image of the entire hard drive rather than just the needed parts, and 
also doesn't allow one to fully restore *just* dome0 while leaving the other 
templates/VMs alone, if desired.

Does such a versatile option exist
I have a lightweight solution that may be good-enough for some people 
out there, and a simple suggestion at the bottom.


I have been bitten by this dom0 backup omission more times that I can 
remember. The problem is that the standard dom0 backup system does not 
save any of my dom0 highly tweaked system configuration files. Thus 
whenever restoring from backup is required, I am forced to manually 
reconfigure everything manually from scratch.


In order to have 'the privilege' of running Qubes-OS here as my desktop 
system I am forced to configure my machine according to "the standard" 
configuration. I need to install specific software, 2FA, install cron 
jobs, run compliance reports, just to maintain access to network resources.


Example: I just got back from short term disability, and found I was 
locked out and I needed to breach my own systems numerous security 
controls, rebuild, and reconfigure from the ground up. I'm still picking 
up the pieces and am trying to get everything back together for the 
inspections starting next week.


To save myself from having to go through this fiasco even one more time 
I am now saving off the dom0 configuration information using a specific 
list of those things that I have to hand modify. I then I push that copy 
to a dedicated AppVM where it will be backed up just as any normal AppVM 
would be. The hardest part is remembering to add any changed 
configuration file to my configuration save list, though I am sure this 
too can be automated.


The super simple command I am using to save this set of configuration 
files is:


sudo tar cf - --derefrence --files-from=$FILELIST | \
   qvm-run -a -p $DOCVM "cd /home/user/dom0-config ; tar xvf -"

Here I am deliberately expanding the directory tree on the other side, 
but you might want instead to simply create an archive and label it with 
a date time-stamp before moving the archive over. I use this tree to 
diff and document my system within that dedicated AppVM. If any dom0 
configuration files have changed it will be obvious. When recovering, by 
simply moving this configuration tree back to dom0, it will put me back 
to where I was before.


Apart from that there may be some rpm packages to install and scripts to 
run, but that is Ok with me because I have all that documented and 
scripted. I don't need to backup everything in dom0. Just the important 
stuff in /etc, /usr/local/*, software archives, special rpm's, etc. If I 
didn't have to edit it, run, or install it, then I really don't need to 
back it up. Its simply a minimalist recovery capsule.


suggestion - If the standard dom0 command line backup tool could be 
extended to allow a dom0 include-list argument, then it might mitigate 
this whole problem. If the user could simply add and remove file 
references to this include-list, then a full backup of dom0 might not be 
necessary. The user then decides what is important to add to this list. 
When restoring, the user would still have to move the individual 
recovered files back into place, but at least the user would *have* all 
the pieces needed to get up and running again.


steve



--
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0a41d757-d134-ca15-9f23-246707cc008c%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Domain [*] has failed to start: Cannot execute qubesdb-daemon

2019-06-03 Thread Steve Coleman

On 6/3/19 2:17 PM, 'awokd' via qubes-users wrote:

Steve Coleman wrote on 6/3/19 5:11 PM:

So, it appears that just having that specific VM name will somehow 
prevent it from ever running. When the AppVM has any other name then 
it seems to work just fine. I just can't name any VM with the same 
original VM name.


Rename the problem VMs to something else, then check your 
/var/lib/qubes/qubes.xml. Confirm the new names are in there, then 
delete any bad entries. Reboot. Cross fingers.




After renaming/deleting the broken VM's there are no references left in 
the qubes.xml file.


However, after renaming the VM's to another name and deleting the log 
files in:


/var/log/qubes/*.VMNAME*.log
/var/log/xen/console/*VMNAM*.log
/var/log/libvirt/libxl/VMNAME.log

then moving the VM name back, everything ran correctly. My guess is that 
there was a file permission or ownership that got messed up and therefor 
qubesdb-daemon was unable to open that resource so it bailed out with no 
error message.


The ownership of the qrexec.VMNAME.log and qubesdb.VMNAME.log are now 
username.qubes where they had previously been root.qubes. Apparently 
when you delete or rename a VM the logfiles are persistent so the 
permissions would prevent any new VM from writing to that same file as 
well.


In furthur testing I found that simply removing the file 
/var/log/qubes/qubesdb.VMNAME.log would allow that VM to start correctly 
even without renaming anything. It's clearly a file 
ownership/permissions problem.


The one mystery left is how did the logfile permissions get messed up 
during the restore process in the first place. Perhaps from running the 
qvm-backup-restore as root? I don't remember doing that but its possible.


Steve

--
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3103eb32-635f-1b17-1515-121fa08432d9%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Domain [*] has failed to start: Cannot execute qubesdb-daemon

2019-06-03 Thread Steve Coleman

On 5/31/19 3:48 PM, Steve Coleman wrote:
After doing a reinstall and restore from backup of my Qubes 4.0 system, 
I have a number of AppVM's that do not want to start for some unknown 
reason. The frustrating thing is there are no AppVM or dom0 logs that 
give me any clue as to where to start chasing down the problem. I have 
grep'ed all logs for "qubesdb-daemon" in dom0, and all I can find is 
qubes.log is saying it could not start the daemon. Not very helpful.


All log files in /var/log/qubes/qubesdb.VMNAME.log are zero bytes for 
all AppVM's that do not run.


Putting the broken AppVM in debugging mode does not help, nor does using 
the -p and -v flags on the qvm-[run,start] command lines. Why it won't 
start is a total enigma since I can not see any error logs on either 
side. Some AppVM's work just fine, while others simply do not. They all 
use the exact same fedora-29 template and the same settings that they 
had before the backup.


 From dom0 qubesvm.py starting at line 1537 I see what appears to be the 
relevant code giving my pop-up error message:


try:
 yield from self.start_daemon(
     qubes.config.system_path['qubesdb_daemon_path'],
     str(self.xid),
     self.name)
 except subprocess.CalledProcessError:
     raise qubes.exc.QubesException(
     'Cannot execute qubesdb-daemon)


Is this code unable to create a system_path using the xid and appvm 
name? Or just read one? A subprocess fork error, or an error deeper 
inside some nameless forked process?


Most VM's start normally, so it should not be the "path" to the daemon 
executable on either side, as that path and executable is in common with 
other VM's that work just fine with the exact same template.


I only thing I see different between these is qvm-prefs is returning xid 
== -1 for those that seem not to work, and positive integer values for 
those that do work. If the above code is building a path using the -1 
xid then this might be a problem?


Could this somehow also be evidence of some kind of lvm pool or qubes 
database corruption from the restore process?  I don't recall seeing any 
error messages during the restore processing, but as it happens, the 
ones that do not work were actually VM's restored later in that overall 
process. Since they were deemed less important I happened to do them 
last. Not sure if that could be relevant here or not, as I have the 
exact same system disk space as before. It just sounds suspicious that 
the later ones to be restored are the ones that seem to be not running.


Anyone have a clue where else to look for a real error messages? Perhaps 
some esoteric dmesg or xl command looking for a xen system error by 
another name? Or do I just need to --set a unique xid to each AppVM to 
make them start properly?


thanks,

Steve



Ok, I did some more testing on this, and it makes no sense...

If I clone the broken AppVM, then the clone made from it will run just 
fine. But wait... there is more.


If I then delete the original AppVM and rename the new clone back to the 
original name, that working AppVM fails with the same "can't start 
qubesdb-daemon" error.


If I clone the working clone, and give that new clone the original name, 
again it fails to run.


Directly renaming a broken AppVM to any other VM name appears to fix the 
problem, but copying it back to the original name breaks it again.


If I delete the broken AppVM and create an brand new AppVM with the same 
broken VM name then that brand new VM will not run, giving the same error.


A clone of a clone of a clone works just fine, as long as you don't give 
it the original VM name.


So, it appears that just having that specific VM name will somehow 
prevent it from ever running. When the AppVM has any other name then it 
seems to work just fine. I just can't name any VM with the same original 
VM name.




Steve


--
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e615ced9-165c-6246-52ce-bffb7f260651%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Domain [*] has failed to start: Cannot execute qubesdb-daemon

2019-05-31 Thread Steve Coleman
After doing a reinstall and restore from backup of my Qubes 4.0 system, 
I have a number of AppVM's that do not want to start for some unknown 
reason. The frustrating thing is there are no AppVM or dom0 logs that 
give me any clue as to where to start chasing down the problem. I have 
grep'ed all logs for "qubesdb-daemon" in dom0, and all I can find is 
qubes.log is saying it could not start the daemon. Not very helpful.


All log files in /var/log/qubes/qubesdb.VMNAME.log are zero bytes for 
all AppVM's that do not run.


Putting the broken AppVM in debugging mode does not help, nor does using 
the -p and -v flags on the qvm-[run,start] command lines. Why it won't 
start is a total enigma since I can not see any error logs on either 
side. Some AppVM's work just fine, while others simply do not. They all 
use the exact same fedora-29 template and the same settings that they 
had before the backup.


From dom0 qubesvm.py starting at line 1537 I see what appears to be the 
relevant code giving my pop-up error message:


try:
yield from self.start_daemon(
qubes.config.system_path['qubesdb_daemon_path'],
str(self.xid),
self.name)
except subprocess.CalledProcessError:
raise qubes.exc.QubesException(
'Cannot execute qubesdb-daemon)


Is this code unable to create a system_path using the xid and appvm 
name? Or just read one? A subprocess fork error, or an error deeper 
inside some nameless forked process?


Most VM's start normally, so it should not be the "path" to the daemon 
executable on either side, as that path and executable is in common with 
other VM's that work just fine with the exact same template.


I only thing I see different between these is qvm-prefs is returning xid 
== -1 for those that seem not to work, and positive integer values for 
those that do work. If the above code is building a path using the -1 
xid then this might be a problem?


Could this somehow also be evidence of some kind of lvm pool or qubes 
database corruption from the restore process?  I don't recall seeing any 
error messages during the restore processing, but as it happens, the 
ones that do not work were actually VM's restored later in that overall 
process. Since they were deemed less important I happened to do them 
last. Not sure if that could be relevant here or not, as I have the 
exact same system disk space as before. It just sounds suspicious that 
the later ones to be restored are the ones that seem to be not running.


Anyone have a clue where else to look for a real error messages? Perhaps 
some esoteric dmesg or xl command looking for a xen system error by 
another name? Or do I just need to --set a unique xid to each AppVM to 
make them start properly?


thanks,

Steve

--
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6a1bc3a1-e9ad-2b56-ce38-ddb0c004a9a8%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Installing: Missing features: IOMMU/VT-d/AMD-Vi, Interrupt Remapping

2019-01-02 Thread Steve Coleman

On 1/2/19 11:41 AM, LefC wrote:

Τη Τετάρτη, 2 Ιανουαρίου 2019 - 5:06:31 μ.μ. UTC+2, ο χρήστης steve.coleman 
έγραψε:

On 1/2/19 9:12 AM, LefC wrote:

Hi, i'm trying to install Qubes for the first time, i am a total newb but eager 
to learn more about this interesting OS.
So i attempted an installation to my old wiped laptop and got this message

Missing features: IOMMU/VT-d/AMD-Vi, Interrupt Remapping

And the warning that Qubes might not work properly. Does that mean that my 
machine is not able to run Qubes at all?? Is there anything that i may can do 
to make it work somehow?
To be honest, i did proceed with the installation, which completed normally 
without any issue but then the system was and is not able to boot Qubes. It 
leads to some Fail/error messages while booting. Is it because of the lacking 
hardware?
Is there any hope for my laptop and Qubes?



Before giving up, go check your BIOS settings for the required features
listed above. In all likelihood you may actually have the necessary
hardware but have them disabled in BIOS by default.

Without knowing *exactly* what system processor and chipset you have we
can not give you any better advice than to check these settings.

Try enabling those settings in BIOS, and then try to install again.
Failing that, you might check to see if you have the latest vendor BIOS
update.  Take notes on what it says about your specific hardware, and
let us know what happens.


Thanks for the answer,
Well, the laptop is a samsung model NP300V5A

Intel Core i5 2410M / 2.30 GHz ( Dual-Core )
with a GeForce GT 520M

I looked up the BIOS settings as you suggested, there's nowhere something like 
the missing features. Only VT-x which says 'Supported'. Its Phoenix BIOS v.08F1
Not sure how to update this, i must look it up and ask again. Also most of its 
options seem to be locked by the manufacturer



Well you can take a look here:
https://www.samsung.com/us/support/owners/product/np300v5a

I didn't see VT-d listed anywhere on the spec page. There is a BIOS 
installer ver 1.0.0.2 listed, but from way back in 2011. If you don't 
have the VT-d hardware there isn't much point to installing 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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/11f6c44e-4b44-b7a7-5933-530eee4f22cb%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Installing: Missing features: IOMMU/VT-d/AMD-Vi, Interrupt Remapping

2019-01-02 Thread Steve Coleman

On 1/2/19 9:12 AM, LefC wrote:

Hi, i'm trying to install Qubes for the first time, i am a total newb but eager 
to learn more about this interesting OS.
So i attempted an installation to my old wiped laptop and got this message

Missing features: IOMMU/VT-d/AMD-Vi, Interrupt Remapping

And the warning that Qubes might not work properly. Does that mean that my 
machine is not able to run Qubes at all?? Is there anything that i may can do 
to make it work somehow?
To be honest, i did proceed with the installation, which completed normally 
without any issue but then the system was and is not able to boot Qubes. It 
leads to some Fail/error messages while booting. Is it because of the lacking 
hardware?
Is there any hope for my laptop and Qubes?



Before giving up, go check your BIOS settings for the required features 
listed above. In all likelihood you may actually have the necessary 
hardware but have them disabled in BIOS by default.


Without knowing *exactly* what system processor and chipset you have we 
can not give you any better advice than to check these settings.


Try enabling those settings in BIOS, and then try to install again. 
Failing that, you might check to see if you have the latest vendor BIOS 
update.  Take notes on what it says about your specific hardware, and 
let us know what happens.


--
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ba6c7721-4cb4-9060-86ce-e082eee5b2d8%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Fed-28 update error

2018-12-20 Thread Steve Coleman

On 12/19/18 6:39 PM, Andrew David Wong wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 12/19/18 4:34 AM, qubes-...@tutanota.com wrote:

Hi, I updated the dom0 and after I tried to update the Fed-28 template. I get 
following error:

[user@fedora-28 ~]$ sudo dnf update
Last metadata expiration check: 0:27:37 ago on Wed 19 Dec 2018 11:04:23 AM CET.
Dependencies resolved.

Problem 1: cannot install the best update candidate for package 
hplip-3.18.6-10.fc28.x86_64
   - nothing provides libnetsnmp.so.35()(64bit) needed by 
hplip-3.18.6-11.fc28.x86_64
Problem 2: cannot install the best update candidate for package 
hplip-libs-3.18.6-10.fc28.x86_64
   - nothing provides libnetsnmp.so.35()(64bit) needed by 
hplip-libs-3.18.6-11.fc28.x86_64
Problem 3: cannot install the best update candidate for package 
libsane-hpaio-3.18.6-10.fc28.x86_64
   - nothing provides libnetsnmp.so.35()(64bit) needed by 
libsane-hpaio-3.18.6-11.fc28.x86_64
Problem 4: package hplip-libs-3.18.6-10.fc28.x86_64 requires 
hplip-common(x86-64) = 3.18.6-10.fc28, but none of the providers can be 
installed
   - cannot install both hplip-common-3.18.6-11.fc28.x86_64 and 
hplip-common-3.18.6-10.fc28.x86_64
   - problem with installed package hplip-libs-3.18.6-10.fc28.x86_64
   - cannot install the best update candidate for package 
hplip-common-3.18.6-10.fc28.x86_64
   - nothing provides libnetsnmp.so.35()(64bit) needed by 
hplip-libs-3.18.6-11.fc28.x86_64

Package  Arch  VersionRepository  Size

Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
hplip-common x86_643.18.6-11.fc28 updates110 k
Skipping packages with broken dependencies:
hplipx86_643.18.6-11.fc28 updates 16 M
hplip-libs   x86_643.18.6-11.fc28 updates204 k
libsane-hpaiox86_643.18.6-11.fc28 updates127 k

Transaction Summary

Skip  4 Packages

Nothing to do.
Complete!

***

When doing the --best --allowerasing I get this:

[user@fedora-28 ~]$ sudo dnf --best --allowerasing update
Last metadata expiration check: 0:28:55 ago on Wed 19 Dec 2018 11:04:23 AM CET.
Error:
Problem 1: cannot install the best update candidate for package 
libsane-hpaio-3.18.6-10.fc28.x86_64
   - problem with installed package libsane-hpaio-3.18.6-10.fc28.x86_64
   - nothing provides libnetsnmp.so.35()(64bit) needed by 
libsane-hpaio-3.18.6-11.fc28.x86_64
Problem 2: cannot install the best update candidate for package 
hplip-libs-3.18.6-10.fc28.x86_64
   - problem with installed package hplip-libs-3.18.6-10.fc28.x86_64
   - nothing provides libnetsnmp.so.35()(64bit) needed by 
hplip-libs-3.18.6-11.fc28.x86_64
Problem 3: cannot install the best update candidate for package 
hplip-3.18.6-10.fc28.x86_64
   - problem with installed package hplip-3.18.6-10.fc28.x86_64
   - nothing provides libnetsnmp.so.35()(64bit) needed by 
hplip-3.18.6-11.fc28.x86_64

*

Any help appreciated.
Thank you!



It's an upstream Fedora issue. For more info, see:

https://github.com/QubesOS/qubes-issues/issues/4629


Yes, this is an upstream problem, which has been fixed in the 
"updates-testing" repo. I got bitten by this one in that hplip got 
removed, so I was unable to print anything, so I was forced to investigate.


The temporary fix here should be to enable the "updates-testing" repo 
and reinstall the packages ntop hplip net-snmp-libs to force the correct 
dependancies to be evaluated.


Since my installation was missing hplip I had to install, rather than 
reinstall, but that set of commands should look something like this:


$ sudo dnf clean all
$ sudo dnf reinstall --allowerasing --enablerepo=updates-testing hplip 
net-snmp-libs

$ sudo dnf clean all
$ sudo dnf update

You may see ntop being removed as a dependent package, in which case you 
may need to reinstall it after the above is completed if you use it. 
Hopefully those two packages from testing were not full of bugs. I'll be 
testing that this afternoon after some meetings.


Steve.





- -- 
Andrew David Wong (Axon)

Community Manager, Qubes OS
https://www.qubes-os.org

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlwa1q4ACgkQ203TvDlQ
MDAJBQ//elkdQlan7qFyKFzj2yV/WNAlpvHxkP6GGX3CUBNlWTe7snFKZjAZgZvy
wJAorPxP0wngEdBGc9VVeQ1OYBb/DZQ6akBTtNYYmAxC+bDfS37RyIKpvFx7e22w
yrj0+0iS0T80HtrvhGfAAvBy7jro8oHiFi2u+1MDwytCVqsk2+ZeFaFaOYpDH9Zd
b5U2QpZrEdF2vckK/pBxQLWfOWgX/FildH1P7VGwKtatHArODJ4qb8GjlzswZCxk
0RDy/FCD2s7vDe3wn46zZSCBHty5XRZO2jkfMbc/pbNeie9Il87JxCNdKXcJ4bci

Re: [qubes-users] Q4 qube-manager broke after dom0 software update yesterday (resolved)

2018-12-10 Thread Steve Coleman

On 12/6/18 1:11 PM, Steve Coleman wrote:

On 12/6/18 11:38 AM, donoban wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/4/18 8:07 PM, Steve Coleman wrote:

I was away for a week and dutifully did all my software updates
upon returning. After updating Dom0 the qube-manager that was
running started having problems, so I restarted it, but it then
refused to run.

RuntimeError: the PyQt4.QtCore and PyQt5.QtCore modules both wrap
the QtObject class

The problem appears to be qube-manager/python3 is first picking up
references to PyQt5 when first launching, and later it is picking
up some PyQt4 references via
/usr/lib64/python3.5/site-packages/qubesadmin/__pycache__/*.pyc
files, which then load files from
/usr/lib64/python3.5/site-packages/PyQt4/__pycache__/* , and thus
PyQt4/QtGui.so gets loaded.

It looks like the qubes-manager-4.0.22-1.noarch is the latest,
though I can't help but think this is a case of cache poisoning or
some Qt4/Qt5 environment issue. If so, can the __pycache__/*.pyc
files be removed and regenerated, or is there another way to avoid
the mixing of PyQt versions?



I think that PyQt5 is not installed on dom0 by default so this problem
is not very likely to happen.

Also it seems that all imports from Qube Manager source specify version
4.



Ok, thanks. At least I now know which direction to go to debug this 
problem. There must be some tool installed that pulled in PyQt5 then. 
I'll check the dependencies and see what that might be, or otherwise 
remove that package.


One would think that python would have a way to control this as a 
dynamic PATH configuration. If they do have control of this dynamic 
loading I have not found that feature yet.




Just to document the outcome, removing the python3-pyqt5 package and its 
dependencies did the trick, and the qubes-qube-manager now runs with no 
problem.


Why pyqt4 and pyqt5 can not both be installed I have no clue, but 
somehow this application was using a little of each (Qt4,Qt5) and failed 
miserably. There should be a mechanism to prevent python from mixing 
incompatible resources. I'm just glad that this same bug did not break 
the command line update tools at the same time.




Please tell if you know some reliable steps for reproduce it.
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEznLCgPSfWTT+LPrmFBMQ2OPtCKUFAlwJUHsACgkQFBMQ2OPt
CKWr+A//Qx8jQ3xuZDNGTmIKUvVBLJNau01wHdRVF+bBW0S7RxfjiwHXjTJ5DLTU
L/ne1fCjGDPG7kV3fqy2sXq0Lfl1brPiIQpcU82f/LpHBsIGb6Uz33vfDGF8hNkC
ZEaK76KHxoA9Z3OVwic/x56kwbLuvXDX8d6M8K37ZOfOxgsgoY7WbGQDf/0dBK6Y
auAnPxQ8K3vhS/prJi2u+DWASBnEkM9d94tCeOFhpVHYkpv/6F1PMhx5CSTy/lwN
aSOy1IUkL54WJ4QwT3NNoIKkd+vhxHHOjvvSeKCQcAANoYkgtkhwEJDD/AQn9bE4
EDAZ8yV3QfHElg64x9SIbQJh5rrlLJpKOLnMMslzQl1zIrAzy5V5YcInXiic6VK8
cNDX+FT07kz5+PoqZ5eUMrnbFjbCE4t53sGRuTS+Zd1QdVIEHTvHd2ToMUfeEBX+
tnLTbqg+rhh/F6oirI+L/jx5oSrye5vNvx5kcg4Q0y4AbEWPY0DVZWuemuMVBQGl
4TqG8zQN7CNU6yW8GRHBf3dLi9DtJVS9LUVe+HlC0AYZw2JDUFGxpo6Jb4LxZ791
V9k/FFzH4CLeRs9nh2aoQDFnjK4PcEEifJep9Grbi+z4wGHxN/VB/+aVU4acKJ/I
9Kdr+D4lvlYV6hGY0qxYugj7L26itILsEBPqeGpomsR+2NgKOus=
=NNXh
-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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6d82eaf3-7e97-7fb1-86fc-ff9b6dd93ba4%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Q4 qube-manager broke after dom0 software update yesterday

2018-12-06 Thread Steve Coleman

On 12/6/18 11:38 AM, donoban wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/4/18 8:07 PM, Steve Coleman wrote:

I was away for a week and dutifully did all my software updates
upon returning. After updating Dom0 the qube-manager that was
running started having problems, so I restarted it, but it then
refused to run.

RuntimeError: the PyQt4.QtCore and PyQt5.QtCore modules both wrap
the QtObject class

The problem appears to be qube-manager/python3 is first picking up
references to PyQt5 when first launching, and later it is picking
up some PyQt4 references via
/usr/lib64/python3.5/site-packages/qubesadmin/__pycache__/*.pyc
files, which then load files from
/usr/lib64/python3.5/site-packages/PyQt4/__pycache__/* , and thus
PyQt4/QtGui.so gets loaded.

It looks like the qubes-manager-4.0.22-1.noarch is the latest,
though I can't help but think this is a case of cache poisoning or
some Qt4/Qt5 environment issue. If so, can the __pycache__/*.pyc
files be removed and regenerated, or is there another way to avoid
the mixing of PyQt versions?



I think that PyQt5 is not installed on dom0 by default so this problem
is not very likely to happen.

Also it seems that all imports from Qube Manager source specify version
4.



Ok, thanks. At least I now know which direction to go to debug this 
problem. There must be some tool installed that pulled in PyQt5 then. 
I'll check the dependencies and see what that might be, or otherwise 
remove that package.


One would think that python would have a way to control this as a 
dynamic PATH configuration. If they do have control of this dynamic 
loading I have not found that feature yet.




Please tell if you know some reliable steps for reproduce it.
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEznLCgPSfWTT+LPrmFBMQ2OPtCKUFAlwJUHsACgkQFBMQ2OPt
CKWr+A//Qx8jQ3xuZDNGTmIKUvVBLJNau01wHdRVF+bBW0S7RxfjiwHXjTJ5DLTU
L/ne1fCjGDPG7kV3fqy2sXq0Lfl1brPiIQpcU82f/LpHBsIGb6Uz33vfDGF8hNkC
ZEaK76KHxoA9Z3OVwic/x56kwbLuvXDX8d6M8K37ZOfOxgsgoY7WbGQDf/0dBK6Y
auAnPxQ8K3vhS/prJi2u+DWASBnEkM9d94tCeOFhpVHYkpv/6F1PMhx5CSTy/lwN
aSOy1IUkL54WJ4QwT3NNoIKkd+vhxHHOjvvSeKCQcAANoYkgtkhwEJDD/AQn9bE4
EDAZ8yV3QfHElg64x9SIbQJh5rrlLJpKOLnMMslzQl1zIrAzy5V5YcInXiic6VK8
cNDX+FT07kz5+PoqZ5eUMrnbFjbCE4t53sGRuTS+Zd1QdVIEHTvHd2ToMUfeEBX+
tnLTbqg+rhh/F6oirI+L/jx5oSrye5vNvx5kcg4Q0y4AbEWPY0DVZWuemuMVBQGl
4TqG8zQN7CNU6yW8GRHBf3dLi9DtJVS9LUVe+HlC0AYZw2JDUFGxpo6Jb4LxZ791
V9k/FFzH4CLeRs9nh2aoQDFnjK4PcEEifJep9Grbi+z4wGHxN/VB/+aVU4acKJ/I
9Kdr+D4lvlYV6hGY0qxYugj7L26itILsEBPqeGpomsR+2NgKOus=
=NNXh
-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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b456beb0-be3a-6019-282c-23e0cdfbcef7%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Q4 qube-manager broke after dom0 software update yesterday

2018-12-04 Thread Steve Coleman
I was away for a week and dutifully did all my software updates upon 
returning. After updating Dom0 the qube-manager that was running started 
having problems, so I restarted it, but it then refused to run.


RuntimeError: the PyQt4.QtCore and PyQt5.QtCore modules both wrap the 
QtObject class


The problem appears to be qube-manager/python3 is first picking up 
references to PyQt5 when first launching, and later it is picking up 
some PyQt4 references via 
/usr/lib64/python3.5/site-packages/qubesadmin/__pycache__/*.pyc files, 
which then load files from 
/usr/lib64/python3.5/site-packages/PyQt4/__pycache__/* , and thus 
PyQt4/QtGui.so gets loaded.


It looks like the qubes-manager-4.0.22-1.noarch is the latest, though I 
can't help but think this is a case of cache poisoning or some Qt4/Qt5 
environment issue. If so, can the __pycache__/*.pyc files be removed and 
regenerated, or is there another way to avoid the mixing of PyQt versions?


thanks,

Steve

--
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a6de8368-4610-3aad-22f8-41654217fc73%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.

dom0> qube-manager
Traceback (most recent call last):
  File "/bin/qubes-qube-manager", line 9, in  
load_entry_point('qubesmanager==4.0.22', 'console_scripts', 
'qubes-qube-manager')()

  File "/usr/lib/python3.5/site-packages/pkg_resources/__init__.py", line 542, 
in load_entry_point return get_distribution(dist).load_entry_point(group, name)

  File "/usr/lib/python3.5/site-packages/pkg_resources/__init__.py", line 2575, 
in load_entry_point return ep.load()

  File "/usr/lib/python3.5/site-packages/pkg_resources/__init__.py", line 2235, 
in load return self.resolve()

  File "/usr/lib/python3.5/site-packages/pkg_resources/__init__.py", line 2241, 
in resolve module = __import__(self.module_name, fromlist=['__name__'], level=0)

  File "/usr/lib/python3.5/site-packages/qubesmanager/qube_manager.py", line 
41, in  from PyQt4 import QtGui  # pylint: disable=import-error

RuntimeError: the PyQt4.QtCore and PyQt5.QtCore modules both wrap the QObject 
class


dom0> sudo strace qube-manager
...
open("/usr/lib64/python3.5/asyncio/__pycache__/sslproto.cpython-35.pyc", 
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib64/python3.5/site-packages/PyQt5/__pycache__/__init__.cpython-35.pyc",
 O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib64/python3.5/site-packages/PyQt5", 
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/usr/lib64/python3.5/site-packages/PyQt5/QtCore.so", O_RDONLY|O_CLOEXEC) 
= 3
...
open("/usr/lib64/python3.5/site-packages/sip.so", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib64/python3.5/site-packages/PyQt5/QtGui.so", O_RDONLY|O_CLOEXEC) = 
3
...
open("/lib64/libXau.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib64/python3.5/site-packages/PyQt5/QtWidgets.so", 
O_RDONLY|O_CLOEXEC) = 3
...
open("/usr/lib/python3.5/site-packages/qubesadmin/__pycache__/tags.cpython-35.pyc",
 O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/site-packages/qubesadmin/events/__pycache__/__init__.cpython-35.pyc",
 O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib64/python3.5/site-packages/PyQt4/__pycache__/__init__.cpython-35.pyc",
 O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib64/python3.5/site-packages/PyQt4", 
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/usr/lib64/python3.5/site-packages/PyQt4/QtGui.so", O_RDONLY|O_CLOEXEC) = 
3
...
open("/lib64/libuuid.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib64/python3.5/site-packages/PyQt4/QtCore.so", O_RDONLY|O_CLOEXEC) 
= 3
open("/bin/qubes-qube-manager", O_RDONLY|O_CLOEXEC) = 3
...
open("/usr/lib/python3.5/site-packages/pkg_resources/__init__.py", 
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/site-packages/qubesmanager/qube_manager.py", 
O_RDONLY|O_CLOEXEC) = 3
/usr/lib/python3.5/site-packages/qubesadmin/label.py:
:py:meth:`PyQt4.QtGui.QIcon.fromTheme`'''


dom0> find /usr/lib/python3.5/site-packages/qubesadmin -type f -exec grep -Hi 
Qt4 {} \; 
Binary file 
/usr/lib/python3.5/site-packages/qubesadmin/__pycache__/label.cpython-35.pyc 
matches
Binary file 
/usr/lib/python3.5/site-packages/qubesadmin/__pycache__/label.cpython-35.opt-1.pyc
 matches


Re: [qubes-users] Q4.0 qvm-prefs kernel property vs the installed/latest kernel

2018-12-04 Thread Steve Coleman

On 11/22/18 8:00 PM, unman wrote:

On Tue, Nov 20, 2018 at 01:03:43PM -0500, Steve Coleman wrote:

I have two up to date fedora-26 templates, that have long since been
upgraded to fc28, that are both apparently 'stuck' at kernel version
4.14.74-1. I apparently can not set either template to a newer kernel. There
are a lot of customizations involved so I am hoping not to have to go back
to the fc28 rpm and start all over.

Both methods of inspection show the old kernel:

QubeManager /QubeSettings/advanced/kernel/

qvm-prefs --get  kernel

The current/latest installed fc28 kernel version appears to be 4.18.18-200,
yet this latest kernel does not even show up under the QubeManager settings,
nor qvm-prefs, and absolutely refuses to set/update this 'kernel' key to
this latest kernel version number.

The qvm-prefs utility simply claims that this newer kernel version is not
installed, yet "rpm-qa | grep 4.18.18-200" clearly shows that it is. In fact
rpm says that the older kernel 4.14.74-1 is *not* installed. If so, then how
is this template even running? I'm using it daily!

I know dnf can block a package from upgrading, but that is clearly not what
is happening here. The packages do update but apparently Qubes is just not
seeing them, as to be able to display any in Qube-Manager or set/use them
using qvm-prefs.

The "Qubes Global Settings" shows the default kernel as 4.14.74-1, and I
can't even change that, because the newer kernels are not listed there
either.

A file system scan for the old version number yields /usr/lib/modules/*
directory that shows up with 4.14.74-1 as an *fc26* module rather than a
fc28 module, so this whole version disparity appears to be due to some kind
of botched fc26 --> fc28 system/module check routine during a past upgrade?
At least that I my best guess at the moment of what broke and when.

In fact /usr/lib/modules/4.14.74-1.pvops.qubes.x86_64/build/
is the only *build directory* where as all the newer kernels this is merely
a symlink into /usr/src/kernels/*/

Is there anywhere that I would find a Qubes "version setting" that switches
from fc26 modules to fc28 modules? Or is it just somehow scanning for this
"build" directory and then ignoring the newer symlinks?

Any clues of what this should be doing might be very helpful about now.

thanks,

Steve



Steve,

The appVMs are booting using kernels set in dom0.
You can find more recent kernels in the testing repositories.
Install them in dom0 and they will become available
  to use in your qubes.

They are kernel-qubes-vm.. and kernel-latest-qubes-vm

sudo qubes-dom0-update --enablerepo=current-testing --action=search
kernel-latest-qubes-vm

I think the "latest" is now 4.19.2, but you can specify earlier versions
if you wish



Thank you for that wonderful explanation. It turns out that the issue 
was that the package "kernel-latest-qubes-vm" was not installed in Dom0. 
So, no wonder I could not set any newer kernel version number.


Not sure how that happened unless it was some kind of dependency being 
removed via some kind of conflict resolution. The only thing is there is 
absolutely *no rpm history* for this package! This gets chalked in as 
being a mystery in my book.


thanks,

Steve 8*}

--
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/798cc4fa-c84e-dfb6-765c-be56f9978ceb%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] How can I remove the GUI when booting qubes

2018-11-20 Thread Steve Coleman

On 11/20/18 3:25 PM, pieter lems wrote:
It doesn't seem to work unfortunately, it does display more information 
tho.


Once Xen finishes booting then the OS itself needs to boot, and that 
grub boot entry probably needs the same 'quiet' key word removed. I 
believe this grub file is generated from a script. so there is another 
file that needs to be edited.


look at grub2-mkconfig command for more info

Op di 20 nov. 2018 om 19:32 schreef donoban >:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/20/18 8:19 PM, pieter lems wrote:
 > Hello everyone, First of all i would like to start of thanking the
 > Qubes developers. I've been using QubesOS for around a month right
 > now and i cannot wish for more. It's insane how much work you've
 > put into the development of the OS and that you've come so far.
 >
 > I was wondering how i can make it so that when qubes is starting i
 > see the boot information (the output of the boot progress,im not
 > sure how i should call it). I know that when u press a key it shows
 > the output but i would like that it always shows. No offence to the
 > GUI tho!
 >

I think that removing 'quiet' in /boot/efi/EFI/qubes/xen.cfg should
work but maybe you can modify other thing for do not lost the change
when upgrading dom0.
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEznLCgPSfWTT+LPrmFBMQ2OPtCKUFAlv0YUgACgkQFBMQ2OPt
CKUyeQ//aH/6q5xpg4Xuu5zXa4sIBDazXLPND7yl25sEha/RW2VwYDUfrfAijcN3
VU+DzVeH2nTByePXXAvz7XNShhYYFnTYo4lEp6GmrHQPaUV7KpGtjT2Egn9k97cA
oyQ90ZowPn0XK7owje8Vi4vV6ZhmVzFi9wlLzX40Dv0grrxOxV5AlrhBavpq+HfJ
Zz8O6k+bmPGqIWP2udBWULFN8+twSOGMCQgAI3mvAWZC/AfMevlooAkcFviawsk3
IpVzRktrriVrNPT1LfJzvhRZVNNq4d9BaFKDPSGO1t9Nts5Srs7MzEBoR1LWVHHG
YoLE6PyE0beUfvHKtyII2M37FSDO+aseQmHk4iPSqg0/TW7P8t5LUZSM/JObSJw2
/YJMfWy7qC/zbDuTkezEE+7rwR1BZp8w9H7Sotm3on4Xzs3B9WXA9VVZfiiiBFt5
f7CTnV0mfMoPiOAX7GqVcc/5YlXD7OSh9Ei0MvHYPAWX3eE23ScY309/T2zqBlD9
DEGQdJ6179roGAWI/HLoy7/BF8iz1o4ahAL0h1s2PkMinYjYfLnvsFDL4aNj/pi0
itKaf+TNQr9JSqpLEWpjWY4w6V2WmqRSmX424cP4TJX6gUuVsWxrPFn8R7uC/aZW
KC9uEbM/qOTJuc+ieNYL2hbC7IlV2CyLghKLMyaxrR92Q5SnIG0=
=gHiN
-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 post to this group, send email to qubes-users@googlegroups.com
.
To view this discussion on the web visit

https://groups.google.com/d/msgid/qubes-users/17835bd5-6058-8f77-ba38-312f519a3082%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

--
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 post to this group, send email to qubes-users@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAK8vAnVEjk0qryoggbn%2BmeFhzmUp4u0i%3DCMw1ajLTLhaxU2hkA%40mail.gmail.com 
.

For more options, visit https://groups.google.com/d/optout.


--
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b7d08d49-d348-f8db-8048-b163ee0d66b5%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Q4.0 qvm-prefs kernel property vs the installed/latest kernel

2018-11-20 Thread Steve Coleman
I have two up to date fedora-26 templates, that have long since been 
upgraded to fc28, that are both apparently 'stuck' at kernel version 
4.14.74-1. I apparently can not set either template to a newer kernel. 
There are a lot of customizations involved so I am hoping not to have to 
go back to the fc28 rpm and start all over.


Both methods of inspection show the old kernel:

QubeManager /QubeSettings/advanced/kernel/

qvm-prefs --get  kernel

The current/latest installed fc28 kernel version appears to be 
4.18.18-200, yet this latest kernel does not even show up under the 
QubeManager settings, nor qvm-prefs, and absolutely refuses to 
set/update this 'kernel' key to this latest kernel version number.


The qvm-prefs utility simply claims that this newer kernel version is 
not installed, yet "rpm-qa | grep 4.18.18-200" clearly shows that it is. 
In fact rpm says that the older kernel 4.14.74-1 is *not* installed. If 
so, then how is this template even running? I'm using it daily!


I know dnf can block a package from upgrading, but that is clearly not 
what is happening here. The packages do update but apparently Qubes is 
just not seeing them, as to be able to display any in Qube-Manager or 
set/use them using qvm-prefs.


The "Qubes Global Settings" shows the default kernel as 4.14.74-1, and I 
can't even change that, because the newer kernels are not listed there 
either.


A file system scan for the old version number yields /usr/lib/modules/* 
directory that shows up with 4.14.74-1 as an *fc26* module rather than a 
fc28 module, so this whole version disparity appears to be due to some 
kind of botched fc26 --> fc28 system/module check routine during a past 
upgrade? At least that I my best guess at the moment of what broke and 
when.


In fact /usr/lib/modules/4.14.74-1.pvops.qubes.x86_64/build/
is the only *build directory* where as all the newer kernels this is 
merely a symlink into /usr/src/kernels/*/


Is there anywhere that I would find a Qubes "version setting" that 
switches from fc26 modules to fc28 modules? Or is it just somehow 
scanning for this "build" directory and then ignoring the newer symlinks?


Any clues of what this should be doing might be very helpful about now.

thanks,

Steve

--
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f37dec5e-f9cf-3a23-a5ed-f4cfe2ac7053%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes menu failing. Come on guys

2018-11-09 Thread Steve Coleman

On 11/8/18 7:45 AM, unman wrote:

On Wed, Nov 07, 2018 at 08:14:23PM -0800, Ryan Tate wrote:



The latest is everything above and below the VMs is gone from the Qubes menu. The bottom 
of the menu where I'd go to shut down just says "No applications found." The 
top where I would go to find settings, Qubes Manager, even the dom0 Terminal is just 
gone. So I don't even know how to debug. I've rebooting several times, it keeps happening.



Had you made any changes to the menu system?
Can you check the contents of /etc/xdg/menus/xfce-applications.menu to
make sure you still have a Menu item for System Tools. If you're not
sure just post the contents here.

There was a problem in the past with .desktop files disappearing.
can you make sure that you have .desktop files in
/usr/share/applications ?

unman


There is one consistently reproducible way to destroy the Qubes menu, by 
simply using the built in xfce/other menu editor to reorganize your menu 
entries, if you happen to be the impatient type in trying to get it 
done. I have tried every menu editor I could find, and they all seem to 
do pretty much the same damage.


Example:
1) Right click on the xfce/Qubes menu button.
2) Select properties from the popup menu
3) Select the edit menu button.
4) Select a sub-menu for any VM to edit
5) Select an entry on the right to move an application up/down in the list
6) Press the up or down button quickly in succession, say to move an 
entry from the bottom of the list, up to the top of the list.

7) Save the menu.

Congratulations, you now have no Qubes menu at all, so lets hope you 
still have a dom0 command window open.


To recover the menu, start a template vm via qvm-run, and run dnf to 
update or make any change that in turn forces a dom0 resync of the Qubes 
menu items. Or perhaps you can just force a resync from the dom0 command 
line (qvm-sync-appmenus), but I have not tested that.


I believe (a wild *** guess, base on only visual clues and behavioral 
evidence) the problem is that the editor rewrites a file upon each 
'move' button click, and if you do it too quickly there is a concurrency 
problem with re-opening the menu files that have not yet been 
closed/flushed to disk. They may be reading and updating a partially 
written menu file.


Do the same thing slowly and count-to-3 between mouse clicks, and there 
is no problem. If you can hear your disk drive churning when clicking 
the up/down button, when its quiet again, then it is ok to push the 
button again.


I'm guessing this is an upstream xfce read/write/thread locking problem, 
but the added complexity of the Qubes menu might be the reason for the 
concurrency/timing issue due to more complexity overhead and Xen CPU 
latencies. I'm guessing if you had a very simple xfce menu (e.g. the 
default/simple xfce OS installation), and without Xen overhead, this 
would likely not happen, thus the proper locking had never been 
implemented. I have not yet had the luxury of the time to chase this 
thread, to actually confirm my suspicion, so your mileage may vary. On 
my system this is 100% reproducible.


Bottom line, don't be too quick with changes to the menu, or you will be 
spending even more time repairing your system. The first time this 
happened I had no clue how to recover.



Steve

--
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ca6434a7-3581-9250-8817-89a749f4f294%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.


  1   2   >