Re: [qubes-users] Salting your Qubes

[pillule]

pillule  writes:


Hi unman.

I am learning to "salting my Qubes", what decided me is your 
recipe for

apt-cacher-ng (sometimes my bandwith really matters).

So far I get some things working such as an automated
template/templateDispVM/staticDispVM for firefox and its 
configuration with some
extensions. 

So with a little more confidence, right now I am installing your 
apt-cacher-ng

recipe.

I read from the docs of apt-cacher-ng :
"6.3 Fedora Core
Attempts to add apt-cacher-ng support ended up in pain and the 
author lost any

motivation in further research on this subject. "

Do you get it working ?

In all cases, can you explicit how you use apt-cacher-ng only 
for debian
derivatives? The RPC policy you provided will apply to all 
templates, and calls
to https from fedora will be denied, preventing them to update ; 
or I am

missing something ?

Happy to take suggestions for other configurations, or 
features.


unman


Sometimes ago you mentioned on the mailing list to use snort and 
tripwire.
I don't know if it is trivial to deploy but that is surely one 
of the next

things I will look at.


I have been fooled by :
https://github.com/QubesOS/qubes-issues/issues/6585

Actually my apt-cacher-ng is also denying qubes updates :

Hit:1 http://HTTPS///deb.debian.org/debian buster InRelease
Hit:2 http://HTTPS///deb.debian.org/debian-security buster/updates 
InRelease

Err:3 http://HTTPS///deb.qubes-os.org/r4.0/vm buster InRelease
 Connection failed [IP: 127.0.0.1 8082]
Err:4 http://HTTPS///deb.qubes-os.org/r4.0/vm buster-testing 
InRelease

 Connection failed [IP: 127.0.0.1 8082]
Reading package lists...
Building dependency tree...
Reading state information...
All packages are up to date.
W: Failed to fetch 
http://HTTPS///deb.qubes-os.org/r4.0/vm/dists/buster/InRelease 
Connection failed [IP: 127.0.0.1 8082]
W: Failed to fetch 
http://HTTPS///deb.qubes-os.org/r4.0/vm/dists/buster-testing/InRelease 
Connection failed [IP: 127.0.0.1 8082]
W: Some index files failed to download. They have been ignored, or 
old ones used 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/874keq4l2y.fsf%40host.localdomain.

Re: [qubes-users] Salting your Qubes

[pillule]

Hi unman.

I am learning to "salting my Qubes", what decided me is your 
recipe for

apt-cacher-ng (sometimes my bandwith really matters).

So far I get some things working such as an automated
template/templateDispVM/staticDispVM for firefox and its 
configuration with some
extensions. 

So with a little more confidence, right now I am installing your 
apt-cacher-ng

recipe.

I read from the docs of apt-cacher-ng :
"6.3 Fedora Core
Attempts to add apt-cacher-ng support ended up in pain and the 
author lost any

motivation in further research on this subject. "

Do you get it working ?

In all cases, can you explicit how you use apt-cacher-ng only for 
debian
derivatives? The RPC policy you provided will apply to all 
templates, and calls
to https from fedora will be denied, preventing them to update ; 
or I am

missing something ?


Happy to take suggestions for other configurations, or features.

unman


Sometimes ago you mentioned on the mailing list to use snort and 
tripwire.
I don't know if it is trivial to deploy but that is surely one of 
the next

things I will look at.

--


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

Re: [qubes-users] customizing Firefox in disp-vms

[pillule]

prago via qubes-users  writes:

I've used salt to configure my disposable VMs and customise 
Firefox.

The repo is available here:
https://gitlab.com/prago/my-salt


Hi prago,

Nice usage of policies.json and user.js

It mays be a bit naive question but are you not concerned about 
downloading and installing .js file directly from internet in your 
template ?


What would be an ideal verification procedure in such case ?
I looked to at least verify the last commit with gpg but 
unfortunately I didn't find the signature of arkenfox on a 
keyserver.


--


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

Re: [qubes-users] Re: customizing Firefox in disp-vms

[pillule]

Emma Borhanian  writes:

You can use an autoconfig 
 
file in the firefox-esr install directory in the template to 
control 
everything except default search, which mozilla has added a 
bunch of 
protections to in order to prevent default search page 
hijacking. You can 
use this to disable "first run" welcome tabs, etc.
You probably also want to put privacy/hardening settings in the 
autoconfig 
file.


To change the default search page you actually need two 
mechanisms:
1. Reverse engineer the way the firefox-esr directory configures 
default 
search.
2. Reverse engineer the way the profile directory configures 
default search.


Hi Emma,

Thanks for pointing autoconfig, it may simplify my setup.

Have you tried to use 
/usr/share/firefox-esr/distribution/policies.json to setup the 
search engine and your addons ?

It is indeed more powerful than a user.js

https://support.mozilla.org/en-US/kb/customizing-firefox-using-policiesjson

I have not yet used it for the search-engines part but there is an 
entry here if you follow the link to the docs.


For the addons part is a bit tricky to get the corrects addons ID,
(I yelled until I found this 
https://github.com/mkaply/queryamoid/releases/tag/v0.2)


--


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

[qubes-users] Re: disposable sys-net and wifi password management

[pillule]

pillule  writes:


Hi,

When using a disposable sys-net, you eventually encounter two 
occurences of
password management that you may want to not repeat at nauseam 
:

[...]
So my question is, if you do use a sys-net-dvm, how do you 
handle this

situation
?

  - do you use bind-dirs ? (is that not reserved to template <- 
  vm ? and not possible at all for dvm-template <- dvm ?)

  - do you use rpc services ? if so how ?
  - another way ?


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

I remembered about mail-archive.com and found this thread which 
gives a solution

:

Configure the networks settings in the templateDispvm.
This needs some manual interventions for each new wifi passwords 
/ installation
Also this means that you need to connect your templateDispvm to 
the targeted

networks with your modem.


Hi again,

There's two scripts to help with it.

When you have to restart a netvm you have to shutdown the vm which 
depends on it or at least use qvm-pref  netvm none
qvm-restart take care of that by disabling this pref before the 
shutdown of a netvm and restore them after it start again.


letsetwifi is similar but meant specially to set your wifi 
password in the templateDispvm so

- it cuts the connexions by disabling the netvm prefs
- it reassigns the network pci devices to the templateDVM
- shutdown the dvm, start the template
- wait for your input with `read` to let you take your time to 
setup your password (you have to do it manually in network 
manager widget)

- at your input restore the initial situation.

be warned that while there is some error handling;
both wont restore the prefs/pci if you interrupt them, eventually 
leaving you with a network that you have to fix yourself.


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


qvm-restart
Description: qvm-restart


letsetwifi
Description: letsetwifi


--


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

[qubes-users] Re: disposable sys-net and wifi password management

[pillule]

pillule  writes:


Hi,

When using a disposable sys-net, you eventually encounter two 
occurences of

password management that you may want to not repeat at nauseam :

 - the wifi password of your network, stored in
/etc/NetworkManager/system-connections/
 - the gnome-keyring will eventually prompt you for your 
 default-keyring (but it
appears that can be skipped in the connexion options), if so it 
will at least

create a file in ~/.conf/

So my question is, if you do use a sys-net-dvm, how do you 
handle this situation

?

  - do you use bind-dirs ? (is that not reserved to template <- 
  vm ? and not possible at all for dvm-template <- dvm ?)

  - do you use rpc services ? if so how ?
  - another way ?


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

I remembered about mail-archive.com and found this thread which 
gives a solution :


Configure the networks settings in the templateDispvm.
This needs some manual interventions for each new wifi passwords / 
installation
Also this means that you need to connect your templateDispvm to 
the targeted networks with your modem.


I guess I get over 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/87k0nzkf08.fsf%40host.localdomain.

[qubes-users] disposable sys-net and wifi password management

[pillule]

Hi,

When using a disposable sys-net, you eventually encounter two 
occurences of password management that you may want to not repeat 
at nauseam :


 - the wifi password of your network, stored in 
 /etc/NetworkManager/system-connections/
 - the gnome-keyring will eventually prompt you for your 
 default-keyring (but it appears that can be skipped in the 
 connexion options), if so it will at least create a file in 
 ~/.conf/


So my question is, if you do use a sys-net-dvm, how do you handle 
this situation ?


  - do you use bind-dirs ? (is that not reserved to template <- 
  vm ? and not possible at all for dvm-template <- dvm ?)

  - do you use rpc services ? if so how ?
  - another way ?

--


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

Re: [qubes-users] issues with i3, xrandr and keyboard

[pillule]

'qtpie' via qubes-users  writes:

Also, how do you change your keyboard settings under 
i3/Fedora/Qubes? I
want to use the us-altgr-intl keymap. Under i3 when I do $ 
localectl
set-keymap us-altgr-intl in a qube vm terminal, this has no 
effect in
applications. The right alt key instead remains used to open 
menu's
(altgr+f for File, altgr+e for Edit, etc.) If I could use 
altgr-intl and

retain that functionality that would actually be great.


Do you mean it activates the toolbar in a software such as firefox
(Alt_R keysym) or it activates a contextual menu in a soft such as
gnome-terminal (Menu keysym) ?

I think such things may be configurable in the application itself.
The thing is when you use AltGr as right Alt, you are now sending
ISO_Level3_Shift as keysym to the application instead of Alt_R, so 
the

application must be aware you want also use it for your things.

A trick, if you do no want to configure the applications, may be 
to use
an utility such as xcape (in dom0) to send Alt_R when you press 
and
release the key alone, and ISO_Level3_Shift when you press the key 
in

conjonction of another.

I hope that help.

--


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

Re: [qubes-users] issues with i3, xrandr and keyboard

[pillule]

'qtpie' via qubes-users  writes:

- Does anyone have a comparable setup and what xrandr command do 
you use?

- Is there an alternative to using xrandr under i3?


Do you have tried to use an utility such as lxrandr or arandr to 
generate

the command of xrandr for you ?

Also, how do you change your keyboard settings under 
i3/Fedora/Qubes? I
want to use the us-altgr-intl keymap. Under i3 when I do $ 
localectl
set-keymap us-altgr-intl in a qube vm terminal, this has no 
effect in
applications. The right alt key instead remains used to open 
menu's
(altgr+f for File, altgr+e for Edit, etc.) If I could use 
altgr-intl and

retain that functionality that would actually be great.


localectl is an utility correlated to systemd, its changes only 
takes effect

*after* a reboot and must be applied in the templateVM.

To change your keymap on the fly you should use setxkbmap. Its 
changes only

last the session.
‘setxkbmap -layout us -variant altgr-intl’

I have bugs with localectl. (options will not clean) Instead I 
export my own

keymap with xkbcomp and loads it in session scripts.

For the qubes way to change the vm keymaps, idk sorry. I only know 
it does

not allow to change your keyboard options so I looked away.

--

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

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

[pillule]

Hello,

I wonder how do you manage your computing life with the problem of 
the clipboard / file sharing.


The documentation states :
https://www.qubes-os.org/doc/copy-paste/
“However, one should keep in mind that performing a copy and paste 
operation from less trusted to more trusted qube is always 
potentially insecure, since the data that we copy could exploit 
some hypothetical bug in the target qube. For example, the 
seemingly-innocent link that we copy from an untrusted qube could 
turn out to be a large buffer of junk that, when pasted into the 
target qube’s word processor, could exploit a hypothetical bug in 
the undo buffer. This is a general problem and applies to any data 
transfer from less trusted to more trusted qubes. It even applies 
to copying files between physically separate (air-gapped) 
machines. Therefore, you should always copy clipboard data only 
from more trusted to less trusted qubes.”


Also I remember a paper of Joanna Rutkowska assuming the same 
principles.



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.

I would like to let the least possible of my data in the VMs which 
are exposed to the network. This, with the fact the ressources of 
my computer are limited, unfortunally may leads to open breaches 
in the comportamentalisation :
Now I have a vault where I takes notes and needs to paste things 
into it. I can't afford using a vault for each new context and it 
will not solve the issue of the clipboard.
Maybe I should just stick to the idea of one context equal one VM, 
and refine what I think is pertinent to put on the word ‘context’.


Otherwise, Is there really nothing one can do to enforce the 
integrity of a piece of text ?
Like using an OCR from dom0 to retranscript an screenshoot of a 
less trusted VM (is that dumb or also somehow flawed or just so 
loud nobody wants 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/878s96aezi.fsf%40host.localdomain.

Re: [qubes-users] Updating a disposable qube / Can't delete unused qubes

[pillule]

On Tue, Nov 03 2020, 'src11' via qubes-users wrote:

> Why am I not able to delete unused qubes? I tried but they're still there.

Sometimes you need to do
`qvm-prefs [VM-NAME] installed_by_rpm false'
before `qvm-remove' 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/87d00mtx9d.fsf%40host.localdomain.

Re: [qubes-users] How to check (in BASH and dom0) whether a appVM exists?

[pillule]

On Tue, May 19 2020, Johannes Graumann wrote:

> On 2020-05-19 10:46, Frédéric Pierret wrote:
>
>> There is a tool for checking state of VMs:
>>
>> [userdom0 ~]$ qvm-check toto
>> usage: qvm-check [--verbose] [--quiet] [--help] [--all] [--exclude EXCLUDE]
>> [--running] [--paused] [--template] [--networked]
>> [VMNAME [VMNAME ...]]
>> qvm-check: error: no such domain: 'toto'
>> [user@dom0 ~]$ echo $?
>> 2
>> [user@dom0 ~]$ qvm-check sys-net
>> qvm-check: sys-net: exists
>> [user@dom0 ~]$ echo $?
>> 0
>>
>> Best,
>> Frédéric
>>
>> On 2020-05-19 10:35, Christophe wrote: qvm-ls|grep yourvmname
>>
>> On 20/05/19 10:32AM, Johannes Graumann wrote: Hello,
>>
>> See subject line ;)
>>
>> Sincerely, Joh
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "qubes-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to qubes-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/qubes-users/74dcf0a303aa9afb95809626034f7e1e%40graumannschaft.org.
>
> Ha - even better ... sorry, saw this late. 
>
> Thanks! 
>
> Joh

Hi,

You maybe interested to know which VM is the last started (sometime
for DVM), here my way to do it :

virsh -c xen:/// list | tail -n 2 | head -n 1 | sed -r 's/^ [0-9]+ *//s .//'

-- 


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

[qubes-users] qubes.el for emacs

[pillule]

Hi,

I discovered some months ago https://gitlab.com/lechten/qubes.el/ by
Dr. Jens Lechtenbörger.

It implement qvm-copy, qvm-open, qvm-convert in emacs, dired, gnus.

With the last merge request I have done, there is some news :

 - commands are invoked with `start-process-shell-command' so emacs
   will not hang until job is done.
 - qvm-copy is implemented (so far qubes.el was thinked for Qubes 3)
 - qubes.el will recognize if you are using Qubes v3 or v4 and adjust itself.

You can customize some behaviors via M-x customize or hack the code.

Note for Qubes v4 that as `qvm-open-in-vm' *still* necessites a valid name of 
VM as
argument, I used "untrusted" by default; if you haven't an "untrusted"
VM, you can change it for any valid VM name, after validation, dom0
will prompt you for the real VM to open things.

Cheers.

--


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

Re: [qubes-users] Reattaching firewall vm to untrusted vm without killing the untrusted vm.

[pillule]

On Sun, Feb 16 2020, billol...@gmail.com wrote:

> Qubes folk,
>
> So, I have a debian-based untrusted vm that is attached to a mullvad
> vpn through Sweden; the mullvad vpn gets its networking from sys-
> firewall (i.e. sys-net -> sys-firewall -> mullvad-vpn -> untrusted vm.
>
> I have another "local" vm that is directly attached to sys-firewall
> (i.e sys-net -> sys-firewall -> local vm).  Nothing other than sys-usb
> starts automatically on boot.
>
> The mullvad-vpn is a standalone vm, set up per the Qubes mullvad
> instructions, while the untrusted and local vms are based on the
> debian-10 template.
>
> I'm running Qubes release 4.0.2.
>
> When I change locations without rebooting the box and switch wireless
> networks, the sys-net, sys-firewall, and local vms automatically
> update.  Unfortunately, the mullvad-vpn vm does *not* update
> automatically.  In order to get networking on the untrusted vm, I have
> to kill it *and* the mullvad-vpn vm, and restart them -- which means I
> have to kill any running apps, which is a pain when I'm doing big image
> tasks in the background.
>
> Is there a way to tell a standaloneVM like my mullvad-vm to either
> update automatically, or a command to get it to re-set its networking
> to a changed sys-firewall vm?
>
> Thanks,
>
> billo

Hi,

You can switch the 'netvm' of any VM on the fly with Qubes Manager or
via command line
`[user@dom0 ~]$ qvm-prefs "vmname" netvm none`
then switch back when ready.

--


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

Re: [qubes-users] Split GPG issue

[pillule]

On Wed, Jan 29 2020, Claudio Chinicz wrote:

> Hi All,
>
> I'm trying to use Split GPG with Thunderird/EnigmaMail (running on an AppVM
> based on whonix-ws). My work-gpg VM is based on Fedora-30.
>
> I've followed the instructions found on
> https://www.qubes-os.org/doc/split-gpg/.  I had to create ~/.profile
> manually with the QUBES_GPG_AUTOACCEPT on dom0.
>
> When I configure Enigmamail Preferences and "overide" with the
> qubes-gpg-client-wrapper and push the "ok" button I get this error message
> "Cannot connect to gpg-agent. Maybe your system uses a specialized tool for
> passphrase handling (e.g. gnome-keyring, seahorse-agent, KDE wallet
> manager, ...). Unfortunately Enigmail cannot control the passphrase timeout
> for the tool you are using. Therefore the respective timeout settings in
> Enigmail are disregarded." (my work-gpg VM starts automatically when I
> start Thunderbird).
>
> I've tried to create a key and (obviously) got an error message. I've
> checked the Enigmamail log/terminal and found this:
>
> /usr/bin/qubes-gpg-client-wrapper --charset utf-8 --display-charset utf-8
> --no-auto-check-trustdb --batch --no-tty --no-verbose --status-fd 2
> --gen-key%echo Generating key
> Key-Type: EDDSA
> Key-Curve: Ed25519
> Key-Usage: sign
> Subkey-Type: ECDH
> Subkey-Curve: Curve25519
> Subkey-Usage: encrypt
> Name-Real: 
> Name-Email: 
> Expire-Date: 1825
>
> Has anyone had the same issue?

I dunno for thunderbird; does it work if you try by command line?

I have a problem with it if I set up *VM-gpg* with a minimal
template, otherwise it works fine …

> Additionally, I would like to ask if anyone knows how to use the same
> work-gpg VM with multiple AppVM? I want to use also with another
> Thunderbird instance running on a regular (non-torrified) VM with another
> email account. Should I add another line in qubes.Gpg (dom0) with the "<2nd
> AppVM> work-gpg allow" statement as a second line, beneath "personal-whonix
> work-gpg allow"?

Yes you can use the same *VM-gpg* for multiple AppVM by adding a new
line before "@anyvm @anyvm ask"

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