Re: [qubes-users] Logging Drop Packets

[unman]

On Fri, Mar 08, 2019 at 06:28:51AM -0800, cmsch...@gmail.com wrote:
> I'm trying to setup an appvm like this: 
> 
> appvm -> appvm_firewall -> vpn -> vpn_firewall -> sys-net
> 
> I want to tighten the firewall rules and do a deny policy. How can I get a 
> log of dropped firewall packet logs from appvm_firewall or vpn_firewall? I've 
> tried a few different iptables commands but I haven't really had any success. 
> 
> Thanks in advance. 
> 

Depends whether you have a "DROP" policy set or a final rule that says
"-j DROP"
In iptables, have a rule immediately BEFORE that rule( so if policy,
have it as last rule, otherwise, penultimate).
iptables -j LOG --log-prefix "DROP "
You can put this in any firewall chain.

You could make it more complex by creating a log/drop chain and
breaking down the descriptors, but I doubt that is necessary in this
case.

If you are using nftables, (check in your sys-firewall), then you can
get the same effect by adding to your DROP statement. You don't need a
separate rule for this.

HTH

unman

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190308165127.324vdae5jf6zmib3%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] QSB #048: Multiple Xen vulnerabilities

[unman]

On Thu, Mar 07, 2019 at 04:27:34AM +, AJ Jordan wrote:
> If anyone wants to double-check that they haven't accidentally created
> a PV domain vulnerable to these XSAs, this command:
> 
> % qvm-ls --fields NAME | tail -n +2 | xargs -n 1 -I % qvm-prefs % virt_mode | 
> grep -ve pvh -e hvm | wc -l
> 
> should do the trick. It reports how many vulnerable VMs are on your
> system.
> 
> -AJ
> 

It's somewhat easier to access the mode directly:
qvm-ls -O NAME,virt_mode |grep -iw pv
will show you the names of any pv qubes.

unman

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190308112953.h3eiqcgtqjxt5tbg%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] networked dvm for vault?

[unman]

On Thu, Mar 07, 2019 at 01:10:02PM -0500, Ryan Tate wrote:
> Short version: Is it a security issue to set a networked disp vm as
> the default disp vm for a vaulted vm?
> 
> I have a vaulted vm (no network) and a printing dvm (limited local
> network access via firewall). It would be convenient to set the
> printing dvm as default disp vm for the vault so i can easily print to
> network when I want to do so.
> 
> But I notice that when I launch "view in disposable vm" from
> right-click menu, there is no confirmation in the GUI as there is for
> qvm-move and so forth. Which makes me wonder if malicious software in
> the VM could use this as an escape vector.
> 
> I read through the below document, and although some security issues
> around dvms are addressed, I could not figure out the answer to my
> question from it:
> 
> https://www.qubes-os.org/doc/disposablevm/
> 
> Thanks for any advice

Short answer: Yes, it is.

I'm assuming that you have Qubes4.0.
The fact that you don't see a prompt suggests that you have a policy set
to "allow" - you can check this in /etc/qubes-rpc/policy/qubes.OpenInVM
If you change that so that it reads:
vault $dispvm ask
then you should see a prompt.
This would go some way to mitigating the risk.

On a more general level, I don't know what is in your vault, and so don't
know what it is you might want to print. I have a number of qubes that
act as vaults, with different levels of content. The most secure has no
default disposableVM and explicit "deny" rules in every relevant
policy. Lower content levels have lesser restrictions.

unman

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190308002408.wpwko7cxd3htgors%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Deleting debian-9 template and getting a new one returns an error: "Error: Unable to find a match"

[unman]

On Mon, Mar 04, 2019 at 11:41:21PM -0500, Chris Laprise wrote:
> On 3/4/19 8:59 PM, Sphere wrote:
> > Thanks for this unman
> > I tried the commands you suggested and it still ended up with the very same 
> > "Error: Unable to find a match"
> > I'll track that issue you raised to know when it gets fixed (Y)
> > 
> 
> Have you tried "sudo dnf clean all" in dom0?
> 

That doesnt fix this.
Nor does creating a new updateVM, (so everything is clean).

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190305133406.fuactcl3ubaoga7i%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] QUBES_GPG_AUTOACCEPT not being honored in 4.0

[unman]

On Mon, Mar 04, 2019 at 09:07:02PM +0100, cubit wrote:
> 
> 
> 
> Mar 4, 2019, 3:10 PM by un...@thirdeyesecurity.org:
> 
> > What shell are you using in gpg?
> > Try putting the export line in .profile and restart gpg. Any different?
> >
> 
> That did the job.   I had it originally listed as I mentioned in 
> .bash_profile which was sourced by .bashrc which was sourced by .profile  but 
> I guess something went wrong along the chain.
> 

No, it was an (undocumented) change as a result of a change in the
shell used in init. I've updated the docs to make this clear.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190305002147.gobqoncd3qhk2jdc%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Structure of qubes

[unman]

On Sun, Mar 03, 2019 at 09:51:05PM -0800, acharya.sagar.sag...@gmail.com wrote:
> > Not sure of the answer, but all you should have to do to use that option 
> > is add it to your kernel= line.
> 
> I think this is an important decision. I need to be sure. There are 2 
> different ways to proceed as shown here...
> 
> https://wiki.xen.org/wiki/Xen_PCI_Passthrough
> 
> It maybe a point of no return if I choose the wrong path. In fact, that can 
> be the reason people haven't been able to implement. I want to be correct at 
> each step.
> 

lsmod confirms that is LKM : you can also check by looking in
/proc/modules

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190304151338.3piqipymx5tel5ew%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] QUBES_GPG_AUTOACCEPT not being honored in 4.0

[unman]

On Mon, Mar 04, 2019 at 02:30:44PM +0100, cubit wrote:
> Following a move from Qubes 3.2  to 4.0.1 I am struggling to get the split 
> key gpg to honor QUBES_GPG_AUTOACCEPT any more 
> 
> The rest of the split key functionality works as expected but it's very 
> frustrating the have QUBES_GPG_AUTOACCEPT default to 300 despite having been 
> manually changed to 86400
> 
> 
> Relevant config riles.   I hope I did not forget to include any important.
> 
> .bash_profile in vault
> 
> user@vault:~$ more .bash_profile
> export QUBES_GPG_AUTOACCEPT=86400
> 
> 
> gpg-split-domain in work
> 
> user@work:~$ more /rw/config/gpg-split-domain
> vault
> 
> 
> qubes.Gpg in dom0
> 
> [user@dom0 ~]$ more /etc/qubes-rpc/policy/qubes.Gpg
> work  vault  allow
> $anyvm  $anyvm  ask
> 
> 
> 
> Cubit

What shell are you using in gpg?
Try putting the export line in .profile and restart gpg. Any 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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190304151019.wvptqnowe7rhj4cd%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Deleting debian-9 template and getting a new one returns an error: "Error: Unable to find a match"

[unman]

On Sun, Mar 03, 2019 at 07:46:52PM -0800, Sphere wrote:
> On Friday, March 1, 2019 at 8:38:07 PM UTC+8, unman wrote:
> > On Thu, Feb 28, 2019 at 10:09:38PM -0500, Chris Laprise wrote:
> > > On 2/28/19 8:30 PM, Sphere wrote:
> > > > I was sure I double checked the line of code I used in dom0 terminal to 
> > > > get a new template which was
> > > > "sudo qubes-dom0-update qubes-template-debian-9"
> > > > 
> > > > Not sure why running this returns with the "Error: Unable to find a 
> > > > match" while just changing 9 to 8 actually works
> > > > 
> > > > The same case happens when I try qubes-template-fedora-29, where my 
> > > > fedora-29 template still exists
> > > > 
> > > > If this is because of some sort of name conflict issue, how could I 
> > > > download the template/s and have them be named something else?
> > > > 
> @unman - Nope I don't have debian-8 installed and that I snagged a fresh copy 
> of debian-9 last year.
> What's noteworthy is that I can definitely trigger installation of debian-8 
> and other templates that I have never installed.
> I can trigger qubes-dom0-update just fine tho and have the repositories 
> update.
> I'll try snagging the templates from the itl repo and see if that still 
> triggers the problem, many thanks for lending me a hand
> hope it solves this problem
> 

I thought this was a Whonix issue, since I encountered it on one box,and
fixed it to updating over Tor not using Whonix.
But with some testing I'm lost - I can duplicate it on some machines, but
with others with *exactly the same configuration* I get the same error
you report. This suggest to me a problem with the template mirrors -
I've just quickly run though them and 3 of them are down/not available.

Fixing the repo to a specific repo seems to work for me.

I've raised an issue at github - #4858

unman

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190304145649.uqns5m6wpdd3465u%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: Q menu cleanup ideas (was Re: [qubes-users] Best practices?)

[unman]

On Mon, Mar 04, 2019 at 04:45:36AM -0800, brendan.h...@gmail.com wrote:
> On Monday, March 4, 2019 at 7:14:40 AM UTC-5, swami wrote:
> > Le 04/03/2019 à 13:03, b@gmail.com a écrit :
> > > * at some point we'll need to talk about how to keep the Qubes menu clean 
> > > with all these clones around. 
> > 
> > It would surely help much to have a « Include in menus » checkbox in the
> > VM properties, to avoid polluting the menu with clone VM entries, and
> > avoid starting by mistake an app from a clone backup VM...
> 
> Perhaps...of course, that might make discovery difficult for new users as you 
> would need to run a dom0 command to get to get to the screen to enable the 
> checkmark if the checkbox was removed.
> 
> Maybe a toggle-style menu item or two at the top of the Q menu:
> - Show (Hide) Template VMs 
> - Show (Hide) Non-included VMs (using your checkbox approach)
> 
> e.g. I would probably mark the baseline (salt-installed) VMs as hidden to 
> make it less likely I update them by mistake
> 
> Alternate ideas to toy with:
> All template VMs should be on a sub-menu.
> All Salt-installed template VMs on a different sub-menu.
> All Salt-installed templates volumes are immutable, and must be cloned for 
> both updates and use with VMs. Note: LVM thin-provisioning avoids wasted 
> space.
> 
> Brendan
> 

I remember when there was just such an option available, and a toggle at
the top of the Manager to show/hide . It was lost in the transition to
the Qube Manager.
Put in a feature request on github for this. No: there's already one
there:
https://github.com/QubesOs/qubes-issues/issues/4005

unman

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190304145027.odxzmaytyzkyio4j%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] where/how does dom0 gets its icons?

[unman]

On Sat, Mar 02, 2019 at 09:32:38AM -0600, Daniel Allcock wrote:
> Thank you David. It seems, though, to be more complicated than that.
> 
> > On 3/1/19 8:54 PM, Daniel Allcock wrote:
> > > Hello,
> > > I would like to understand what to do to customize the icons
> > > that appear in the Q menu for template and app vms.
> > > The only way I have found that works is to overwrite icon
> > > files in /usr/share/icons/Adwaita/* in the template vm.
> > > chose that icon theme in xfce settings.  Everything just works.  
> > 
> > I don't know about Adwaita or anything, but Qubes OS adheres to the 
> > Freedesktop Standard [1] (I guess version 1.0 though).
> > 
> > So the entire menu incl. icons is managed by *.desktop and *.menu
> > files in dom0. Nothing is imported from within any VM.
> 
> the vm's do communicate their desktop files to dom0, and icons for
> them.  This is what populates the directories in dom0 that produce
> the Q menu.  Whenever you install software in a template vm using
> dnf, it says "notifying dom0 about newly installed applications..."
> Whenever you choose "refresh applications" in Qubes Manager, dom0
> fires up the underlying template and reimports the desktop and icon
> files.
> 
> The basic mechanism in the Freedesktop standard is that that each
> desktop file specifies an icon, eg "Icon=utilities-terminal".
> When it comes time to display an icon, the system looks in the user's
> selected icon theme for a file of that name (perhaps with a
> suffix like .svg or .png).  That icon theme may specify a fallback
> icon theme, where the system will look if it doesn't find an icon
> of that name.  The fallback can have fallbacks, etc, with "hicolor"
> being the icon theme of last resort. (This theme might not appear
> in menus, for example it doesn't appear in xfce's icon theme setting
> screen.  But it is present in /usr/share/icons.)
> 
> The point is that what icons are displayed has two inputs: the icon
> names in the desktop files, and the user's choice of icon theme, which
> maps those icon names to actual image files.  What I would like
> to understand is how qubes handles this.  It resolves the icon
> names to image files in some way, imports the icons to dom0,
> and colorizes them.  How does the resolution work?
> 
> I had two guesses, both
> seemingly reasonable but neither correct. (For each appvm, it might
> use the icon theme setting of the user account in that appvm.  Or,
> dom0 might use the theme in the appvm that has the same name
> as the theme chosen in dom0.)
> 
> At this point my hypothesis is that the
> communication-of-icons-to-dom0 process 
> (1) completely ignores appvms in favor of their underlying templates. 
> (2) completely ignores icon theme settings, just using Adwaita icons
> (from the template vm; it does not use, or perhaps uses at a lower
> priority, the Adwaita icons already present in dom0). 
> 
> Would appreciate any info, even just confirmation of this.
> 
> Thank you,
> Daniel
> 

Hi Daniel,

It's some time since I looked at this, but I had a quick look at the
code. Take any of this with a (large) pinch of salt, but it may help you
to get to the right place.

I think the magic happens in
/usr/lib/python3.5/site-packages/qubesappmenus/receive.py .
This is where the icon directory is created, and icons are picked up
from the templates.(Yes, as you  say, they come from the template).
appmenus in the template are parsed, and the contents written in to
appmenu templates in dom0.

The icon file is read from the desktop file referenced in the template,
and copied to dom0. This is done by a call to imgconverter.
You'll find there a function get_xdg_icon_from_vm which attempts to
copy and sanitise an icon image from the template.

For applications installed in qubes, have a look at:
https://www.qubes-os.org/doc/managing-appvm-shortcuts/

So I think  your hypothesis 1 is correct, and 2 is partly right.

hth

unman

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190302161740.bi4kcobu4a3lx37c%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Responding to the Whonix trolls...

[unman]

On Fri, Mar 01, 2019 at 07:27:08PM +, Achim Patzner wrote:
> On 28.02.2019 15:10:21, "unman"  wrote:
> 
> 
> > On Thu, Feb 28, 2019 at 11:03:12AM +0100, Achim Patzner wrote:
> > >  On 20190227 at 22:30 -0800 cooloutac wrote:
> > > 
> > >  Whenever I accidentally read a posting by raahelps@ I'm wondering what
> > >  crime we committed to have to bear something like this and what could
> > >  be done to avoid attracting people like that...
> > > 
> > >  Do us all a favour and go troll somewhere else
> > I don't think this is helpful
> 
> I guess I'm of a different opinion in that case. Sometimes someone has to
> speak up and draw a line in the sand.

All you are doing is perpetuating the problem.

> 
> > Please consider the guidelines and be respectful and polite to others.
> 
> Unlike others I strongly believe that respect has to be earned and it can be
> retracted. The user in question spent nearly all his time on this mailing
> list. And _none_ of his postings ever enriched any discussion.

I don't agree. I have my own problems with that user, but he has in the
past provided help on the list, and will do in the future.

> 
> Keep in mind that "a wise man changes his mind, a fool never will" just
> means the fools will win in the end.
> 
> > None of these accusations of trolling help build the community, or
> > advance Qubes.
> 
> In that case I would like to demand a vote (of exclusion of certain users)
> as this is building a community I wouldn't want to be a part of. I can
> understand why he is not welcome on the whonix lists anymore. And I strongly
> believe it should be the same here. I guess we will need a management
> decision on that point.
> 
> 
> Achim

I don't want a list that is banning people or excluding them. It's
regrettable that Whonix does so. In my experience, that rarely works
given the ready availability of new email addresses.
If you don't like a user, just add them to your kill file.
Build the community that *you* want, by promoting the issues/discussions
that are of value. Let the others wither away.
Credit readers with the sense to decide who is worth listening to.

unman



-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190302022114.y3m6sxkek762rnaf%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes: Unable to connect to VPN

[unman]

On Fri, Mar 01, 2019 at 01:47:22PM -0800, Otto Kratik wrote:
> On Tuesday, February 19, 2019 at 2:53:22 PM UTC-5, Jon deps wrote:
> 
> > https://www.qubes-os.org/doc/vpn/
> > 
> > I believe it would be helpful  if you indicate  which method  you have 
> > used to create the VPNper the URL  there 
> > 
> > 
> > perhaps it is more obvious to others 
> 
> 
> Thanks for your reply - sorry I somehow missed seeing it earlier. I managed 
> to sort of figure out what is going on and sort of fix it.
> 
> I am using the super-simple method of just invoking "openvpn whatever.ovpn" 
> from  terminal within an AppVM itself, rather than creating a dedicated proxy 
> or gateway as suggested in the docs. What is happening is the following..
> 
> Initially before connecting to the vpn, the file /etc/resolv.conf contains 
> the default Qubes sys-net dns entries, namely:
> 
> nameserver 10.139.1.1
> nameserver 10.139.1.2 
> 
> 
> When the vpn connects, it uses update-resolv-conf to overwrite the contents 
> of that file. It places some comment-text near the top and changes the 
> nameserver entries to its own, which is good and wanted of course. No 
> complaints.
> 
> When terminating the vpn connection by any means available (I tried several 
> different ones), openvpn again automatically updates that /etc/resolv.conf 
> file, but *only* to remove the entries it placed there, nothing more. The 
> comment-text is left intact and the nameserver entries are simply deleted, 
> resulting in a more or less empty and useless file and no DNS resolution 
> whatsoever. The script does not seem to store and remember the previous 
> entries that were there before (sys-net defaults) and replace them when 
> finished. It just erases everything and leaves it like that.
> 
> Thus after disconnecting the vpn I have to go back into that file and 
> manually re-add the sys-net entries to regain DNS resolution functionality. 
> Ultimately I'm just going to write a short bash script that puts the needed 
> entries back after disconnection, which I'll run at termination every time.
> 
> I don't know enough about openvpn to instruct it to "always run this extra 
> script upon disconnection", though I'm sure there must be a relatively easy 
> way to do so.
> 

Call it with --down   to have a script run when the tunnel closes.
If you check the man page, there are a variety of different options for
running scripts/commands at different events, but I suspect that will
fit the bill.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190302020753.fufcx25cdx2k5r6c%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Deleting debian-9 template and getting a new one returns an error: "Error: Unable to find a match"

[unman]

On Thu, Feb 28, 2019 at 10:09:38PM -0500, Chris Laprise wrote:
> On 2/28/19 8:30 PM, Sphere wrote:
> > I was sure I double checked the line of code I used in dom0 terminal to get 
> > a new template which was
> > "sudo qubes-dom0-update qubes-template-debian-9"
> > 
> > Not sure why running this returns with the "Error: Unable to find a match" 
> > while just changing 9 to 8 actually works
> > 
> > The same case happens when I try qubes-template-fedora-29, where my 
> > fedora-29 template still exists
> > 
> > If this is because of some sort of name conflict issue, how could I 
> > download the template/s and have them be named something else?
> > 
> 
> The older release with the apt vulnerability may have been removed from the
> repository, and the patched version may still be in testing?
> 
> Easiest way to resolve that is to add '--enablerepo=qubes*testing'.
> 

I dont believe this is so.
A fixed version (201901281256) is in qubes-templates-itl, and I
*believe* that I grabbed it from there before.
What you need to run is:
sudo qubes-dom0-update --enablerepo=qubes-templates-itl  qubes-template-debian-9

@Sphere - do you have a debian-8 installed? If so it may be that yum
remembers which repo it installed from, and so is able to grab the
update. If this isnt the case (and the repo wasnt updated during the
day) then I'm lost for an explanation.

Generally, if you want to do this manually, you can always grab from
https://yum.qubes-os.org/r4.0/templates-itl/rpm.
Download the package.
Manully check the signature using "rpm -K" (You will need to get signing
key and Qubes master)
Transfer to dom0
install using "rpm -i "

Much better to use the native tools, but that option is always
available.

unman

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190301123804.sdgxs55dka24vyvx%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Structure of qubes

[unman]

On Thu, Feb 28, 2019 at 12:16:34AM -0800, acharya.sagar.sag...@gmail.com wrote:
> I wanted to understand the tree structure of qubes.
> 
> So my guess is this.
> 
> dom0 is the owner of every other thing. There are 4 template VMs, fedora, 
> debian, 2 whonix ones.
> 
> When a domain restarts, it takes it settings from the template on which it is 
> based and it's own home directory and other couple ones which are just in it, 
> I guess stored in ROM.
> 
> I created another fedoraDev template for my development purposes on which my 
> work qube is based. work has no net access. When I installed pandas in my 
> fedoraDev template, it didn't reflect in work after restarts. When I changed 
> work netVM to sys-firewall and run "pip install pandas", there's no internet!
> 
> Also, I want to install nvidia drivers from rpmfusion for which I need to add 
> repos. I don't know where is dnf is. It's in dom0 but it is not connected to 
> internet. I need to make them in fedora. In my personal domain connected to 
> internet, there's no dnf.
> 
> I need to know the structure of qubes better to understand dnf and my python 
> pandas installation. I'm certainly missing something.
> 

Your summary of the Qubes structure is pretty good.

Where has panda been installed in the template? The only case where it
wouldnt appear in the work qube would be where it was installed in
/home/user in the template.
Check the path to library in the template and confirm it is there in the qube. 
You
may need to adjust your path in the qube.

In dom0 you need to use qubes-dom0-update - I suggest you read this:
https://www.qubes-os.org/doc/software-update-dom0

In dom0 and in templates, there is no direct internet connection, and
updates (whether rpm or deb) run by proxy in an updateVM.
https://www.qubes-os.org/doc/software-update-vm/ in the section on
"Updates proxy" may help.

unman

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190228142233.xw7v4t4fom2imeu2%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Responding to the Whonix trolls...

[unman]

On Thu, Feb 28, 2019 at 11:03:12AM +0100, Achim Patzner wrote:
> On 20190227 at 22:30 -0800 cooloutac wrote:
> 
> Whenever I accidentally read a posting by raahelps@ I'm wondering what
> crime we committed to have to bear something like this and what could
> be done to avoid attracting people like that...
> 
> Do us all a favor and go troll somewhere else.
> 
> 
> Achim

I dont think this is helpful
Please consider the guidelines and be respectful and polite to others.
None of these accusations of trolling help build the commmunity, or
advance Qubes.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190228141021.xuymbpvxmu35ihzw%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Oryx Pro laptop (BOOTX64.cfg for Qubes 4.0.1)

[unman]

On Thu, Feb 28, 2019 at 02:18:57AM -0800, Daniil Travnikov wrote:
> On Wednesday, February 27, 2019 at 10:19:09 PM UTC-5, awokd wrote:
> > Don't edit the ISO directly. dd or cp it to a USB drive (not partition), 
> > then follow the steps and mount the second partition and edit files in 
> > there.
> Thank you very much for your answer and for your help!
> 
> Ok, that's what I am doing step by step:
> 
> 1. I write .iso via Rufus in DD mode.
> 
> 2. When I am trying to open file BOOTX64.cfg:
> [user@dom0 BOOT]$ sudo nano BOOTX64.cfg
> 
> I can't save any edits in files and after open nano editor I see this below:
> [ File 'BOOTX64.cfg' is unwritable ]
> 
> What am I doing wrong?
> 

You are trying to write to an iso file, which is a read only file
system. (It's an image of a CD/DVD)

As awokd has suggested, you need to copy the files to a USB drive, or
similar, and edit them there. Then create a new iso image and boot from
that.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190228140359.jtcmszi2vdo3egqn%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Shrinking a private volume

[unman]

On Tue, Feb 26, 2019 at 10:30:35PM +0100, 799 wrote:
> Hello,
> 
> I've migrated ~150gb of data into a Qubes Storage Qube.
> After cleaning up older files I have reduced the data to 100gb.
> Now I'd like to free the additional 50gb so that dom0 can use this capacity
> for other qubes.
> 

You dont need to do anything. In 4.0 dom0 will simply use the
unallocated space. (Well, sometimes I restart a qube for this purpose.)
That 50GB is *already* available to other qubes.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190227131701.aj5dpr5uxkda27d6%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Weird dnf update command behavior on fedora-29 template

[unman]

On Tue, Feb 26, 2019 at 06:54:15PM -0800, Sphere wrote:
> It started happening just today
> Executing sudo dnf update command on my fedora-29 template forcefully makes 
> my sys-net start
> 
> But thing is, I'm no longer using sys-net template as my net vm and this 
> caused me to triple check my settings and my update VM is showed correctly as 
> I had intended = a VM designed to securely process DNS queries that is 
> attached to sys-firewall
> 
> Despite this, the behavior continues, even if I kill and/or halt my fedora-29 
> template and I have no clue as to why this happens it's like something is 
> forcing it to use sys-net in an attempt to get through my secure processing 
> of DNS queries
> 
> I also double checked that the template has no assigned net vm as intended 
> according to how Qubes was designed and it's also set properly to 'none'
> 
> It's absolutely persistent to the point that I ended up deleting my sys-net 
> template and now the sudo dnf update command abruptly ends with "Error: 
> Failed to synchronize cache for repo 'fedora-modular'"
> 
> Can anyone help me with the logs to check/commands to use in diagnosing this 
> problem properly?
> 

This is expected. Not a problem.
When you run dnf update , Qubes will start the update VM that you have
set.
As with any qube, if that has a netvm then it will start *that*, etc etc,
right up to sys-net.
If it didn't start a network connection, then you would get an update
error (as indeed you have).

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190227123049.pwh2245owdngdvb4%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] "Qubes Update" tool - can you ignore a template

[unman]

On Mon, Feb 25, 2019 at 03:31:18PM +0100, cubit wrote:
> Feb 25, 2019, 2:17 PM by un...@thirdeyesecurity.org:
> 
> > Disable the qubes-update-check service.
> > You can do this from qube manager or using qvm-service.
> > I disable that service everywhere.
> >
> 
> Thank you unman.   I can see how to do this via qvm-service but looking at 
> the qubes manager gui, I don't see the option.  Is there a particular tab it 
> should be listed under?
> 
> Cubit
> 

The services tab doesn't show services which have the default settings,
which can be confusing.
Use the drop-down menu to select the service, use the "+" button to add
it to the bottom pane, and then deselect the check box. Click OK and
you're done.

You can set global settings from the System-GlobalSettings menu item,
and there is option to "Disable checking for updates for all qubes"

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190225151007.u6txttrcwavvjxxc%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] "Qubes Update" tool - can you ignore a template

[unman]

On Mon, Feb 25, 2019 at 02:22:53PM +0100, cubit wrote:
> In the Qubes Update tool under 4.x,  is it possible to set a template to be 
> ignored for update checking?
> 
> The reason for this is I like to keep the default installed "fedora-29" 
> template unused and work off a clone  "fedora live" and in a worst case 
> scenario I can use the "fedora-29" taplate to make new clones if that latter 
> breaks or I want a template with out all the software I installed in "fedora 
> live"
> 
> The problem with this, as I never update "fedora-29" it always has updates 
> available
> 
>  Cubit

Disable the qubes-update-check service.
You can do this from qube manager or using qvm-service.
I disable that service everywhere.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190225141732.was5i346yml7er2n%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes for enterprise usage

[unman]

On Sun, Feb 24, 2019 at 06:28:36AM -0800, tggrps wrote:
> Thanks for the response - interesting to learn about the lacking Windows 
> guest support.
> Do you know which specific SMEs are using Qubes OS? (e.g. specific users I 
> can talk to) Interested in learning more from their experience pushing it to 
> more than a handful of users.
> 
> BTW - also see this article about Qubes OS (and others) that also claims 
> there's a big problem about hardware compatibility with Qubes OS making it 
> impractical for enterprises:
> https://www.brianmadden.com/opinion/client-virtualization-part-2-how-client-vms-have-evolved
> 
> Thank you!
> 
> On Friday, February 22, 2019 at 1:23:29 PM UTC+2, unman wrote:
> > On Fri, Feb 15, 2019 at 12:23:28PM -0800, tggrps wrote:
> > > Hi all,
> > > 
> > > Did anyone try to use Qubes for enterprise use cases? e.g. for securing 
> > > access to sensitive resources? How did that end up?
> > > 
> > > Last time I looked at Qubes, it didn't have enterprise manageability 
> > > features and required users to be familiar with Linux, which is not 
> > > always the case with enterprise users. The HCL is also a bit of a concern 
> > > as enterprise laptops might not well support Linux (audio/video/docking 
> > > stations/wifi/power management...).
> > > 
> > > Details about your experience with Qubes today for enterprise users 
> > > (either power users or simple users) would be helpful!
> > > 
> > > Thanks!
> > 
> > Qubes has salt stack and some features for manageability.
> > Look here:
> > https://www.qubes-os.org/doc/salt
> > https://www.qubes-os.org/news/2017/06/27/qubes-admin-api
> > 
> > It does not require *users* to be familiar with Linux, but undoubtedly
> > admins do. I don't know what a power user is.
> > Sensible selection from the HCL make the choices somewhat limited, but
> > workable.
> > I know some SMEs that use Qubes, but the sysadmins are extremely
> > competent in Linux and Xen.
> > The biggest blocker to widespread adoption is the somewhat sketchy
> > support for Windows imo. (Win 7 support is generally good, but later?)
> 

Please don't top-post when mailing the list.
I know the admins who use Qubes watch this list - if they want to chip
in, they will.
I'd seen that article. I didnt find it particularly useful. I dont think
it's fair to say that Qubes has a problem with hardware compatibility,
any more than Linux has such a problem.
As I said, choosing the hardware is important.
If you commit to Qubes, then its simple to find hardware that works
well. Probably not the latest processors/mboards, but solid enterprise
laptops are available and work well. It's certainly true that you cant
pick *any* laptop and have a trouble free install/use, but frankly the
same goes for (e.g) Debian.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190224164805.pufax65jvribmxuu%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] MTU setting for all interfaces

[unman]

On Sun, Feb 24, 2019 at 02:02:10PM +1000, Beto HydroxyButyrate wrote:
> I have MTU 9000 set on my internal network.  sys-net connects to this
> network.
> 
> I want all qubes VM interfaces to default to MTU 9000 rather than 1500.
> 
> Is there some simple global setting I can make to enable this?

You could set it at the router level in sys-net using a mangle table.
This is available for both iptables and nftables.
I've  done this with iptables in the past and I dont recall issues with
conntrack and connected clients. ymmv

iptables has tcp-MSS patch that allows you to hit this in FORWARD rules
- dont know if similar is available for nftables.

unman

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190224141432.n76eoa5geseil5kk%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Whonix Yes or No

[unman]

On Sun, Feb 24, 2019 at 10:36:12PM +1100, haaber wrote:
> > On 2/19/19 5:05 PM, ashleybrown...@tutanota.com wrote:
> > > 
> > > 
> > > Please, it would be greatly appreciated. Especially on how to ensure no
> > > clear traffic happens and that it only goes over tor.
> > 
> > This is covered now here:
> > https://hackmd.io/JIXLStC-Sbq8rr1mjomCDQ
> 
> thank you for sharing this.  Bernhard

If you want a packaged solution with similar functionality for stretch,
I package 3isec-tor at https://qubes.3isec.org
Add the stretch repository to your template and apt install 3isec-tor.

unman

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190224134230.vhr5e4j36fqw5hrp%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Whonix Yes or No

[unman]

On Sat, Feb 23, 2019 at 01:53:17PM -0600, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 19/02/2019 8.12 PM, unman wrote:
> > On Sun, Feb 17, 2019 at 08:50:01PM +0100, r...@posteo.net wrote:
> >> On 2/17/19 10:49 PM, jrsmi...@gmail.com wrote:
> >>> Reading through the post questioning the trustworthiness of 
> >>> Whonix, I can't tell whether we can continue trusting/using 
> >>> Whonix or not.  Can someone (preferably in a position to speak 
> >>> for QubesOS), please state, in a straightforward and 
> >>> unambiguous manner, spell this out for us?
> >> 
> >> Personally, I don't trust Whonix. The decision to not trust 
> >> Whonix is not based on the sysadmin/aussie issue that came up 
> >> recently on the list. I'm simply not convinced that they are 
> >> capable of designing and writing secure software. Furthermore, 
> >> there is no reason to use whonix in the first place, especially 
> >> when you are using Qubes. Creating a tor netvm is rather
> >> straight forward (and a dispvm that includes the Tor Browser if
> >> you like to use that as well). If there is enough interest, I can
> >> also write up a summary on how to do that in Qubes.
> >> 
> >> Regards
> > 
> > Have you looked at the qubes-tor package and 
> > www.qubes-os.org/doc/torvm? - that page is removed from the menu 
> > but still available. The qubes-tor package is OK but with some 
> > tweaking makes a solid replacement for Whonix gw - certainly for 
> > live images and machines with limited RAM. imo the decision to 
> > deprecate that package and then remove all reference to it from
> > the docs was a mistake.
> > 
> > unman
> > 
> 
> It's not true that all reference to TorVM was removed from the docs.
> In fact, the intro section of our main Whonix page specifically
> mentions TorVM and links to the the TorVM page. [1]
> 
> As you know, the decision to deprecate TorVM was years ago, [2][3] and
> it's been unmaintained ever since. Using it now could be dangerous,
> unless you really know what you're doing.
> 
> 
> [1] https://www.qubes-os.org/doc/whonix/
> [2] https://github.com/QubesOS/qubes-issues/issues/1196
> [3] https://github.com/QubesOS/qubes-issues/issues/1201
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlxxpKUACgkQ203TvDlQ
> MDAfIhAAni1qEcGYUJZ2Rvr7mzlenxY4BAY/I5fxm+ROZpMxWMmkJBJGHvRoPn8b
> W39f+d1WRH6RXCb9xsoJ9up4fTs05ZmjD8mULwoy5ugh58lYLfipTJwGyOLReQnM
> DtkpWhmLxGF8O8U3ndjZJLOBSg73EmnlxsyDwLdBdVkqSfzCS++pdPlpjEgjfjSy
> H8gBX+YnBuev/hUdTDBYsLsoHy35uIlq/AWkULLv+Md8zLh9fCfqHYsvRNdbUFfA
> 7aCv/9M2KwNZyWAr8hjhVyncPaqKHupaROv3bRN9sKCiH3vjFapNb44FRTMO1cb7
> NytBgwR2mimluXvYFgFhOq7RzRgejmB1ZeNvmV98FFOJAOlE/Wadc4BIPd77aRWk
> z6lZCcUz7OfoAUYfO2FqlGhJJjLsSX8qMcnv2hNTHRBbj7SLDsXisoBIxXpVHDTi
> zFCU/d8UimN9gOodybfF4TxkwG3taRO7GmDzhZJMx2S3uzqZpgAO9qut8lzZAevl
> SH3grIuANK3BBkqi+2QcXuKByxljVTjiZocxwjdmJP3a5pgG258zTxn43+QW2PU5
> WB1/maSXyColKLHcimypxTpBHFNw/EjecqUiCWFMZgQAlsLYjjfA87O7pg5/YnYf
> ICPz6EW9Chb2wP3ULSIcwnXkm6q22HpsUfTzk9Ld2fbx8RWyJAg=
> =6ucB
> -END PGP SIGNATURE-

I stand corrected Andrew.
But the page was removed from the menu and packages are no longer built.
That looks like removed to me, and goes beyond being "deprecated".

As far as being unmaintained, the package worked perfectly well, and the
errors reported were either generic Tor errors (as I pointed out) or
incorrect usage. The advantage of that package was its simplicity.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190224133834.jcdmu23oafpaf6uw%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How to connect to usb tethering of my mobile to sys-net qube

[unman]

On Thu, Feb 21, 2019 at 05:25:52AM -0800, acharya.sagar.sag...@gmail.com wrote:
> I don't have a sys-usb. If I assign my usbs to sys-usb, then how will the net 
> VM have access to it?
> Also according to Joanna here, networking stacks lie in NetVM
> https://blog.invisiblethings.org/2017/10/03/core3.html
> So I want to move my USB bus of the mobile connection to sys-net. When I 
> tried the command
> 
> qvm-pci -a sys-net 08:00.3 
> which is the address of my usb bus, it shows error regarding 'sys-net'
> 
> Also,
> Under dom0, when I execute commmand
> qvm-block
> With tethered usb it doesn't show any device and without tethered usb, it 
> shows
> 
> dom0:sr0  File-Stor_Gadget (CDROM)
> which means once I start tethering, the USB connection somehow dissappears.
> 
> Thanks Stuart
> 
Are you trying to attach pci device to a running sys-net? Dont.
(What was the error you got?)

qvm-block shows (as the name suggests) block devices.
qvm-usb or qvm-device may be of more help in this context.
Post output from those commands tethered and non-tethered.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190222113147.pk7lmyqbhife6scf%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes for enterprise usage

[unman]

On Fri, Feb 15, 2019 at 12:23:28PM -0800, tggrps wrote:
> Hi all,
> 
> Did anyone try to use Qubes for enterprise use cases? e.g. for securing 
> access to sensitive resources? How did that end up?
> 
> Last time I looked at Qubes, it didn't have enterprise manageability features 
> and required users to be familiar with Linux, which is not always the case 
> with enterprise users. The HCL is also a bit of a concern as enterprise 
> laptops might not well support Linux (audio/video/docking stations/wifi/power 
> management...).
> 
> Details about your experience with Qubes today for enterprise users (either 
> power users or simple users) would be helpful!
> 
> Thanks!

Qubes has salt stack and some features for manageability.
Look here:
https://www.qubes-os.org/doc/salt
https://www.qubes-os.org/news/2017/06/27/qubes-admin-api

It does not require *users* to be familiar with Linux, but undoubtedly
admins do. I don't know what a power user is.
Sensible selection from the HCL make the choices somewhat limited, but
workable.
I know some SMEs that use Qubes, but the sysadmins are extremely
competent in Linux and Xen.
The biggest blocker to widespread adoption is the somewhat sketchy
support for Windows imo. (Win 7 support is generally good, but later?)

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190222112325.rvjzhijhnzugmfgc%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Some VMs on an external disk (unavailable at boot)

[unman]

On Tue, Feb 12, 2019 at 07:37:51PM -0500, preill...@gmail.com wrote:
> 
> 
> There was a page called this that I referred to. 
> https://www.qubes-os.org/secondary-storage
> 
> I don't see that page today.
> 

It's at https://www.qubes-os.org/doc/secondary-storage

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190222110855.3n2fahhvdcuhwpve%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How to set individual VM swap?

[unman]

On Fri, Feb 22, 2019 at 10:11:42AM +, 'awokd' via qubes-users wrote:
> Eric:
> > R4.0 I must be missing something - really quite
> > basic - cannot see how to change the fixed 1GB
> > allocation of swap to each VM on its volatile
> > volume at startup. This is much too small for a
> > larger VM - eg a 6GB f29 VM running leaky
> > software, I notice Swap: 0.0 free and it is then
> > not long before the biggest memory hog gets the
> > bullet from the kernel - out of memory - when
> > the VM is nowhere near thrashing.
> > 
> > I expected either a fixed value for swap or a
> > ratio to maxmem exposed by qvm-prefs. Ratio
> > makes more sense as then inheriting a default
> > from the template should work.  Should be on
> > Qubes Manager/Settings/Advanced tab under maxmem
> > as well.  Is opening an issue warranted?
> > 
> > In the mean time where is this constant defined?
> > 
> > Thanks, Eric
> > 
> https://github.com/Qubes-Community/Contents/blob/master/docs/misc/iaq.adoc#how-can-i-provision-a-vm-with-a-larger-non-standard-swap-and-tmp

The 1G is the partition size set for /dev/xvdc1
Since /dev/xvdc is 10G in size and only 1G is allocated to swap, an
alternative (better?) would be to use that space.
/sbin/swapoff -a
/sbin/parted /dev/xvdc rm 1
/sbin/parted /dev/xvdc mkpart primary 0 10G -s
/sbin/swapoff -a
/sbin/mkswap /dev/xvdc1
/sbin/swapon -a

You can put this directly in to /rw/config/rc.local and it will
reprovision swap on boot, with little effect on boot time.

unman

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190222105740.g2t5wrix732j7jzd%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] how to setup gentoo or archlinux

[unman]

On Thu, Feb 21, 2019 at 12:24:00PM +, marmot-te wrote:
> Hi
> 
> I am stuck with gentoo with the following steps ...
> -creating a HVM with gentoo ISO
> -setup networking ... > many try in conf files without success
> 
> And for archlinux,
> I try to follow the official docs but this seems outdated (qubes v3), I
> cannot achieve the steps
> 
> >$ gpg --keyserver pgp.mit.edu --recv-keys 0xDDFA1A3E36879494
> >gpg: directory `/home/user/.gnupg' created
> >gpg: new configuration file `/home/user/.gnupg/gpg.conf' created
> >gpg: WARNING: options in `/home/user/.gnupg/gpg.conf' are not yet
> >active during this run
> >gpg: keyring `/home/user/.gnupg/secring.gpg' created
> >gpg: keyring `/home/user/.gnupg/pubring.gpg' created
> >gpg: requesting key 36879494 from hkp server pgp.mit.edu
> >gpgkeys: key DDFA1A3E36879494 can't be retrieved
> >gpg: no valid OpenPGP data found.
> >gpg: Total number processed: 0
> >gpg: keyserver communications error: keyserver helper general error
> >gpg: keyserver communications error: unknown pubkey algorithm
> >gpg: keyserver receive failed: unknown pubkey algorithm
> 
> I also try to create a HVM with retroArch iso, successfuly setup
> networking, but, at the end of installation, a reboot is needed and
> after reboot, there is no system installed
> 
> So, do you have any advices for installing and testing this kinds of
> distributions inside QubesOS?

You simply haven't given enough information for me to comment on the
gentoo issue. Generally, you need to run (in dom0) qvm-ls -n gentoo-qube
and note the IP address, and then configure that address and the gateway
in the HVM.

As for arch, I don't know what "official docs" you are using - the Qubes
one?
Be aware that 3.2 will reach eol at the end of next month, so you should
be looking to upgrade to Qubes 4. I believe that arch templates will be
available for 4.
On the specific issue you cite re gpg, neither dom0 nor templates have
network access. You should retrieve the key you want in an online key,
verify its authenticity, transfer it to the offline target, and then add
it to your gpg keyring.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190221134346.tscn3n4ja5xg4f4v%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Whonix Yes or No

[unman]

On Sun, Feb 17, 2019 at 08:50:01PM +0100, r...@posteo.net wrote:
> On 2/17/19 10:49 PM, jrsmi...@gmail.com wrote:
> > Reading through the post questioning the trustworthiness of Whonix, I can't 
> > tell whether we can continue trusting/using Whonix or not.  Can someone 
> > (preferably in a position to speak for QubesOS), please state, in a 
> > straightforward and unambiguous manner, spell this out for us?
> 
> Personally, I don't trust Whonix. The decision to not trust Whonix is
> not based on the sysadmin/aussie issue that came up recently on the
> list. I'm simply not convinced that they are capable of designing and
> writing secure software. Furthermore, there is no reason to use whonix
> in the first place, especially when you are using Qubes. Creating a tor
> netvm is rather straight forward (and a dispvm that includes the Tor
> Browser if you like to use that as well). If there is enough interest, I
> can also write up a summary on how to do that in Qubes.
> 
> Regards

Have you looked at the qubes-tor package and www.qubes-os.org/doc/torvm?
- that page is removed from the menu but still available.
The qubes-tor package is OK but with some tweaking makes a solid
replacement for Whonix gw - certainly for live images and machines with
limited RAM.
imo the decision to deprecate that package and then remove all reference
to it from the docs was a mistake.

unman

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190220021241.ormtmw7yzgwiwmre%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] backup of files in a qube without networking to an internet service

[unman]

On Tue, Feb 19, 2019 at 03:41:23PM +, lik...@gmx.de wrote:
> Hi,
> 
> assume there are files stored in a qube without networking. Furthermore 
> assume there's a secured backup server located in the internet. This server 
> is only a storage of client-side (before data is sent over the wire) 
> encrypted files.  What options do you imagine to backup those files (skip the 
> client-side encryption) to the server?
> 
> I can imagine the following options:
> 1. enable temporary the network with firewall restricted to the server for  
> the (previously offline) qube
>  Advantage: no inter-vm copying of files.
>     Disadvantage: firewall rules must be setup correctly to avoid to bypass 
> any other traffic like icmp/dns etc. I can imaging a potential information 
> leakage due to enabling network access.
> 2. copy files temporary to another qube (dvm?) with a firewalled internet 
> connection
>     Advantage: files not being backed up can stay secured in the non-network 
> cube. Leakage of data is reduced in comparison to 1.
>     Disadvantage: can take time and needs additional disk ressources
> 
> I've learned that you should always find at least 3 options, otherwise you 
> haven't thought hard enough. Which options am I missing?
> 
> Which option would you prefer and why?
> 
> Best, Pete

3. Create encrypted (compressed) backup in offline qube.
qvm-copy backup to online disposableVM.
Copy encrypted file to backup server.

Advantage: All files secured in non-network qube.
Disadvantage: ???

Is inter-vm copying of files really an issue? Free space such an issue?
Using compressed backups should help mitigate this as a serious issue,
but that problem would extend to *all* your Qubes use.

unman

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190220004623.q5vg6vwzhg3r5fv6%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How does Qubes DNS resolving work?

[unman]

On Fri, Feb 15, 2019 at 08:12:35AM +0100, ashleybrown...@tutanota.com wrote:

> > Please don't top post. Take a minute to make it easier for other users.
> > As is clear in another thread, there is a clear warning about DNS on the
> > GUI firewall - I find it hard to believe that anyone could miss this.
> >
> I am new to mailing lists. What does top-post mean? Do you mean don't post 
> the reply at the top of the message and instead at the bottom like this?
> 

That's right, just like that.
It's also acceptable to interleave comments within the text:

> Can you give an example?
Of course, here is one.
> When would you want to do that?
When you want to comment on a number of distinct issues within the post.

It's also good to cut out extraneous material - as I have done here.
Some people cut *all* the previous posts, and that makes it very
difficult to follow what is going on.

Welcome to the lists.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190216023016.4q265tvlk3yobxox%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Is it safe to install Qubes4 on laptop used windows10 before?

[unman]

On Wed, Feb 13, 2019 at 08:55:01PM +, zxcvw...@scryptmail.com wrote:
> Hello All,I have a laptop from family that is rarely used,but with windows10 
> installed on it,arguably the most infamous windows version.If I install 
> Qubse4.0 on this laptop, would qubes completely wipe windows10 away?  Since 
> some hardware's ID numbers are registered with microsoft in update 
> process,and maybe even UUID, would microsoft still be able to track this 
> laptop when it's online?Second option, is to take off the harddrive with 
> windows10 and change to a completely new one purely for qubes. with the 
> concern above still there-the hard ware records---can microsoft track THIS 
> laptop when it's online?* by installed with windows 10 ---I mean it pressed 
> the agree button on microsoft agreement when new laptop   switched on, this 
> stage is offline,  and pressed 'update' button, and fully updated with 
> microsoft and registered with it, this part is online.Please advise, thank you
> 

That's a really good question.
Certainly MS will have some information about the hardware configuration
of that laptop. That doesnt mean that MS would be able to track you
online, but it does raise the issue that IF someone were able to get
information about the hardware and IF they were able to get information
from MS THEN they would be able to trace it back to you.
When you install Qubes there are options to delete existing partitions,
and if you choose to encrypt Qubes (I seem to recall that) the existing
partitions will be overwritten, so the old Windows will be gone.

If you are seriously worried about these issues I would recommend
getting a burner laptop with new drive and look in to the use of
Whonix-Qubes, or Qubes and Tor. If you are just somewhat concerned then to
be honest a simple wipe and install of Qubes would be enough.

unman

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190214161236.y5ewslazpfu4esqn%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How does Qubes DNS resolving work?

[unman]

On Thu, Feb 14, 2019 at 03:05:20PM +0100, ashleybrown...@tutanota.com wrote:
> > The magic is in NAT rules (but I had to research this too.) See 
> > https://www.qubes-os.org/doc/networking 
> > <https://www.qubes-os.org/doc/networking/>, and "sudo iptables -t nat -L" 
> > in sys-firewall and sys-net.
> 
> I previously looked at IP tables and honestly I really do not understand it. 
> Can you please explain a little how it works?
> 
> Here is what my nat look like in sys-firewall:
> 
> Chain PR-QBS (1 references)
> target prot opt source   destination
> DNAT   udp  --  anywhere 10.139.1.1   udp dpt:domain 
> to:10.139.1.1
> DNAT   tcp  --  anywhere 10.139.1.1   tcp dpt:domain 
> to:10.139.1.1
> DNAT   udp  --  anywhere 10.139.1.2   udp dpt:domain 
> to:10.139.1.2
> DNAT   tcp  --  anywhere 10.139.1.2   tcp dpt:domain 
> to:10.139.1.2
> 
> So, when I do ping google.com it needs to do a DNS request. Because my AppVm 
> /etc/resolv.conf is set to 10.139.1.1 it creates a DNS request to send to 
> 10.139.1.1. However, no VM on the network actually has this address.
> 
> Is that packet modified? I am assuming what happens is the packet is 
> forwarded to whoever the internet provider is (in this case sys-firewall). 
> Sys-firewall then forwards it to sys-net. Sys-net then forwards it to the DNS 
> server.
> 
> I am assuming the IP-Header of each hop is rewritten. So, for example, 
> sys-net will rewrite the IP header to be the external IP address for the 
> computer and thus it will receive a response to that IP. Assuming this is 
> correct how does the original AppVM get the correct response? I assume 
> multiple AppVMs are all forwarding these UDP dns requests through 
> sys-firewall and then sys-net. And then when sys-net gets a response how does 
> it know to send which response to which specific AppVM?
> 

Yes, you are spot on. The packet is sent upstream (routing table on
sys-firewall) and hits sys-net.
On sys-net, you'll see in the nat table (I'm assuming iptables on
Debian) rules that rewrite udp/tcp to 10.139.1.1 to use the DNS resolver
provided by the external network.
DNAT   udp  --  * * 0.0.0.0/0    10.139.1.1    udp dpt:domain to:X.X.X.X

These are stateful firewalls that keep track of the packets passing
through them. Sys-net returns the DNS result to sys-firewall and it's
there that the response is matched to the request and sent back to the
originating qube.

hth

unman

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190214155143.6kq4cibl6dp4uhbp%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How does Qubes DNS resolving work?

[unman]

On Thu, Feb 14, 2019 at 03:13:00PM +0100, ashleybrown...@tutanota.com wrote:
> 
> 
> Hopefully one day they revert it back to how it was in 3.2. A very common 
> use-case for the firewall is likely to ensure things like DNS requests do not 
> happen through the normal means (and instead go over something like Tor or a 
> VPN). Unfortunately, the current config does not make it very obvious that 
> someone should block DNS ports. Making it very easy for someone to shoot 
> themselves in the foot because the interface is not intuitive (it says it 
> blocks all traffic other than what is specified and then later modifies this 
> saying "just kidding, we let DNS through")
> 
> Feb 14, 2019, 2:05 PM by ashleybrown...@tutanota.com:
> 
> > > The magic is in NAT rules (but I had to research this too.) See > 
> > > https://www.qubes-os.org/doc/networking 
> > > > , and "sudo iptables -t nat 
> > > -L" in sys-firewall and sys-net.
> >
> > I previously looked at IP tables and honestly I really do not understand 
> > it. Can you please explain a little how it works?
> >
> > Here is what my nat look like in sys-firewall:
> >
> > Chain PR-QBS (1 references)
> > target prot opt source   destination
> > DNAT   udp  --  anywhere 10.139.1.1   udp 
> > dpt:domain to:10.139.1.1
> > DNAT   tcp  --  anywhere 10.139.1.1   tcp 
> > dpt:domain to:10.139.1.1
> > DNAT   udp  --  anywhere 10.139.1.2   udp 
> > dpt:domain to:10.139.1.2
> > DNAT   tcp  --  anywhere 10.139.1.2   tcp 
> > dpt:domain to:10.139.1.2
> >
> > So, when I do ping google.com it needs to do a DNS request. Because my 
> > AppVm /etc/resolv.conf is set to 10.139.1.1 it creates a DNS request to 
> > send to 10.139.1.1. However, no VM on the network actually has this address.
> >
> > Is that packet modified? I am assuming what happens is the packet is 
> > forwarded to whoever the internet provider is (in this case sys-firewall). 
> > Sys-firewall then forwards it to sys-net. Sys-net then forwards it to the 
> > DNS server.
> >
> > I am assuming the IP-Header of each hop is rewritten. So, for example, 
> > sys-net will rewrite the IP header to be the external IP address for the 
> > computer and thus it will receive a response to that IP. Assuming this is 
> > correct how does the original AppVM get the correct response? I assume 
> > multiple AppVMs are all forwarding these UDP dns requests through 
> > sys-firewall and then sys-net. And then when sys-net gets a response how 
> > does it know to send which response to which specific AppVM?
> >
> > -- 
> > Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: 
> > https://tutanota.com 
> >
> >
> > Feb 14, 2019, 11:46 AM by > qubes-users@googlegroups.com 
> > > :
> >
> >> ashleybrown...@tutanota.com >>  wrote 
> >> on 2/14/19 6:28 AM:
> >>
> >>> When I look at /etc/resolv.conf in the following VMs it says different 
> >>> things:
> >>>
> >>> 1) Normal AppVM:
> >>>
> >>> nameserver 10.139.1.1
> >>> nameserver 10.139.1.2
> >>>
> >>> 2) Sys-firewall VM:
> >>>
> >>> nameserver 10.139.1.1
> >>> nameserver 10.139.1.2
> >>>
> >>> 3) Sys-net VM:
> >>>
> >>> [actual resolvers]
> >>>
> >>> The chain for DNS packets is obviously AppVM -> Sys-firewall -> sys-net
> >>>
> >>> However, what I don't undersatnd is that 10.139.1.1 does not exist. That 
> >>> is not the IP address for any VM on the network. This can  be verified in 
> >>> Qubes Manager looking at the IP column. In addition, 10.139.1.1 refers to 
> >>> different VMs depending on the VM sending the packets. In AppVM it routes 
> >>> to sys-firewall. In sys-firewall it routes to sys-net.
> >>>
> >>> So, my question is how does all of this work? Where exactly does any 
> >>> request to 10.139.1.1 route to the actual connected VM. Looking at IP 
> >>> table rules I do not see where traffic sent to 10.139.1.1 goes to 
> >>> [sys-firewall IP here] for example. It appears to be doing it all 
> >>> magically, so where is the magic?
> >>>
> >>
> >> The magic is in NAT rules (but I had to research this too.) See >> 
> >> https://www.qubes-os.org/doc/networking 
> >> >> , and "sudo iptables -t nat 
> >> -L" in sys-firewall and sys-net.
> >>

Please don't top post. Take a minute to make it easier for other users.
As is clear in another thread, there is a clear warning about DNS on the
GUI firewall - I find it hard to believe that anyone could miss 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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the 

Re: [qubes-users] Valid Concerns Regarding Integrity of Whonix Project

[unman]

On Thu, Feb 14, 2019 at 04:29:45PM +1100, haaber wrote:
> Are canaries now  "illegal" in Aussi law as well ???
> 
> On 2/14/19 3:26 PM, teresardavida...@gmail.com wrote:
> > Summary: I have reason to believe the possibility that Mig5 (the new 
> > SysAdmin on Whonix project) could be compelled under federal law to provide 
> > assistance is high and the threat to the security and anonymity offered by 
> > the project could be compromised as a result is also high.
> > 
> > I recently visited the Whonix community website for an unrelated purpose 
> > and discovered something that I think in honest to good faith deserves 
> > public discussion.
> > 
> > I was alarmed and shocked to see my post abruptly deleted and my account 
> > permanently disabled.
> > 
> > I would like to post my thoughts here to the Qubes User community for 
> > further scrutiny and discussion and perhaps maybe get the attention of the 
> > project maintainer who I do see regularly participate on this channel.
> > 
> > Below is a copy paste of the submission which was deleted from the Whonix 
> > community forum.
> > 
> > [Quote]
> > This post is in no way doubting the integrity or calling into question the 
> > character of Mig5 the new sysadmin for the whonix project.
> > 
> > But I do feel it is necessary to point out that the new sysadmin is 
> > Australian (or resides in Australia). Under Australian law, he can be 
> > compelled through threat of imprisonment to cooperate with the Australian 
> > government. This law is designed to compel individuals that work on 
> > projects such as Whonix to insert or write code that permits lawful access. 
> > If a person is served with such enforcement, they are required to keep it 
> > secret or risk imprisonment.
> > 
> > This law was only recently introduced and is already being used to great 
> > effect according to recent reports.
> > 
> > While Whonix is an open-source project it is important to remember that 
> > open source does not imply greater security. One only needs to consider one 
> > of the most widely used and scrutinized open source projects (OpenSSL) had 
> > a backdoor that went undetected for several years. It was just two lines of 
> > code. It literally broke the internet.
> > 
> > I deeply regret having to bring this to the attention of the community 
> > please do not interpret my thoughts here as a question of Mig5's character. 
> > I value all contributions but believe the circumstances and severity of the 
> > consequences warrant public discussion. The bottom line is, as the law is 
> > written, he would be required to cooperate and in secret. I think someone 
> > like him, in a position he now occupies, represents a textbook example of 
> > why this law was written in the first place. In my opinion, it is not a 
> > question of "if" he is compelled but rather just a matter of "when".
> > 
> > Unfortunately it is not uncommon for Whonix to be encountered by forensic 
> > analysts who have the regrettable job of investigating computer equipment 
> > seized by suspects charged with child abuse related offenses. At least not 
> > in Australia. I can say with certainty this project already has high 
> > visibility among specific cyber investigative divisions within both state 
> > and federal AG. I do not have any classified information I can share and if 
> > I did I would not share it but I can provide some information in private to 
> > Patrick that taken to its logical conclusion would suggest this project is 
> > likely to be a high priority target for these new laws.
> > 
> > [/Quote]
> > 

Please dont top post.

Whonix does not use canaries, as you can see here:
https://forums.whonix.org/t/whonix-warrant-canary/3208

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190214153956.uxhpkrzqkfuihqpk%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] why was DNS/ICMP removed from Qubes manager/firewall in R4?

[unman]

On Thu, Feb 14, 2019 at 03:13:50PM +0100, ashleybrown...@tutanota.com wrote:
> Hopefully one day they revert it back to how it was in 3.2. A very common 
> use-case for the firewall is likely to ensure things like DNS requests do not 
> happen through the normal means (and instead go over something like Tor or a 
> VPN). Unfortunately, the current config does not make it very obvious that 
> someone should block DNS ports. Making it very easy for someone to shoot 
> themselves in the foot because the interface is not intuitive (it says it 
> blocks all traffic other than what is specified and then later modifies this 
> saying "just kidding, we let DNS through")
> 
> Feb 14, 2019, 11:59 AM by simon.new...@gmail.com:
> 
> > On Thursday, February 14, 2019 at 11:54:28 AM UTC, simon@gmail.com 
> > wrote:
> >
> >> > On Wed, Feb 13, 2019 at 08:42:10AM -0800, >> simon.new...@gmail.com 
> >> > <mailto:simon.new...@gmail.com>>>  wrote:
> >> > > In 3, if i clicked on "block connections" in the Qubes manager 
> >> > > firewall section, there was (if memory serves me) an option to block 
> >> > > DNS and ICMP. 
> >> > > 
> >> > > That is not present in R4 (though docs say you can disable DNS and 
> >> > > ICMP manually)
> >> > > 
> >> > > I'm just wondering what the logic behind the removal was? I would have 
> >> > > thought that a general user who clicks "block connections" on Qube 
> >> > > would not expect the qube to be able to actually send out and receive 
> >> > > network packets such as DNS or ICMP. This presents information leakage 
> >> > > scenarios (default DNS lookups of given qube) and also potential 
> >> > > egress vectors if a qube is ever compromised (DNS tunnelling, ICMP 
> >> > > tunnelling). 
> >> > 
> >> As I said, I understand the documentation is correct. thats not my 
> >> question. My question is why was it removed as an option when the firewall 
> >> box itself in network manager says "Deny network access except..." 
> >>
> >> My point is it is counter intuitive. If it says "deny network access 
> >> exccept..." then there is an expectation that it will deny network access 
> >> except for what is specified. There used to be tick buttons (allow 
> >> updates/allow ICMP/allow DNS), which made it clear on the granular control 
> >> there - but were removed in R4. The underlying subsytems you can still do 
> >> that, sure. 
> >>
> >> Can I suggest that the wording "deny network access except..." is changed 
> >> to "Deny TCP and UDP access except ..." for the avoidance of any doubt.
> >>
> >
> >
> > https://github.com/QubesOS/qubes-manager/pull/153 
> > <https://github.com/QubesOS/qubes-manager/pull/153>
> >

Please dont top post - it breaks the thread of the conversation.

I dont find the current position confusing, since the DNS and ICMP
position is clearly stated in the NOTE at the bottom of the window.

Simon, to answer your original question, there are many features in 4.0
which are aimed at simplifying use of Qubes. I think this is one of
them.
The underlying issue is this: if you want to set a firewall rule using a
named site, then you must not only  set the rule, (and the resolution
will be set at the upstream firewall), but you must also enable DNS -
otherwise your qube will not be able to resolve the address, even
though you have correctly set the firewall rule.
This adds a layer of complexity which a naive user would not understand.

The decision was made to keep DNS open in a trade off between usability
and security.
There's also an underlying assumption that users who want more will be
able to negotiate command line tools. This assumption may be misplaced.
There are many users (not only of Qubes) who consider themselves "power
users" (never understood what that meant), but dont seem able to
understand iptables or use anything except a GUI. (Just to be clear, I'm
not aiming at any contributor here.)

As for ICMP, it's a moot point whether you should ever block ICMP at
firewall level. Again, the benefit of having ICMP enabled is that basic
network mechanisms are enabled, and basic diagnostic tools are
available. It's a trade off between security and usability.

As with *all* parts of Qubes, if you dont like the defaults change them
on your system.
If you like, propose a change by submitting a PR.
There's an open issue on exactly this, where Marta outlined the issue and
invited contributions that would allow the c

Re: [qubes-users] qvm-copy-to-vm question

[unman]

On Wed, Feb 13, 2019 at 08:12:42PM -0800, Todd Lasman wrote:
> 
> On 2/13/19 3:18 PM, 'awokd' via qubes-users wrote:
> > Todd Lasman wrote on 2/13/19 1:58 AM:
> > > I'm not sure if I'm doing this correctly.
> > > 
> > > According to the usage, the syntax is:
> > > qvm-copy-to-vm destination_qube_name FILE
> > 
> > > All I want to do is copy a file from one qube to the next without
> > > hassle. Suggestions?

You can suppress the prompt by setting rules in
/etc/qubes-rpc/policy/qubes.Filecopy
So if you have in that file:
qube1 qube2 allow
In qube1 you can use qvm-move-to-vm qube2 foo and no prompt will appear.

The prompt appears because either you have not specified a target qube
or you have not given appropriate permissions.

unman

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190214151214.mrzmsbxkexui4tgk%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How secure is a VM if a user tries to tampers it?

[unman]

On Fri, Feb 08, 2019 at 07:07:45PM -0500, Chris Laprise wrote:
> On 2/8/19 5:12 AM, Francesco Frassinelli wrote: > > Feb 8, 2019, 10:42 AM by 
> qubes-...@tutanota.com
> > :
> >  > Feb 8, 2019, 9:05 AM by frap...@gmail.com :
> >  >
> >  > > Hi!
> >  > >
> >  > > The system administrators working in my company do not want to let
> > user access to the internal network with OS that are not under their
> > control and they only support Windows at the moment.
> >  > >
> >  > > I would like to propose QubesOS as an alternative, with a Windows
> > VM managed by them inside it, connected to the internal network via VPN
> > (we already have this VPN in place for accessing the internal network
> > while working outside of the building). In addition to this, users could
> > run the operating systems and the applications they want in different
> > VMs, thanks to QubesOS features.
> >  > >
> >  > > The system administrators would not have to support QubesOS, just
> > the Windows VM, but this solution could only be accepted if I am able to
> > show that there is a reasonable guarantee that tampering the Windows VM
> > from QubesOS is as hard as tampering the same Windows system installed
> > on a regular machine (with secure boot, hardware encryption, etc.).
> >  > >
> >  > >
> >  > > My question is: how secure is a VM if a user tries to tampers it?
> > Is SGX a technology that can be used to provide that level of security?
> > If so, is it used by QubesOS at the moment?
> >  > >
> >  > >
> >  > > Any suggestion, comment or link would be greatly appreciated.
> >  > >
> >  > >
> >  > > Frafra
> >  > >
> >  >
> >  > It shouldn't be an issue as employees were already given a certain
> > level of trust in the organozation, based on their position and
> > competencies. Employee with malicious intent can easily break into the
> > current setup too, like copy and paste, deal with the critical
> > information with malicious intent. Adding Qubes to the trusted setup
> > doesn't make the situation significantly worse. It should, on the other
> > hand, significantly increase the security of the endpoint, if set up
> > properly.
> >  >
> >  > The issue you mention is more about trust in employees, the trust
> > model, than about selected OS in usage.
> > 
> > The problem is that there are cryptolockers, phishing email, and so on,
> > and some users are more vulnerable than others (a developer has a
> > different background compared to an accountant), but it has been decided
> > that is better not to differentiate between users ("your colleague can
> > install whatever you want and you cannot") and keep a stricter security
> > policy allowing only pre-approved OS on the internal network.
> 
> Thinking about the threat model, qubes-fan's advice makes a lot of sense.
> 
> With a regular Windows laptop the company admins are already trusting you
> with physical access. That is a lot of power. So the question is why
> wouldn't this trust extend to a Windows VM on Qubes, which has superior
> protection from any remote attacks?
> 

It seems to me that Qubes simply doesn't fit the bill, and *does* make
the situation significantly worse.
OP said that:
"The system administrators working in my company do not want to let
user access to the internal network with OS that are not under their
control and they only support Windows at the moment."

In order to give the Windows qube access to the internal network, on a
standard install, the Windows qube would be proxying via sys-net, an OS
"not under their control" so that is a non starter.
One way to work around this would be to directly attach network device
to Windows qube. But what's the point then? Unless one had another NIC
to attach to sys-net which could NOT connect to the VPN(I mean
absolutely could not) then one would not be able to use those other
qubes online.

The other reason that Qubes would not be suitable is this: OP said -
"The system administrators would not have to support QubesOS, just
the Windows VM, but this solution could only be accepted if I am able to
show that there is a reasonable guarantee that tampering the Windows VM
from QubesOS is as hard as tampering the same Windows system installed
on a regular machine (with secure boot, hardware encryption, etc.)."

I read this as saying that the protection from tampering should extend
to OP as well as other users. Can OP give that reasonable guarantee? Of
course not. The way that Qubes is structured means that any user would
be able to "tamper with the Windows VM" or subvert any controls placed
on that VM by the company administrators.
A hardened locked down Windows install provides significant protection
against users, who simply do not have "a lot of power". Qubes puts
control in the hands of the user, and that, it seems to me, is exactly
what the system administrators dont want to provide.

I'm not saying that it's a complete no go. I have no doubt that it may
be 

Re: [qubes-users] Re: why mail-list?

[unman]

On Wed, Feb 06, 2019 at 10:15:54AM -0600, John Goold wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 2/6/19 1:12 AM, 'awokd' via qubes-users wrote:
> > kitchm via Forum:
> > 
> ...
> >> It is currently illegal by federal law to clear your browser 
> >> history.
> > 
> > Cite?
> 
> What one does with one's browser history, even assuming one's browser
> has a browser history, is clearly not governed by law, except perhaps
> in countries like China and Russion.
> -BEGIN PGP SIGNATURE-
> 
> iQEzBAEBCAAdFiEEe8Wcf7Po7bts2Rl4jWN9/rQYsRwFAlxbCDgACgkQjWN9/rQY
> sRwFfQf+MRGgCma20R/XDSkO0X94ul0kb8p/GfUBQbw7/bbdNKXtawkUtzGqe44I
> IExLLsikRRTdHGIMvHVpBXNjQGm2Qh6MdL4v+cd/CN2vtj5Yh2ifk5OF5xt5hb0A
> EX+8EYoo5GoF+2urI3IU6NTKBL0tCDiKIcjVIMuxg9ah0mo1QTO5+ewlX5AGlyLS
> c2dVDHB3svCIKQ9xrHZxcNLL3WKL6lrOwP/oGuM6NLGJtnBDbS7ihkJA1GMu7m5H
> 3hHQFq7vb8/6vNf6L8jqC3MPDbp/zXXwCk1UjLofnbUX+ExVDKPZF43qI8yMiGwN
> UkdsgfCZfIQjh1jKGDXhJ2/xyhySvw==
> =zjDq
> -END PGP SIGNATURE-

Actually, it may be governed by law in the US, but not in Russia.
The  FBI have interpreted Sarbanes-Oxley as creating a
felony offence where one deletes browser history where there was
reasonable expectation of investigation.
It has been used against Matanov, a friend of the Boston bombers, and
David Kernell, who hacked Sarah Palin's email.
The EFF have highlighted this interpretation of Sarbanes Oxley as
egregious, but no doubt the authorities deem it necessary.

Note that it is NOT illegal in the US to clear your browser history:
but it may prove a felony offence to do so. In the two cases cited there
were reasonable grounds to suppose that a federal investigation would
take place.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190206163608.t24cbnwjpkffsomp%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: SECURITY ALERT

[unman]

On Tue, Feb 05, 2019 at 12:21:53PM -0500, kitchm via Forum wrote:
> Andrew, thanks for that.  Much appreciated.
> 
> unman, this has nothing whatsoever to do with google groups,
> and of course should not.  Computer users know that to find
> out about a canary, one always goes to the web site.  If you
> had bothered to learn about how these things work it would
> have helped us all.

I suggested that you should have looked at the archives before posting
FUD.
Qubes canaries are published through the Qubes Security Pack -
https://github.com/QubesOS/qubes-secpack
They are also posted to the qubes-users and qubes-devel mailing lists
and Andrew also posts them to reddit, I believe. But imo the secpack
takes primacy. Perhaps you could check there in the future.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190206000336.n3lj5fme2rbcztbr%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] USB qube when installed on external SSD

[unman]

On Mon, Feb 04, 2019 at 12:34:28AM -0800, newqubesu...@gmail.com wrote:
> So, quick question that I can't find asked anywhere. I'm installing qubes. 
> Hopefully for the last time. I'm wondering if I can create the USB qube when 
> I'll be booting from an external SSD. I'm thinking no because it would 
> potentially cut itself off... If I'm right about this, is there another way 
> to securely use USBs? Or maybe make the qube, but omit the SSD?
> 

The answer depends on how many USB controllers you have.(I'm assuming
that your SSD is connected via USB, although you dont actually say
this.)
If you only have one controller, then you're right about cutting it off.
If you have two you can allocate one to sys-usb, and connect other USB
devices to it.
Look at www.qubes-os.org/doc/usb and
www.qubes-os.org/doc/assigning-devices/ for advice on identifying USB
controllers. 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190205004936.ajx67uithznjfrso%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Debian minimal template

[unman]

On Tue, Feb 05, 2019 at 11:34:24AM +1100, haaber wrote:
> > On Mon, Feb 04, 2019 at 04:47:44PM +1100, haaber wrote:
> > > Hello, does someone know if the debian-9-minimal template is pre- or
> > > post-  APT-vulnerability? Is it being "maintained" as well as debian-9
> > > itself?  Thank you, Bernhard
> > > 
> > > 
> > 
> > The debian-9-minimal template in the templates-itl-testing repository
> > (201901271906) is post-APT vuln.
> > It is maintained in precisely the same way as debian-9 itself.
> > 
> thank you unman. I tried to use it as sys-net, but
> 1) network-manager did not start on boot
> 2) when starting it by hand, I got the impression that the
> network-manager data is stored elsewhere under debian than under fedora
> - to the effect that I lost all saved wireless connections!
> 
>  Is there an easy way to cure that?  Bernhard

Andrew has quite correclty pointed out the complete absence of any
documentation on how to use the debian-9-minimal template. I'll try to
remedy this soon.
In the meantime you could follow the guidelines for using the
fedora-minimal template. (Apologies if you've already done this.)

The wireless connection information is actually stored under /rw/config , so it
wont be lost.(Check it's there)
In Debian, Network manager information is held under
/etc/NetworkManager, which is, I would have thought, the same as Fedora.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190205004243.u3cfklfh26colrrk%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How to do the extra configuration needed on a new template

[unman]

On Sun, Feb 03, 2019 at 10:16:55PM -0800, Sphere wrote:
> So I got a new Fedora-29 template but the problem is that after assigning it 
> to sys-net/sys-firewall all it shows is something similar to what you when 
> you start a generic PC after BIOS POST.
> 
> All that's in this link:
> https://www.qubes-os.org/news/2019/01/07/fedora-29-template-available/
> 
> Is how to get the template but I don't think I found anywhere detailing what 
> to do afterwards.
> 

I'm not clear what you mean by this: "what you when you start a generic
PC after BIOS POST".

Once you have installed the template (with dnf or qubes-dom0-update),
then all you have to do is assign it to qubes as required. Those qubes
will then start using the assigned template.
You can confirm this by opening a terminal in sys-net and observing
contents of /etc/fedora-release

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190205003525.oyr2mp4iduk4w4me%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Debian minimal template

[unman]

On Mon, Feb 04, 2019 at 04:47:44PM +1100, haaber wrote:
> Hello, does someone know if the debian-9-minimal template is pre- or
> post-  APT-vulnerability? Is it being "maintained" as well as debian-9
> itself?  Thank you, Bernhard
> 
> 

The debian-9-minimal template in the templates-itl-testing repository
(201901271906) is post-APT vuln.
It is maintained in precisely the same way as debian-9 itself.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190205003051.qrtxfivfjbksy34f%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Borked template vm

[unman]

On Sat, Feb 02, 2019 at 03:27:00PM -0600, Stuart Perkins wrote:
> 
> 
> On Sat, 2 Feb 2019 14:08:27 -0600
> Daniel Allcock  wrote:
> 
> >Hello all,
> >
> >I seem to have borked a template vm, to the point that no applications
> >will start and I can't even use qvm-run from dom0 to do anything, not
> >even touch a file.  There is one directory in 
> >the root of the filesystem that contains
> >a ton of config info that I would like to recover.  I'd
> >appreciate any help.
> >
> >If I start an app in this vm from the Q menu then
> >I get notification that it has started, and the vm does appear in the
> >system tray VM management widget, but nothing else seems to happen.
> >Halting the vm gives notification
> >that the vm is stopping, and then the vm disappears from that widget.
> >
> >Here is what I have thought of so far. 
> >
> >(1) I imagine there is a way to mount a template vm's root filesystem, 
> >either in dom0 or in another vm.  I couldn't find docs on that.
> >
> >(2) I made a backup of that vm to another vm, and then used the
> >emergency recovery method from
> >https://www.qubes-os.org/doc/backup-emergency-restore-v4/
> >to produce files containing the borked template's root and private
> >filesystems.  Following the instructions there allowed me to mount
> >the private filesystem and access its contents.  But the config
> >stuff that I want to recover lies in the root filesystem, and I
> >was unable to mount it: 
> >
> >$sudo mount -o loop vm1/root.img /mnt/img
> >mount: /mnt/img: wrong fs type, bad option, bad superblock
> >on /dev/loop0, missing codepage or helper program, or other error.
> >
> >(This works fine with root replaced by private.)  As a further 
> >strangeness, the "file" command thinks root.img is dos:
> >$ file vm1/root.img 
> >vm1/root.img: DOS/MBR boot sector, extended partition table (last)
> >
> >Adding "-t vfat" to the mount command doesn't change the failure.
> >On the other hand, "file" recognizes private.img as an ext4
> >filesystem.
> >
> >Am extremely confused and a bit worried!  Help very much appreciated.
> >Daniel
> >
> 
> If all else fails, use qvm-block -A to attach the drive image to a different 
> vm in order to recover information off of it.
> 

You need to get the partitions in the root image, and then mount them
to your recovery qube, like this:
losetup -P /dev/loop1 /dev/qubes_dom0/vm-debian-9-root
qvm-block a qube dom0:loop1p3 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190203011153.7syukcoe766egyaf%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Mounting 'WD Unlocker' (Encrypted External HDD) Qubes 4

[unman]

On Sat, Feb 02, 2019 at 09:51:33PM +, 'awokd' via qubes-users wrote:
> OGBaby wrote on 2/2/19 9:47 PM:
> > On Saturday, February 2, 2019 at 1:57:42 PM UTC-6, OGBaby wrote:
> > > How does one mount a 'My Passport Ultra' encrypted drive with qubes 4?
> 
> > > How does one enter the pass-phrase for an encrypted Passport drive? When 
> > > Attaching 'sys-usb:sda' nothing appears within the file manager. The 
> > > drive is functional and contains media.
> > 
> > It's weird, i'm seeing references here and elsewhere for passport drives 
> > with qubes but none of the posts mention mounting the unlocker..?
> > 
> 
> I doubt the WD proprietary software is Linux compatible. I think what most
> do is disable the WD encryption and format the entire external drive with
> LUKS software encryption instead.

I've had some success with this:
https://github.com/0-duke/wdpassport-utils
ymmv

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190203010050.53mwokepdeun65ai%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] SECURITY ALERT

[unman]

On Thu, Jan 31, 2019 at 01:46:50PM -0500, kitchm wrote:
> There has been no promised canary published, so users must
> assume that the authorities have issued warrants to the
> administration.
> 
> Warning to everyone!

I realise that you find the google groups mailing list difficult to
deal with, but if you had bothered to search the archives you would
have found the canary was issued to this list on Jan 9th.

Canaries are also issued in the qubes security pack , at
https://github.com/QubesOS/qubes-secpack. Again, you would have found
Canary#18 was issued there and signed on Jan 8th.

No warning necessary.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190203004438.2pljj7cqejy6hqx5%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?

[unman]

On Mon, Jan 28, 2019 at 01:44:37PM +, 'awokd' via qubes-users wrote:
> unman wrote on 1/27/19 5:21 PM:
> > (As an aside I'm always baffled by people querying
> > how they can use Facebook under Tor or Whonix. What are they thinking?)
> 
> There are good reasons for it. See
> https://www.wired.com/2014/10/facebook-tor-dark-site/ for example. To the
> thread's topic, using Debian's onion repositories helps avoid MITM attacks.
> Of course, can't protect against compromise of the repositories themselves,
> but that's not a problem that can be solved at the communications layer.

You missed my point because I wasn't clear enough.
I know that Facebook is accessible over Tor.
But why would anyone concerned with privacy ,(presumably why they are
using Tor or Whonix), want to sup with the devil of Facebook? I don't
think any spoon is long enough, not even one passing through 3 hops.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190201160520.sngsqzec3ykz47mh%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] why mail-list?

[unman]

On Thu, Jan 31, 2019 at 10:33:33PM -0300, Franz wrote:
> On Thu, Jan 31, 2019 at 2:11 PM Stuart Perkins 
> wrote:
> 
> >
> >
> > On Thu, 31 Jan 2019 18:01:58 +0100 (CET)
> > 19hundreds <19hundr...@tutanota.com> wrote:
> >
> > >
> > >I agree at some level with what you are saying however, the current
> > mailing list has a lot of valuable information so I believe it's gonna be
> > hard to se it replaced with something else.
> > >
> > >Beside the unofficial resources listed by others, I add
> > https://reddit.com/r/qubes  (it's SO
> > comfortable!)
> > >
> >
> > Some of us who keep e-mails off line have the additional benefit of having
> > an archive of all e-mails since joining the list.  I can search them for
> > something BEFORE asking a new question.  I have done so with this group a
> > few times already and not had to bother asking something which was already
> > asked and answered.
> >
> > I use claws-mail to retrieve all of my e-mails (about 27 different e-mail
> > accounts...one paid for [legal expectation of privacy] and several
> > gmail/hotmail/yahoo) and since claws-mail is configured to store e-mails as
> > discrete files, I can search them with grep and other *nix utilities.  I
> > have an archive going back almost 30 years with over 700,000 discrete
> > e-mails from the many groups I used to belong to, as well as private
> > stuff.  It is far easier to just store them than to sort through them for
> > deletion...but they are organized by folders/directories to make it easy to
> > ignore the ones not pertinent for the time.
> >
> >
> Unbelievable!! I always thought that the only practical way to retrieve old
> emails was using a google account, but you seem to suggest that you are
> able to do the same  with claws-mail. How much space does 700K emails take?
> Because you seem to keep them on your computer, correct? And does the
> search of old emails work as convenient as google?
> 

mutt+notmuch

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190201121026.okiazkivpc7ae6vg%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: why mail-list?

[unman]

On Thu, Jan 31, 2019 at 09:47:33PM -0500, kitchm wrote:
> The basic concept here is clarify what is being discussed. 
> There appears to be two things; one is how a mail-list works
> and the other is how a mail-list is not as good as a forum.
> 
> Being able to retrieve old e-mails assumes one has a mail
> store.  Either one keeps them on their own computer by
> downloading them from the server thru POP3, he accesses them
> from the server by IMAP or she has to access a mail-list
> server so see them thru the web interface.
> 
> In the case of the mail-list server, one may also use his or
> her own e-mail client program, such as Thunderbird, Claws or
> other program.  Both of these programs can handle newsgroups
> and Usenet listings.
> 
> Google bought Dejanews archives of the postings on Usenet. 
> They then started Google Groups while still maintaining a
> gateway to Usenet.  It makes some sense that if one can
> handle newsgroups then one should be able to handle
> googlegroups.  Sadly, such is not the case.
> 
> Being Google, they opted for a proprietary setup and do not
> allow access like the standard methodology of the Usenet. 
> Another strike against Google.
> 
> Therefore, there is no reason to use Google Groups at all. 
> If I have to go to another program to view the information
> shared between people, then I will use a forum.  At least I
> can see that in a properly graphical way.  Not only that,
> but all postings after my initial one will come right to my
> e-mail client.

Thank you for the education. 
You can interact with the googlegroups list entirely through email.
If you want to use a forum use Zrubi's:
https://qubes-os.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190201120924.bbxmlo4eokx32gdg%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: why mail-list?

[unman]

On Thu, Jan 31, 2019 at 11:39:42PM -0500, Eric wrote:
> What is all the fuss about? I am replying here from the
> Qubes user forum that is integrated into the mailing list
> since October last year. A link to this thread:
> https://qubes-os.info/index.php?t=msg=650=0;
> This forum is currently unofficial but seems to work fine.
> Only has a few months worth of data so far but a Google
> search pulls up the groups entries for older stuff.

Indeed- what *is* the fuss about..
The main users list is available as a google group - you can use that
as a mailing list, or using the web interface. You dont need a google
account.
Thanks to Zrubi's efforts, the same content is available as a standard
Forum.
The content is also available archived at
https://www.mail-archive.com/qubes-users@googlegroups.com/
(The content also used to be available via Gmane before the breakage.)

All this is explained at:
https://www.qubes-os.org/support/

To anyone who cant search their archived mail, just one word
(two?):notmuch.

unman

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190201120457.aqbthz5notixtbh7%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Reversing dom0 testing repo installation

[unman]

On Wed, Jan 30, 2019 at 03:28:17PM +0100, qubes-...@tutanota.com wrote:
> 
> Just a humble reminder for my question. I tried to research the topic, but 
> didn't move anywhere. Can anyone advice me please?
> 
> Jan 28, 2019, 3:59 PM by qubes-...@tutanota.com:
> 
> > hi, I accidentaly downloaded and installed the dom0 update from the testing 
> > repo. Is there any way to reverse the action and keep only the stable 
> > version?
> >
> > I already disabled the testing repo in the /etc/yum.repos.d/qubes-dom0.repo
> >
> > Thank you
> >

Check /var/log/dnf** to see exactly what changes have been made to your
system

If you are using a Fedora based qube as UpdateVM, then you can use the
downgrade option:
qubes-dom0-upgrade action=downgrade 

I'm not familiar with this and don't use it. It isn't an option if you are
using Whonix or another Debian based UpgradeVM

In that case, you can get a list of all the available versions:
qubes-dom-update --action=list --showduplicates 

And then should be able to install a specific version:
qubes-dom-update package-version

It's a little more long winded, but you are exercising full control.
Hope that helps somewhat.

unman

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190131150632.tjsrviwzynazcnp3%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: hcl for qubes 4.0 or 4.0.1 is it good?

[unman]

On Thu, Jan 31, 2019 at 11:50:13AM +0100, Zrubi wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 1/31/19 11:45 AM, Panini Panini wrote:
> > 16GB RAM doesnt work fine? and a ssd with 500gb instead of hdd will
> > be more good?
> 
> 16GB is fine, but the more is the better ;)
> SSD is a must.
> 
> - -- 
> Zrubi
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCAAdFiEEmAe1Y2qfQjTIsHwdVjGlenYHFQ0FAlxS0t8ACgkQVjGlenYH
> FQ3upBAApx/izY/jRjiIDxTlPlQLyJlZ8ixQ3bhE2alRPTsNsjoqRGDYUs9LIPtN
> 6zUxocd+OKWQha5YD83L4X5bVx32UPYveihg32eDXXfCQLSl5vqPt/76kMcODi2a
> vPZOan28TqGHPBybKbo41sGEKvOdsfZASJryRkfsp1j7DMEVprsTuQHMKrtLjyvb
> +OCkBdvtUv3DUap6Y2vxEhCAklSE8XsO+GHFBpim1mJliHRw9sv0NcXDb1SrkVhi
> vAROGSv5qVfucelQfUSpZhBMyl0ivuWaVjqEDwWloGMFXtzA0WZgVKfMUpVGQ83Y
> hEaByR9DTe4WtrWBUx7Zpcme2oBGOmFmEiDG3NBWtrt7V7vf8V222hNl/d6M0aX4
> RauWy6+2BoNj5Cig7O4tfyZ8be3+xKpSRh97vhoW041jvVQyhuYkOM3S93VTgDDd
> WfvlWZZZfGa8YzONNCSE7k/kFEVPQnyB9TkY343xLhQT8af7zeYyesKCm+3aVhtR
> x/e58QeKmx1yBxIWM5Ww50jqXqiQDuZHB96Grzr3Hz4Y7FmEbpgCd+g5B4wIuKX+
> iDfYTIEtEdIUjXwFcYRC5q4v8mamiU26X7VoQ6WGw0WK+jN2BAy6xnEHh14Ads/+
> ncZOzv7p//SxfkdZ0e36X6GsVgDFV8Tslzx7p31tuKmbL+JX7AM=
> =J6+L
> -END PGP SIGNATURE-

I know many people using Qubes 4 with 12GB and HDD, without issues.
SSD is better, but not a must.


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190131143250.4ljtch4vo2swkcpw%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?

[unman]

On Mon, Jan 28, 2019 at 01:30:29PM -0800, goldsm...@riseup.net wrote:
> On 2019-01-28 19:46, billol...@gmail.com wrote:
> > On Monday, January 28, 2019 at 10:27:32 AM UTC-5, gold...@riseup.net wrote:
> >> On 2019-01-27 19:15, billol...@gmail.com wrote:
> >> > On Sunday, January 27, 2019 at 12:22:03 PM UTC-5, unman wrote:

> To Billollib
>  
>  First, Its disappointing you didn't apologise for hijacking my thread.
>  
>  Second, you complain I misrepresented you in my summary. Perhaps you
> forget writing the following: " I used to do
> > > network security for a small scientific government network back in the
> > > 1990s, and I constantly ran into the problem that there is an inverse
> > > relationship between security and usability.  The scientists on my
> > > network were constantly finding ways of going around whatever security
> > > measures I put in place precisely because they didn't want to deal
> > > with the "hassle."
> My summary of the above was: "It's the Users of software that subvert
> OS's.". I think that's a fair summary of what you said about Users -
> in this case scientists.
> 
> Finally: Please, no further hijacking of other peoples posts
> 

To state the obvious it's not your thread, and no one need apologise for
commenting, or taking the discussion in a new direction.
I doubt that Billollib "forgot writing" anything. I assume that he felt
that you represented him, and you had missed the point of what he wrote.
Let's try to be civil please.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190130002519.cyq5axyfci4mhad7%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?

[unman]

On Sun, Jan 27, 2019 at 02:37:16AM -0800, goldsm...@riseup.net wrote:
> On 2019-01-27 01:34, unman wrote:
> > On Sat, Jan 26, 2019 at 04:39:45AM -0800, goldsm...@riseup.net wrote:
> >>
> >> Am I right in thinking  that the recently discovered apt vulnerability
> >> (DSA 4371-1) in Debian based systems could and should have been
> >> mitigated against many years ago  by downloading and activating an apt
> >> package; "apt-transport-https", which forces apt updates via https? The
> >> researcher (Max Justicz) who discovered the vulnerability has stated it
> >> couldn't have been exploited if https had been implemented.
> >>
> >> If "apt-transport-https" is the magic bullet, why in the past hasn't it
> >> been implemented by default? And, why for the future, is it not being
> >> implemented immediately by Qubes, Debian et al?
> >>
> >> During the past decade many people with good foresight had predicted the
> >> apt vulnerabilty and urged administrators to install the
> >> solution;"apt-transport-https". Regrettably, the vocal majority of
> >> so-called experts said that's unnecessary because the packages are
> >> signed. Was that incompetent advice? or was it a coordinated response
> >> from agents of State Actors to hide a deliberate backdoor? I've no idea,
> >> but given Snowdens revelations I would not rule anything out.
> > 
> > No you're not right in thinking this.
> > You seem to have missed the section where Max explicitly say that "a
> > malicious mirror could still exploit a bug like this, even with https."
> > So apt-transport-https is no magic bullet, particularly as a cursory
> > glance suggests that it allows forcing SSL version to SSLv3, which is
> > known to be insecure.
> > 
> > Imagine that apt-transport-https *had* been adopted - have you actually
> > looked at the list of vulnerabilities in libcurl, and the various
> > breakages in the TLS CA system? I can imagine some one
> > posting exactly like you: "Was the move to https incompetent advice? or
> > was it a coordinated response from agents of State Actors to hide a
> > deliberate backdoor? I've no idea, but given Snowdens revelations I
> > would not rule anything out."
> > 
> > I would rule some things out. And in this case it looks like a simple
> > mistake. And if you read any of the arguments re http/https you'd see
> > that there are reasonable arguments on both sides, and the "so called
> > experts" took reasoned positions.
> > 
> > It's always been open to you to install the package and switch to https
> > transport in your Debian templates, of course. And Qubes had already
> > started to use that by default too.
> > Not to downplay the importance of the bug, but let's not lose
> > our heads.
> 
> Apologies. I've reposted this because the subscripts weren't clear in
> the earlier post. Hopefully this will be clearer.
> Thank you for your responses.
> I appear to have prodded a hornets nest! I make no apology for that.
> It’s good and allows everyone an opportunity to express their views.
> Hopefully backed up by facts.
> Here's some background as to where I'm coming from:
> 1/ I use Debian based templates; including Whonix, exclusively (I do
> have doubts about Fedora’s integrity; calls home, owned by IBM/Redhat,
> monetised etc). So, all my apps (including service apps like
> sys-firewall, sys-net sys-usb) are compromised if Debian gets exploited.
> At this point for me its game over. I'm completely stuffed. Now when
> Qubes eventually issues a QSB; Security Bulletin almost 24 hrs after the
> vulnerability was publicly announced, saying its comparable to a firefox
> exploit: I get angry and say what complete and utter PR horsesh*t. 
> 
> 2/ Nobody's going to blame Qubes for an vulnerability like this in
> Debian etc. However, the least I'd expect from Qubes is a timely
> warning. Personally, I got a warning from Whonix a good 12 hrs before
> Qubes alerted us!
> 
> 3/ Most people have made an assumption that the good guys i.e. Max
> Justicz found the vulnerability first. Personally I never assume
> anything and prefer to think "worst case scenario". In this case I have
> had no privacy or security whatsoever for possibly years. Whilst Dom0's
> been protected, I'm not - what use is that?
> 
> Now turning to Unman's comments:
> 1/
>  no you're not right in thinking this.
> you seem to have missed the section where max explicitly say that "a
> malicious mirror could still exploit a bug like this, even with https."
> 

Re: [qubes-users] QSB #46: APT update mechanism vulnerability

[unman]

On Sun, Jan 27, 2019 at 03:33:11PM +0100, Alexandre Belgrand wrote:
> Le dimanche 27 janvier 2019 à 13:11 +, Holger Levsen a écrit :
> > I *believe* they probably misunderstood evil32.com and it's fallout.
> 
> CAs and GNU/Linux distributions are #1 targets for national
> intelligence agencies.
> 
> Debian developers are not using smartcards to store their GPG keys,
> including the master key signing code. It is very likely that Debian
> master key has been stolen. I would be very surprised if it had not
> been stolen.
> 
> One reason why nobody wants to use SSL, including OpenBSD, is that
> there is a wide belief that SSL private keys have been stolen.
> Therefore there is no need to use SSL, as it does not offer a real
> protection.
> 
> This is simply GAME OVER (part 1 of the game).
> 
> One reason why I am not using Qubes, is that it does not offer a real
> protection compared to Debian, as both systems are IMHO compromised.
> 
> At present, any government with a valid certificate from Intel can use
> Intel ME backdoor to access all resources from a computer, including
> keyboard and screen and there is no way to secure an X86 computer.
> 
> If Qubes was making a wide use of Smartcards with a separate pinpad
> reader and was using a hardened operating system like OpenBSD or even a
> hardened GNU/Linux, I would have a closer look at it.
> 

I'd be interested to know what system has been graced with your
approval.
If you believe all this, then what makes you think that national
intelligence agencies haven't infiltrated *bsd, coreboot and any other
system you can name. 
imo Qubes does a reasonable job of providing a more secure system
that's usable by ordinary users.
Spreading unfounded allegations is a disservice to the community.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190127164722.becnlytbz5bidzhz%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] QSB #46: APT update mechanism vulnerability

[unman]

On Sun, Jan 27, 2019 at 01:11:37PM +, Holger Levsen wrote:
> On Sun, Jan 27, 2019 at 12:54:26AM +0000, unman wrote:
> > > Keep in mind that all PGP Debian/Ubuntu signing keys have been stolen
> > Do you have *any* evidence for this claim?
> 
> I *believe* they probably misunderstood evil32.com and it's fallout.
> 
> 
> -- 
> tschüß,
>   Holger
> 
> ---
>holger@(debian|reproducible-builds|layer-acht).org
>PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
> 

Do you think so? That doesn't seem what they are claiming. 
Alexandre , what was it you meant?

The problem is that I *already* see this sort of claim spreading - see
another posting by John Redcap - and eventually there'll be a group of
users convinced that all signing keys have been stolen.
It's very difficult to stop a canard like this.
Unless, of course, Alexandre has some evidence?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190127140934.rmrnn3azaqsffy7w%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Help installing package in template VM via snap

[unman]

On Sat, Jan 26, 2019 at 01:33:15PM +0100, 799 wrote:
> Hello,
> 
> I am trying to update my multimedia howto for Qubes and would like to use
> a  fedora-29--minimal template instead of debian.
> 
> I try to install a package via snap but the template VM is not allowed to
> access the repository:
> 
> snap install , results in:
> api.snapcraft.io ... read: connection refused.
> 
> Question:
> What are the correct steps to allow internet access for the template VM?
> If possible only to api.snapcraft.io?
> 
> I looked at the Qubes docs https://www.qubes-os.org/doc/software-update-vm/
> but couldn't find a solution, can someone point me into the right direction?
> 

There's a package in qubes-testing which you can install in the template
qubes-snapd-helper. You can then use snap in qubes based on the template
- I think that will fit your use case.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190127020944.3vrwb435fgk3bgpy%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?

[unman]

On Sat, Jan 26, 2019 at 04:39:45AM -0800, goldsm...@riseup.net wrote:
> 
> Am I right in thinking  that the recently discovered apt vulnerability
> (DSA 4371-1) in Debian based systems could and should have been
> mitigated against many years ago  by downloading and activating an apt
> package; "apt-transport-https", which forces apt updates via https? The
> researcher (Max Justicz) who discovered the vulnerability has stated it 
> couldn't have been exploited if https had been implemented.
> 
> If "apt-transport-https" is the magic bullet, why in the past hasn't it
> been implemented by default? And, why for the future, is it not being
> implemented immediately by Qubes, Debian et al?
> 
> During the past decade many people with good foresight had predicted the
> apt vulnerabilty and urged administrators to install the
> solution;"apt-transport-https". Regrettably, the vocal majority of
> so-called experts said that's unnecessary because the packages are
> signed. Was that incompetent advice? or was it a coordinated response
> from agents of State Actors to hide a deliberate backdoor? I've no idea,
> but given Snowdens revelations I would not rule anything out.

No you're not right in thinking this.
You seem to have missed the section where Max explicitly say that "a
malicious mirror could still exploit a bug like this, even with https."
So apt-transport-https is no magic bullet, particularly as a cursory
glance suggests that it allows forcing SSL version to SSLv3, which is
known to be insecure.

Imagine that apt-transport-https *had* been adopted - have you actually
looked at the list of vulnerabilities in libcurl, and the various
breakages in the TLS CA system? I can imagine some one
posting exactly like you: "Was the move to https incompetent advice? or
was it a coordinated response from agents of State Actors to hide a
deliberate backdoor? I've no idea, but given Snowdens revelations I
would not rule anything out."

I would rule some things out. And in this case it looks like a simple
mistake. And if you read any of the arguments re http/https you'd see
that there are reasonable arguments on both sides, and the "so called
experts" took reasoned positions.

It's always been open to you to install the package and switch to https
transport in your Debian templates, of course. And Qubes had already
started to use that by default too.
Not to downplay the importance of the bug, but let's not lose
our heads.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190127013421.7pdxo4adq4tmqefe%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: looking for quickest way to copy text from dom0-Terminal to another VM

[unman]

On Sat, Jan 26, 2019 at 09:39:47AM +0100, 799 wrote:
> Am Sa., 26. Jan. 2019, 04:33 hat Andrew David Wong 
> geschrieben:
> 
> >
> > Please take a look at this issue:
> >
> > https://github.com/QubesOS/qubes-issues/issues/3571
> 
> 
> 
> Happy to see that this topic (no clipboard from dom0) is at least known.
> I don't agree that copying from dom0 is dangerous because "The user could
> have secrets in dom0, e.g., keyfiles".
> 
> 
> My passwords are in a vault VM and if someone messes up handling from dom0
> it is very likely that he/she didn't understand the security concept behind
> Qubes and therefore the user is likely the biggest attack surface NOT the
> clipboard.
> 
> Please offer a solution where the user can choose (free software!!) to
> enable/disable the clipboard (choosing means freedom).
> 
> It seems there is a workaround, can this be bound to a key (maybe also
> using xclip in dom0)?
> echo -n dom0 > qubes-clipboard.bin.source .
> 
Of course there's a workaround:
 | tee file
qvm-copy-to-vm  file

You can script this and create a key binding 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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190127005844.umz6ewf36xnyozwm%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] QSB #46: APT update mechanism vulnerability

[unman]

On Sat, Jan 26, 2019 at 11:42:27AM +0100, Alexandre Belgrand wrote:
> Le mercredi 23 janvier 2019 ŕ 18:05 +0100, Marek Marczykowski-Górecki a
> écrit :
> > We have just published Qubes Security Bulletin (QSB) #46:
> > APT update mechanism vulnerability.
> 
> Keep in mind that all PGP Debian/Ubuntu signing keys have been stolen
> and injection may occur during apt-get install/update using man-in-the-
> middle attack, at least in some countries. Unless packages are compiled
> with reproducible builds and fingerprints are available online, there
> is no way to avoid such an attack.

What a great start to the week.
Do you have *any* evidence for this claim?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190127005426.3qne7kcdcvv6pses%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ssh giving me locale error

[unman]

On Thu, Jan 24, 2019 at 03:25:49PM +0100, Zrubi wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 1/24/19 3:00 PM, unman wrote:
> 
> > I think you have a locale set in the qube whihc cannot be generated
> > on the server. Can you check this by looking at locale settings in
> > both.
> > 
> 
> I think the problem is that there is NO locale set in the default
> template.
> 
> You can check this by the localectl command.
> 
> As this is used in a lot of place, it is wise to correct it by setting
> a valid locale in a template.
> 
> - -- 
> Zrubi

really? There is in debian templates, even minimal.
Let's see what OP reports.
In any case, the resolution would be the same.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190124163338.hbkw3ur34xykgxm4%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ssh giving me locale error

[unman]

On Thu, Jan 24, 2019 at 04:58:26AM -0800, billol...@gmail.com wrote:
> I have recently installed 4.0.1 with KDE Plasma as my Desktop.  I tried to 
> ssh to another computer through my "untrusted" domain, and received the 
> following error.   I don't have trouble talking to the site for other stuff 
> -- it's my personal virtual server that I use for email and such, and my 
> email client syncs just fine.  The port is correct -- I can connect from 
> other machines.
> 
> Any instructions on how to fix this would be appreciated.  The same thing 
> happens with my "personal" domain.
> 
> [user@untrusted ~]$ ssh -p 2225 
> The authenticity of host '[someplace.com]:2225 ([123.456.789.123]:2225)' 
> can't be established.
> 's password: 
> Last login: Tue Jan 22 20:31:55 2019 from 11.22.33.44
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
>   LANGUAGE = (unset),
>   LC_ALL = (unset),
>   LANG = "C.UTF-8"
> are supported and installed on your system.
> perl: warning: Falling back to the standard locale ("C").
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
>   LANGUAGE = (unset),
>   LC_ALL = (unset),
>   LANG = "C.UTF-8"
> are supported and installed on your system.
> perl: warning: Falling back to the standard locale ("C").
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
>   LANGUAGE = (unset),
>   LC_ALL = (unset),
>   LANG = "C.UTF-8"
> are supported and installed on your system.
> perl: warning: Falling back to the standard locale ("C").
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
>   LANGUAGE = (unset),
>   LC_ALL = (unset),
>   LANG = "C.UTF-8"
> are supported and installed on your system.
> perl: warning: Falling back to the standard locale ("C").
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
>   LANGUAGE = (unset),
>   LC_ALL = (unset),
>   LANG = "C.UTF-8"
> are supported and installed on your system.
> perl: warning: Falling back to the standard locale ("C").
> 
I think you have a locale set in the qube whihc cannot be generated on the
server. Can you check this by looking at locale settings in both.

If this is the case, then there are a few options. The easiest is to
stop accepting locale on the server - look in /etc/ssh/sshd_config in the
"remote" and see if you have AcceptEnv set . 
Or in local file, comment out SendEnv in /etc/ssh/ssh_config.

Try one of those and see if it fixes the issue.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190124140027.spzl46z3wbvnvjzn%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] diff files across appvms

[unman]

On Wed, Jan 23, 2019 at 08:15:53AM -0800, john.e.ma...@gmail.com wrote:
> 
> unman, thank you for being so generous with your time. I appreciate the 
> education. Yes, I was looking in appvms. I'm starting to understand better 
> what needs to be done. I'll see how far I get.
> 
> John
> 
No problem. Remember that at the monment all management is done in dom0,
so it is there that policy decisions are set.
If you hit any more problems dont hesitate to come back.

unman

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190124115605.cdxr2phyqlwnw7cy%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Backup stops when the backup file reaches 3Gb

[unman]

On Thu, Jan 24, 2019 at 01:00:15AM -0500, Chris Laprise wrote:
> On 01/23/2019 08:15 PM, js...@bitmessage.ch wrote:
> > Mike Keehan:
> > > Hi,
> > > 
> > > I'm using Qubes Backup to save some of my qubes into another VM.
> > > The backup VM has 18 Gb of storage available, but whenever the
> > > backup file reaches 3Gb, the backup process just hangs.
> > > 
> > > No CPU usage, no error messages, just stops.  The backup window
> > > shows 40% complete, but never moves any further (different % for
> > > different combinations of qubes in the backup list).
> > > 
> > > After waiting a considerable time (well, 5-10 minutes), hitting
> > > Cancel in the backup window does cancel it.  The rest of the
> > > system is continuing to work without problem.  Happens every
> > > time I try to use Qubes backup.
> > > 
> > > The Qubes Disk Space widget shows less than 50% disk used overall,
> > > the backupVM shows only 18% disk used when the 3Gb file has been
> > > saved.
> > > 
> > > I'm stumped.
> > > 
> > > Mike.
> > 
> > Hi,
> > 
> > You may have to wait longer than 5-10 minutes. I experience something
> > similar when doing a full backup, except it's worse because i'm backing
> > up like 2.5TB. It appears to hang for several hours at a time (and this
> > happens more than once), but it does eventually make visible progress
> > again. The whole process takes over 24 hours. This is why i do full
> > backups very infrequently.
> > 
> > For you it shouldn't take nearly as long because it's a lot less data,
> > but the progress appearing to hang for a while seems to be normal.
> > 
> > I'm using 3.2 tho, and i know they made changes to the backup mechanism
> > under the hood in 4.0, so i'm not sure if this issue still applies in
> > 4.0.
> 
> Marek,
> 
> Isn't this the null bytes bug in GNU tar?
> 
> https://groups.google.com/d/msgid/qubes-users/f4d997d5-7191-06d0-e7bb-ef42745a7db5%40posteo.net
> 
> It would be a good idea to update this in dom0. My own backup tool uses GNU
> tar as well.
> 
> -- 
> 
> Chris Laprise, tas...@posteo.net
> https://github.com/tasket
> https://twitter.com/ttaskett
> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

It seems a little early to judge.

Mike - it looks from your comment as if you have been trying with
subsets of the qubes? Can you confirm if these are running or stopped.

Like jsnow, I'm regularly able to backup far more than 3G without issue,
so it looks as if there's something particular about this scenario.
It would be helpful if you could confirm the issue when all qubes you
are backing up are stopped.
Then try bisecting the qubes backup group - keep bisecting if you hit
the problem again until you either find the problematic qubes or have
backed them all up.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190124112950.ldybghvvpc5jham4%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] diff files across appvms

[unman]

On Wed, Jan 23, 2019 at 07:19:14AM -0800, john.e.ma...@gmail.com wrote:
> On Wednesday, January 23, 2019 at 9:54:50 AM UTC-5, unman wrote:
> > On Wed, Jan 23, 2019 at 05:38:42AM -0800, john.e.ma...@gmail.com wrote:
> > > On Tuesday, January 22, 2019 at 8:18:48 PM UTC-5, unman wrote:
> > > > On Tue, Jan 22, 2019 at 01:23:54PM -0800,  wrote:
> > > > > Is it possible to compare (diff) files across appvms. Or (and), is it 
> > > > > possible to pass arguments to an appvm through a dom0 terminal. 
> > > > > 
> > > > > Basically, I want to check if a Keepassxc file in my vault is 
> > > > > different than a Keepassxc file in my appvm. 
> > > > > 
> > > > > Thanks for any ideas.
> > > > > 
> > > > > John
> > > > > 
> > > > 
> > > > You can do this using qvm-run-vm or by using qvm-run in dom0.
> > > > Look at the policy file in /etc/qubes-rpc/policy/qubes.VMShell and the
> > > > warning.
> > > > 
> > > > If all you want to do is see if the files differ, then you can just
> > > > generate hashes: from vault -
> > > > qvm-run-vm appvm 'md5sum db.kdbx'
> > > > Compare that with local hash.
> > > > 
> > > > I dont think you can diff the files themselves.
> > > 
> > > unman, I don't have qvm-run (perhaps that's for 3.2?), and running hash 
> > > command example you gave (modified to point to a file that exists in the 
> > > appvm) produced no output. Specifically:
> > > 
> > > $ qvm-run vault 'md5sum file.kdbx'
> > > Running 'md5sum file.kdbx' on vault
> > > 
> > > But no output. Any ideas?
> > > 
> > > Thanks.
> > > John
> > > 
> > 
> > In qubes, you should have qvm-run-vm tool. In dom0, qvm-run. The
> > capabilities (and controls) are different.
> > 
> > You are trying to run in dom0 - to get output there you need to use;:
> > qvm-run -p vault 'md5sum file.kdbx'
> > The '-p' allows for stdio from the running program to be passed to dom0
> > - be aware of the potential risks. Otherwise the command is run (and
> > stdio kept) in the target qube.
> > 
> > In qubes, you use qvm-run-vm - you must have considered
> > /etc/qubes-rpc/policy/qubes.VMShell
> > So, from vault run "qvm-run-vm appvm 'md5sum file.kdbx'", and the output
> > of that command run on appvm will appear in vault, and you will be able
> > to make the comparison.
> 
> unman, thank you for this. I understand the difference now, and using qvm-run 
> -p in dom0 works fine. I cannot get qvm-run-vm to work, because I'm presented 
> with "Request refused". I don't understand the significance of 
> /etc/qubes-rpc/policy/qubes.VMShell, but I don't actually have a directory 
> called policy, so that file path is /etc/qubes-rpc/qubes.VMShell.
> 
> I can make this work using dom0, but I suspect (but don't know for sure) that 
> that is unwise.
> 
> John

It's not ideal because you are parsing the output of an (unknown) command
run in a qube in dom0.

You are getting the "request refused" because you have not set a policy
rule allowing vault to run commands in appvm.
I dont have /etc/qubes-rpc/qubes.VMShell, and I do have
/etc/qubes-rpc/policy.
I've just checked this on a number of boxes, including a clean 4.0 image
and they all have the same.
It occurs to me that you are looking in the qube, and not in dom0 - can
you check this? You need to set the policy in dom0, and it will be
applied in individual qubes.


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190123160439.z4vxeg6osuauiwq2%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] vault color (black?) & window decorations

[unman]

On Tue, Jan 22, 2019 at 08:05:03AM -0800, brendan.h...@gmail.com wrote:
> On Tuesday, January 22, 2019 at 10:53:30 AM UTC-5, chuc...@gmail.com wrote:
> > On Monday, October 15, 2018 at 8:07:38 AM UTC-5, awokd wrote:
> > > bre...ail.com:
> > > > Hi folks,
> > > > 
> > > > Regarding the default R4 color scheme...
> > > > 
> > > > ...does anyone else find that the default color for vault (black?) 
> > > > makes it nearly impossible to see the window titles and/or windows 
> > > > controls (close, maximize, minimize)?
> > > > 
> > > > Why does that color scheme set the window title (and controls) to dark 
> > > > text/controls on a dark background?
> > > > 
> > > Have noticed it but it hasn't bothered me enough yet to change it! I 
> > > think there's an issue somewhere out there mentioning it.
> > 
> > Is it possible to user-modify (or, more specifically, add to) the existing 
> > available window colors? I'm adding some additional "zones" and have been 
> > trying to figure it out.
> 
> My workaround was setting all my templates to use the black backgrounds with 
> impossible to read window titles and shifting other VMs to more reasonable 
> colors.
> 
> Brendan
> 

There is a longstanding open issue about adding more
colours/decorations. I dont believe at present that this can be easily
changed.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190123151805.tfaa3oouadqwiuid%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] V3.2 script does not work on v4.01

[unman]

On Wed, Jan 23, 2019 at 11:43:39AM -0300, Franz wrote:
> Hello
> I moved to Qubes 4 and my script to start various VMs and programs, which
> worked fine with V3.2, now just executes only the first command and stops
> there. Why?
> 
> Script
> qvm-start untrusted
> wmctrl -s 1
> qvm-run untrusted firefox
> qvm-run untrusted nautilus
> qvm-start personal
>  and many others commands
> 
> It stops with:
> sh script.sh
> Running 'firefox' on untrusted
> 
> I get nothing more than that. Why does not it start also nautilus and many
> other stuff as it did with Qubes 3.2?
> 
> best
> Franz

As you've discovered in 4.0 qvm-run blocks on the program being run.
You need to use:
qvm-run untrusted firefox &
etc

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190123150759.vpvmpr2w3jp6ipln%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Networking widget in KDE on qubes

[unman]

On Wed, Jan 23, 2019 at 06:21:44AM -0800, billol...@gmail.com wrote:
> I recently installed 4.0.1 on my laptop and it seems to be working great, 
> though I'm still working through some of the how-do-you-copy-files stuff and 
> some of the networking stuff.  But, it's just a different way of doing 
> things, and that can be learned.
> 
> 
> I followed the directions in the qubes docs for installing KDE, and it worked 
> great. Thanks to the folk who made *that* work so well.  I know that KDE is 
> in bad odor because of its size, etc., but I still like it. And with my shiny 
> new SSD drive, it's plenty zippy for me.  I've pretty much figured out how to 
> customize it manually.
> 
> But I'm having a problem with the networking widget.
> 
> I apparently can't upload a screenshot, but were you to see it, you'd see 
> that all my monitoring widgets (cpu, hard disk, etc) are working fine, but 
> the Network Monitor is blank -- because there's no device for it to look at.  
> I understand that the desktop runs in dom0, and dom0 doesn't have networking, 
> but (and this is my conceptual problem) that would mean that the network 
> manager must run somewhere else than dom0, right?  Where is it, and is there 
> a way to get my networking widget to talk to wherever that is?
> 
> Thanks,
> 
> billo
> 

I'm afraid it is one of the last issues bedevilling KDE in dom0 - the
icon is "there" but does not appear. 
As you say, dom0 does not have networking, but sys-net does. That is
where the NetworkManager applet runs, and the output should be passed to
dom0 for display. (Currently dom0 controls all the gui.) In Xfce this
works fine but in KDE the mechanism is broker currently.
The icon is there, and you can discover it by mousing over it, and
interact with it as expected. Once you understand this the absence
proves less of a problem.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190123150145.vfwfcnqlpyidl7la%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] diff files across appvms

[unman]

On Wed, Jan 23, 2019 at 05:38:42AM -0800, john.e.ma...@gmail.com wrote:
> On Tuesday, January 22, 2019 at 8:18:48 PM UTC-5, unman wrote:
> > On Tue, Jan 22, 2019 at 01:23:54PM -0800,  wrote:
> > > Is it possible to compare (diff) files across appvms. Or (and), is it 
> > > possible to pass arguments to an appvm through a dom0 terminal. 
> > > 
> > > Basically, I want to check if a Keepassxc file in my vault is different 
> > > than a Keepassxc file in my appvm. 
> > > 
> > > Thanks for any ideas.
> > > 
> > > John
> > > 
> > 
> > You can do this using qvm-run-vm or by using qvm-run in dom0.
> > Look at the policy file in /etc/qubes-rpc/policy/qubes.VMShell and the
> > warning.
> > 
> > If all you want to do is see if the files differ, then you can just
> > generate hashes: from vault -
> > qvm-run-vm appvm 'md5sum db.kdbx'
> > Compare that with local hash.
> > 
> > I dont think you can diff the files themselves.
> 
> unman, I don't have qvm-run (perhaps that's for 3.2?), and running hash 
> command example you gave (modified to point to a file that exists in the 
> appvm) produced no output. Specifically:
> 
> $ qvm-run vault 'md5sum file.kdbx'
> Running 'md5sum file.kdbx' on vault
> 
> But no output. Any ideas?
> 
> Thanks.
> John
> 

In qubes, you should have qvm-run-vm tool. In dom0, qvm-run. The
capabilities (and controls) are different.

You are trying to run in dom0 - to get output there you need to use;:
qvm-run -p vault 'md5sum file.kdbx'
The '-p' allows for stdio from the running program to be passed to dom0
- be aware of the potential risks. Otherwise the command is run (and
stdio kept) in the target qube.

In qubes, you use qvm-run-vm - you must have considered
/etc/qubes-rpc/policy/qubes.VMShell
So, from vault run "qvm-run-vm appvm 'md5sum file.kdbx'", and the output
of that command run on appvm will appear in vault, and you will be able
to make the comparison.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190123145448.pefoxs4boi56w2fc%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Using Untangle as Qubes firewall

[unman]

On Tue, Jan 22, 2019 at 11:32:22AM -0800, scoobyscra...@gmail.com wrote:
> Hello,
> 
> I am new to Qubes running on 4.0.  I would like to test the Untangle firewall 
> and have it run in place of sys-firewall and still use the default sys-net.
> 
> I created the Untangle firewall as a HVM VM but it only shows one interface.  
> How do I add the virtual interface?  What else am I missing?
> 
> TIA
> 

You should be able to set the HVM as netvm for another qube and the vif
will be set. Try 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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190123012015.ytwolkprdlbfvhnr%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] diff files across appvms

[unman]

On Tue, Jan 22, 2019 at 01:23:54PM -0800, john.e.ma...@gmail.com wrote:
> Is it possible to compare (diff) files across appvms. Or (and), is it 
> possible to pass arguments to an appvm through a dom0 terminal. 
> 
> Basically, I want to check if a Keepassxc file in my vault is different than 
> a Keepassxc file in my appvm. 
> 
> Thanks for any ideas.
> 
> John
> 

You can do this using qvm-run-vm or by using qvm-run in dom0.
Look at the policy file in /etc/qubes-rpc/policy/qubes.VMShell and the
warning.

If all you want to do is see if the files differ, then you can just
generate hashes: from vault -
qvm-run-vm appvm 'md5sum db.kdbx'
Compare that with local hash.

I dont think you can diff the files themselves.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190123011845.fd7q6dikueppbpno%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] hard disk locked after trial run

[unman]

On Tue, Jan 22, 2019 at 11:08:19AM +0100, Dieter Zakel wrote:
> [image: IMG_3494.jpeg]
> 
> On Tue, Jan 22, 2019 at 12:44 AM unman  wrote:
> 
> > On Mon, Jan 21, 2019 at 09:03:40AM -0800, Dieter Zakel wrote:
> > > I have installed the Qubes-OS on my laptop as a trial run and now I am
> > unable to install another OS.
> > > Because dom0 is locked...
> > > When trying to install linux the partitioning process freezes...
> > > Has someone any idea how to remove this security feature?
> > > Thank you very much!
> > >
> >
> > Do you want to replace Qubes, or install another OS alongside it? What
> > you need to do depends on how much space you allocated to Qubes in the
> > first place.
> > Also different depending on whether 3.2 or 4.0, and which OS you have in
> > mind.
> >
> > If you have encryted drive and want to shrink partition to make space
> > for new OS this can be done, but is somewhat involved.
> > If you just want to remove Qubes and your new installer cant handle it,
> > boot from a live linux USB, and use gparted to remove the Qubes
> > partition.
> >

Hello Dieter
Can you answer those questions?
Also, the images are no use to me. Can you tell me what they show?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190122131223.bgdfiehyvs6e3tg7%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] hard disk locked after trial run

[unman]

On Mon, Jan 21, 2019 at 09:03:40AM -0800, Dieter Zakel wrote:
> I have installed the Qubes-OS on my laptop as a trial run and now I am unable 
> to install another OS.
> Because dom0 is locked...
> When trying to install linux the partitioning process freezes...
> Has someone any idea how to remove this security feature?
> Thank you very much! 
> 

Do you want to replace Qubes, or install another OS alongside it? What
you need to do depends on how much space you allocated to Qubes in the
first place.
Also different depending on whether 3.2 or 4.0, and which OS you have in
mind.

If you have encryted drive and want to shrink partition to make space
for new OS this can be done, but is somewhat involved.
If you just want to remove Qubes and your new installer cant handle it,
boot from a live linux USB, and use gparted to remove the Qubes
partition.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190121234433.jegr47uhpmoxwmcu%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] removal of debian-9 template fails because is marked as installed by packetmanager.

[unman]

On Tue, Jan 22, 2019 at 07:24:37AM +1100, Eric wrote:
> 
>   
> 
>   
>   
> On 1/22/19 5:35 AM, gone wrote:
> 
> 
>   Hi,
> I've done too many changes to my debian-9 template and would
> like to reinstall a "pure", original debian-9 template
> again.
> So I cloned it and based all the existing debian App-VMs on
> the clone-template. 
> But removal of debian-9 template fails because it is marked
> as installed by packetmanager.
> How can I remove and reinstall it?
> 
> 
> 
> in dom0: sudo qubes-dom0-update --action=reinstall
>   qubes-template-debian-9
>   
> 
> 
> 
> 
> -- 

Hi Eric
Your answer is partly right, but all that HTML gets in the way.
Can you switch to plain text please?

Also reinstall will try to install the *same* version that is currently
installed, although there may be a more recently built template
available.
You can work round this by:
sudo dnf remove qubes-template-debian-9
sudo qubes-dom0-update qubes-template-debian-9

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190121233500.d5hpcrumdtelum4b%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] qvm-prefs clockvm command fails

[unman]

On Sun, Jan 20, 2019 at 11:16:17PM -0800, goldsm...@riseup.net wrote:
> On 2019-01-20 23:57, unman wrote:
> > On Sun, Jan 20, 2019 at 04:42:12AM -0800, goldsm...@riseup.net wrote:
> >> I'm following qubes docs
> >> https://www.qubes-os.org/doc/disposablevm-customization/ and trying to
> >> set clockvm to disp-sys-net using command in Dom0 qvm-prefs clockvm
> >> disp-sys-net
> >> which gives message: qvm-prefs: error: no such domain clockvm. Have
> >> tried variations of clockvm e.g. ClockVM to no avail.
> >>
> >> As an alternative fix, I set clockvm to disp-sys-net in gui "global
> >> settings". Buy not sure its working
> > 
> > Look again - that should be qubes-prefs not qvm-prefs
> 
> Thanks Unman
> That was a dumb mistake on my part.
> Sorry to waste your time

No need to apologise. It's easy to do, particularly after a list of
"qvm-pref" commands.
We all make mistakes.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190121130544.5epdi5sm6hpbhkir%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Updates Proxy questions and possible concern

[unman]

On Sat, Jan 19, 2019 at 07:55:17PM -0600, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 19/12/2018 6.37 PM, unman wrote:
> > On Wed, Dec 19, 2018 at 11:06:25PM +, mossy wrote:
> >> Hello all,
> >>
> >> I was looking to see if I could update an offline standalone VM, by
> >> appending a line to `etc/qubes-rpc/policy/qubes.UpdatesProxy` and I now
> >> have some questions.
> >>
> >> First, I noticed the lines:
> >>
> >> ~~~
> >> # Default rule for all TemplateVMs - direct the connection to sys-net
> >> $type:TemplateVM $default allow,target=sys-net
> >> ~~~
> >>
> >> Q1) Is this correct?  Shouldn't updates be directed to sys-firewall
> >> instead of sys-net?  Are all of our templates exposed to (untrusted)
> >> sys-net?
> >>
> >> Hopefully I am wrong about this, but either way I'd appreciate if
> >> someone could explain...
> >> [...]
> > 
> > Q1. Yes, the default is to use sys-net. You can change this if you wish.
> > (I do)
> > The update proxy has always been set to sys-net by default.
> > The proxy used to filter traffic, but no longer does so. Again, I change
> > this behaviour.
> > [...]
> 
> What do you change it to? sys-firewall?
> 
> Why do you change it? Do you see some security risk with using sys-net?
> If so, should we file a bug report to have this changed by default?
> 

I use a caching proxy (apt-cacher-ng) for all updates.
(I also dont allow outbound traffic from sys-net or sys-firewall, but
that's another story.)

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190121004420.mwspf2kz2akymdxq%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Google Only Allows Foreign Language Login

[unman]

On Sun, Jan 20, 2019 at 11:26:42PM +0100, kit...@tutanota.com wrote:
> It appears the mailing list interface at Google is not for English users.  I 
> cannot post or reply without a pop up window in a foreign language.
> 
> Does anyone know how to get around this?
> -- 

I guess you are connecting via Tor, so the interface is tailored to
whatever seems appropriate.
At the bottom of the sign in window you can select whatever language
suits you.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190121001510.d2d6lfnegxnko5ia%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] USB Keyboard

[unman]

On Sun, Jan 20, 2019 at 11:16:10PM +0100, kit...@tutanota.com wrote:
> Upon reading the system requirements and recommendations, I read the 
> statement "A non-USB keyboard or multiple USB controllers".  Please explain 
> the reasoning there.  Thank you.
> 

Qubes offers USB isolation from dom0, using a sys-usb qube.
If you only have one USB controller, and a USB keyboard, then you have to
have the USB keyboard available in dom0, or you will not be able to
unlock the encrypted disk.
This means that *all* USB devices will be attached to dom0, so you are
missing out on the protection offered by sys-usb.
Have a look at https://www.qubes-os.org/doc/usb particularly the warning
on USB input devices.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190121001142.khaj5ct7ovd32gm5%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] qvm-prefs clockvm command fails

[unman]

On Sun, Jan 20, 2019 at 04:42:12AM -0800, goldsm...@riseup.net wrote:
> I'm following qubes docs
> https://www.qubes-os.org/doc/disposablevm-customization/ and trying to
> set clockvm to disp-sys-net using command in Dom0 qvm-prefs clockvm
> disp-sys-net
> which gives message: qvm-prefs: error: no such domain clockvm. Have
> tried variations of clockvm e.g. ClockVM to no avail.
> 
> As an alternative fix, I set clockvm to disp-sys-net in gui "global
> settings". Buy not sure its working

Look again - that should be qubes-prefs not qvm-prefs

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190120235703.stg4vr2ww2ran4kz%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Firefox Account SyncVM

[unman]

On Sun, Jan 20, 2019 at 07:52:42AM -0800, Mathew wrote:
> Is sync bookmarks from a firefox account in a Qubes AppVM a bad idea ?
> 
I think the main issues here are:
Risk of individual bookmarks carrying identifying information.
The range and variety of bookmarks being used to fingerprint users and
correlate between qubes.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190120234959.r3ue7zcey4bgdu7z%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] sys-net & sys-firewall fail to start, new install

[unman]

On Fri, Jan 18, 2019 at 07:40:30AM -0500, Scott Lewis wrote:
> Thanks but unfortunately I don't know that issue helps, as those who were
> able to resolve it did so by updating which I cannot do since sys-net fails
> to start.
> 
> This issue, https://github.com/QubesOS/qubes-issues/issues/3349 , seems to
> cover that problem but nothing's mentioned about net & firewall failing to
> start.
> 
 > 
> On Fri, Jan 18, 2019, 07:22 Mike Keehan  
> > On Thu, 17 Jan 2019 16:42:28 -0800 (PST)
> > scott.lewis.engin...@gmail.com wrote:
> >
> > > Hello, I apologize in advance if this has already been addressed but
> > > searching for "sys-net" & "libxl" give many confusing results, I
> > > don't see any that match both not working, and I'm completely new to
> > > Qubes. My problem is that after 2 different installs of the same
> > > version, 4.01, I keep getting the same problems: When I get into
> > > Qubes I cannot update dom0, and sys-net & sys-firewall both fail to
> > > start even though my NIC is correctly listed in devices for -net.
> > >
> > > Basic info:
> > > Dell Optiplex 780, bios= A15 as recommended in HCL.
> > > Qubes 4.01, sigs checked good.
> > > Install 1 done by USB, created in windows, had same issues as
> > > described below. Re-installed by DVD thinking I'd muffed something
> > > (think I read on reddit that USB installs made from windows had
> > > issues) and the behavior is exactly the same.
> > >
> > > Behavior observed:
> > > (anything in [xxx] is me telling you the variation, as I get this for
> > > 2 VM's, 2 error codes, etc.)
> > > * Dom0 starts and runs, but -net & -firewall will not.
> > > * When I attempt to manually start either, I get this error message:
> > > "ERROR: Start failed: internal error: libxenlight failed to create
> > > new domain 'sys-net' [or sys-firewall],
> > > see /var/log/libvirt/libxl/libxl-driver.log for details".
> > >
> > > When I less the log, I get these errors dozens of time with
> > > timestamps ranging from date of install to today: 1: "[date:time]:
> > > libxl: libxl_create.c:610:libxl_domain_make:domain creation fail:
> > > Operation not supported" 2: "[date:time]: libxl:
> > > libxl_create.c:982:initiate_domain_create:cannot make domain: -3"
> > > Those errors and nothing else.
> > >
> > > I've tried to update dom0 by command as found in docs, as well as
> > > through GUI without success. I found a page elsewhere that described
> > > temporarily putting NIC in firewall or another VM to see if it
> > > worked, but I must be doing it wrong as I always get loopback errors
> > > when trying to save. It always tells me failed, regardless. No wonder
> > > if network isn't working.
> > >
> > > Under sys-net, I see the correct name and model of my NIC, but I
> > > can't seem to figure out how to see if the NIC is operational since
> > > sys-net isn't working (new to qubes sorry!), however I verified my
> > > router is not showing an IP assigned, though link LED is on.
> > >
> > > If anyone can help me try to figure this out, I'd really appreciate
> > > it. I'm still a bit green on linux but I learn fast, I recently gave
> > > up on Windows (I hate 10 so much I could scream) so I'm trying to
> > > dive in with qubes (deep end of the pool I think) as it best suits my
> > > needs with the VM implementation.
> > >
> > > I'd post the log itself, but I can't seem to figure out how to make
> > > USB copy work yet since I've been beating my head on the networking
> > > issue.
> > >
> > > Thanks, and sorry in advance if this duplicated another thread.
> > >
> >
> > Similar issues in the past were raised in this bug report -
> >
> > https://github.com/QubesOS/qubes-issues/issues/3125
> >
> > It might give you some pointers.
> >
> > (I found it by searching for "Qubes libxl_domain_make:domain creation
> > fail: Operation not supported" in google.)
> >
> > Mike.
> >

Test whether issue is with NIC by removing the card from sys-net and confirming 
that
sys-firewall starts (after sys-net).
Shutdown both.
Re-attach NIC to sys-net.
Report back.


You can extract logs from dom0 by creating a qube with NO netvm, and
using qvm-copy-to-vm to transfer the log to that qube.  Attach USB
device to the qube (using devices widget) and copy log off 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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190118141657.4bdsdejxhwezeers%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Mirage-Firewall - Trusted in Dom0?

[unman]

On Fri, Jan 18, 2019 at 04:38:56AM -0800, goldsm...@riseup.net wrote:
> On 2019-01-15 15:19, Goldi wrote:
> > I've been happily using Qubes for several years and noticed that
> > several prominent members of the Qubes Team have in the past suggested
> > installing Mirage-Firewall as an alternative to Sys-Firewall. However,
> > I cannot find any reference to MF in the Qubes Docs. 
> > I'd like to install Mirage-Firewall, but I have a nagging doubt about
> > whether the code can be trusted. Particularly as it has to been
> > installed in Dom0
> > What do you guys recommend? Can the MF developer be trusted?
> > 
> > https://groups.google.com/d/msgid/qubes-users/21F0DB51-AF5A-4729-8708-14C54BB4C29A%40riseup.net?utm_medium=email_source=footer
> In Nov 2018 a prominent member of the Qubes team; Unman suggested using
> Mirage-Firewall.
> I'd appreciate very much a reply to my earlier query about the integrity
> and reliability of the code/developer of Mirage Firewall
> 

There is a reference in the docs to GSOC potential work: otherwise
you'll find discussions here and in qubes-devel, and there's an open
issue in qubes-issues.
I have no view on the integrity of Thomas - don't know him. His
contributions have been good and he's always seemed helpful and to know
what he's talking about. 
You can look at the code yourself and come to view on that: it's pretty 
straightforward. 
https://github.com/talex5/qubes-mirage-firewall

I've done some testing, and the firewall works as expected, with no
strange effects I could see.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190118135237.aoc5mdezlhtvjvt7%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Physical network adapter vlan

[unman]

On Fri, Jan 18, 2019 at 02:00:44AM -0800, scarp...@gmail.com wrote:
> Hi,
> After checking the google group and documentation at cannot find any 
> information regarding the add of vlan on the public ip of the qubes os. 
> In my case i need to add 2 ip address on my physical interface of my computer 
> and one if them need to be in vlan.
> 
> Any idea or post i miss?
> 
> Best regards
> 
There have been questions about use of VLANs in the past: you should be
able to search the archive.
Configuring the external interface is no different from using
Network Manager in whatever distribution you are using for sys-net
template.
The Qubes specific part will be connecting your qubes to the relevant IP
addresses. Simple way would be to have two firewall qubes, each
dedicated to one IP, and enforcing separation there. Then allocate your
qubes to the firewalls as appropriate.
If you think that you need to have a qube using *both* IP addresses,
then you might want to think a little more about the security domains
that you have defined, and how you have broken down your work. Not
saying that cant be done (it can), but in almost every case I've seen
it's proved to be unnecessary.

there should be enough here to get you done. If you  need more help
give a little more detail on what you are trying to achieve.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190118121102.zsiwrjbamlawjzoh%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Firefox Account SyncVM

[unman]

On Thu, Jan 17, 2019 at 10:20:31AM -0800, R A F wrote:
> Hi Everyone,
> 
> I'm trying to find a way to sync firefox bookmarks but I do not want to use 
> firefox account. So my question to all of you is:
> Does anyone knows if there is a possible way to create local account that 
> will be hosted on standalone VM so I could connect all Firefox Apps to 
> connect to that source ans sync bookmarks, plugins, etc. The whole point here 
> is to keep all bookmarks in safe place that same way some people keep their 
> passwords keys etc.
> Maybe if there is no such a solution someone could start new project? I would 
> do that myself, but currently do not have advanced coding skills :-(
> 
> Thanks for all replays 
> BR
> Raf
> 

Search the archives of this list for discussions on this topic: Firefox
Bookmarks should get you relevant posts, and links to some sample
scripts.
The biggest danger is that your bookmarks will carry identifying
information between qubes, breaking the isolation model. If you plan for
this and are aware of the risks then you can adopt anything between
storing/syncing whole profiles between one "storage" qube and other
qubes, and copy/pasting bookmarks from storage qube in to other firefox
qubes as needed.



-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190118013837.keqgry63jatpvd5s%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Renaming .desktop file side-effect

[unman]

On Wed, Jan 16, 2019 at 01:19:54PM -0800, John Goold wrote:
> I encountered an "interesting" phenomenon which could be a defect (bug) or 
> expected behaviour (an odd "feature"). If a defect, it could be in the file 
> manager under Debian (Nautilus?).
> 
> If I attempt to rename a file in ~/local/share/applications/ when I save the 
> change, ".desktop" is appended to the file name. This occurs even if the name 
> entered in the rename dialog already has a .desktop extension.
> 
> An example: I copied dropbox.desktop from /usr/share/applications to 
> ~/local/share/applications (to use as a template). Renaming it by just 
> changing "dropbox" to "vuescan" resulted in vuescan.desktop.desktop.
> 
> It took me a few minutes to realize what was happening :-(  The easy 
> workaround was to remove the .desktop file extension when renaming as it 
> would automatically get appended.
> 
> Surely this is unexpected behaviour? Does anyone know if this is a "feature" 
> and will it pop-up when attempting to rename files in other directories?
> 
It is a "feature" of Gnome Files, not specific to Debian, and is
expected behaviour. (bizarre but expected in the mysterious world of
Gnome.)
I think that it applies only to files in the applications directories
and was presumably introduced to ensure that launchers would not be broken.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190117015310.kkkulazhrrqiy5nj%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Keyboard and mouse issue (R 4.0.1)

[unman]

On Wed, Jan 16, 2019 at 08:31:37AM +0200, Ivan Mitev wrote:
> 
> 
> > Not really a Fedora person. Probably not. :-(
> > On the other hand, I *do* find a GUI way of setting the key under System
> > Settings/Keyboard in KDE, and in Xfce, under
> > SystemTools-Keyboard-Layout.
> 
> Oh, you're right - as usual :)
> 
I think I've already demonstrated that this is not so. 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190116120428.azv7gldn7hcuib2e%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Re: VMApp files from template

[unman]

On Wed, Jan 16, 2019 at 04:22:32AM -0500, Dave Albiston wrote:
> Thanks for your patience, uman
> 
> It is the exec line that is the problem. In the work domain
> I can run the script using:
> 
> sh /home/Scripts/myscript.sh
> 
> I guess that the menu exec statement is being run in dom0.
> So how can the statement be changed to point to a file in
> the work domain? Or, alternatively, how can the command be
> forced to execute in the work domain?
> 
> It's a learning curve!

We're all learning.

Make the script executable in the work qube.
Then in dom0 , try 'qvm-run work /home/Scripts/myscript.sh' at console.
Assuming that works, then you have the exec statement to use in the menu
item.
If it doesnt work, then you can use 'qvm-run -p' to get stdin/out in the
console, which may help with troubleshooting. Or start logging in the
script to see where it breaks.
You can also use '-u ' to run as specified user.

Once you can call the command from dom0, use that as the exec line.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190116120212.h2pbeq542juihdsh%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: VMApp files from template

[unman]

On Tue, Jan 15, 2019 at 08:26:00AM -0500, Dave Albiston wrote:
> Thanks, uman
> 
> I followed alternative instructions and the menu option is
> provided by placing a .desktop file in
> /usr/share/applications. This works and the command is
> attempted. But it cannot find the script which is in the
> VMApp folders, so there is a file not found error.
> 
> I presume the command is executing in dom0. How can I make
> it look for the script file in the VMApp space?
> 
> many thanks, Dave

What does your desktop file look like?
If you compare with the files used in other menu items, and look at my
last post, you will see how to run files in qubes by executing commands in
dom0.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190116005551.5tvaqwa6zik5uxxo%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Issues installing QubesOS on Samsung Gateway from bootable external hard drive

[unman]

On Tue, Jan 15, 2019 at 09:43:53PM +, 'learningtoday' via qubes-users wrote:
> Hello everybody!
> 
> Set up qubes on external hard drive to boot upon launch. Downloaded latest 
> version from [https://www.qubes-os.org](https://www.qubes-os.org/)
> 
> Installer loads fine, proceeds with install, but then I get these errors:
> 
> > [ 215.94. ] dracut-initqueue[649]: Warning: dracut-initqueue timeout - 
> > starting timeout scripts
> > [ 215.94. ] dracut-initqueue[649]: Warning: Could not boot
> > [ 215.94. ] dracut-initqueue[649]: Warning: /dev/root does not exist
> > Starting Dracut Emergency Shell
> > Warning: /dev/root does not exist
> >
> > Generating "/run/initramfs/rdsosreport.txt"
> >
> > Entering emergencym ode. Exit the shell to continue.
> > Type "journalctl" to view system logs.
> > You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or 
> > /boot after mounting them and attach it to the bug report.
> 
> And when I enter journalctl I get a thousand line report.
> 
> Laptop: Samsung Gateway 700Z series.
> 
> Please let me know which more data should I submit to help troubleshoot and 
> find solution to this problem.
> 
> Looking forward to hearing any tips,
> NewbieLinuxUser

Not quite clear on how far the installation got. 
Did you succeed in setting up qubes, or do these errors occur during 
installation?
Are you using UEFI boot?
Did you verify installation medium?
What options did you select when installing Qubes?
Did you install Qubes to externmal USb drive?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190116005019.nghy5eim5fphvoq6%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Keyboard and mouse issue (R 4.0.1)

[unman]

On Tue, Jan 15, 2019 at 05:08:39PM +0200, Ivan Mitev wrote:
> 
> 
> On 1/15/19 2:42 PM, unman wrote:
> > On Tue, Jan 15, 2019 at 09:26:31AM +0200, Ivan Mitev wrote:
> >>
> >>
> >> On 1/15/19 3:36 AM, jrg.desk...@gmail.com wrote:
> >>> KEYBOARD
> >>>
> >>> How do I set the "compose" key on the keyboard? I have run several Linux 
> >>> distributions (base on Debian/Ubuntu) for several years and have had no 
> >>> problems setting a compose key so that I could enter diacriticals and 
> >>> symbols like the em-dash and the Spanish upside down exclamation and 
> >>> question marks.
> >>
> >> IIRC there's no gui setting in XFCE for setting a compose key. I don't
> >> use such key myself but I guess you can edit dom0's
> >> /etc/X11/xorg.conf.d/00-keyboard.conf and add XkbOptions there (eg.
> >> Option "XkbOptions" "compose:menu"). Run `grep "compose:"
> >> /usr/share/X11/xkb/rules/base.lst` to find what keys you can use.
> >>
> > 
> > The default key combo is Shift+AltGR - enabled by default in X
> > You can also set XkbOptions compose: in /etc/default/keyboard
> 
> I thought that /etc/default/keyboard was only for debian and
> derivatives. Are you sure it works for fedora ?

Not really a Fedora person. Probably not. :-(
On the other hand, I *do* find a GUI way of setting the key under System
Settings/Keyboard in KDE, and in Xfce, under
SystemTools-Keyboard-Layout.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190116004325.scbjumkfrurwrlgy%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Debugging

[unman]

On Tue, Jan 15, 2019 at 09:26:29PM +0100, birdynam wrote:
> Hi all,
> 
> What's the best way to debug a appvm ?
> 
> Thanks

Set out clearly what the (perceived) problem is.


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190116003413.x2wo4znqanccq433%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Keyboard and mouse issue (R 4.0.1)

[unman]

On Tue, Jan 15, 2019 at 09:26:31AM +0200, Ivan Mitev wrote:
> 
> 
> On 1/15/19 3:36 AM, jrg.desk...@gmail.com wrote:
> > KEYBOARD
> > 
> > How do I set the "compose" key on the keyboard? I have run several Linux 
> > distributions (base on Debian/Ubuntu) for several years and have had no 
> > problems setting a compose key so that I could enter diacriticals and 
> > symbols like the em-dash and the Spanish upside down exclamation and 
> > question marks.
> 
> IIRC there's no gui setting in XFCE for setting a compose key. I don't
> use such key myself but I guess you can edit dom0's
> /etc/X11/xorg.conf.d/00-keyboard.conf and add XkbOptions there (eg.
> Option "XkbOptions" "compose:menu"). Run `grep "compose:"
> /usr/share/X11/xkb/rules/base.lst` to find what keys you can use.
> 

The default key combo is Shift+AltGR - enabled by default in X
You can also set XkbOptions compose: in /etc/default/keyboard

> Alternatively, set up an autostart command - you now know how to do
> that:) - and run setxkbmap like so:
> 
> setxkbmap -option compose:menu
> 
> Note: keyboard settings are propagated from dom0 to VMs so you simply
> need to set them in dom0 to have them working in all the VMs. However I
> found that this was unreliable when switching languages - in case that's
> something you have to configure see [1] for a workaround.
> 
> > The other issue with the keyboard involves disabling the Caps Lock key (I 
> > am a fumble-fingered 73-year old and the caps lock key is the bane of my 
> > typing existence).
> 
> XkbOptions: caps:none
> 
> or,
> 
> setxkbmap -option "caps:none"
> 
> Combined with the above:
> 
> setxkbmap -option "caps:none compose:menu"
> 
> 
> > MOUSE
> > 
> > Before using the "Salt" method of setting up a sys-usb VM, I had my mouse 
> > set as left-handed. Then I got sys-usb set up. The mouse reverted to 
> > right-handed, but when I checked the System Tools --> Mouse and Touchpad, 
> > it indicated the mouse was left-handed.
> > 
> > But it is not :-(   Changing the setting to right-handed and then back had 
> > no effect. I have searched the menus to no avail.  Adding "Settings" to the 
> > sys-usb VM menu and then trying to invoke it failed.
> 
> Sorry, can't really help here; hopefully other users will chime in.
> 
> Dumb question though: are you sure you selected the right (no pun
> intended) mouse in System Tools --> Mouse and Touchpad ? On my system I
> have 3 mice - the laptop's trackpoint, touchpad and an external usb
> mouse ; I just tried to set the right/left handed setting for each of
> them (the setting works individually for each mouse) and it worked.

Yes, making change in Systen Tools has always worked for me.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190115124244.zrzfvqmsirxak5py%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] VMApp files from template

[unman]

On Tue, Jan 15, 2019 at 12:13:55PM +, Dave Albiston wrote:
> Hi there
> 
> I am new to Qubes so please be patient!
> 
> How can I access files in my VMApp folders from the template? I need to do
> this to add a menu option to run a script stored in the VMApp.
> 
> Many thanks
> 
> -- 
> Dave Albiston

Hi Dave

If you want to customise the menu, then the process is carried out in
dom0, not in a template.
If you are using the default of Xfce, then look at:
https://wiki.xfce.org/howto/customize-menu
In general, to run a program in a qube, you use something like this:
qvm-run -q --service --  qubes.StartApp+
or:
qvm-run -q  

The former form expects a desktop file, the latter uses a program name.
You can test these from a command line in dom0 to make sure that you
have the right format, and then create an appropriate menu item using
the command.

If you need more help, feel free to ask

cheers

unman



-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190115123134.numeshyni43p4xpc%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Qubes 4.0.1 Live

[unman]

If anyone is interested, I've put up a Live image for 4.0.1 at:
https://qubes.3isec.org/Live

The image only has Fedora and Debian templates, no sys-usb, (obviously)
and nothing is set to autostart. Doesnt use swap.
It will run off DVD or USB, and is serviceable in 8GB - the more memory
the better.

There's a desktop shortcut to install, but it doesnt work (as yet).

unman

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190114013330.q3sd72paaq6zorkn%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Debian minimal template

[unman]

On Fri, Jan 11, 2019 at 04:25:00PM +0100, Zrubi wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 1/10/19 1:14 AM, unman wrote:
> > If any one is interested there's a prebuilt debian-9-minimal
> > template currently available in itl-testing.
> 
> would you mind sending the output of
> dpkg -l
> 
> Thanks.
> - -- 
> Zrubi

Of course:

acl  2.2.52-3+b1   
adduser  3.115 
adwaita-icon-theme   3.22.0-1+deb9u1   
amd64-microcode  3.20160316.3  
apt  1.4.8 
apt-listchanges  3.10  
apt-transport-https  1.4.8 
apt-utils1.4.8 
aptitude 0.8.7-1   
aptitude-common  0.8.7-1   
aspell   0.60.7~20110707-3+b2  
aspell-en2016.11.20-0-0.1  
at-spi2-core 2.22.0-6+deb9u1   
avahi-daemon 0.6.32-2  
base-files   9.9+deb9u6
base-passwd  3.5.43
bash 4.4-5 
bash-completion  1:2.1-4.3 
bc   1.06.95-9+b3  
bind9-host   1:9.10.3.dfsg.P4-12.3+deb9u4  
binutils 2.28-5
bsdmainutils 9.0.12+nmu1   
bsdutils 1:2.29.2-1+deb9u1 
busybox  1:1.22.0-19+b3
bzip21.0.6-8.1 
ca-certificates  20161130+nmu1+deb9u1  
colord   1.3.3-2   
colord-data  1.3.3-2   
console-setup1.164 
console-setup-linux  1.164 
coreutils8.26-3
cpio 2.11+dfsg-6   
cpp  4:6.3.0-4 
cpp-66.3.0-18+deb9u1   
crda 3.18-1
cron 3.0pl1-128+deb9u1 
cryptsetup   2:1.7.3-4 
cryptsetup-bin   2:1.7.3-4 
cups 2.2.1-8+deb9u2
cups-browsed 1.11.6-3  
cups-client  2.2.1-8+deb9u2
cups-common  2.2.1-8+deb9u2
cups-core-drivers2.2.1-8+deb9u2
cups-daemon  2.2.1-8+deb9u2
cups-filters 1.11.6-3  
cups-filters-core-drivers1.11.6-3  
cups-pk-helper   0.2.6-1+b1
cups-ppdc2.2.1-8+deb9u2
cups-server-common   2.2.1-8+deb9u2
dash 0.5.8-2.4 
dbus 1.10.26-0+deb9u1  
dbus-user-session1.10.26-0+deb9u1  
dbus-x11 1.10.26-0+deb9u1  
dconf-cli0.26.0-2+b1   
dconf-gsettings-backend:amd640.26.0-2+b1   
dconf-service0.26.0-2+b1   
debconf  1.5.61
debconf-i18n 1.5.61
debian-archive-keyring   2017.5
debian-faq   8.1   
debianutils  4.8.1.1   
debugedit4.12.0.2+dfsg1-2  
desktop-file-utils   0.23-1
dh-python2.2017012

Re: [qubes-users] Re: Can't open xterm from default fedora-29-minimal template

[unman]

On Sun, Jan 13, 2019 at 04:36:32PM -0800, Tonyt wrote:
> On Sunday, January 13, 2019 at 7:11:33 PM UTC, 799 wrote:
> > Hello,
> > 
> > 
> > after I had some problems rebuilding my fedora-28 based templates with 
> > fedora-29, I re-installed the template using:
> > 
> > 
> > sudo qubes-dom0-update --action=reinstall qubes-fedora-29-minimal
> > 
> > 
> > while the installation worked and I can start and qvm-shutdown the new 
> > template, I am unable to launch a xterm terminal.
> > 
> > I tried it via the qubes menu, qvm-run fedora-29-minimal xterm, and also 
> > with the --user root option ... the AppVM starts, but no xterm is coming up.
> > Is this something which came from a recent update (of dom0 or the template)?
> > I knew that I didn't had this problems before.
> > 
> > 
> > - O
> 
> This sounds like this:
> https://github.com/QubesOS/qubes-issues/issues/4671
> 
> Which I solved with this:
> The problem: missing e2fsprogs, so /rw cannot be prepared.
> quick workaround: qvm-run -u root --no-gui -p fedora-29-minimal 'dnf install 
> -y e2fsprogs'
> 

There's an updated minimal template in templates-itl-testing

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190114004037.z76qb4l2sqikgle6%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] bind-dirs qubes 4.0.1

[unman]

On Sun, Jan 13, 2019 at 09:00:27PM +, Robert Rettig wrote:
> > Hi,
> >
> > with the current 4.0.1 even the "How does it work?" section as mentioned
> > here
> > https://groups.google.com/d/msg/qubes-users/m0qWwToAi8w/phdwx1hSCQAJ
> > cannot be applied.
> >
> > Maybe because the file `bind-dirs.sh` is not available at the described
> > location anymore?
> >
> > A file with the same name would be here `/usr/lib/qubes/init/bind-dirs.sh`.
> >
> > Created a template clone from `fedora-29` and installed `Docker CE` into it.
> >
> > ```
> > curl -fsSL https://get.docker.com -o get-docker.sh
> > CHANNEL=stable sh get-docker.sh
> > sudo usermod -aG docker user
> > sudo systemctl enable docker
> > ```
> >
> > Shutdown that template and created an appvm from it.
> >
> > I added the bind-dir files as described. But it will not create symlinks
> > or copy existing files.
> >
> > In which state the `bind-dir.sh` is running. Maybe docker daemon already
> > created the files and no initial symlinks can be mounted by the script?
> >
> >
> > Thanks for some hints.
> >
> 
> I inovked the script manually
> 
> ```
> sudo /usr/lib/qubes/init/bind-dirs.sh
> ```
> after that it seems to work.

This was covered in the list recently.
debian templates have a symlink in /usr/lib/qubes but Fedora templates
seem to lack 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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190114003820.7a2zq2bqq3u7fimo%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Using OpenBSD as Qubes firewall

[unman]

On Sun, Jan 13, 2019 at 08:28:58PM +0100, alexandre.belgr...@mailbox.org wrote:
> Dear all,
> 
> Pardon my ignorance, is it possible to use OpenBSD to provide firewalling to 
> Qubes?
> I have nearly zero confidence in GNU/Linux although I use it everyday.
> 
> Kind regards,

If you search this list you'll see this has already been covered.
You can install openBSD as HVM, and with some manipulation of basic
Qubes networking, have it act as a netvm. Thus take place of sys-net or
sys-firewall.

You can find some notes that may help here:
https://github.com/unman/notes/blob/master/openBSD_as_netvm

unman

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190114003548.vx6xvpxqubjaoq5n%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.