Re: [qubes-users] Help Needed - Qubes OS Installation Error with LUKS

[Steve Coleman]

Did you reuse an older partition having a LUKS partition without
"reclaiming" it? In order for you to install using an old LUKS partition
without overwriting a new files stem it would need to know the key, but the
installer may not be set up to ask for it. Just a guess.

On Sat, Sep 23, 2023, 2:33 PM Daniel Samani 
wrote:

> Dear Qubes Community,
>
> I trust this message finds you all in good health. I'm reaching out to
> seek your assistance regarding a perplexing issue that has arisen during my
> Qubes OS installation.
>
> *Issue:*
> During the Qubes OS installation process, I encounter an unexpected
> challenge. After reaching the point where LUKS is created on dev/nvme0n1p4,
> an error occurs with the installation. However, contrary to my
> expectations, I am not prompted to input a passphrase. Instead, I'm
> presented with the following error message:
> "An error occurred while activating your storage configuration: Failed to
> activate device: Incorrect passphrase."
>
> This situation has left me puzzled, as I assumed I would be required to
> enter a passphrase during installation.
>
> I kindly request your guidance and expertise to help me understand and
> resolve this issue. Any insights or suggestions you can provide would be
> greatly appreciated.
>
> As a reference, I've recorded the entire installation process. The error
> appears at approximately 2 minutes and 25 seconds into the recording:
> https://youtu.be/fur5ilL0OYE?feature=shared
>
> Thank you for your valuable assistance in clarifying this matter.
>
> Best regards,
> Daniel Samani
>
> --
> 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/CAOk9u0UtRcTMHuS%3Dk05fJLN3VuVNzmZYGuC9vvxfRvQyME%2Bbtw%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/CAJ5FDniPwKZ8SN%3D8-vroTtPpC6zGoT9K57u1eQqvi8K5cJK%2BuA%40mail.gmail.com.

Re: [qubes-users] "GVFS is not available"

[Steve Coleman]

On Sat, Aug 12, 2023, 12:54 PM  wrote:

> ales...@magenta.de:
> > I am using a fresh installation of Qubes 4.1.1.
> >
> > When I use the File Manager Preferences tab there is a message
> > indicating that GVFS is not available.


You need to install the gvfs package in the template you are using for your
AppVM.

It's not a standard package installed by default because it relies on many
other packages. Do a search in your flavor repository (fedora,debian,etc)
for the package and install it in your template, and then restart your
AppVM.


https://wiki.gnome.org/Projects/gvfs

"Important features including
> > trash support, removable media and remote location browsing will not
> work".
> >
> > I also notice that I cannot use removable storage with any of my VMs, if
> > I attach a storage device to a VM the OS indicates success but the
> > device is not available anywhere.
> >
> > I think part of the problem is probably that I do not have a sys-usb.
> >
> > Can someone help me correct these problems?
> >
>
> Is there no solution to this? I don't want to reinstall the OS because
> it takes some hours to complete and maybe it will make no difference.
>
> Here is more information.
>
> In installation process I made the following selections:
>
> - Templates: Fedora, Debian, Whonix
> - Default system qubes YES
> - sys-firewall, sys-net and sys-usb disposable YES
> - Default application qubes YES
> - Qube to hold all USB controllers YES
> - sys-net qube for both networking and USB devices YES (I am using a USB
> ethernet adapter)
> - Whonix Gateway and Workstation qubes YES
>
> --
> 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/838de6ff-0dc0-c4de-5bb1-3cb7a2350f17%40magenta.de
> .
>

-- 
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/CAJ5FDnixsp%3DYYDyVMpNSzHchhF5RtS05%2BE8RTtc0VC3qB-nJPw%40mail.gmail.com.

Re: [qubes-users] Template for X?

[Steve Coleman]

On Sat, Apr 29, 2023, 4:53 AM Sandy Harris  wrote:

> Is there a template to make a qube that just runs as an X terminal?
>

If you turn on Qubes debugging for any AppVM it will start within a
terminal window with a command line interface. If that AppVM has X
installed you should still be able to start other apps that will appear in
their own window.

Is this what you are looking for?

-- 
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/CAJ5FDngZpbkSRrY-at8S7082xbfFAqX_ML3XGQ%2B7mAg9dEyYWA%40mail.gmail.com.

Re: [qubes-users] Qubes Contrib repository

[Steve Coleman]

On Sun, Aug 21, 2022 at 10:29 AM 'unman' via qubes-users <
qubes-users@googlegroups.com> wrote:

> On Sat, Aug 13, 2022 at 10:02:15PM +0200, Qubes wrote:
>
> qubes-dom0-update --repo=qubes-contrib-dom0-r4.1-current --action=list
>
Q1: Is there any way to list these in a way that can actually be copied to
the clipboard from the sys-firewall xterm?

Using ctrl-c to copy something just closes the window and there is no menu
bar for a copy/paste operation.

Q2: Is there a configuration to get sys-firewall add the menu bar back to
this dynamically opened xterm?

On my system this command lists the packages in a completely unreadable
color, which is why I wanted to copy it, so I could then paste it into
something that would strip the awful color from the list so I could
actually read it. I'm assuming there is a terminal configuration that
controls these default window attributes?

Q3: Or change the color for this xterm so I can actually read what I need
to type into the next command, if I found something I wanted to install?

A way to enlarge the width of the terminal to prevent the text from
wrapping around would also be a help.

thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAJ5FDnir-GW51KZjo%2BhacKudWE3%3D84GuTvYjx_v9p8%3DRdg7Oqw%40mail.gmail.com.

Re: [qubes-users] Fedora rpmfusion repos

[Steve Coleman]

On Mon, Aug 1, 2022, 9:27 AM Qubes  wrote:

> Qubes wrote:
> > Is the documentation on this [page] to enable the rpmfusion repos still
> > relevant?
> >
> > Doing "sudo dnf config-manager --set-enabled rpmfusion-free", gives me
> > an error, "Error: No matching repo to modify: rpmfusion-free".
> >
>
> This appears to be specific to the Fedora-xx-minimal template. I don't
> know why, can someone give me a pointer?
>

Fedora minimal will not include the rpmfusion-*.repo file/repo because it's
supposed to be "minimal" while the rpmfusion are "extras". You can of
course copy the rpmfusion-*.repo files over to your minimal template if you
like. You can find these files in this path in the normal fedora template:

/etc/yum.repos.d/rpmfusion-free.repo

They are generally disabled so that including them by mistake is not a
security risk. Anything in the rpmfusion repository generally carries more
risk because it is less vetted than the normal fedora repository.

>
>

-- 
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/CAJ5FDnhbCstW6U1oVFbrsnUvkE-_Bd933gLjgVxV%2BoahjVnuTQ%40mail.gmail.com.

Re: [qubes-users] Problems with announced Fedora 35 templates

[Steve Coleman]

On 6/12/22 12:35, Viktor Ransmayr wrote:

Hello Demi,

Am So., 12. Juni 2022 um 18:18 Uhr schrieb Demi Marie Obenour 
:


> > What is the contents of /etc/yum.repos.d in your fedora-34
template?
> > You might have repositories pointing at the R4.0 repos.
>
> Here's the content:
>
>     [user@fedora-34 ~]$
>     [user@fedora-34 ~]$ cd /etc/yum.repos.d
>     [user@fedora-34 yum.repos.d]$ ls -all
>     total 68
>     drwxr-xr-x   2 root root  4096 May 20 21:05 .
>     drwxr-xr-x 114 root root 12288 Jun 12 17:11 ..
>     -rw-r--r--   1 root root   183 Oct  2  2021
adobe-linux-x86_64.repo
>     -rw-r--r--   1 root root   728 Apr 28  2021
fedora-cisco-openh264.repo
>     -rw-r--r--   1 root root  1344 Apr 28  2021
fedora-updates-testing.repo
>     -rw-r--r--   1 root root  1286 Apr 28  2021 fedora-updates.repo
>     -rw-r--r--   1 root root  1239 Apr 28  2021 fedora.repo
>     -rw-r--r--   1 root root   191 Oct  2  2021 google-chrome.repo
>     -rw-r--r--   1 root root  1483 May  5 02:00 qubes-r4.repo
>     -rw-r--r--   1 root root  1324 Oct  2  2021
> rpmfusion-free-updates-testing.repo
>     -rw-r--r--   1 root root  1264 Oct  2  2021
rpmfusion-free-updates.repo
>     -rw-r--r--   1 root root  1248 Oct  2  2021 rpmfusion-free.repo
>     -rw-r--r--   1 root root  1369 Oct  2  2021
> rpmfusion-nonfree-updates-testing.repo
>     -rw-r--r--   1 root root  1309 Oct  2  2021
> rpmfusion-nonfree-updates.repo
>     -rw-r--r--   1 root root  1312 Oct  2  2021
rpmfusion-nonfree.repo
>     [user@fedora-34 yum.repos.d]$
>
> With kind regards,

Can you check that qubes-r4.repo points to the R4.1 repository and not
the R4.0 repository?  The symptoms you are describing are consistent
with it pointing to the R4.0 repository.


Here's the content of this file:

[user@fedora-34 yum.repos.d]$
[user@fedora-34 ~]$ cd /etc/yum.repos.d
[user@fedora-34 yum.repos.d]$ cat qubes-r4.repo
[qubes-vm-r4.0-current]
name = Qubes OS Repository for VM (updates)
baseurl = https://yum.qubes-os.org/r4.0/current/vm/fc$releasever
#baseurl = 
http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.0/current/vm/fc$releasever

gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-primary
skip_if_unavailable=False
gpgcheck = 1
enabled=1

[qubes-vm-r4.0-current-testing]
name = Qubes OS Repository for VM (updates-testing)
baseurl = https://yum.qubes-os.org/r4.0/current-testing/vm/fc$releasever
#baseurl = 
http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.0/current-testing/vm/fc$releasever

gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-primary
skip_if_unavailable=False
gpgcheck = 1
enabled=0

[qubes-vm-r4.0-security-testing]
name = Qubes OS Repository for VM (security-testing)
baseurl = https://yum.qubes-os.org/r4.0/security-testing/vm/fc$releasever
#baseurl = 
http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.0/security-testing/vm/fc$releasever

gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-primary
skip_if_unavailable=False
gpgcheck = 1
enabled=0

[qubes-vm-r4.0-unstable]
name = Qubes OS Repository for VM (unstable)
baseurl = https://yum.qubes-os.org/r4.0/unstable/vm/fc$releasever
#baseurl = 
http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.0/unstable/vm/fc$releasever

gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-unstable
gpgcheck = 1
enabled=0

[user@fedora-34 yum.repos.d]$

You were right - but - I have no clue what went wrong & what to do 
next ...


With kind regards,


It looks to me like your template is a 4.0 Template regardless of the 
fedora revision.


Here is what I would do:

1) Download a R4.1 fedora-35 template rpm here:

https://ftp.qubes-os.org/repo/yum/r4.1/templates-itl/rpm/qubes-template-fedora-35-4.0.6-202205081759.noarch.rpm

2) The rpm needs to be moved someplace where dom0 can install it.

3) dom0> sudo dnf install /path/to/template.rpm

    or sudo rpm -i /path/to/template.rpm

4) Update the template first to get all the current security patches

5) switch sys-firewall to use the new template and restart sys-firewall

6) Then use qvm-template to retrieve any other templates you need for 
R4.1 usage.


--
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/9e7205eb-7f17-676b-e623-42838adc73a0%40gmail.com.

Re: [qubes-users] Problems with announced Fedora 35 templates

[Steve Coleman]

On Thursday, June 9, 2022 at 1:10:45 AM UTC-4 viktor@gmail.com wrote:

> Hello Qubes Community,
>
>
> Here's the content of /etc/qubes-rpc/ :
>>
>> [user@sys-firewall ~]$ cd /etc/qubes-rpc/
>> [user@sys-firewall qubes-rpc]$ ls
>> qubes.Backup qubes.PdfConvertqubes.SuspendPostAll
>> qubes.ConnectTCP qubes.PostInstall   qubes.SuspendPre
>> qubes.DetachPciDevicequbes.ResizeDiskqubes.SuspendPreAll
>> qubes.Filecopy   qubes.Restore   qubes.USB
>> qubes.GetAppmenusqubes.SaltLinuxVM   qubes.USBAttach
>> qubes.GetDatequbes.SelectDirectory   qubes.USBDetach
>> qubes.GetImageRGBA   qubes.SelectFilequbes.UpdatesProxy
>> qubes.Gpgqubes.SetDateTime   qubes.VMRootShell
>> qubes.GpgImportKey   qubes.SetMonitorLayout  qubes.VMShell
>> qubes.InstallUpdatesGUI  qubes.ShowInTerminalqubes.WaitForSession
>> qubes.OpenInVM   qubes.StartApp
>> qubes.OpenURLqubes.SuspendPost
>> [user@sys-firewall qubes-rpc]$ 
>>
>
> With Fedora 34 having reached EOL now, is there anything else I can do, 
> other than a complete new installation of Qubes OS R4.1 ? 
>
>
Sorry for not replying for a while but somehow I had been blacklisted from 
posting to the forum. Still not sure why that happened. I did reply by 
email but that bounced with a forum gateway denial response. I could login 
to the forum but it would not let me reply to anything. Other Discourse 
forums were also giving me problems so its possible somebody was spamming 
using my email address and thus put me on some kind of global blacklist, 
but that is just a guess.

It looks to me that your current sys-firewall template is not up to date 
for your current R4.1 version, or just broken. If you have any other 
templates on your system (e.g. debian-11, fc35-minimal, fc35-xfce )  you 
might want to try switching sys-firewall to something else and then try to 
use qvm-template to download a working template of the f35 flavor. If that 
does not work you might try to just download a new template manually from 
here:

https://yum.qubes-os.org/r4.1/templates-itl/rpm/

If needed, you will need to move that rpm to media accessible to your dom0 
for the local rpm utility install. Once that template is installed, update 
the template asap, and then you should switch your sys-firewall to use that 
template and then try qvm-template again. Once sys-firewall has an 
up-to-date and working template this problem should be resolved. 

btw - I learned this the hard way myself years ago (R3.1 days) and now I 
always keep an extra unmodified template around for emergencies such as 
this. I also use a different and more simplified template tailored 
explicitly for both sys-net and sys-firewall so that future updates are 
less likely to break my connectivity. If anything happens to my 
connectivity I can just switch one or both VM's to use that alternate 
template while I debug the problem. 

When migrating to Qubes R4.1 I also had a similar problem after restoring 
my old templates from backup onto the new Qubes R4.1 system. The old 
templates did not work correctly with the new system so I needed to get a 
pristine fc35 template to get things working while I upgraded my older fc34 
templates in place. Mixing the two on the new system was just a 
can-of-worms and updating them all in place to f35 is advisable rather than 
leaving them around as fc34 in a broken state. If your customizations to 
your fc34 template was minimal then making a clean break to fc35 is likely 
a very good idea.  

I 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/d4a863a6-09bb-4f71-92a2-6ebea4c2bd49n%40googlegroups.com.

Re: [qubes-users] Problems with announced Fedora 35 templates

[Steve Coleman]

On Sun, May 29, 2022 at 4:39 AM Viktor Ransmayr 
wrote:

> Hello slcoleman,
>
> stevenlc...@gmail.com schrieb am Samstag, 28. Mai 2022 um 21:54:40 UTC+2:
>
>>
>>
>> Thanks for your quick reply!
>
> However, when I try to list the available templates using the
> 'qvm-template' command, I get the same error message:
>
> [vr@dom0 ~]$ qvm-template list
> [Qrexec] /bin/sh: /etc/qubes-rpc/qubes.TemplateSearch: No such file or
> directory
> ERROR: qrexec call 'qubes.TemplateSearch' failed.
> [vr@dom0 ~]$
>
>
>
I just checked my own system and ran a python3 trace on the command. The
file  /etc/qubes-rpc/qubes.TemplateSearch should be on the sys-firewall ,
assuming the default configuration. If you use a different OS or changed
your "Dom0 update qube" in the "Global Settings" for dom0 updates then that
update VM may not have this file installed. I would start by looking
there.

> --
> 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/e401d5aa-3837-4beb-bd23-1e8dcc6853b8n%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/CAJ5FDngmmAH_8vVfnzvAR4Uiyxy0GfxiSZ6Hymn1dDR3%3DK3NRA%40mail.gmail.com.

Re: [qubes-users] Problems with announced Fedora 35 templates

[Steve Coleman]

On Sat, May 28, 2022, 3:28 PM Viktor Ransmayr 
wrote:

> Hello Qubes Community,
>
> I run into a problem already in the very first step of the standard
> installation method:
>
> If I perform "sudo qubes-dom0-update qubes-template-fedora-35" in a 'dom0'
> terminal, I receive the following error msg:
>
> [vr@dom0 ~]$ sudo qubes-dom0-update qubes-template-fedora-35
> Redirecting to 'qvm-template install  fedora-35'
> [Qrexec] /bin/sh: /etc/qubes-rpc/qubes.TemplateSearch: No such file or
> directory
> ERROR: qrexec call 'qubes.TemplateSearch' failed.
> [vr@dom0 ~]$
>
> My Qubes R4.1 system so far had two 'dom0' updates, which successfully
> finished using the Qubes Updater ...
>
> If I try it manually, I always receive the following feedback:
>
> [vr@dom0 ~]$
> [vr@dom0 ~]$ sudo qubes-dom0-update
> Using sys-firewall as UpdateVM to download updates for Dom0; this may take
> some time...
> No updates available
> [vr@dom0 ~]$
>
> Any ideas on why the template is not found - and - what I should
> additionally check on my system?
>
> With kind regards,
>
> Viktor
>

I reported a similar problem a few days ago. At the time the f35 templates
were not appearing on some indexes and the devs were looking into it.

I just used a browser to download the rpm's from itl and installed them
locally.

Note : You should be using qvm-template command with R4.1, which is why the
forwarding message.

> --
>
>

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

Re: [EXT] [qubes-users] Re: Qubes OS 4.1-rc3 has been released!

[Steve Coleman]

On Mon, Jan 10, 2022, 11:15 AM 'awokd' via qubes-users <
qubes-users@googlegroups.com> wrote:

> Scat:
>
> > TPM: Device not found <---Is this Anti-Evil Maid" ?
>
> Yes.
>
> VT-D settings look OK. Qubes will warn on install if something required
> is missing.
>

Anybody try using a vTPM or TPM Simulator with Qubes?

My machine came with a "software TPM" which only works under Windows
apparently. I had previously looked at Xen vTPM but somehow could not
manage to get it to work under Qubes. I can't be the only one out there
without a TPM, so I just wanted to ask if anyone else had looked into a
virtual/software replacement yet.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAJ5FDniV4zk7ETMEW5B5AMDVfYE7NjU_6iCXW2f3yk-uk9W-uQ%40mail.gmail.com.

Re: [qubes-users] Systemd terminating qubesd during backup?

[Steve Coleman]

On 10/11/21 14:07, Rusty Bird wrote:

Steve Coleman:
> I seem to have an intermittent problem when my backup scripts are 
running

> late at night.

> My qubesd is apparently being shutdown (sent a sigterm signal) by 
systemd
> during my long running backup sessions which then causes an eof pipe 
close
> exception and qvm-backup then receives a socket exception and 
immediately
> receives a second exception while still handling the first 
exception, thus
> the qvm-backup process gets forcibly terminated mid stream. Just 
prior to

> the qubesd shutdown I can clearly see that systemd had also
> shutdown/restarted the qubes memory manager (qubes-qmemman) too.

> Q: What kind of background maintenance processing would actually require
> qubesd or the memory manager to be restarted?

It's crond running logrotate. Fixed in R4.1 but not yet in R4.0:
https://github.com/QubesOS/qubes-issues/issues/5004

> Q: Could this processing be put on hold during backups?

I always sandwich backup runs between 'systemctl stop crond' and
'systemctl start crond'.


Great!

I was hoping for an answer like that. In my case the system will be 
shutting down after the unattended backup completes, so this is actually 
twice as easy!


thanks!


Rusty

>


--
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/d1528316-5e0e-9052-2f43-952c91559fcb%40gmail.com.

[qubes-users] Systemd terminating qubesd during backup?

[Steve Coleman]

I seem to have an intermittent problem when my backup scripts are 
running late at night.


My qubesd is apparently being shutdown (sent a sigterm signal) by 
systemd during my long running backup sessions which then causes an eof 
pipe close exception and qvm-backup then receives a socket exception and 
immediately receives a second exception while still handling the first 
exception, thus the qvm-backup process gets forcibly terminated mid 
stream. Just prior to the qubesd shutdown I can clearly see that systemd 
had also shutdown/restarted the qubes memory manager (qubes-qmemman) too.


Q: What kind of background maintenance processing would actually require 
qubesd or the memory manager to be restarted?


Q: Could this processing be put on hold during backups?

Q: Or, how could I at least know when this maintenance is scheduled to 
happen so I could defer my own processing?


My scripts can certainly trap this error, erase the incomplete backup 
file, then loop and check for qubesd to complete its restart, and then 
finally restart my own backup processing, but why should this even be 
necessary?


When this happens its almost always during the backup of my largest VM 
which can take well over 90 minutes to complete.  If I can somehow 
block/defer this kind of system maintenance until after my backups are 
complete that would be better than having to deal with trapping random 
restarts.


thanks,

Steve

Sorry for the amount of text below but googlegroups would not let me 
send this as *.txt attachments:


qvm-backup error:

Making a backup... 56.28%
Connection to qubesd terminated, reconnecting in 1.0 seconds

Backup error: Got empty response from qubesd. See journalctl in dom0 for 
details.


Traceback (most recent call last):
  File "/usr/lib/python3.5/site-packages/qubesadmin/app.py", line 580, 
in qubesd_call

    client_socket.connect(qubesadmin.config.QUBESD_SOCKET)
FileNotFoundError: [Errno 2] No such file or directory

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/qvm-run", line 5, in 
    sys.exit(main())
  File "/usr/lib/python3.5/site-packages/qubesadmin/tools/qvm_run.py", 
line 199, in main

    args = parser.parse_args(args, app=app)
  File "/usr/lib/python3.5/site-packages/qubesadmin/tools/__init__.py", 
line 384, in parse_args

    action.parse_qubes_app(self, namespace)
  File "/usr/lib/python3.5/site-packages/qubesadmin/tools/__init__.py", 
line 170, in parse_qubes_app

    namespace.domains += [app.domains[vm_name]]
  File "/usr/lib/python3.5/site-packages/qubesadmin/app.py", line 91, 
in __getitem__

    if not self.app.blind_mode and item not in self:
  File "/usr/lib/python3.5/site-packages/qubesadmin/app.py", line 114, 
in __contains__

    self.refresh_cache()
  File "/usr/lib/python3.5/site-packages/qubesadmin/app.py", line 63, 
in refresh_cache

    'admin.vm.List'
  File "/usr/lib/python3.5/site-packages/qubesadmin/app.py", line 583, 
in qubesd_call

    'Failed to connect to qubesd service: %s', str(e))
qubesadmin.exc.QubesDaemonCommunicationError: Failed to connect to 
qubesd service: [Errno 2] No such file or directory



journalctl output:
Oct 11 03:15:02 dom0 systemd[1]: Stopping Qubes memory management daemon...
Oct 11 03:15:02 dom0 systemd[1]: Stopped Qubes memory management daemon.
Oct 11 03:15:02 dom0 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=qubes-qmemman comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 11 03:15:02 dom0 kernel: audit: type=1131 audit(1633936502.556:250): 
pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=qubes-qmemman 
comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? 
terminal=? res=success'

Oct 11 03:15:02 dom0 systemd[1]: Starting Qubes memory management daemon...
Oct 11 03:15:07 dom0 qmemman.daemon[18836]: MIN_PREFMEM=199229440 
DOM0_MEM_BOOST=349175808 CACHE_FACTOR=1.3

Oct 11 03:15:07 dom0 systemd[1]: Started Qubes memory management daemon.
Oct 11 03:15:07 dom0 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=qubes-qmemman comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 11 03:15:07 dom0 kernel: audit: type=1130 audit(1633936507.784:251): 
pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=qubes-qmemman 
comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? 
terminal=? res=success'
Oct 11 03:15:07 dom0 qmemman.daemon.algo[18836]: 
balance_when_enough_memory(xen_free_memory=53353416961, 
total_mem_pref=0, total_available_memory=53353416961)
Oct 11 03:15:07 dom0 qmemman.systemstate[18836]: stat: 
xenfree=53405845761 memset_reqs=[]
Oct 11 03:15:07 dom0 qmemman.daemon.algo[18836]: 
balance_when_enough_memory(xen_free_memory=5

Re: [qubes-users] Unable to install templates in Qubes OS 4.1beta

[Steve Coleman]

On 10/11/21 15:55, 799 wrote:


... but if I try install via:
[user@dom0 ~]$ sudo qubes-dom0-update qubes-template-fedora-33

... I can see that it will download the package but I get:

Using sys-net as UpdateVM to download updates for Dom0; this may take 
some time...
Last metadata expiration check: -1 day, 21:47:12 ago on Mon 11 Oct 
2021 05:49:33 PM CEST.

No match for argument: qubes-template-fedora-33
Error: Unable to find a match: qubes-template-fedora-33

Any idea where I can look for the root cause as I am a bit desparate.


Just a guess here. Is it possible that sys-net is running out of disk 
space from the download and has the matching problem because it wasn't 
physically downloaded?


In any case you might try cleaning the cache with the --clean option and 
then rerunning the download/install.


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6a480f40-df36-42bc-d0c5-26bfa9c19176%40gmail.com.

[qubes-users] Systemd terminating qubesd during backup?

[Steve Coleman]

I seem to have an intermittent problem when my backup scripts are 
running late at night.


My qubesd is apparently being shutdown (sent a sigterm signal) by 
systemd during my long running backup sessions which then causes an eof 
pipe close exception and qvm-backup then receives a socket exception and 
immediately receives a second exception while still handling the first 
exception, thus the qvm-backup process gets forcibly terminated mid 
stream. Just prior to the qubesd shutdown I can clearly see that systemd 
had also shutdown/restarted the qubes memory manager (qubes-qmemman) too.


Q: What kind of background maintenance processing would actually require 
qubesd or the memory manager to be restarted?


Q: Could this processing be put on hold during backups?

Q: Or, how could I at least know when this maintenance is scheduled to 
happen so I could defer my own processing?


My scripts can certainly trap this error, erase the incomplete backup 
file, then loop and check for qubesd to complete its restart, and then 
finally restart my own backup processing, but why should this even be 
necessary?


When this happens its almost always during the backup of my largest VM 
which can take well over 90 minutes to complete.  If I can somehow 
block/defer this kind of system maintenance until after my backups are 
complete that would be better than having to deal with trapping random 
restarts.


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/4fb6c085-4491-c67a-a940-98cca1f89c7c%40gmail.com.
Making a backup... 56.28%
Connection to qubesd terminated, reconnecting in 1.0 seconds

Backup error: Got empty response from qubesd. See journalctl in dom0 for 
details.

Traceback (most recent call last):
  File "/usr/lib/python3.5/site-packages/qubesadmin/app.py", line 580, in 
qubesd_call
client_socket.connect(qubesadmin.config.QUBESD_SOCKET)
FileNotFoundError: [Errno 2] No such file or directory

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/qvm-run", line 5, in 
sys.exit(main())
  File "/usr/lib/python3.5/site-packages/qubesadmin/tools/qvm_run.py", line 
199, in main
args = parser.parse_args(args, app=app)
  File "/usr/lib/python3.5/site-packages/qubesadmin/tools/__init__.py", line 
384, in parse_args
action.parse_qubes_app(self, namespace)
  File "/usr/lib/python3.5/site-packages/qubesadmin/tools/__init__.py", line 
170, in parse_qubes_app
namespace.domains += [app.domains[vm_name]]
  File "/usr/lib/python3.5/site-packages/qubesadmin/app.py", line 91, in 
__getitem__
if not self.app.blind_mode and item not in self:
  File "/usr/lib/python3.5/site-packages/qubesadmin/app.py", line 114, in 
__contains__
self.refresh_cache()
  File "/usr/lib/python3.5/site-packages/qubesadmin/app.py", line 63, in 
refresh_cache
'admin.vm.List'
  File "/usr/lib/python3.5/site-packages/qubesadmin/app.py", line 583, in 
qubesd_call
'Failed to connect to qubesd service: %s', str(e))
qubesadmin.exc.QubesDaemonCommunicationError: Failed to connect to qubesd 
service: [Errno 2] No such file or directory





Oct 11 03:15:02 dom0 systemd[1]: Stopping Qubes memory management daemon...
Oct 11 03:15:02 dom0 systemd[1]: Stopped Qubes memory management daemon.
Oct 11 03:15:02 dom0 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=qubes-qmemman comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 11 03:15:02 dom0 kernel: audit: type=1131 audit(1633936502.556:250): pid=1 
uid=0 auid=4294967295 ses=4294967295 msg='unit=qubes-qmemman comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 11 03:15:02 dom0 systemd[1]: Starting Qubes memory management daemon...
Oct 11 03:15:07 dom0 qmemman.daemon[18836]: MIN_PREFMEM=199229440 
DOM0_MEM_BOOST=349175808 CACHE_FACTOR=1.3
Oct 11 03:15:07 dom0 systemd[1]: Started Qubes memory management daemon.
Oct 11 03:15:07 dom0 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=qubes-qmemman comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 11 03:15:07 dom0 kernel: audit: type=1130 audit(1633936507.784:251): pid=1 
uid=0 auid=4294967295 ses=4294967295 msg='unit=qubes-qmemman comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 11 03:15:07 dom0 qmemman.daemon.algo[18836]: 
balance_when_enough_memory(xen_free_memory=53353416961, total_mem_pr

[qubes-users] HCL -Lenovo Thinkpad L15 i3- Type 20U3

[Steve]

Absolutely everything seems to be working flawlessly, only had to 
disable strict reset for network card


--
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/008c47b1-0da0-e004-2803-215bcef841de%40gmail.com.


Qubes-HCL-LENOVO-20U3S04200-20210702-195512.yml
Description: application/yaml

Re: [qubes-users] Networking with debian10-minimal instead of fedora-33

[Steve Coleman]

On Wed, Jun 30, 2021, 10:55 AM 'taran1s' via qubes-users <
qubes-users@googlegroups.com> wrote:

> Hi, I am trying to make work the sys-net and sys-firewall under
> debian-10-minimal template, instead of fedora-33, but without success.
> Fedora is annoying with its updates and also I would like to decrease
> the exposure to the complexity of fedora-33 full template wherever
> possible.
>

I don't have any suggestion for the Debian issue, but what I do to limit
the updates is clone the fedora-33-minimal to a template called
fedora-33-net, strip out any apps not needed, and then use that for my
networking AppVM's. With fewer apps there are far fewer updates to deal
with.

-- 
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/CAJ5FDniF2%3DUBoyKTd0WBwPJ%2BiX%2BY%3Dcni5KeSonnGjfwKkxJFKQ%40mail.gmail.com.

Re: [qubes-users] Trying to create an OSINT VM with Qubes Fedora template: Need help getting pip to work

[Steve Coleman]

On Mon, Jun 7, 2021, 11:36 AM Chrome  wrote:

>  For one, I'm not installing chrome anytime soon. I'll try to stick to
> open source,
>

There are times when Firefox doesn't want to play nice with some websites,
and trying an alternative browser can help identify those issues. When that
happens I try the Chromium browser which is essentially the Google browser
sourcecode but compiled as to leave out the intrusive Google spying
features. It is open source so the only question is do you trust that the
people maintaining this browser to have left out enough. While I will not
use it as my primary browser I do sometimes use it for testing purposes. I
have found that it generally works well for media files and scripts that
firefox may refuse to run 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/CAJ5FDniYGV5%2Br5-BatENyW-hqVHWHCarf8SX78EHRnEz_Y41rw%40mail.gmail.com.

Re: [qubes-users] Trying to create an OSINT VM with Qubes Fedora template: Need help getting pip to work

[Steve Coleman]

On 6/6/21 2:12 PM, Chrome wrote:

Hello there all,

I am currently following the instructions to create an OSINT VM 
Michael Bazzell's "Open Source Intelligence Techniques 8th Edition."
Its a good book. I do wish he had a chapter for Qubes in it. I think the 
only reason Michael doesn't push Qubes as a platform is that it has a 
steep learning curve that not many are willing to take on. If you do 
Qubes anyway and the learning curve is Ok, then you will find Qubes to 
be a much more flexible platform in the long run.
Naturally I'm trying to avoid installing a whole new OS (Ubuntu is 
recommended by the author) or to have a dedicated laptop for this. I 
figured it would be a fun experiment to see how far I could get with 
Qubes before I ran into problems.


All the way I'm sure.

So far, issues are minor but when I hit a roadblock, like the below 
terminal text, I'm ill-prepared to troubleshoot it myself. Can someone 
help me understand what I'm looking at and how to fix it so I can 
install packages via pip onto my Fedora templateVM? Thank you


First templates do not have network access by default so you may need a 
proxy setup.


https://qubes-os.discourse.group/t/when-to-assign-templatevms-a-network-connection/4307/2

By default pip needs/wants to install directly into the system space 
(/usr/local/) which on a template is not shared with the AppVM. Because 
this directory is not even presented to an AppVM file system it wont be 
useable in the AppVM. It would need to be installed in the AppVM itself 
if you want it installed in /usr/local.


The problem is, security wise, its a bad idea to run foreign code (pip's 
package installer scripts) as root in a template. You could easily 
compromise every AppVM on the system by introducing malicious code. That 
is way pip was warning about running as root.


But if you use the "--user" flag as the error message says then pip can 
install the packages an AppVM with everything installed into the user's 
home directory. That way the user has control over the env and can 
choose which environment they want to use.


If you were wanting to have the ability to start from a pristine 
starting point for each user session then you might want to either to 
create a dvm or create a default AppVM which can be cloned as often as 
you like.



Relevant Terminal text:
[user@fedora-32 ~]$ sudo -H python3 -m pip install instalooter


https://stackoverflow.com/questions/42988977/what-is-the-purpose-of-pip-install-user

$ sudo -H python3 -m pip install --user instalooter

The above will install in the users directory instead

WARNING: Running pip install with root privileges is generally not a 
good idea. Try `python3 -m pip install --user` 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/e65162b1-bb72-9ee8-777e-17a146fcb96c%40gmail.com.

Re: [EXT] [qubes-users] MS Office 365 in Qubes

[Steve Coleman]

On Wed, May 26, 2021, 5:21 PM William Oliver  wrote:

> On Wed, 2021-05-26 at 15:53 +0200, Ulrich Windl wrote:
> >
> >
> > Office 365 _without_ MS-Windows? Are you kidding? Maybe Microsoft
> > provides it for other platforms, but _why_ would one use the
> > Microsoft
> > product? (I'm using OpenOffice/LibreOffice for years, and it's OK for
> > me)
>
> Normally, I create the presentation in LibreOffice and then take it to
> a place that runs Windows at work and fix the presentation there.  I
> retired from my normal job recently, so I can't do that any more, even
> though I still do presentations.  At the moment, my church is letting
> me use their computers for this, but I don't know that it will go on
> forever.
>

It may not address your immediate needs but the "Microsoft Nonprofit"
program can provide 10 free Office365 licenses for 10 years to any
qualifying nonprofit organization. If you got your church to qualify then
maybe they will set you up with a license? MS also allows unlimited binary
installs (PC, iOS, Android, etc) for each individuals assigned license plus
some discounts on the Win10 OS you could use as an AppVM. There is also
TechSoup.org which provides discounted software and refurbished hardware to
qualifying nonprofits.

I am also battling with the Office365 products on Qubes. If you want to
have  discussion off line please do not hesitate to reach out to me. I know
about the MS NonProfit  program because I have my own startup 501(c)(3) (
hdri.org) for doing medical research on a long ignored disease that has no
test, no cure, no statistics collected because nobody ever gets diagnosed,
and so currently it will never be funded for any research in humans. Your
dog can be easily tested and cured but you would likely get kicked out of
the clinic or ignored for even suggesting you might have this very same
disease. It's being treated exactly the same as Lyme disease was back on
the 60's. Will they ever learn?

Sorry for the tangential off topic discussion.

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

Re: [EXT] Re: [qubes-users] Re: Fedora 32 approaching EOL

[Steve Coleman]

On Wed, May 26, 2021, 9:45 AM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> On 5/13/21 2:36 AM, Steve Coleman wrote:
> >
> >
> > On Wed, May 12, 2021, 5:52 PM Ulrich Windl
> >  > <mailto:ulrich.wi...@rz.uni-regensburg.de>> wrote:
> >
> > On 4/30/21 1:31 AM, Andrew David Wong wrote:
> >  > Dear Qubes Community,
> >  >
> >  > Fedora 32 is scheduled to reach EOL (end-of-life [1]) on
> 2021-05-25.
> >
> > I have a question on
> > https://www.qubes-os.org/doc/template/fedora/upgrade/
> > <https://www.qubes-os.org/doc/template/fedora/upgrade/>:
> >
> > Towards the end of the update procedure "Detailed instructions for
> > standard Fedora TemplateVMs" there is the command
> > [user@dom0 ~]$ sudo dnf remove qubes-template-fedora-
> >
> > However I wonder: I did not install a fedora- template per
> > instructions, and I wonder about this asymmetry.
> >
> >
> > When you installed Qubes the default templates were installed for you.
> > Because the fedora-32 came onto your system as an rpm it can only be
> > removed by removing that rpm. To remove it, if you wish, you need to
> > change all AppVMs to use some other template, to remove any qubes
> > dependencies, then you remove the rpm.
> >
> > If you want to see all the default rpm templates you can do: "dom0> rpm
> > -qa | grep qubes-template". Those templates need to be removed via dnf
>
> "rpm -qa qubes-template\*" might be a bit more efficient. ;-)
>
> > or rpm rather than just deleting it from the qube-manager or the qvm-*
> > command line tool. When you clone a template it will not have an rpm
> > file associated with it, so it can be removed easily using qube-manager.
> >
> > I always clone all the rpm templates then remove the rpm's, and then
> > rename the clones to the name I actually want. If I ever need a fresh
> > copy I can always reinstall the rpm and clone it to start over.
>
> So cloning actually duplicates the rpm-installed template so it's safe
> to remove the RPM package afterwards?
>

Yes, it's safe. There are no rpm dependencies to prevent it's removal. You
just need to be sure no AppVM anywhere on your system is currently using
it. As long as no templates exist using the default name it's simple to
reinstall from rpm to grab a pristine unmodified copy whenever you need one.

Cloning it merely copies the template contents to a new template name that
is not controlled by any rpm. The new clone can be backed up and restored
like any normal vm and can be quickly removed as long as it has no Qubes
AppVM dependencies using 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/CAJ5FDnjwY8tgWtsbgYPOiMimd529teSgsz_PgW7f6%3Doh4GfXUQ%40mail.gmail.com.

Re: [qubes-users] Re: Fedora 32 approaching EOL

[Steve Coleman]

On Wed, May 12, 2021, 5:52 PM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> On 4/30/21 1:31 AM, Andrew David Wong wrote:
> > Dear Qubes Community,
> >
> > Fedora 32 is scheduled to reach EOL (end-of-life [1]) on 2021-05-25.
>
> I have a question on https://www.qubes-os.org/doc/template/fedora/upgrade/
> :
>
> Towards the end of the update procedure "Detailed instructions for
> standard Fedora TemplateVMs" there is the command
> [user@dom0 ~]$ sudo dnf remove qubes-template-fedora-
>
> However I wonder: I did not install a fedora- template per
> instructions, and I wonder about this asymmetry.


When you installed Qubes the default templates were installed for you.
Because the fedora-32 came onto your system as an rpm it can only be
removed by removing that rpm. To remove it, if you wish, you need to change
all AppVMs to use some other template, to remove any qubes dependencies,
then you remove the rpm.

If you want to see all the default rpm templates you can do: "dom0> rpm -qa
| grep qubes-template". Those templates need to be removed via dnf or rpm
rather than just deleting it from the qube-manager or the qvm-* command
line tool. When you clone a template it will not have an rpm file
associated with it, so it can be removed easily using qube-manager.

I always clone all the rpm templates then remove the rpm's, and then rename
the clones to the name I actually want. If I ever need a fresh copy I can
always reinstall the rpm and clone it to start over.

-- 
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/CAJ5FDngFUjOQKS4nVAVLLVb-3ULJj1RyQOupXgi-BdYY%3D8u0bQ%40mail.gmail.com.

Re: [qubes-users] detect tcp/ip connections of executables due to qubes firewall restrictions

[Steve Coleman]

On Mon, May 10, 2021, 2:57 PM 'awokd' via qubes-users <
qubes-users@googlegroups.com> wrote:

> lik...@gmx.de:
> > Hi!
> >
> > Due to the current implementation/design of qubes firewall, it's hard to
> use domain names for firewall rules, because of "static" DNS resolution:
> > https://github.com/QubesOS/qubes-issues/issues/5225
> >
> > To find out the "connection wishes/tries" of an executable, what's the
> recommendation to use them for firewall rules?
> >   1.  Let's assume all network access except DNS is restricted from
> a AppVM. How can I find out which domains/IPs which executable is trying to
> use/connect to?
> >   2. What are you're best practices to find out all IPs for a domain
> to white list them?
> >
> > Best, P
> >
> 1. netstat -pan, and/or tcpdump from somewhere networking isn't blocked.
> Might have to watch DNS requests to see what it's attempting to resolve.
> Don't know of a way to do it with networking disabled.
>

At one point in the past I was running  Boinc and Thunderbird in network
restricted AppVMs. The sys-firewall was set to the default deny mode so
that I could prevent connections to anywhere except the specific  servers I
gave it permissions to. I had a python script that ran tcpdump in a pipe
and read the output and then auto-generated the qubes firewall commands
needed to open the firewall, but I manually chose which addtesses to
actually allow.

When the firewall blocks a packet it sends a specific ICMP packet back to
the AppVM containing the address/port that was blocked. I simply filtered
for and read those packets from tcpdump and printed the appropriate 'add'
command to stout in a terminal so I could then copy/paste that command to
another terminal window to add the address/port once I investigated why the
requesting program might have needed that connection. It would be trivial
to add a gui with a click-to-add button.

This could likely be done on the internal interface in sys-firewall
(untested) or in the AppVM (where you could also check which process was
using that port number, e.g. netstat -pan) depending on the trust level in
your AppVM. One could put this in a batch learning mode to collect all
these commands during a test run and then add them to the sys-firewall
permanently once verified.

As for performance, you only need to monitor it periodically if the app
stops working, like when they shift to some other round-robbin server. You
could easilly run it as a cron job at night to see what connections had
been tried while you were not there. There is however limitations on the
number of rules you can add so you might need to change individual
addresses into network blocks once you start having those resource limiting
issues. Thunderbird for instance tried to check for plug-ins at lots of
different 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAJ5FDng%3DzSm9fDsLVbB5WjVGE7aDDJjsO8kihOzjWfFwgjQ68A%40mail.gmail.com.

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

[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

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

[qubes-users] Error: "GLX extension not found"

[Steve Phillips]

I always get the error "GLX extension not found" when trying to run 
graphical programs written in Go, V, and other languages. They compile 
fine, but then won't run.

I assume that these programs basically can't access the graphics card, and 
that that's what this GLX error means?

Either way, is there some package I need to install in order for this to 
work?

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ebe9ad12-85d1-48ec-8a40-289007b11a39n%40googlegroups.com.

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

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

[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

[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
> <https://groups.google.com/d/msgid/qubes-users/9d137cef-525f-48bf-bd49-85c17ad02b9an%40googlegroups.com?utm_medium=email_source=footer>
> .
>

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

[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

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

[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

[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

[Steve Coleman]

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

> Mike_Keehan <https://qubes-os.discourse.group/u/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
> <https://qubes-os.discourse.group/t/qubes-users-r4-0-4-rc1-unable-to-delete-or-backup-certain-qubes/1507/3>
> or reply to this email to respond.
>
> To unsubscribe from these emails, click here
> <https://qubes-os.discourse.group/email/unsubscribe/f2a96951586260ffa6442e60947eb759a3b75ce7e285aa587ac9d2d10be81bc3>
> .
>
>

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

[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

[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

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

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

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

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

[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

[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

[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] Re: External Fully Encrypted SSD Drive. What do you think?

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

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

[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
> <https://groups.google.com/d/msgid/qubes-users/3e39d011-8d2b-474e-818a-ed0b6058ef40%40googlegroups.com?utm_medium=email_source=footer>
> .
>

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

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

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

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

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

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

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

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

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

[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

[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

[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

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

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

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

[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

[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

[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

[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

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

[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

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

[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

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

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

[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

[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

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

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

[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

[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

[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

[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

[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

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

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

[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

[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

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

[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

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

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

[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

[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

[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

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