Re: [qubes-users] Restored, and it's missing so much...

[Drew White]

On Tuesday, 27 September 2016 14:58:58 UTC+10, johny...@sigaint.org  wrote:
> By backup/restore I assume you don't mean Qubes backup/restore feature,
> but you copying .img files around manually, correct?

Correct, because they are the HDD, the rest is not even worth saving in a 
STANDALONE.

If it was not a standalone then it wouldn't be an issue.

It's a bug in Qubes where the libxenlight or whatever it's called can't create 
the domain, so what I used to do, especially for standalone Windows VMs was 
just rename the folder, make the folder again, copy the config over.. then 
REMOVE VM.
That would remove it from the structure. Then I'd create a new VM with 
identical name, then move the root.img and private.img files back in and away 
I'd go again, it would be able to create the domain and all.

but just now, the one I did earlier, had the same error, so I did what I would 
normally do that works. But this time, it started, then I ran the program from 
the CLI, and it wasn't even installed. So I ran the RPMs again... and it said 
it was missing the dependencies.

Yet it was the same VM with all the alterations and data that I had from the 
standalone guest.

-- 
You received this message because you are subscribed to the Google Groups 
"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/fe33d4f4-ca81-493d-adea-40a6ba0a2c93%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Restored, and it's missing so much...

[johnyjukya]

> Hmmm, you would probably also need to re-export the app shortcuts to dom0.
>  This *may* be the best way to do it, but the Qubes devs may have a better
> suggestion.  Open a terminal in the newly restored VM and run:
>
> "/usr/lib/qubes/qrexec-client-vm dom0 qubes.SyncAppMenus /bin/sh
> /etc/qubes-rpc/qubes.GetAppmenus"

Whoops, scratch that.  As always, the Qubes' devs have already taken care
of that, and have a better, more official way.  From dom0:

"qvm-sync-appmenus "

(And, of course, the appmenus come from the VM's templateVM, not from the
AppVM, which I neglected to mention.  So you only need to do that if
you're restoring a TemplateVM, not an AppVM.)

Cheers

JJ

-- 
You received this message because you are subscribed to the Google Groups 
"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/256780391417c64d27352f0d917561b3.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Snapshots - Use of CoW

[Drew White]

On Tuesday, 27 September 2016 14:23:45 UTC+10, johny...@sigaint.org  wrote:
> > On Monday, 26 September 2016 12:11:56 UTC+10, johny...@sigaint.org  wrote:
> >> AppVM's are designed to toss changes, other than /home, /rw, /usr/local.
> >> It's a good thing; if one gets compromised, it's a temporary compromise.
> >> :)
> >>
> >> If you want permanent changes, update your template.
> >>
> >> But it sounds like you might want a "standalone VM":
> >
> > Hi JJ, I know it's meant to, but if I'm testing something, I want to
> > install pre-requisites for things, then it may have to restart, then I
> > want to take a snapshot, then perform the next step, then do another
> > snapshot, and revert if I need to.
> 
> Fair enough.  That's something I also would find useful, and is why I'm
> switching to btrfs root soon.
 



> >> Also, using BTRFS as a root (or VM host) filesystem should allow you to
> >> snapshot/rollback the standalone VM to your heart's content (and clone
> >> it
> >> instantly).  BTRFS is all about the copy-on-write.
> >
> > I'm not going to use that on an SSD, that creates way too many writes. As
> > far as I've read and know, correct me if I'm wrong, BTRFS is a journaling
> > file system, meaning it writes the changes that it's going to make to the
> > journal, and then writes the changes to the disk. This means it writes
> > everything twice.
> > On an SSD that isn't good, it decreases the life of the drive by over 50%.
> 
> From the BTRFS Faq:
> 
> "There are some optimizations for SSD drives, and you can enable them by
> mounting with -o ssd. "
> 
> "Mount -o ssd_spread is more strict about finding a large unused region of
> the disk for new allocations, which tends to fragment the free space more
> over time. Mount -o ssd_spread is often faster on the less expensive SSD
> devices. The default for autodetected SSD devices is mount -o ssd. "
> 
> Doesn't sound too bad to me.  Are SSD's really that prone to wearing out
> quickly?
 
Yes they do.
I had 2 SSDs, both doing the same thing. One was EXT4, the other was EXT2.
EXT4, after a check, had over 2 million errors on it. The EXT2 had 1 error.


> Ignoring spare files, if you consider that a reflink copy of, say, a 2G
> file (such as a VM .img file) takes almost no disk activity on BTRFS (just
> a metadata cloning due to the COW nature), while ext4 churns away
> reading/writing the full 2G of data, I'd say that BTRFS could *save* you a
> whole bunch of wear on your SSD.
> 
> snapshotting and reverting under BTFS is near immediate, versus copying of
> multiple large files; seems like a no-brainer in favor of BTRFS.
> 
> From another page:
> 
> "Btrfs is SSD-aware and exploits TRIM/Discard to allow the file system to
> report unused blocks to the storage device for reuse. On SSDs, Btrfs
> avoids unnecessary seek optimization and aggressively sends writes in
> clusters, even if they are from unrelated files. This results in larger
> write operations and faster write throughput, albeit at the expense of
> more seeks later."
> 
> And:
> 
>   https://oss.oracle.com/pipermail/btrfs-devel/2008-February/000513.html
> 
> And:
> 
>   https://www.linux.com/learn/weekend-project-get-started-btrfs
> 
> which comments:
> 
> "the system uses a copy-on-write strategy that writes changed data to disk
> first, then updates the references in the tree. This crash-proofs the
> filesystem, but without the overhead of maintaining a journal."
> 
> (That article was six years ago, not sure if things have changed, but on a
> quick search I couldn't find any reference to BTRFS using journaling.)
 
Then perhaps the things I read back then were mistaken, or worded what they 
said the wrong way.


> In fact, the wiki page on journaling filesystems:
> 
> https://en.wikipedia.org/wiki/Journaling_file_system#Alternatives
> 
> considers BTFS and COW-based filesystems as *alternatives* to journaling
> filesystems:
> 
> "Full copy-on-write file systems (such as ZFS and Btrfs) avoid in-place
> changes to file data by writing out the data in newly allocated blocks,
> followed by updated metadata that would point to the new data and disown
> the old, followed by metadata pointing to that, and so on up to the
> superblock, or the root of the file system hierarchy. This has the same
> correctness-preserving properties as a journal, without the write-twice
> overhead."
> 
> So your fears may be unfounded, and you might be missing out on a tech
> that provides exactly what you need.  :)
> 
> > This is why I use EXT2 Filesystem, even in the templates. (The templates
> > were originally EXT3/4 if memory serves, as an LVM.
> 
> Flying without a journal (especially wrt metadata) is a bit bold in this
> day and age.  :)
 
Not really.


> > Well, I can't use Qubes 4.0, because you are FORCING it to REQUIRE
> > technology in the CPU that my Multi-CPU system doesn't have.
> 
> That's a thorn in my side as well, but possibly the price of progress.

It's not the price of progress, it should be an 

Re: [qubes-users] Restored, and it's missing so much...

[johnyjukya]

 > I just copied my standalone VM that was working, to back it up.
>
> Then I restored the .img files, which is the HDD, and now it's telling me
> I don't have the dependancies to run the application that I was running
> before I copied the img files.
>
> Why is this broken?
> Why will backup/restore not let this work properly?

By backup/restore I assume you don't mean Qubes backup/restore feature,
but you copying .img files around manually, correct?

What exactly is "telling you you don't have the dependencies to run the
application?"  Which application?  (Do you mean when you try to use the
VM's start menu shortcuts?)

There's more to an AppVM than just the files in the directory.  (I think
most other info about the AppVM's lives in /var/lib/qubes/qubes.xml.)

Obviously this isn't a "supported" method, but here's what I've done in
the past to restore some VM's when my Qubes install got trashed (due to
filesystem corruption of running on an external USB drive, and being a bit
sloppy about the fsck repair):

For each AppVM, create a new, empty AppVM with the same settings as the VM
you wish to restore.

Then (making sure the VM isn't running), replace the .IMG files of the new
VM with the ones from the old VM to be restored.

Then add any shortcuts you have had before.

Worked like a charm.

Hmmm, you would probably also need to re-export the app shortcuts to dom0.
 This *may* be the best way to do it, but the Qubes devs may have a better
suggestion.  Open a terminal in the newly restored VM and run:

"/usr/lib/qubes/qrexec-client-vm dom0 qubes.SyncAppMenus /bin/sh
/etc/qubes-rpc/qubes.GetAppmenus"

(Borrowed from /usr/lib/qubes/qubes-trigger-sync-appmenus.sh, but that
looks like it might only do that if changes have been flagged.  I'm
guessing a bit here.)

Or just install any new package with apt-get, and the menus should sync. 
Then re-add your shortcuts in Qubes VM Manager.

It would be convenient if qubes.xml were "deconstructed" a bit into
separate human readable config files stashed in each VM's directory; but
that might not be great for performance.  Most other things about a VM are
fairly accessible and intuitive, except for qubes.xml.

(Also, when copying around .IMG files, make sure you use "cp
--sparse=always" to preserve the sparseness, otherwise the new destination
will take up the full listed size of the file, and not just the allocated
blocks, as well as taking a lot longer.  "ls -ls" will show the actual
allocated block count of your files.)

Cheers

JJ

-- 
You received this message because you are subscribed to the Google Groups 
"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/3de9d0f3b16a3cef77a62d286887d739.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Snapshots - Use of CoW

[johnyjukya]

> On Monday, 26 September 2016 12:11:56 UTC+10, johny...@sigaint.org  wrote:
>> AppVM's are designed to toss changes, other than /home, /rw, /usr/local.
>> It's a good thing; if one gets compromised, it's a temporary compromise.
>> :)
>>
>> If you want permanent changes, update your template.
>>
>> But it sounds like you might want a "standalone VM":
>
> Hi JJ, I know it's meant to, but if I'm testing something, I want to
> install pre-requisites for things, then it may have to restart, then I
> want to take a snapshot, then perform the next step, then do another
> snapshot, and revert if I need to.

Fair enough.  That's something I also would find useful, and is why I'm
switching to btrfs root soon.

>> Also, using BTRFS as a root (or VM host) filesystem should allow you to
>> snapshot/rollback the standalone VM to your heart's content (and clone
>> it
>> instantly).  BTRFS is all about the copy-on-write.
>
> I'm not going to use that on an SSD, that creates way too many writes. As
> far as I've read and know, correct me if I'm wrong, BTRFS is a journaling
> file system, meaning it writes the changes that it's going to make to the
> journal, and then writes the changes to the disk. This means it writes
> everything twice.
> On an SSD that isn't good, it decreases the life of the drive by over 50%.

>From the BTRFS Faq:

"There are some optimizations for SSD drives, and you can enable them by
mounting with -o ssd. "

"Mount -o ssd_spread is more strict about finding a large unused region of
the disk for new allocations, which tends to fragment the free space more
over time. Mount -o ssd_spread is often faster on the less expensive SSD
devices. The default for autodetected SSD devices is mount -o ssd. "

Doesn't sound too bad to me.  Are SSD's really that prone to wearing out
quickly?

Ignoring spare files, if you consider that a reflink copy of, say, a 2G
file (such as a VM .img file) takes almost no disk activity on BTRFS (just
a metadata cloning due to the COW nature), while ext4 churns away
reading/writing the full 2G of data, I'd say that BTRFS could *save* you a
whole bunch of wear on your SSD.

snapshotting and reverting under BTFS is near immediate, versus copying of
multiple large files; seems like a no-brainer in favor of BTRFS.

>From another page:

"Btrfs is SSD-aware and exploits TRIM/Discard to allow the file system to
report unused blocks to the storage device for reuse. On SSDs, Btrfs
avoids unnecessary seek optimization and aggressively sends writes in
clusters, even if they are from unrelated files. This results in larger
write operations and faster write throughput, albeit at the expense of
more seeks later."

And:

  https://oss.oracle.com/pipermail/btrfs-devel/2008-February/000513.html

And:

  https://www.linux.com/learn/weekend-project-get-started-btrfs

which comments:

"the system uses a copy-on-write strategy that writes changed data to disk
first, then updates the references in the tree. This crash-proofs the
filesystem, but without the overhead of maintaining a journal."

(That article was six years ago, not sure if things have changed, but on a
quick search I couldn't find any reference to BTRFS using journaling.)

In fact, the wiki page on journaling filesystems:

https://en.wikipedia.org/wiki/Journaling_file_system#Alternatives

considers BTFS and COW-based filesystems as *alternatives* to journaling
filesystems:

"Full copy-on-write file systems (such as ZFS and Btrfs) avoid in-place
changes to file data by writing out the data in newly allocated blocks,
followed by updated metadata that would point to the new data and disown
the old, followed by metadata pointing to that, and so on up to the
superblock, or the root of the file system hierarchy. This has the same
correctness-preserving properties as a journal, without the write-twice
overhead."

So your fears may be unfounded, and you might be missing out on a tech
that provides exactly what you need.  :)

> This is why I use EXT2 Filesystem, even in the templates. (The templates
> were originally EXT3/4 if memory serves, as an LVM.

Flying without a journal (especially wrt metadata) is a bit bold in this
day and age.  :)

> Well, I can't use Qubes 4.0, because you are FORCING it to REQUIRE
> technology in the CPU that my Multi-CPU system doesn't have.

That's a thorn in my side as well, but possibly the price of progress.

JJ

-- 
You received this message because you are subscribed to the Google Groups 
"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/3f782b239892ed875d93497ab3d1.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] I can't disable ipv6 on Debian Template

[johnyjukya]

> Really ? No one to find also suspicious a wild init/1 tcp6 port listening
> on your templateVM, right out of the box ? This got to be real.
...
> I am answering you on my phone just because it seems my old Qubes deleted
> partition doesn't like very much my USB key to runs over it, for some
> reason. And this is pissing me off.
...
> So let me rephrase : how do you completely remove Qubes OS from your hard
> drive so that eventually it might still accept another OS install ? Fuck
> this shit.
...
> Btw on any decent OS you can clear your own partitions on installation
> window and refresh your own disk without installing the OS. On Qubes you
> can't. You are supposed to run the install to do so. And it seems the
> install fucks your hardware next -.-
...

Ummm, I think I'm tending to agree with Unman's suspicions:

> and I wonder if it's a troll anyway, when I look at some of the
> later comments.

I deem thee a troll.  An angry, foul-mouthed troll.

Or someone who has an agenda against Qubes' goals.

Either that, or you're in way over your head technology-wise and don't
have the patience to work through it, even with a community trying to help
you.

I might suggest you go install Windows (or buy a tablet) and take out your
anger elsewhere.

Cheers

JJ


-- 
You received this message because you are subscribed to the Google Groups 
"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/4144e1e93b958945a74aedbb99685c7f.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?

[johnyjukya]

> Wow. Not even 4 GB of compiled drivers for the WiFi. You are saying it's 4
> GB of raw plaintext source code..?
>
> WOW
>
> That's INSANELY complex.

Apologies, I spoke a bit hastily.  What was seeing was 4 million Git
objects, not 4G of data (although it may be).  And that included all
branches and all the history of the repo, so it's not a fair measure.

(In my defense, back in my day we used "rcs" and we got along just fine. 
Then we switched to "sccs."  Then "cvs." Then "svn."  Then "git."  One
needs a version control system just to keep track of the version control
system that is currently in vogue.)

I just checked out the master branch and it clocked in at 917 meg.  Still
not exactly lightweight.  No single directly was above a Megabyte.  There
is just lots and lots and lots of directories.  :)

Plus, the source tree contains filesystem implementations, tools, etc., etc..

Within the master branch, drivers/net/wireless clocks in at 34 meg
(getting a bit more reasonable, lol).

Some stats: the total line count of all the .c and .h files under
drivers/net/wireless is just over a million lines of code.  There were
1310 .c/.h files, which averages out to 770 LOC per .c/.h file.

They represent device support for 15 different vendors (and no doubt
supporting more brands of similar devices, with OEM rebranding and such).

Somewhere in the neighbor of under 250 different device variations
supported (although that is a rather clumsy measure based upon defines in
Makefiles; I'm getting tired, lol).

An example of the biggest files and their lines-of-code:

  28721 ./broadcom/brcm80211/brcmsmac/phy/phy_n.c
  12061 ./intel/ipw2x00/ipw2200.c
  10630 ./broadcom/brcm80211/brcmsmac/phy/phytbl_n.c
  10318 ./broadcom/b43/radio_2056.c
   8646 ./intel/ipw2x00/ipw2100.c
   8231 ./ath/ath10k/wmi.c
   8224 ./cisco/airo.c
   8139 ./broadcom/brcm80211/brcmsmac/main.c
   8066 ./ath/ath10k/mac.c
   8027 ./ralink/rt2x00/rt2800lib.c
   7018 ./broadcom/brcm80211/brcmfmac/cfg80211.c
   6873 ./intel/iwlegacy/4965-mac.c
   6726 ./broadcom/b43/phy_n.c
   6652 ./ath/ath10k/wmi.h
   6575 ./ti/wlcore/main.c
   6348 ./marvell/mwl8k.c
   6334 ./realtek/rtl8xxxu/rtl8xxxu_core.c
   5872 ./broadcom/b43/main.c
   5594 ./intel/iwlegacy/common.c
   5511 ./ath/ath9k/ar9003_eeprom.c
   5247 ./broadcom/brcm80211/brcmsmac/phy/phy_lcn.c
   4843 ./realtek/rtlwifi/rtl8821ae/phy.c
   4706 ./ath/wcn36xx/hal.h
   4572 ./realtek/rtlwifi/rtl8821ae/table.c
   4549 ./atmel/atmel.c
   4337 ./marvell/mwifiex/cfg80211.c
   4305 ./broadcom/brcm80211/brcmfmac/sdio.c
   4230 ./intel/iwlwifi/mvm/mac80211.c
   4170 ./ath/ath6kl/wmi.c
   4143 ./realtek/rtlwifi/rtl8821ae/hw.c
   4097 ./intel/iwlwifi/mvm/rs.c
   4062 ./broadcom/b43legacy/main.c
   4046 ./intersil/hostap/hostap_ioctl.c
   4036 ./ath/ath6kl/cfg80211.c
   4008 ./intel/iwlwifi/dvm/commands.h
   3965 ./ath/ath5k/phy.c
   3959 ./intel/iwlegacy/3945-mac.c
   3878 ./broadcom/b43/tables_nphy.c
   3861 ./realtek/rtlwifi/btcoexist/halbtc8821a2ant.c
   3819 ./realtek/rtlwifi/btcoexist/halbtc8192e2ant.c
   3774 ./rndis_wlan.c
   3626 ./realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
   3594 ./realtek/rtlwifi/rtl8192de/phy.c
   3576 ./ath/ath10k/wmi-tlv.c
   3370 ./intel/iwlegacy/commands.h
   3180 ./ath/ath9k/ar9002_initvals.h
   2456 ./broadcom/b43/tables_lpphy.c

Some of the bigger files seem to be tables used for radio communication,
possibly DSP-like tables to drive things (and nary a comment to be seen),
and (thankfully) not so much binary chunks of proprietary code.

Others are large in order to interface with (and/or implement?) complex
modem command sets.  And probably many other reasons.  But that's a quick
sampling of the fun.

Similar to my hasty comments on the code size, my complaining about how
the code was structured turns out not to be specific to the wireless, but
is a common approach for kernel configuration and drivers in general.

But it's safe to say the complexity is an order of magnitude greater than
for ethernet.

> A bit like how people have said phone basebands are incredibly complex,
> not to mention, closed source.

I've come to think of basebands (in phones, for example) as like ISP's, a
bit beyond your control, and as things that should be compartmentalized
hardware-wise and treated as potentially hostile.  Sadly, I think many
phones today aren't implemented in that spirit.

One horrific example of getting things completely backwards (allowing the
baseband to freely probe around and modify the phone's memory, ostensibly
in the name of support, I suppose :S) is the "Samsung backdoor":

http://redmine.replicant.us/projects/replicant/wiki/SamsungGalaxyBackdoor

Replicant, a stripped-down non-proprietary fork of Android, tries to
isolate and not play well with that baseband feature, effectively treating
it as potentially hostile.  Sad that it's necessary.

"Our free software replacement for the incriminated binary is Samsung-RIL
which relies on libsamsung-ipc: both are used in Replicant.

[qubes-users] Re: Why won't Google Chrome remember my Google logins?

[chklin]

https://bugs.chromium.org/p/chromium/issues/detail?id=631171

-- 
You received this message because you are subscribed to the Google Groups 
"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/817124c2-35c5-4396-a847-1d1475c9edc7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] I can't disable ipv6 on Debian Template

[nishiwaka46]

Hey,

Really ? No one to find also suspicious a wild init/1 tcp6 port listening on 
your templateVM, right out of the box ? This got to be real.

I am still interested in your solutions to quit Qubes OS and have another OS 
being able to run on my USB key and be installed, if you don't mind.

I am answering you on my phone just because it seems my old Qubes deleted 
partition doesn't like very much my USB key to runs over it, for some reason. 
And this is pissing me off.

So let me rephrase : how do you completely remove Qubes OS from your hard drive 
so that eventually it might still accept another OS install ? Fuck this shit.

Btw on any decent OS you can clear your own partitions on installation window 
and refresh your own disk without installing the OS. On Qubes you can't. You 
are supposed to run the install to do so. And it seems the install fucks your 
hardware next -.-

-- 
You received this message because you are subscribed to the Google Groups 
"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/4187ae87-4afc-437f-b26f-cf793b7f7f60%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Restored, and it's missing so much...

[Drew White]

Hi folks,

I just copied my standalone VM that was working, to back it up.

Then I restored the .img files, which is the HDD, and now it's telling me I 
don't have the dependancies to run the application that I was running before I 
copied the img files.

Why is this broken?
Why will backup/restore not let this work properly?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To 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/c169e683-7d92-4465-8db1-8eef6018e584%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Snapshots - Use of CoW

[Drew White]

On Monday, 26 September 2016 12:11:56 UTC+10, johny...@sigaint.org  wrote:
> AppVM's are designed to toss changes, other than /home, /rw, /usr/local. 
> It's a good thing; if one gets compromised, it's a temporary compromise. 
> :)
> 
> If you want permanent changes, update your template.
>
> But it sounds like you might want a "standalone VM":

Hi JJ, I know it's meant to, but if I'm testing something, I want to install 
pre-requisites for things, then it may have to restart, then I want to take a 
snapshot, then perform the next step, then do another snapshot, and revert if I 
need to. 

Some of the ones I want to do this for are standalone. I have multiple 
standalones because I can't do what I want to do completely.

I have 1 for web development, 1 for pascal coding, 1 for pic programming, and 
several others. They don't have internet access, only LAN access. So they are 
secure because I limit what they can talk to on the network too.
They can talk to the respository that's on the LAN, so that I don't have to 
download updates from the internet 10 times just to update my PC. I download 
once, then update everything.

If it gets compromised, then I just restore from a backup, but since it can't 
talk to the internet, there is no real threat there.


> Also, using BTRFS as a root (or VM host) filesystem should allow you to
> snapshot/rollback the standalone VM to your heart's content (and clone it
> instantly).  BTRFS is all about the copy-on-write.

I'm not going to use that on an SSD, that creates way too many writes. As far 
as I've read and know, correct me if I'm wrong, BTRFS is a journaling file 
system, meaning it writes the changes that it's going to make to the journal, 
and then writes the changes to the disk. This means it writes everything twice.
On an SSD that isn't good, it decreases the life of the drive by over 50%.

This is why I use EXT2 Filesystem, even in the templates. (The templates were 
originally EXT3/4 if memory serves, as an LVM.


On Monday, 26 September 2016 19:23:11 UTC+10, Marek Marczykowski-Górecki  wrote:
> Also in case of templates, you have qvm-revert-template-changes, which
> will rollback changes done during last template run. Currently only one
> such revision is stored.
> 
> In Qubes 4.0 there will be (actually this is already implemented) an
> option to keep multiple of them, and not only for templates, but also
> for normal AppVMs.


Well, I can't use Qubes 4.0, because you are FORCING it to REQUIRE technology 
in the CPU that my Multi-CPU system doesn't have.
So I'm stuck on 3.2
Having it in 4+ is more than useless to me.

If it was able to be instantiated into 3.2 somehow, that would be great. If 
not, then I would have to do it myself after learning every line of code in the 
final system.

I appreciate that it's going to be in there, but it would be beneficial to have 
it in a version that wasn't so restrictive.


-- 
You received this message because you are subscribed to the Google Groups 
"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/77a03af5-08c6-418f-b954-9d91d75ccbca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Thunderbird: "Open link in DispVM"

[Clark Venable]

Robert,

You are right. I misread your post as referring to attachments rather than 
links. Sorry about that.

Clark

-- 
You received this message because you are subscribed to the Google Groups 
"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/281c929b-f6e5-422e-a9c4-cb7e0b82834f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Why won't Google Chrome remember my Google logins?

[Clark Venable]

Thanks for the confirmation, Mat. I was just chalking it up to not having done 
something right.  As I indicated, Firefox works as I expect, so I've just 
switched to that as my main browser.

Clark

-- 
You received this message because you are subscribed to the Google Groups 
"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/1f1330fb-0868-4b16-b610-7839b73154c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] I can't disable ipv6 on Debian Template

[johnyjukya]

> What does "systemctl list-sockets" show?  Any services that systemd is
> providing a listener for should be listed here.

If you do spot a network socket service in that listing, you can stop the
current service with "systemctl stop blah.socket", and disable it in the
future (next reboot or VM restart) with "systemctl disable blah.socket".

There's always the potential that it could be re-enabled in the future by
installing another package dependent upon that service.  (That's bitten me
a couple of times.)

To block that from potentially happening, use "systemctl mask blah.socket"
and the service will stay off regardless of new dependencies.

("systemctl unmask" undoes the blocking.  Go figure.)

Oh yeah, to have those commands truly "stick," you should run them from
the template, not the AppVM.

Slight digression (from JJ, no way?!?!?): There's a few config things like
this (e.g. /etc/fstab) that I really think should be (by default) symlinks
to /rw/config, so they could be tweaked on an per-appVM basis.  (At risk
of a compromised VM being able to have more lasting hack-related effects
after a restart.)

It's easy enough to do in the template/appvm yourself, of course. e.g.:

# cp /etc/fstab /rw/config/fstab && ln -s /rw/config/fstab /etc/fstab

in the TemplateVM.  You could similarly do that with any systemctl config
files that you need different on a per-appVM basis.

Cheers

JJ

-- 
You received this message because you are subscribed to the Google Groups 
"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/ad4e21c34c3cab74a369f046abeb277b.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Thunderbird: "Open link in DispVM"

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-09-26 01:30, Robert Mittendorf wrote:
> Hey Clark,
> 
> the article which you referenced to is about opening (and converting) PDF 
> documents. My idea is about opening URLs (Links) in a DispVM. I think that is 
> not related in any way, is it?
> 
> Robert
> 

Robert,

Your emails got caught in the spam filter. I'm sorry
about that. I approved only one of them (rather than
all 4-5) because I figured your intention was to send
the message to the list only once. You should be added
to the whitelist now.

P.S. - Please try to avoid top-posting.

> btw: did you notice, that googlegroups blocks email having a subject starting 
> with a quote (single ' or double ") ? I - I sent this email 4 times over 
> several days.
> 
> Am 09/24/2016 um 11:02 PM schrieb Clark Venable:
>> Have you seen this?
>>
>> https://micahflee.com/2016/07/how-qubes-makes-handling-pdfs-way-safer/
>>
>> Clark
> 


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

iQIcBAEBCgAGBQJX6ZXPAAoJENtN07w5UDAwpTgQAJGLzh6A59px+f+2yV7Esao2
k9/1uwme+Ttx1FqO1NmXztCftJAcMi8zKuDsGozdCZXCoQrH5ZGUD/qqmfv8v/OH
iLnTx9kvsdxgJlD9HRJn0j/FU6W2ivhVlRmesuBO5YnxONvfJBG4AlwDQDBb4JPF
Pb8rF4BwoZJDtt+3O8vqmJkXwGqgowj8kJdTWlaN7+31UbSMzSs2OByJfVswtJ++
iz5trJjzjYTTIroDxLuSZlznxkKqfNKAlsmCFAU61vIPK7J7BQnZ1MCulmPZsAiX
j/lJyADSqaeZCCWJOzbWuYlJzU80wbu7BI6qn7RczAzzyIngaJ4mu4UqJe6SI78d
XEKu7FctcgzY85AxDvl4VHBDGaJ7CHbWvKRzNjuLdTAhzrFKjkVjqEdBEi0iF1ah
t6sM3jgvDS2kWjgkMGsTUg3LzfovtORBtAB0afen1c2bUOe7LCBzyX0oBKVIYpns
0yfres46pf8wxT+HTiNIInugCAv0T2YI5dKuwbNiYmI4Jzphc8sdsqYMpdi2gQ6e
XvD0MtE3tsBk69Mgbu2xdtVIJ1umhW5aEPoX/zV3y1+DbaHm/VVU4iu4wljqqnkR
hR6L0lBBaNvzWItg2DnbxKSqmQZ8KV6GIeHugmS+QoxVK8jFW+a8rnxJFe+/ThYn
MBhC8tZp9vqGqkS0zhm9
=IEXM
-END PGP SIGNATURE-

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

Re: [qubes-users] I can't disable ipv6 on Debian Template

[johnyjukya]

> Thank you guys for your help, but unfortunately I don't think there is a
> way to get rid of this process listening on tcp6 on init (systemd... d
> standing here for distant...). It is listed as 1 on PID, I don't think you
> can't remove it, it is a main process. So I am not interested in using
> Qubes anymore because I  disapprove those bad policies on respect of
> privacy.

systemd listens on sockets on behalf of other services (and fires them up
when a connection arrives, similar to "inetd" in days of old).

What does "systemctl list-sockets" show?  Any services that systemd is
providing a listener for should be listed here.

The configuration files that control such behavior could be shown with:

> sudo find /usr/lib/systemd /etc/systemd -name '*.socket'

This may also reveal useful information, but the above is probably
sufficient:

"sudo lsof -i -p 1"

Cheers

JJ

-- 
You received this message because you are subscribed to the Google Groups 
"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/d78f57a37c459a66ba5cd74b4154a8c2.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] HCL - Lenovo Thinkpad X1 Carbon 4th gen (20FB)

[Jean-Philippe Ouellet]

A few notes:

The 4.1 kernel R3.1 ships with is not usable due to graphics issues on
resume. Update with the unstable repo or use 3.2.

I am booting in UEFI mode, and had to follow the advice of
https://www.qubes-os.org/doc/uefi-troubleshooting/ in order to get the
4.4 kernel to boot. This was *very* time consuming to find out the
hard way.

The internal disk is an NVMe device, and appears to just be supported,
no problem.

Wireless works with 4.4 kernels and seems stable.

Graphics, audio, and wireless all appear to continue to work after
suspend/resume so far.

I have not had the machine long enough to have a confident idea of
battery life yet, but the 4th-gen x1 runs hotter while completely idle
than my 1st-gen x1 does while playing music and doing light disk/net
i/o, so there must be room for improvement. More recent kernels should
improve things, but I have yet to try.

I was on a 1st-gen (3443) x1 carbon before and had the screen go
permanently-white (but works when plugged into an external monitor).
That was running Qubes just fine too (although 8gb ram was a little
tight for my level of compartmentalization). Infuriating-to-discover
UEFI issue aside, the 4th-gen x1 carbon seems like a good upgrade.
They removed the dedicated volume buttons, hardware r/f kill switch,
and dropped down to a single USB controller (keyboard still not on
USB, thankfully), but otherwise it's a rather similar device.

I'll have to use it for a while before I'm willing to recommend it for
Qubes, but so far it seems like a decent option.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To 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/CABQWM_BjR-7sPDNh%2B276fSpBBbrXz5vFWZw43Ee24x5O5JYPrA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-LENOVO-20FBCTO1WW-20160926-174010.yml
Description: Binary data

Re: [qubes-users] How to mount USB with ISO in Windows-Template

[Jean-Philippe Ouellet]

On Mon, Sep 26, 2016 at 3:01 PM, martin.forum  wrote:
>
> https://www.qubes-os.org/doc/uefi-troubleshooting/

WOW! That was it... Thank you!

I had ignored that page (having come across it several times) because
the symptoms it describes did not match the behavior I was
experiencing, but it did indeed solve my issue! :D

I have submitted a pull request to add my symptom explicitly to that
page to hope to avoid someone else wasting time with the same problem
as me: https://github.com/QubesOS/qubes-doc/pull/194

Sincerely,
A very happy (and feeling kinda dumb) user :)

-- 
You received this message because you are subscribed to the Google Groups 
"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/CABQWM_B6zYweW1p_3K6qdGnO-UkuSC-BHRRinV%3DhPZp-smZW5A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] I can't disable ipv6 on Debian Template

[nishiwaka46]

Hey,

Thank you guys for your help, but unfortunately I don't think there is a way to 
get rid of this process listening on tcp6 on init (systemd... d standing here 
for distant...). It is listed as 1 on PID, I don't think you can't remove it, 
it is a main process. So I am not interested in using Qubes anymore because I  
disapprove those bad policies on respect of privacy.
I don't want data to travel from my main template to Qubes servers without my 
consent and I don't like the fact someone might monitor what I am doing with my 
Debian template through ipv6. Really disappointing.

Tbh at first I liked the fact that Qubes doesn't allow to be installed inside 
another OS, it looked like a nice security feature, but now that I can't clear 
completely my hard disk from Qubes hard drive protection, this is really 
annoying as I can't reinstall another OS
on my hard drive.

Any help on how to uninstall completely Qubes by removing the hard drive 
protection would be appreciated. I didn't find a way to do it in documentation.

Regards

-- 
You received this message because you are subscribed to the Google Groups 
"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/a1ca58ae-1237-4663-8e81-f9c3098e4d74%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?

[johnyjukya]

> Please read if you haven't already:
>
> http://invisiblethingslab.com/resources/2014/Software_compartmentalization_vs_physical_separation.pdf
>
> 2 big takeaways:
>
> 2. The Physical Gateway needs to be secure not only from attacks from the
> Internet but also attacks from the client appVM.

Haven't read the paper yet (will definitely do it), but that's a very
intriguing point.

> 1. A typical networking stack presents a huge attack surface.

In response to the original poster (and for my own curiosity), I was going
to take a look at the Wireless drivers for the athlon 5k cards (no CPU on
board).

Google landed me at the Linux wireless driver site, so I went to grab a
Git clone of the latest wireless driver source.  Four gigabytes! 
Yeeeouch.  So I ^C'd that, and will just go digging through the drivers in
the kernel source tree instead when I get a chance.

(Maybe a lot of that is firmware blobs or something, I don't know; I'll
take a look in more detail when I get a chance.  But regardless, the
attack surface must be big.)

The WiFi stuff is hard to navigate, a lot of shared common code, endless
configuration files with definitions that enable/disable certain chunks of
code for different chipsets and cards and features, and so forth.

I had trouble even finding the relevant any relevant .c file, so much of
it was configuration macros.  Most of the code seemed to live in many,
many different .h files instead.

My head hurt, so I went to bed, lol.

Needless to say, none of that increased my confidence in WiFi.  Ethernet
is far simpler, and thus, IMO, safer.

(When I do take a look at the code, probably tonight, I'll post a
comparison on lines-of-code between a typical WiFi driver and Ethernet
driver.  I wouldn't be surprised to see a 10:1 ratio, if it's even
possible to find enough separated code to do a comparison.)

As a quick binary module comparison, and not necessarily a fair one (as
the WiFi stuff no doubt drags in other modules):

Ethernet driver for a 3com card:

/net/ethernet/3com$ size 3c59x.ko
   textdata bss dec hex filename
  415112968  49   44528adf0 3c59x.ko

Ethernet driver for an ath5k card:

/net/wireless/ath/ath5k$ size ath5k.ko
  text data bss dec hex filename
 1535451529   8  155082   25dca ath5k.ko

ath5k.ko has a number of undefined symbols relating to ieee80211 (WPA2),
so just *one* of the modules it would depend upon is this:

/net/mac80211# size mac80211.ko
   textdata bss dec hex filename
 529986   53348  64  583398   8e6e6 mac80211.ko

Oh, and also this, just for WPA:

/net/wireless# size *.ko
   textdata bss dec hex filename
 380654   713953656  455705   6f419 cfg80211.ko
   36881088   0477612a8 lib80211_crypt_ccmp.ko
   66961168   078641eb8 lib80211_crypt_tkip.ko
   2166 968   03134 c3e lib80211_crypt_wep.ko
   2132 992   43128 c38 lib80211.ko

(Other than net/netfilter, net/wireless is the largest sub directory in
the net driver module hierarchhy.)

The Wireless drives no doubt bring in many other modules for the other
encyrptions and features.  (The Ethernet stuff likely brings in other
stuff as well, but probably the same core ethernet dependencies are also
required by the wireless stuff)

>From that very quick comparison, it's a minimum of 26x (!) more code just
for the ath5k+WPA2 support, versus the driver for a 3com ethernet card.

Cheers,

JJ

-- 
You received this message because you are subscribed to the Google Groups 
"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/6008c7066cc61d8632f3473c35f3e146.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?

[neilhardley]

Very useful info, but what I meant is whether the Ethernet drivers/firmware etc 
are more secure than the WiFi ones.

I wasn't really talking things like RF leakage 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/ecbd7136-a6f1-4bcf-b7c5-8a830ee3c7fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?

[johnyjukya]

> And yes, by all means, I will use Whonix's system rather than my own
> custom script.

I agree that Whonix is a key component.  A NetVM that ensures *all* your
traffic goes through Tor, with no leakage, as well as doing secure DNS
lookups for you, is a big security plus.

They've also put a fair bit of work into the iptables (i.e. firewall)
configuration of the sys-whonix Network VM.  Something I had expected of
Qubes, and a bit more on par with what Tails does.

And Whonix is more of an open sourced "configuration" rather than a code
base.  It just ties other established pieces together solidly, and
configures them well. And you're free to check it out and put together
yourself, no coding required.

In System, Global Settings, it's good to make sys-whonix your Update VM as
well, reducing MITM risk during the update process.  As well as making it
your Clock VM, to avoid clock synchronization leaks.

(apt-get-transport tor is slightly preferable, since it goes directly to
Debian's hidden service, encrypted of course, for updates.  But hopefully
package signing would reduce any risk for dodgy exit nodes and the like
when using sys-whonix for updates.)

It's worth noting that using whonix does increase the number of trusted
parties from two (Fedora + Qubes devs) to four (Fedora + Qubes + Debian +
Whonix devs).  More repositories/updates for potential threats or bugs. 
But where all are open source, that's probably not a big additional
security risk.  The benefit far outweighs the risks, IMO.

Cheers,

JJ

-- 
You received this message because you are subscribed to the Google Groups 
"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/9b6ce2e7b0a256e05bad31d067da1cbf.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?

[johnyjukya]

> Well, entr0py, you are correct.
>
> It does indeed come down, to either Xen, or my networking stack.
>
> Let me ask... what is the security like for Ethernet..?

Anything going over a wire is going to have a far shorter RF leakage range
than WiFi.  Unless your threat actor is in the house or next door,
ethernet is hard to beat for security (and simplicity).

WiFi protocols are (obviously) over the air, which is inherently more
vulnerable. Plus they're more complex, and complexity is no friend of
security.

WiFi (protocols and hardware itself) is a pretty juicy target for NSA and
state actors, so you know a lot of effort is being put into that. 
Ethernet is pretty well-established and boring as compared to WiFi.

https://en.wikipedia.org/wiki/Wireless_security

That being said, there is an argument that since WiFi is encrypted by
default (usually), and Ethernet isn't, WiFi may be considered more secure
in that aspect.  But you can certainly (as discussed before) make sure
everything going over the ethernet cable is encrypted.

But WiFi has had a pretty bad track record of security (WEP, WPA, WPS all
considered crackable), so I'd stick with wired.  If you're paranoid, make
sure your cable runs are short and RF-shielded.

WPA2 (a.k.a 802.11i) is considered secure for the long run; but given the
complexity, and the aggressiveness of state actors and crooks to put
backdoors and bugs into the protocols and hardware, I'd stick with
ethernet.

Broadcasting and security don't mix, even with encryption.

If someone sneaks onto your ethernet, they'll have to it by tapping into
an existing wire, picking up RF leakage, or plugging into your cable
modem.  Pretty noticeable and containable.

If someone sneaks onto your WiFi network somehow, you likely won't notice.

A few points about WiFi routers:

- Often the admin pages are just http, not https.  So anyone on your
network (legitimately, or not) can snag the cable modem credentials and
later reconfigure you modem to redirect traffic to themselves, or
whatever.

- Make sure your admin password is long, random, and unique.  Only
administer it or change the password when WiFi is off and you're the only
one connected on ethernet.

- Turn off SSID broadcast.  Users can type in the network name (something
non-guessable, not just "linksys" or "dlink",lol).

- While Mac address spoofing is easy, it still can't hurt to turn on Mac
authentication, so only listed Mac addresses are permitted on the network.
 If they can't otherwise snoop on the network, they won't know *which* Mac
addresses to spoof, so it could help a bit.

- I also turn off DHCP serving (for both WiFi and ethernet).  It's not
that inconvenient to manually type in the address, gateway, DNS.  I use an
unusual IP address range as well.  None of those necessarily add
significantly to security, but they sure don't hurt, especially for the
less sophisticated threat.

And don't use your ISP's DNS.  It's trivial for a small-time
privately-owned provider (or the NSA tapping into the same) to hijack DNS
and send you to a spoofed site.

Google's 8.8.8.8/8.8.4.4 is quite popular, if you trust google inherently.
 (I don't.)  Open DNS's 8.26.56.26 is also popular, but it does redirect
to ads for unrecognized sites, which isn't particularly cool.

I prefer using my commercial VPN provider's DNS server.  If I can't trust
the VPN provider, my security is toast anyway, so I might as well trust
their DNS too.  :)  To me, a good commercial VPN provider is one of the
few "stakes in the ground" you have to place and trust.

(Also, I connect to my VPN provider by IP address, which I verify several
different ways, rather than by DNS lookup.)

Also, if you run whonix or Tor, it can do the DNS resolution for you over
Tor, which is great for security and preventing DNS leakage.

If you do serve up DHCP from your cable modem, put in your preferred DNS
server there, so any clients automatically use it.

But in general, don't use WiFi if you're concerned at all about security.  :)

> Let's say I connected to my home router via Ethernet, and also served out
> the Tor connection to a 2nd laptop, over Ethernet.
>
> In this setup, there is no WiFi at all.
>
> Would that make things more secure..?

I would say yes, unless there's someone nearby who can pick up leaking RF
from your ethernet connection, a fairly rare and manageable threat.

I turn on WiFi when friends, family, my kids, are over, or for casual
browsing (with a VPN layer on top).  But never for anything work related
or personal.  Otherwise it's off.  (Some modems have a button to do that;
but make sure it's not a WPS configuration button, because that's
insecure.)

Interestingly, I noticed my FM radio, tuned to around 100 Mhz (go figure)
picks up Ethernet noise.  It's a good ghetto way to see how leaky your
cables might be.  For my wiring, moving a foot or so away from the cable,
and you don't hear anything.

(I have one VOIP phone which just screams RF noise in the 100 mhz range. 

Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?

[neilhardley]

And yes, by all means, I will use Whonix's system rather than my own custom 
script.

I originally created my own, because I saw that Whonix didn't have VT-D.

But then I learned that VT-D is nowhere near as good as I thought.

I originally thought VT-D isolates the devices from the Net VM itself. But in 
fact, VT-D only keeps the devices inside of Net VM... and the security of Net 
VM itself is still dependent on Xen.

So... yes I will definitely look into using Whonix for this rather than my 
own script.

But just to re-iterate my previous question.. do you think Ethernet is any more 
secure than WiFi.

In your answer, you explicitly say to get rid of WiFi, due to security 
problems... But how about Ethernet..?

Thanks

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

Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?

[neilhardley]

Well, entr0py, you are correct.

It does indeed come down, to either Xen, or my networking stack.

Let me ask... what is the security like for Ethernet..?

Let's say I connected to my home router via Ethernet, and also served out the 
Tor connection to a 2nd laptop, over Ethernet.

In this setup, there is no WiFi at all.

Would that make things more secure..?

-- 
You received this message because you are subscribed to the Google Groups 
"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/7fc44baf-ea60-485d-93c9-faa06fb04bde%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Why won't Google Chrome remember my Google logins?

[Mathew Evans]

On Sunday, 25 September 2016 15:33:35 UTC+1, Clark Venable  wrote:
> On Sunday, September 25, 2016 at 8:42:08 AM UTC-4, Clark Venable wrote:
> > Nope. Allow local data to be set is enabled.
> 
> It all works as I expect in Firefox, So I'm happy to leave this alone and 
> just use Firefox rather than Chrome (which is probably what the devlopers 
> intended by including Firefox in the distro. :-)

I can confirm i had the same issue with Chrome. There is somthing funky going 
on between seahorse and chrome and how in the AppVMs details are stored. As 
long as you do not restart the AppVM you can close and reopen chrome as many 
times as you want and it will work fine, even with disable background 
processes. when you restart the AppVM the info in seahorse seams to expire 
instantly.

-- 
You received this message because you are subscribed to the Google Groups 
"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/697a0a56-b0fc-4bf0-a256-f6f3fdf973ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: AMD vis-a-vis NVIDIA GPU

[neznaika]

> 1. Downloaded 
> http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora21/noarch/bumblebee-release-1.2-1.noarch.rpm
> 2. extracted two files from it:
> * /etc/yum.repos.d/bumblebee.repo
> * /etc/pki/rpm-gpg/RPM-GPG-KEY-bumblebeepublic
> 3. Verified the files that the key is well known and the *.repo requires GPG 
> key check.
> 4. Copied the files to their location in Dom0 manually.
> 5. sudo qubes-dom0-update bumblebee
> 6. sudo systemctl enable bumblebeed
> 7. reboot

Hi! I am s long time try to solve this problem (optimus).. I found your 
"how to" and wanna(ed) try again. Again i deleted Windows and install 
Qubes(500th time) and now i'm again stucked.  At the 5th line i get this: 
goo.gl/TW5Xot
Maybe you know what  does it mean? My english (and Linux) is so bad:( But 
Windows10-paranoia dont give me relax. And i cant understand what i need to do 
with this error. 

-- 
You received this message because you are subscribed to the Google Groups 
"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/d982b327-0b1b-4f83-a201-d2dd7dde70f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Setup VPN, DNS script and iptables

[asdfgher]

> On 09/25/2016 06:35 AM, asdfg...@sigaint.org wrote:
>> Hello
>> After setup my VPN in network manager (but not in config/vpn like the
>> tutorial says) I have configured DNS script (in my client and like
>> qubes-vpn-handler.sh file) and iptables (only the 2 lines that block
>> forwarding connection). Do these work the same  although I have used
>> different VPN setup?
>>
>> Thank you
>>
>
> It could work mostly the same (hard to say without details), but you
> will probably end up with your vpn vm configured to use the vpn's DNS.
> Some might consider that less functional or secure because, after the
> connection is made, anything inside the vpn vm that tries to access the
> net will end up going through the tunnel instead of clearnet. OTOH the
> doc setup has the vpn DNS used only by downstream vms, not the vpn vm
> itself.
>
> Also, with the vpn doc script config, essentially nothing is allowed as
> (vpn vm) in/out traffic except the vpn connection itself. The forwarding
> rules you added are great for protecting downstream vms, but they don't
> help protect the vpn vm in this way.
>
> Chris
>

"anything inside the vpn vm that tries to access the net will end up going
through the tunnel instead of clearnet."
Who setup a vpn vm want that all inside it must be through the tunnel, if
I want it go through clearnet I create another vm.

"but they don't help protect the vpn vm in this way"
What do you mean with this?

Regards

-- 
You received this message because you are subscribed to the Google Groups 
"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/7385e875f0c28254701465941d9bf0b7.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Snapshots - Use of CoW

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, Sep 26, 2016 at 02:11:42AM -, johnyju...@sigaint.org wrote:
> > Hi folks,
> >
> > Any chance that there will be added in the feature for snapshots?
> > even CoW snapshots would be good, then a consolidation option once done.
> >
> > I have one issue where I want to do something, but I have to 7z the VM
> > before I can do anything to it in-case it breaks.
> >
> > I know that there are CoW options there, but how do I access them?
> > You already use the technology since 2.0, but I have not seen it go
> > anything beyond that for the dispvm and the like.
> >
> > the AppVMs, they have CoW for them, but it's not persistant on the CoW
> > file, that file is destroyed after the VM is shut down.
> >
> > I tried changing it to not be destroyed on shutdown when it used a CoW
> > file, but Qubes just tell me to get stuffed and destroys it once the guest
> > is shut down.
> >
> > How can I fix this please?
> 
> AppVM's are designed to toss changes, other than /home, /rw, /usr/local. 
> It's a good thing; if one gets compromised, it's a temporary compromise. 
> :)
> 
> If you want permanent changes, update your template.
> 
> But it sounds like you might want a "standalone VM":
> 
> https://www.qubes-os.org/doc/software-update-vm/
> 
> Also, using BTRFS as a root (or VM host) filesystem should allow you to
> snapshot/rollback the standalone VM to your heart's content (and clone it
> instantly).  BTRFS is all about the copy-on-write.

Also in case of templates, you have qvm-revert-template-changes, which
will rollback changes done during last template run. Currently only one
such revision is stored.

In Qubes 4.0 there will be (actually this is already implemented) an
option to keep multiple of them, and not only for templates, but also
for normal AppVMs.

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJX6Oj4AAoJENuP0xzK19csboIH/0Ia7XuTrCdSABbE13MmTCvX
m87DVH/N37DOIyh6eCIfp47ybtBiPlfm66OgSmmjca4ROk/WPPaMNDOeVSSnbJpx
rL4b3BDIFlfnWgdxEWGTlkpKq/VogvF+3A1WN1QpgQ0Ek2mRURqthYcQifiZ4ivI
NbHuwnn5USpfq2G5wLETbgxb/WvPDTbKACkEAvr+YpGgirKP2rJcMutkqwArgo1h
YhMzYPdGODh1TI16kLGrTg4xr4D4W9MLfSwxxf8rclFxRlSFC0ygemwF3H7dYrCa
0HQMYb1a2XEF4q4RXxiztBdKjwLUKW5suni3DvbaSWcpxcI8Yq+GI5DLllls0h8=
=bIXB
-END PGP SIGNATURE-

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

Re: [qubes-users] Re: Thunderbird: "Open link in DispVM"

[Robert Mittendorf]

Hey Clark,

the article which you referenced to is about opening (and converting) 
PDF documents. My idea is about opening URLs (Links) in a DispVM. I 
think that is not related in any way, is it?


Robert

btw: did you notice, that googlegroups blocks email having a subject 
starting with a quote (single ' or double ") ? I - I sent this email 4 
times over several days.


Am 09/24/2016 um 11:02 PM schrieb Clark Venable:

Have you seen this?

https://micahflee.com/2016/07/how-qubes-makes-handling-pdfs-way-safer/

Clark


--
You received this message because you are subscribed to the Google Groups 
"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/664b1604-dc80-0f91-772c-4d3ba8deb325%40digitrace.de.
For more options, visit https://groups.google.com/d/optout.