from:"johnyjukya"

> Hi JJ,
>
> My PC has 10 USB Bus's.
> My keyboard and mouse are on bus 10, which is PCI device .XX.X and I
> left that one on Dom0.

Are they 10 separate PCI devices, 10 separate USB buses?

I'd be very surprised if that were the case.  But also very impressed, and
wanting such a motherboard for myself.  It'd be awesome for Qubes.

But it's more likely that it's a single USB controller with 10 ports.

If you do a "lspci" do you see 10 different USB PCI devices?  (Well, it
would probably be 20, as each USB bus usually shows up with a USB 1.1 and
a USB 2.0 version.)

Or does "lspci" just show two USB PCI devices (one 1.1, and one 2.0)?

The USB PCI device can have 10 *ports*, and still just be one PCI device,
assignable to only a single Qubes VM.

I have 8 ports (well, 6 after blowing 2 of them on some projects, but
that's another story), which are handled by a single USB PCI device (which
has two presences, one for 1.1 (ohci), one for 2.0 (ehci).

(I'm rather impressed that the single controller let me blow two ports,
while keeping the others alive.  Nice isolation, NVIDIA!):

# lspci
00:02.0 USB controller: NVIDIA Corporation MCP61 USB 1.1 Controller (rev a3)
00:02.1 USB controller: NVIDIA Corporation MCP61 USB 2.0 Controller (rev a3)

"lsusb -t" is also telling:

# lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/8p, 12M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/8p, 480M
|__ Port 4: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, xxxM
|__ Port 6: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, xxxM
|__ Port 7: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, xxxM
|__ Port 8: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, xxxM

USB ports are not the same as USB PCI devices/busses.  And the only reason
you see two Bus's in both cases above, is because it's a USB 1.1 and USB
2.0 presence of the same single USB controller.

It *may* be possible to assign the 2.0 controller instance (fast hard
drives, thumb drives, etc.) to a given VM, while keeping the slower 1.1
HID instance (keyboard, mouse) in dom0, but I wouldn't count on it.  (I
might try that when I get a chance.)

We'd possibly need Andrew or Merek or some other Qubes expert to answer that.

Just get your keyboard/mouse onto PS/2, and then things get a lot simpler
to figure out.

> However I now have another issue...
>
> "Error starting VM 'sys-usb': Requested operation is not valid: PCI device
> :00:1a.0 is in use by driver xenlight, domain sys-usb"
>
> What does this mean?
> It does this for each PCI device. I have removed them 1 by 1 just to
> verify.
>
> Why won't it just assign the device?

Perhaps because you really only have one USB PCI device/bus, and because
two of the ports are tied up in dom0 with your USB keyboard/mouse it wants
to (out of necessity) control them all (well, the one USB controller,
really) and won't let you assign individual ports on the common USB PCI
bus to different VM's??

I've never seen that error, so I'm just guessing; that's a question for
the Qubes dev experts.

I'm actually still running my boot/root drive off of USB until an imminent
reinstall (with btrfs root, yay!), so I'm a bit of a hypocrite singing the
praises of USB VM isolation.  As long as my boot/root is on USB, I can't
create a USB VM, despite having a PS/2 keyboard/mouse.  Soon...  Soon...

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/64d179f7274c52e3eda2c6401259dcf2.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] USB VM

> It may no longer be the case, but it used to be that most USB keyboards
> and mice had controllers that also automatically auto-detected and
> supported PS/2, with a simple passive passthrough dongle between the
> USB->PS/2 connection.
>
> http://www.ebay.com/itm/Cool-PS2-Female-to-USB-Male-Port-Mouse-Adapter-Converter-Connector-for-Keyboard-/321935935564?hash=item4af4e0884c:g:F98AAOSwgApW-yRg
>
> $0.75 each, including international shipping.
>
> You or someone you know may even have such dongles kicking around; if so,
> given them a try.  The common logitech ones seem to work for most every
> keyboard/mouse I've tried.

I should mention that if you're paranoid, are a high-value targeted
individual, or simply have a psycho on your butt, you may want to do a
good check of such a dongle with a ohmmeter or scope.

Or even better, wire your own.

It's a wonderful place to hide a keylogger.  :)

http://www.keydemon.com/ps2_hardware_keylogger/
https://www.keelog.com/usb_hardware_keylogger.html
http://www.instructables.com/id/How-to-build-your-own-USB-Keylogger/

I have a couple of these in my "JJ's Meseum of Dodgy Devices."

Thankfully I didn't have to pay for them myself, but they were graciously
snuck into my inventory of parts by secret admirers.  So very kind of
them, and without even wanting credit.  :)

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/942e123f99dcd7bc60f509d719d7.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] USB VM

> I want to get the USB VMs to work, but I use keyboard and mouse via USB,
> not PS/2, so it will not permit me to configure it.
>
> I wish to attach specific USB Ports to Dom0, which is 1 of the bus's. And
> the other USB bus's to the USBVM, but I can't find out what device to
> attach to Dom0 to allow this.
>
> I know what my USB3 is because that's a PCIe card. So that's easy enough
> to push to a USBVM. But the others, not so easy.
>
> Is it possible to assign specific USB ports instead of whole USB bus's?

Pretty sure the answer is "no."  You can assign a whole USB bus (which is
typically a single PCI device) to a VM, but you can't split it up beyond
that, other than the default of having dom0 relay specific devices to
specific VM's (which isn't dom0 USB isolation at all).

My mobo has 8 USB ports, but they're all on a single bus, so it's all or
nothing.

It's worth looking into whether your keyboard/mouse support PS/2.

It may no longer be the case, but it used to be that most USB keyboards
and mice had controllers that also automatically auto-detected and
supported PS/2, with a simple passive passthrough dongle between the
USB->PS/2 connection.

http://www.ebay.com/itm/Cool-PS2-Female-to-USB-Male-Port-Mouse-Adapter-Converter-Connector-for-Keyboard-/321935935564?hash=item4af4e0884c:g:F98AAOSwgApW-yRg

$0.75 each, including international shipping.

You or someone you know may even have such dongles kicking around; if so,
given them a try.  The common logitech ones seem to work for most every
keyboard/mouse I've tried.

Or, if you're handy with a soldering iron, make your own.

https://imgur.com/a/n3BJ0

I've chopped up an old PS/2 cable and soldered it to a USB keyboard
successfully in the past.  (Even just cut and twisted the wires together
in a pinch, lol.  Worked great.)

Worst case, splurge the <$10 each on getting a nice PS/2 mouse and
keyboard, and proceed with far greater confidence/security, and more
easily isolate your USB to a VM.

(Heck, I'd send you a free PS/2 mouse/keyboard if it didn't cost more to
ship than to it would be for you to purchase new.)

Maybe it's less common these days for keyboards/mice to support that
feature, but it's hardly difficult even today to buy or find a good PS/2
mouse and keyboard for dirt cheap.

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/9a89fa98a26dc3959505a12ab81dd1f1.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Anything else to wipe other than HDD and BIOS..?

> You can get a motherboard that has a removable bios chip that you can just
> snap in to replace,  Then call the company and have them send you one or
> two to hold onto for emergency lol.  There is also mobos with dualbios,
> most ly this is for bringing a bricked board back to life.

I actually have one of those motherboards here.  It sounded like a very
kick-ass feature, the double-bios to restore in case of problems.  And the
board has 8 SATA, a dozen USB, some serious video and audio capabilities, 
32g memory capabilities, IOMMU, etc.

But it was given to me out of the blue right after I retired a
dodgy/compromised machine, so I'm a little wary.  A shame, because it's
one hell of a motherboard.

I might fire it up with Qubes in a non-critical/non-trusted manner.  (Or
set it up in a Windows machine, sell it, and buy a known secure
motherboard.  :) )

> Also don't forget malware can reside in other firmware also.  SO that
> means all pci devices,  like gpu,  netcard.  etc...  most experts will
> tell you just to replace everything to be sure if you think you are
> compromised at that level and its important.

Would you say a motherboard that integrates a lot of that (with the dual
recovery BIOS) would be less prone to compromise (or at least easier to
restore from compromise) than a machine that separate PCI cards providing
that sound/video/net?

Presumably, if you can trust the vendor and its BIOS, one flashing of the
BIOS (or recovery from the backup) should restore you to a state that
could be trusted.  A lot easier than doing the same (if even possible) for
the net/sound/video add-on cards, no?

Or would it be easier for a threat actor to attack a specific motherboard
and its integrated peripherals, rather than a random set of add-on cards?

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/54219c183f184f416f6dda20c57ec5ba.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Anything else to wipe other than HDD and BIOS..?

> Yeah, Joanna is seriously epic.

Upon that, we can all agree.

Everything she designs or writes up, seems bang-on (and wonderfully
informative) in this increasingly security-threatened world we're living
in.

She's probably just a fictional character created by the NSA to mesmerize
and lure us Linux geeks into this honeypot known as Qubes. :)

(Even I'm not quite that paranoid. Yet, at least.)

> How about Raspberry Pi..? That seems to have very few components.

That's interesting.

As a side project (one of s s many), I'm working on a
Arduino-based system that will let me do secure, encrypted note-taking,
email, SMS, messaging, etc., with (similarly secure/encrypted/hack-proof)
mouse/keyboard/storage, as well as even being a platform for further
development of the same system, without dependency upon a vulnerable PC or
laptop.

And also being lower-power and mobile, which helps security further.

Things like secure and encrypted SMS, messaging, email, note taking,
PDA-like functionality (on par with Palm Pilots in days of old) are
certainly possible, without being threatened by hacks from all the
organized (or disorganized) crooks or overly-aggressive governments
pushing, unhindered and beyond reproach, way beyond constitutional and
ethical boundaries.

They will be portable, low power, low cost, open source, transparent tools
that could be used by the oppressed, the abused, whistle-blowers, the
relentlessly hacked, that are afraid to speak out, as well as the general
public.

I've been focused upon Arduino/atmega328 due to the low cost,
accessibility, transparency, etc..

(The harassment I've personally been undergoing has been keeping me, errr,
rather "frugal," so the atmega328 platform is appealing.)

Raspberry is a bit like Arduino/atmega on steroids. I've not gone there
because it draws more power, costs more; but at the end of the day, it's
more powerful and probably has similar security/transparency as the
Arduino/atmega328 if done properly.

And with its additional processing power, it's a more likely candidate for
replacing a PC for things like web browsing, Tor, VPN, PGP, (things a bit
beyond atmega328's capabilities). And in those cases, the extra cost is
still far below even a basic notebook or tablet.

(Not sure how it rates power-consumption-wise as compared to
notebooks/tablets, maybe a bit worse. I see it used a lot for home media
PC's, which I doubt would last long on a couple of CR2032 batteries. :)
But still way better than a PC, as long as we still can rely upon power to
our homes, it'll do. :) )

I am firmly convinced that the only salvation to corrupt surveillance
states and the take-over of the world by the greedy and corrupt, is a
revolution to more simplistic, secure, and (especially) transparent
technology that achieves a lot of the same things as today's hopelessly
complex smartphones, Wifi, broadbands, web browsers.

I'll stop the rant now. :) But progressing/expanding up to the
Raspberry's power while still achieving the same goals, is something I'm
going to seriously ponder.

(There are a number of other processors, like STM32 and others, that can
similarly bring more processing power without blowing security. My
approach is quite portable, so any or all of the platforms should be
viable to include in the solution.)

Thanks for the inspiration. :)

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

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

> My PC's RT clock might drift by a few seconds each week

Actually, it's not even that bad. I'm sure I've fired up motherboards or
laptops that haven't been touched in years, and their clocks were accurate
within a minute.

So there's no need for synchronizing your time so frequently.

I just read that NTP apparently adjust the frequency of polling based upon
how fast your clock seems to be drifting, which is admirable.

http://www.ntp.org/ntpfaq/NTP-s-algo.htm

But the poll interface ranges from 64 to 1024 seconds; even at the high
end, that seems unnecessarily frequent from the very small amount of clock
drift I've experienced.

But flipping to a GPS-based source instantly eliminates those concerns.

Question: for what purpose do we require super-accurate clocks in the
first place? There are some rolling password algorithms based upon time,
and certificates handling will get cranky if you're months or years off,
but other than that, what is the necessity of keeping a PC within seconds
of the correct time?

(On tails, when it starts up, it does a time synchronization, claiming
it's required for Tor purposes. Anyone know the nature of 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/e9811afeee4015304424657087604877.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

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

> The "listening" services are less of a concern, since the firewall
> wouldn't permit any incoming connections to be passed through to start
> with.  It's the "phone home" style services, like time sync, Samba name
> lookups on microsoft servers, and such, that are more concerning, and
> privacy-busting.

The paranoid part of me (which is about 95% of me) half-suspects that NTP
is actively monitored by the powers that be, to keep tabs on us
security-minded Linux geeks.

There's been enough major security bugs in NTP, that one must wonder if
they're akin to the heartbleed/rng/SSL/etc. compromises that don't
necessarily look like innocent mistakes.

Qubes is good at trying to get dom0 to push the time to the VM's by its
own means.  And if you set the ClockVM to sys-whonix, say, you remove, or
at least greatly reduce, the ability of TPTB to track your setting your
clock.  :)

However, as mentioned, the default of using NTP time syncing is enabled by
default in the Debian-8 template, which defeats that protection for Debian
Appvms, unless you disable it in the template.  Just an oversight, I'm
sure.  (No sarcasm, for once.)

My PC's RT clock might drift by a few seconds each week, if that; I'm not
sure why time synchronization has to be so damn frequent and aggressive. 
A red flag for the paranoid.  :)

I have a RS232 GPS dongle that spits out the time with 1-second accuracy
(or atomic-clock level accuracy, if you use the 1-second clock-tick signal
available on one of the chips, which I have done, lol).

I plan on hooking that up to my Qubes setup in the near future, and
disabling network-based clock sync all together.

(Until Qubes 4.0 comes out, forces me to upgrade to a newer motherboard
with no RS232 support. :) )

Might be a good open-sourced hardware project.  I think I've seen some out
there already, although not necessarily integrated smoothly into Qubes.

Just one more hole to make sure we plug.

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/bf7ec94cf1cebb9c873ff1cdb58667bf.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

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

> Also just to add qubes devs have fedora template with less listening
> process then debian-8 which is not default and more community based.  But
> if you want to use use debian instead for your sysnet or firewall or w/e.
>  You can disable all the listening processes yourself.

It's an outstanding ticket (among a few other related ones):

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

As compared to all the other stuff the Qubes devs have on their plates, I
assume it's a relatively low priority, since Debian-8 is a bit of an
"addon" as compared to Fedora-23, and its easy enough for someone to fix
in the template themselves.

The "listening" services are less of a concern, since the firewall
wouldn't permit any incoming connections to be passed through to start
with.  It's the "phone home" style services, like time sync, Samba name
lookups on microsoft servers, and such, that are more concerning, and
privacy-busting.

I was not pleased to see the Debian vm, by default, connecting to some
microsoft servers for Samba name resolution, lol.  Especially when I never
use any SMB style naming, nor programs, to start with.

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/3d3fd84cfffb6a89a3e285ae6981ea3d.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Anything else to wipe other than HDD and BIOS..?

> How about Google Chromebooks which have a system to auto-restore the OS if
> it thinks it's been tampered with..?

Doesn't that imply trust in Google, who is known to cooperate with NSA and
such (as required by US law)?

I have had serious problems with a hacked Android phone, and the
"weirdness" went away when I avoided installing Google Play
Store/Services.  The minute I install Google Play, it appears to be
compromised, accessing files and uploading constantly.

(A device should download, not upload, lol.)

Personally, I have little doubt that Google has backdoors in Play Services
for law enforcement, and I also have no doubt that those backdoors have
been misused for inappropriate/nefarious purposes (LOVINT style).

So Chromebooks, no.  Unless everything is open source top to bottom, and I
can build it myself.  But who has time for that.

> Or what about a read-only BIOS in the first place..?
>
> Is there any reason BIOS can't be read-only..?

Lol, that seems like the most basic, logical, simple answer, that I've
never seen implemented.  A simple switch or jumper could disable the write
line on the BIOS flash.  In the (very) rare case when you need to flash a
BIOS (especially rare on older machines), flipping the switch or
connecting the jumper would be such a minor inconvenience.

I'm tempted to look up the specs of the flash BIOS chip on my motherboard,
and see if I can hack in that tweak myself.

I've noticed that with my flashrom reading/comparison, that the beginning
of the BIOS area changes when I change BIOS settings, and corresponds to
the stuff dumped by 'dmidecode.'

Does this mean that your BIOS settings are actually stored in the same
flash rom as the BIOS?  If so, I'm not necessarily sure that the same
write-line-jumper hack is any worse.  Maybe even better.  It'd also
protect against any BIOS setting changes.

Are there any BIOS setting changes that *need* to be updated on the fly by
the BIOS without user intervention?  (If the settings are indeed typically
stored in the same flash.)  Whenever I reboot, I see some "updating nvvm
blah blah blah" thing, which implies that maybe there is some writes to
the BIOS settings upon boot.

One way to find out, lol...  (Looks at soldering iron...)

This motherboard is on its last legs (after a poweroff, it's real cranky
to wake up, takes reconnecting the power a dozen times or more before it
fires up), so experimenting with making the BIOS flash chip read-only
isn't a terribly risky project.  Will report back with any results if I
try it.

> I basically want a computer which is most easy to wipe/reinstall and then
> it's truly wiped.

Computers should have *zero* state in the first place, as in days of old.

The state should be kept on your storage devices, operating system, etc.. 
I seem to recall an article on that particular point, maybe even by the
legendary Joanna herself.

Google, Google, Google...  (Actually, Duckduckgo, Duckduckgo, Duckduckgo):

Yeah, it was, God love her:

http://blog.invisiblethings.org/2015/12/23/state_harmful.html

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/3e701c3a47b5d28743c73423e8f5746d.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Anything else to wipe other than HDD and BIOS..?

> On Tuesday, September 27, 2016 at 6:51:31 AM UTC-4, neilh...@gmail.com
> wrote:
>> If I think a computer has been infected, is there anything else I should
>> wipe/re-install other than
>>
>> 1. Hard Drive / Operating System
>>
>> 2. BIOS

This also brings up the question of BIOS vs. EFI, which has some parallels
to the Ethernet vs. WiFi security discussion in that other exciting
thread.

EFI supposedly has more lines of code than the Linux kernel, which can't
be good.

In my opinion, the device drivers should manage the hardware, not the
motherboard's BIOS/EFI.  The BIOS should be just enough to get the base
system loaded from disk, and it can do its thing.

The complexity and attack surface of EFI concerns me, which is why I'm
glad to stick with BIOS, until I'm forced to EFI.  (Also, I'm broke, lol. 
Another reason I'm sticking with my BIOS-based motherboards.)

(will Qubes 4.0 force that as well?  Likely the newer hardware required
for Qubes 4.0 will be EFI-only, so the question may be moot.)

I know TPM/Anti-Evil-Maid is an EFI-only thing, and supposedly a useful
(essential?) thing for boot security.  But is it worth the massive amount
of extra code involved?

Any opinions on the BIOS vs. EFI thing, from a security standpoint?

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/d76dee67e2aa4a7900661db546b89eba.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Screen geometry for VMs

> I'm back with a brand-new workstation setup to try Qubes on. I bought a
> Matrox C680 and hooked up six monitors to its DisplayPort outputs. I'm
> using Qubes R3.2 fully updated as of now, with XFCE.

Six monitors???  Wow!

Can I come over and hang out at your place?

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/c73d9f35f04b57bc1517e92679942933.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Anything else to wipe other than HDD and BIOS..?

> I forget which blackhat event,  they showed how you can think you are
> flashing a bios.  But the malware will remain.

That's creepy.  Don't most BIOS flashing utilities do a verification?  Or
perhaps the flashing utility itself is what was compromised in the
blackhat demo.

Another reason why doing a flashrom under Tails, and then reading it back,
is a good idea of your motherboard supports it.  Pretty hard for malware
to fake that (at least without some additional flash storage to do its
tricks).

At the very least, using a slightly "unexpected" utility like flashrom
helps dodge the obvious hacks.

(Similar to someone's post in reply to the Laptop internet sharing thread,
that using a *different* VM isolation on the laptop, KVM/Qemu or whatever,
might be a good idea.  For an attacker to have to compromise Xen *and*
Qemu, makes for a busy project to say the least.  It'd very likely stop
any automated virus in its tracks.)

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/ffcae9624e249cbad5d63a261173cf47.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] "Carrying forward" a DMA attack..?

>> Especially if you did the sharing via a separate vpn or ssh tunnel. But
>> in general, I don't think Qubes security should be considered much if
>> any benefit to adjacent non-Qubes systems.
>>
>> Chris
>>
>> > The benefits far outweigh the risks, as long as you don't do most of
>> your
>> > critical browsing/email through unencrypted connections; in which case
>> > your probably screwed anyway :).
>> >
>> > JJ
>> >
>
> or just only allow https in the vm firewall settings.

That's a wonderfully simple solution that never crossed my mind.

(My VPN ProxyVM is only allowed to send packets to specific VPN servers on
the given port, using the firewall, which is a bit of a parallel to that. 
Great peace of mind for stopping leaks of unencrypted data.)

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/5068e719853d90f9b3551cca68a41026.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Anything else to wipe other than HDD and BIOS..?

> If I think a computer has been infected, is there anything else I should
> wipe/re-install other than
>
> 1. Hard Drive / Operating System
>
> 2. BIOS
>
> Is there anything else that a hacker could possibly infect that needs to
> be wiped/re-installed..?

Lol, don't get me started...

- Any PCI card (esp Network/Video/Sound) that has any kind of flashable
firmware

- Similarly, probably any PCMCIA cards

- Any USB peripheral, especially flash drives; sadly, I don't think
there's any way to verify your HD firmware hasn't been tampered with
(write only, typically), and flash drives vary so much, it's not
particularly practical to check/clean them.  Some flash drive vendors have
repair tools that can redo the BIOS (handy when the drive appears to get
pooched), but it's fairly rare to find, I think.

- SMB/DMI Bios Tables (as shown by dmidecode) - Related to the BIOS, and I
think cleansed when you reflash your BIOS.  Even so, it's good to maybe
pop your motherboard battery or short out any BIOS-reset jumper to make
sure you're starting with clean settings.

- Basically, anything that can carry state needs to be looked at (although
your RTC probably doesn't have an attack vector :) )

- I've heard that rogue printers can even keep copies of what you print. 
I'm not sure if this can happen from an infection, or if it needs to be a
factory/interdiction implant.  Doubtful if such a thing could be cleansed.

I feel like I'm missing something else, but I might be thinking of more
hardware-based attacks (fake chokes on video cables that broadcast, etc.)

On-board peripherals (sound, network, video) typically have their firmware
as chunks in the main motherboard BIOS, I believe, so re-flashing a fresh
BIOS takes care of those.

A major oddity and frustration is that so many motherboard manufacturers
only provide their BIOS's via FTP/HTTP (and don't provide hashes!), just
begging to be MITM'd with dodgy firmware during download.  So careful with
any downloads.

It's a good idea to run the BIOS (and any firmware you download) through
virustotal.com, which supposedly supports BIOSes now.  You will typically
see that it's already been checked in the past by someone else, and is
clean.

Similarly, if you have to boot DOS to run a firmware flash utility, be
careful.  I've used FreeDOS successfully in the past, but the motherboards
I use thankfully support the Linux utility "flashrom" which seems to be
able to successfully burn (and read) the BIOS on a lot of motherboards and
other devices.

(Of course, you always run the risk of bricking your system, but I think
it's generally pretty safe, and won't go ahead if it isn't capable on your
system.)

I occasionally use FlashROM (installable with apt under Tails, and I use
it while offline) to read and compare my BIOS against the original fresh
burn.  (I'll see the DMI tables at the beginning change as I make any BIOS
changes, but so far, no mods to the code.  :) )

I'd like to see FlashROM available in dom0 for the ability to do this
under tails.  But I guess that would be a super-dangerous utility to have
floating around dom0, so rebooting to Tails now and then to check my BIOS
is an acceptable inconvenience.

Oh, and before you do reflash your BIOS, boot into Tails (or Debian,
Redhat, whatever) install FlashROM, and do a "flashrom -r" to read the
existing BIOS for posterity.  Run the resulting file through VirusTotal. 
It's interesting to compare with another "flashrom -r" after re-flashing
the new BIOS.

It'd be good to catch any corrupt BIOS before you overwrite it, to know if
you've been compromised that way, and to share the particular hack with
the security community.

Related:
http://www.businessinsider.com/nsa-says-foiled-china-cyber-plot-2013-12

(Hey, thanks for looking out for us, NSA!)

Note that any contents of a .ROM file you download to burn, won't
necessarily compare exactly to the results of a "flashrom -r".  But if you
"flashrom -r oldbios.rom", burn a fresh BIOS, and do another "flashrom -r
newbios.rom", you should have a good base for comparison.  I do a "hexdump
-C" on each .rom file, and then diff them to see what's different.

If you end up upgrading your ROM in the process, obviously there will be a
number of differences.  The more interesting thing is if VirusTotal shows
anything, or if, down the road, you notice changes in subsequent "flashrom
-r"'s.  If anything other than the SMB/DMI tables at the beginning change,
you need to assume you've been compromised (again).

(flashrom needs a "--programmer internal" option, which I left out for
clarity above.)

Obviously, any hard drive's boot sector should be examined as well.  If
you're worried about compromise, you're going to scrub your disks anyway.

I usually do a regular "dd if=/dev/sda of=latest.img bs=512 count=2048",
and compare against a saved baseline image that I grabbed after a fresh
install.  Any changes to the MBR, Grub stage 2 will be noticed with a
comparison against the original.  Any

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

> 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] Restored, and it's missing so much...

 > 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

> 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

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

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

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

> 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

--
You received this message because you are subscribed to the Google Groups
"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] I can't disable ipv6 on Debian Template


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

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

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

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

--
You received this message because you are subscribed to the Google Groups
"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..?

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

> OK, so the main takeaway from your answer:
>
> "The card doesn't have a host CPU and so it doesn't require a firmware
> source"
>
> that seems like the most interesting
>
> the driver would still need to be bug-free though
>
> who knows whether any of these have even been audited

I think the wireless drivers are fairly well reviewed, and from a quick
glace, there seems to be a lot of code sharing/reuse between drivers.  I
plan to look a bit closer at the ath5k driver when I get a chance to see
the nature of that hardware.

A couple of other points:

- This may go without saying, but any USB-based networking device, and all
security bets are off (right Andrew? :) ).  While PCI is an electrical
specification and hardware protocol, USB is a far more (overly) complex
protocol that out of necessity requires a USB controller, which is, of
course, a CPU in its own right.  Which, if compromised, could suddenly
pretend to be a keyboard and send you to a malware site to load up, when
you're not looking.  :)

- More importantly, by separating out your laptop from Qubes, I think you
might be *increasing* your risk, not decreasing it:

I believe one of the common threat models is, for example, a state actor
backdoor placed in your NIC that is activated by a special sequence of
data that could be present in a web page you're coaxed to (or faked with a
MITM tampering), or in an email sent to you, or whatever.

When your NIC sees the magic string "GiveMeYourStuff", it starts DMA'ing
around and sending off the contents of memory, including any keys, disk
cache, data, whatever.  Not good.

The NIC in sys-net sees that magic string, and it sends away sys-net's
memory.  No big deal.  That's boring, stock stuff that's mostly the same
on any Qubes setup.  There's nothing of use there.

Of course, it could tamper with the net connection content as well, but
with Tor (in another VM), that won't buy the attacker anything but seeing
encrypted traffic.  The VM isolation has done its job.

And, in fact, since sys-net is *only* seeing encrypted Tor traffic, it
shouldn't be possible for it ever see that "GiveMeYourStuff" magic string
that was on a web site or email, but its triply-encrypted Tor version.

(Now, if someone unilaterally blasts a packet with that magic string right
to your IP address, your sys-net compromised-NIC is going to see it and do
its thing, regardless of other tor traffic going on.  This occurs at the
hardware level, before iptables gets to do its thing, too, so no help
there.  Thus, you really do need that sys-net isolation.)

Now, the more interesting part: your laptop.  It's connected to the Qubes
box via ethernet and internet sharing, also has a NSA/orgcrime backdoor'd
NIC installed at the cooperative manufacturer's factory, or through mail
interdiction.

You go to read your Google Groups but the page is intercepted/redirected
to the attacker's page.  Or you're sent an email with the magic string in
it.  Or you read my sneakily malicious post that includes the magic words
"GiveMeYourStuff."

While that string arrives in sys-net and sys-tor on Qubes encrypted, once
it passes through tor and is decrypted, it is passed cleartext over the
crossover ethernet cable to your laptop's NIC.  It sees "GiveMeYourStuff"
at the hardware level, in the clear, and takes its cue to DMA through your
Laptop's memory, phoning home (conveniently over your Tor connection,
which doesn't hurt the attacker, since it comes out of the Tor exit node
to be sent to the attacker's site decrypted).

By separating out your Laptop from Qubes, you're failing to protect your
laptop's NIC (and thus your whole non-VM'd laptop).

The *content* you send and receive from your laptop will be encrypted in
transit, which is good.  But any attacks on your laptop NIC from dodgy
sites or phishing or magic email are still as much present as if your
laptop were directly on the Internet.  In effect, it *is* directly on the
Internet, just with a path between
sys-tor->guard->relay->relay->exit-node->Internet Site encrypted during
transport.

It provides you privacy, and protection against MITM in the Tor Network,
but it doesn't provide protection from the Internet at large.

All NIC's, including the Laptop, need to be isolated in a sys-net VM of
some sort.

Now, unless your laptop has one of those CPU-less NIC's (unlikely) or you
manage to find a NIC for your laptop that isn't USB (challenging) and that
doesn't have a CPU or other processor on it (such as those listed on that
Wiki page), you probably avoid that threat.  That's a lot of "if's."

Running Tor or TorBrowserBundle on the laptop itself could mitigate that
risk, since the laptop's NIC would only be seeing encrypted traffic, and
not open to that threat model.

Your setup seems to be premised upon the tethered connection providing the
Tor functionality.  Unless you somehow isolate your laptop NIC or get one
with no CPU/processor, you're better off keeping Tor/Tbb on the laptop,
not the Qubes gateway

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

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

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/580fa3f46fe08c86d235378638dd584c.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

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

> Yeah... and surely this is exactly what can happen, no..?
>
> We had 2 Xen exploits in the last 1 year.

I expect those exploits have caused a lot more scrutiny of the code, so
hopefully such exploits won't be heard of again.  Qubes devs are moving
away from PVM which should avoid the threat of such exploits as well, from
my understanding.

> Surely a compromised sys-net can just run a Xen exploit, and can then
> breach into any other VM, including dom0.
>
> This is the whole reason why I decided to use 2 laptops.. because Xen is
> not secure.

Well, if you're going with that assumption, then you best get Tor off
Xen/Qubes all together, so your Qubes box is only seeing encrypted
traffic.  But then, do you trust your laptop more so?  And if so, why are
you using Qubes at all?

You're going to end up with a string of four or five PC's before you're
done, and probably no more secure.  I jest, but only somewhat.  :)

You have to start trust somewhere, and I think Qubes/Xen is one of the
most promising and secure systems available (even Snowden seems to agree).

Xen has had two significant bugs.  How many times have devices/systems
been compromised by the NSA or other state actors and crooks?  I'm
guessing the number has several more digits than the number "2."

> So, I think the solution is to simply use a WiFi and Ethernet that do NOT
> have any bugs in the first place.

And I'd like a government, police force, courts, business, and social
world with zero corruption and zero crooks.  The government can backdoor
everything it wants in such a perfect world.  I think such expectations
are about as realistic as finding a completely safe NIC.

It's not just bugs you need to worry about, but gear that is intentionally
compromised by NSA or organized crime at the factory, or in transit, both
of which are realities.

And if the NSA puts a backdoor in place, with the best of intentions, that
doesn't mean that crooks (or spurned LOVINT users), inside or outside of
the NSA, can't abuse it.  Frankly, I'm coming to the opinion that NSA and
other state actors have broken the tech world so badly that I no longer
want to be part of it.  I just can't promise security to potential clients
any more, nor can I guarantee my own security 100%.

I might switch to an industry where you don't need to leverage trade
secrets and proprietary code.  It's hard/impossible to build any tech
business while completely hacked.  If I were a welder, for example, I
could care less about surveillance/hacking.

I've recently switched from web programming to more simple hardware-based
development projects to keep my sanity going forward.  And some of the
gadgets are designed to address such security issues, like an open-source
strongly encrypted keyboard with corresponding Linux driver.  But I might
just end up switching industries all together.

People who fight the hacking too much, sometimes meet with untimely and
unfortunate ends.  :S

A tradesman can't work and do his job well if someone has busted all his
tools.  And that's where we are/will-be with computers and
networking/Internet today.

/endrant

> As far as I can tell, networking firmware in Linux is actually implemented
> in Linux, and not installed on the actual device itself.

I wouldn't say that's true.  There's device drivers that live on Linux,
and there's Firmware that lives on the card (and can be uploaded from
Linux, with some cards).

Even with a card that can receive firmware, what exactly is on the card
receiving the firmware update?  A CPU running some bootloader, potentially
compromised by the NSA or orgcrime.  So there's no guarantees there.  And
who's to say there isn't some secondary circuitry splitting off the signal
and sending it to an attacker's server, outside the domain of the
firmware.

> Therefore, so long as the driver was open source, then surely it can be
> audited for any DMA bugs.

If the driver *and* firmware were open source, which is even more rare. 
And again, unless the firmware is flashed with a JTAG or some other
direct-write method, there has to be some cpu+bootloader to receive the
firmware from the Linux driver, which is free to muck with the firmware
(or quietly ignore it) if the bootloader were compromised.

The newer the hardware (esp. with U.S. based companies), the more likely I
would say that state-sponsored compromise would be present.  The oldest,
dumbest cards might be the safest.  But a more interesting point below:

> Here is a comparison of open source wireless drivers
>
> https://en.wikipedia.org/wiki/Comparison_of_open-source_wireless_drivers

That's a great resource.

The one thing that caught my eye were the devices with the [3] footnotes:

"The card doesn't have a host CPU and so it doesn't require a firmware
source"

That's what I'm talkin' 'bout.  :)  To me, that seems like the most
promising route.

Not to say that such cards don't have *some* CPU or other backdoor.  But
it might be possible to verify if this is/isn't the

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

> If your Tor is running in another appVM, such as whonix-gw does, the worst
> a sys-net compromise could do is redirect the *encrypted* Tor traffic from
> whonix-gw, which isn't terribly useful for the attacker.

Oh, I should mention, as you asked in your original question, that yes, a
compromised sys-net could absolutely and trivially reveal your IP,
regardless of whether Tor is running in sys-net or another AppVM.

All the attacker has to do is fling a single packet to their server
(bypassing Tor), and they have your address.  "ping" would do the trick.

But if Tor is in a separate AppVM, any data going into sys-net is
triply-encrypted, and the content is safe from an attacker who has
compromised sys-net.  (If Tor is running in sys-net, the traffic coming in
from the VM isn't Tor-encrypted, obviously, and far more visible, HTTPS
notwithstanding.)

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/b4db5a08cca0cef35d47c814c9121326.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

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

> OK, but I have already built the script. I have it running in Net VM. It
> works.
>
> I am NOT asking you to make an alternative system.
>
> I am simply asking whether an attack on the WiFi/Ethernet in the Net VM
> could also end up messing up my Tor script.
>
> Look at the question again:
>
> http://imgur.com/a/CTbLk

As mentioned, if sys-net is compromised by a NIC attack, anything running
in it is vulnerable, including the ability to modify/replace tor or tweak
the iptables to redirect all traffic intended for tor, unencrypted (other
than HTTPS encryption), to the attacker's server.

It's MITM-vulnerable for non-HTTPS connections.  And given that HTTPS
isn't secure against state actors or anyone corrupt with CA abilities,
losing the Tor layer, even with HTTPS, could be disastrous. Not great.

If your Tor is running in another appVM, such as whonix-gw does, the worst
a sys-net compromise could do is redirect the *encrypted* Tor traffic from
whonix-gw, which isn't terribly useful for the attacker.

Tor traffic is encrypted three layers deep (one might say, like an onion
:) ), with three separate public keys, for three different Tor relays. 
Unless the attacker has the private keys for those three relays (which are
randomly chosen by Tor in its vm), there's not a lot they can do with the
traffic, other than be aware of it, block/DDOS it, or correlate traffic if
they control enough entry/exit nodes.

(Now, if the compromised sys-net can somehow otherwise breach other
AppVM's or dom0, you're screwed.  But that's a given anyway, and hopefully
impossible after the latest patch against a recent and real such
vulnerability :)  And if it were possible, it would be a different attack
vector all together, since sys-whonix [for example] has no PCI devices to
be susceptible to a DMA attack.)

This discussion brought to mind another potential attack vector, in the
case of a compromised sys-net: If sys-net were compromised due to a NIC
attack of some form, it could present any fraudulent windows it wants
(e.g. password prompts) in dom0.

So make sure your sys-net has a unique and noticeable color assigned to
it, and pay heed to your window border colors.  (I guess that's the main
point of the window border coloring, is to clue in the user to attacks of
this nature.)

It could also replace/redirect the update server in sys-net, but package
signing should catch and prevent harm from that.

Digressing a bit, but related: if you ever see failed fetches during
"apt-get update," especially for security package lists, I'd recommend you
interrupt and run again.  Apparently upstream blocking of security updates
is one way attackers can leverage known vulnerabilities.  (And the fact
you're need to update a security package list is a huge "tell" that you
suffer from that vulnerability.)

More than once I've seen package lists update fine, but certain security
package list updates fail.  It could just be a transient error on the
server, but given that it's a known attack vector, it can't help be
cautious.

I'd highly recommend using apt-transport-tor, which gets packages direct
from debian, through an encrypted connection:

https://guardianproject.info/2016/07/31/howto-get-all-your-debian-packages-via-tor-onion-services/

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/4f610b3190edc47beeb97e4a7664a132.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

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

> nishiwak...@gmail.com:
>> Hello,
>>
>> I am surprised that there is no way to disable ipv6 on Debian template.
>>
>> I reinstalled first the template using documentation
>> https://www.qubes-os.org/doc/reinstall-template/
>>
>> Then I added "net.ipv6.conf.all.disable_ipv6 = 1" in /etc/sysctl.conf, I
>> did reboot the Template but it didn't change the outcome, I still had
>> ipv6 ports opened using "netstat -antp"

Did you try this:

https://superuser.com/questions/575684/how-to-disable-ipv6-on-a-specific-interface-in-linux

In /etc/sysconfig/network:

NETWORKING_IPV6=no
IPV6_AUTOCONF=no


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

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

> I'm pretty sure that can be done fairly simply, out-of-the-box via
> NetworkManager, not requiring a script:

Oh, and another good tip, is to make another NetworkManager show up in a
secondary VM (other than just from sys-net), you can manually add
"network-manager" (and check it) as a service in the Qubes VM Manager
(under the services tab).  That's how you get a VPN ProxyVM configured and
running, for example:

https://www.qubes-os.org/doc/vpn/

Works great!  I was using OpenVPN from the command-line and with config
files, until I realized NetworkManager would do it all for me in a more
integrated fashion.

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/6f3796d4647939c594dfe348b1676721.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

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

> In terms of "hotspot" terminology, what it does is, quote from author of
> the script:
>
> "it bridges the two interfaces but uses NAT to achieve it"

Ah, so it sets up some iptable nat rules (and maybe tweaks torrc to allow
it to listen on a non-local interface; although iptables could do that
redirection, too.)

I'd generally call that "tethering" or "internet connection sharing." 
"HotSpot" implies public shared WiFi to me.

I'm pretty sure that can be done fairly simply, out-of-the-box via
NetworkManager, not requiring a script:

https://wiki.archlinux.org/index.php/NetworkManager#Sharing_internet_connection_over_Ethernet

Although if you're tunneling into another VM, it might not be that
straight forward.  Some good info and examples on such tunneling here:

https://www.qubes-os.org/doc/qubes-firewall/

And redirecting into Tor might not be doable solely from the
NetworkManager, not sure.  Although if you install Qubes-whonix, whose
gateway (sys-whonix) redirects *all* traffic over Tor, you could probably
get everything running just with GUI configuration, no scripting required.
 (Less maintenance, more reliability.)

https://www.whonix.org/wiki/Qubes

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/aa8cdd60b636376a3622e33a0db75ad8.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

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

> OK, it's the original poster here.
> The consensus so far is that anything I run inside sys-net should be
> vulnerable, and that it is advised not to run programs in sys-net.
>
> So, in this case, how am I supposed to run my Ethernet Tor hotspot..?

I think you're going to have be more specific about what "ethernet tor
hostpot" means.  Hotspots are typically publicly accessible WiFi internet
access points.  ("Ethernet" to me implies wired, so hotspot makes a bit
less sense.)

> I had somebody write me a script that lets Qubes connect by WiFi to my
> home router, and then serve out an Ethernet hotspot that runs everything
> through Tor.
> The program works fine, but yes, it does run within sys-net.

"serve out an ethernet hotspot" and "runs everything through tor" are
confusing phrases to me.  Are you running a Tor Relay?  Or a Wifi hotspot
that sends things through Tor?  Again, if you're more specific about what
you're doing, you'll get better responses.

If you are running a network-facing service, such as a WiFi hotspot or a
gateway into your system for yourself, sys-net would indeed be a
reasonable place locate such a service.

At the very least, if you're handling incoming connections, you'll need
some port forwarding in sys-net to another VM that provides the service.

If you are running a WiFi hotspot that forwards things through the Tor
network, I'd run tor in another VM and forward the requests from sys-net
with iptables.  Tor isn't exactly a monster, but it's certainly a hacking
target for NSA and organized crooks, so I'd lean towards having it out of
sys-net.

Frankly, if you're just looking for a good personal VPN style thing, I'd
take a closer look at that streisand link I posted earlier, and leave your
personal home Qubes system out of it.  $5/mo for a server to run streisand
to eliminate incoming connections on your home system, is well worth it.

Unless I completely misunderstand what you're trying to achieve, which is
entirely possible.

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/1eeeb93551d30e346fd18edf451df272.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

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

> I am surprised that there is no way to disable ipv6 on Debian template.
>
> I reinstalled first the template using documentation
> https://www.qubes-os.org/doc/reinstall-template/
>
> Then I added "net.ipv6.conf.all.disable_ipv6 = 1" in /etc/sysctl.conf, I
> did reboot the Template but it didn't change the outcome, I still had ipv6
> ports opened using "netstat -antp"
>
> I even added "sudo ip6tables -P INPUT DROP" in "/rw/config/rc.local", but
> I still got those distant servers listening when I check using commands
> like "sudo lsof -i6" or "netstat -antp" on my Debian Template.

I agree that IPV6 shouldn't be used; IPV4 works, and is simpler, and thus
potentially less vulnerable (less attack surface, yadda, yaada.)  While
IPV6 isn't necessarily new, it still seems a bit "mysterious" to me.  It's
certainly more complex, and complexity is no friend of security.

Why not just disable IPV6 ("ignore") in the Network Manager (in sys-net,
displayed on the taskbar in dom0, next to the Qubes Manager icon)?

If sys-net/NetworkManager has ipv6 disabled, no VM is going to get any
IPV6 packets through.

> What is rpcbind, avahi-dae

I also agree that avahi shouldn't be enabled.  It is one of the first
things I disable in Qubes.  It's a zeroconf/Bounjour thing.  Not needed,
and more attack surface.

rpcbind is a portmapper thing, useful for NFS, and I'm not sure what else,
really.  Another thing I also disable.  (Probably like you, for security
reasons, I don't like seeing anything listening when I do a netstat.)

Also, this:

http://blog.level3.com/security/a-new-ddos-reflection-attack-portmapper-an-early-warning-to-the-industry/

I should note that due to a lot of hacking/harassment, I'm a bit more
paranoid than your typical user.

While it's probably innocent, seeing things like this enabled by default
in a system always make me a bit less trusting of such a system; has an
NSA-tampering feeling to it.  :)

(Similar to audio/pulseaudio enabled in sys-net/sys-firewall, the apparmor
extra-profiles not being included in Tails for some bizarre reason, and
the like.)

exim4, I believe, was also enabled by default in fedora-23/debian-8, which
makes little sense.  If you want a mail server, set up a mail server,
don't have them running in every VM by default.

(As I mentioned in another post, I think there's an outstanding ticket to
eliminate unnecessary systemctl services in the debian and fedora
templates.)

> and why you got this ipv6 bound to systemd on
> PID 1 ? Looks suspicious, I thought Ipv6 was disabled by default on Qubes.

I've seem people diss systemd as being unnecessary complex and obscure,
and thus a bit of a risk for security.  However, the dependency management
it provides is very powerful imho, and well worth it.

(I can't help but think the same startup dependency results couldn't have
been achieved with the "make" utility.  Probably not quite as elegantly,
but without adding another new utility.)

You say you see ipv6 bound to systemd?  Is it listening on a specific port
or anything?

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/dd0a71c1168b8a19068ad1fd4e942a44.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] "Carrying forward" a DMA attack..?

Chris wrote:
> Especially if you did the sharing via a separate vpn or ssh tunnel. But
> in general, I don't think Qubes security should be considered much if
> any benefit to adjacent non-Qubes systems.

This is one of my favorite implicit features of Qubes:

Setting up multiple layers of network protection is so much easier
than on a non VM'd system.

When I used to use Tails, I set things up to use VPN-over-Tor, so any
dodgy Tor exit node only sees encrypted VPN traffic, and my nosy ISP
doesn't know if I'm use a VPN, or which provider. I've also done
Tor-Over-VPN, and VPN->Tor->VPN setups. :)

It was a nightmare to set up. And that can lead to mistakes.

On Qubes, it's a simple matter of layering another ProxyVM above
sys-firewall. Add the NetworkManager service in the VM Manager settings,
and you can configure OpenVPN, and you're good to go. Any additional
layers are just as easy.

(Qubes-whonix is a good example of such a configuration.)

Memory can be a problem for limited systems (such as mine) and multiple
ProxyVM layers, but (at a slightly greater risk of the effects of a
compromise) could do your VPN configuration right in sys-firewall/sys-net
if you wished, to avoid additional VM's.

For example, with sys-net -> sys-firewall -> sys-whonix -> sys-vpn ->
AppVM (and hey, throw a Tor Browser on top of that if you want to go nuts)
any attacker has quite a few challenges ahead of them. :)

I generally go with sys-net->sys-firewall->sys-vpn, and Torbrowser when I
need to get to a .onion site.

It's rewarding to fire up iptraf-ng in sys-net, and see nothing but
encrypted packets to your VPN provider, while your AppVM's think they're
just on the regular net. :)

(Standard disclaimer, of course, that your VPN provider will see any
unencrypted traffic you send through it. As Chris mentioned,
https-anywhere can with that risk.)

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

Re: [qubes-users] "Carrying forward" a DMA attack..?

I'm curious as to why you would say this.

Any additional firewall between a Laptop and the network is a plus for
security, and with Qubes isolating the NIC in a virtual machine, its safer
from compromise than a typical firewall.

Now, some firewalls, such as shorewall running on a Linux box, might have
slicker and more advanced/flexible firewall configuration than Qubes, the
network card isolation is a huge boost to security in my eyes.

And there's nothing stopping you from running shorewall or another
firewall in your sys-firewall, to get the combined benefits of both
approaches.

While I like the simplicity of Qubes' firewall config, I'd actually like
to see more powerful firewall/iptables configuration, as well as having it
locked down to a greater degree by default (such as with Tails' iptables
configuration).

Similarly, I'd like to see apparmor installed and configured tightly with
Qubes by default. (Again, Tails is a good example of including apparmor
support by default, although they inexplicably exclude the "extra"
profiles, which include chromium and some other useful/critical profiles,
IMO. Maybe its for performance reasons, but it still seems crazy [almost
suspicious, lol] not to include them.)

Qubes NIC isolation + iptables + apparmor can make a system incredibly
secure against breaches. While Qubes' isn't designed as a firewall for
other computers/devices, it strikes me as having the potential to be a
safer firewall base than the alternatives.

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

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

> Simple question: Why are Ethernet and WiFi in sys-net..?
>
> Is it
>
> (A) Just for easy access to the same network for all App VMs..?
>
> (B) Because this is isolating Ethernet and WiFi from the rest of the
> system, to stop DMA attacks..?

Primarily (B).  Any DMA attack or other network hardware compromise is
confined to the net VM, and not your more critical work VM's (or dom0).

> It's not clear to me whether the VT-D protection is occurring because you
> are putting these devices in sys-net.
>
> Or whether the VT-D is implemented regardless of which VM the
> Wifi/Ethernet are in.

I'm not quite clear what you're getting at here.  The network device(s)
could live in any VM, and thus be isolated from the rest of the system.

But by Qubes convention, the devices are put in sys-net, which is
sys-firewall's NetVM, which in turn is typically the NetVM for other
AppVM's.

> I ask this because I want to run some programs in sys-net, and wonder
> whether a DMA attack could screw up these programs.

It absolutely could.  I'd generally recommend against running anything in
sys-net unless its very specifically needed, raw net-related, or low-risk.
 Things like wireshark, iptraf are useful to have in sys-net, for example.

Any program running in sys-net doesn't benefit from the firewall rules
protection at all, either.

Just as with dom0, the fewer programs running (and thus the smaller attack
surface) in sys-net (and sys-firewall), the better.

Which is why I'd like to see unnecessary things like pulseaudio, exim,
(and possibly even the X server) not included in sys-net by default.  I
think there's a Qubes ticket to that effect.

Digressing a bit, but here's an interesting, leaner replacement for
sys-firewall:

http://roscidus.com/blog/blog/2016/01/01/a-unikernel-firewall-for-qubesos/

What's the nature of the program(s) you want to run in sys-net?  Is there
any reason they couldn't be run in another AppVM instead?

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/2b6bd00d61406084ca4dc4b21243f71d.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] "Carrying forward" a DMA attack..?

> If the Qubes machine is hit by a DMA attack, it is compromised and could
> thus tamper with the forwarded Internet connection however the attacker
> desires.  (As well as scraping any credentials you might use in common on
> the Qubes box, and carrying out aggressive attacks on anything on your
> network.)

That's also assuming the DMA attack isn't confined to a
non-net/non-firewall/non-dom0 VM.

A single compromised AppVM that isn't involved in the shared network
connection shouldn't affect the laptop (but could scrape info and tamper
with anything you do in that VM, which might have cascading effects with
any credentials used elsewhere).

But if dom0 or sys-net/sys-firewall (or whonix-gw or any other
netvm/proxyvm) is affected by the DMA attack, the rest of what I said
should apply.

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/6978265996a4e9a7ec09b8eac062a91a.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] "Carrying forward" a DMA attack..?

> Let's say I have a Qubes machine connected to a 2nd laptop by Ethernet.
>
> The Qubes machine is sharing its Internet connection.
>
> Let's say the Qubes machine gets hit with a DMA attack.
>
> The 2nd laptop is not a Qubes machine, and therefore doesn't have VT-D for
> DMA protection.
>
> Can the DMA attack be "carried forward" to the 2nd laptop... or is it
> killed for good by the Qubes machine..?

My take on it:

If the Qubes machine is hit by a DMA attack, it is compromised and could
thus tamper with the forwarded Internet connection however the attacker
desires.  (As well as scraping any credentials you might use in common on
the Qubes box, and carrying out aggressive attacks on anything on your
network.)

So a compromised machine couldn't specifically "forward" a DMA attack per
se, but it has full control of the Internet connection and traffic to and
from the laptop.

Any unencrypted net connections could be spied upon, tampered with,
MITM'd, injecting spyware (which may in turn use a DMA attack itself, or
0day exploits, or whatever) into an unencrypted mail/http connection, for
example.

I'd say it's no more risky than what a crooked ISP, a hacked Cable Modem,
or anything else upstream in the net connection could achieve.

Any strongly encrypted connection (Tor, OpenVPN, HTTPS without state-actor
CA certificate tampering/spoofing, etc.) should be safe, other than
potential denial-of-service which would be pretty noticeable.

I would say having the Qubes box between the laptop and the Internet
generally increases the safety of the laptop.

The benefits far outweigh the risks, as long as you don't do most of your
critical browsing/email through unencrypted connections; in which case
your probably screwed anyway :).

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/bfbc4f1250a9ae5f80d3cc221b6d6ba8.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] New version of Qubes Screenshot Tool (0.5 beta)

2016-09-24 Thread johnyjukya

> Hello,
>
> New version of Qubes Screenshot tool available.
>
> https://github.com/evadogstar/qvm-screenshot-tool
>
>
> If you do not know what is it: a tool to easy make screenshots and
> upload them to the AppVM and to the web ( imgurl service ).
>
> Changelog:
> - Now, it's possible to re-open imgurl uploaded dialog again, if it was
> closed. I found that it's very useful at the daily use to get uploaded
> url again.
> - "Ksnapshot" removed from the menu if it's not available at the system
> (because of Qubes XFCE migration and KDE not available now by default)

Hey, I just noticed that the screenshot utility supposedly supports imgur.
 How does it do that from dom0?  Similar to qubes-dom0-update, and use the
firewall or other VM to do the networking?

When I tried it, I just got an error that it couldn't transfer to imgur. 
Is this not supported in dom0, or is there something misconfigured at my
end?

(I don't have dispvm's enabled, for memory conservation reasons; would
that be relevant?)

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/61b10ca2233832607b73eb993e3f5f2a.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Dear qubes-users

2016-09-24 Thread johnyjukya

> Mr. Harrison:
>> Dear qubes-users,
>>
>> I am long time qubes follower and user. I apologize in advance if anyone
>> feels this request is spam.
>>
>> I am looking for two invite codes needed to sign up to anonymous
>> riseup.net email service.

I agree that asking random strangers for Riseup invites is inappropriate,
especially on a mailing list.

But just FYI, I received my riseup account by mailing the administrators,
explaining the ongoing harassment/hacking/spying situation that
necessitated better email security, and they gave me an account without
referrals.

sigaint is another option that doesn't require referrals, but does require
Tor to access as it's only available as hidden service (a good thing,
probably):

http://sigaintevyh2rzvw.onion

(Sigaint was asking for donations recently, saying they only had a month
or so of operating funds left; so there's a chance they could suddenly
disappear, but for now, it's not a bad option.)

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/c8a80ea67d6ce794f734603c90432606.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] BTRFS?

2016-09-22 Thread johnyjukya

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Thu, Sep 22, 2016 at 03:56:57PM -0700, Connor Page wrote:
>> In fact, I think the right question is "Will Qubes 4 be compatible with
>> btrfs root if vm storage is expected to reside on a LVM thin pool?"
>
> This is a good question. The new storage handling is flexible enough to
> allow writing a module to handle btrfs even better than in Qubes 3.x.
> But it is unlikely that we'll manage to write such module for 4.0. If
> someone would contribute such module, then yes - it will be supported.
> Otherwise, probably somehow around 4.1 or later.

4.0 will be less flexible in this respect?

LVM thin volumes sound interesting (just read up on them today) and handy
for allocation, but they'll be mandatory for VM storage??

(Again, as mentioned in my earlier post, btrfs seems like it would meet
the same needs and then some.)

Why is it that so many things I hear about 4.0 are concerning to me?

I realize one must make sacrifices and architectural choices in the name
of progress.

But so far what I know of 4.0 is that it won't run on any of my PCs, it
won't (initially at least) support btrfs root, and the "decomposition"
sounds like it's going to spread configuration stuff in various places
rather than in one spot, the Qubes Manager (well, and the menu), where
they're generally very easy to find.

(There was something else that didn't sit well with me, but it escapes my
feeble mind at the moment.  Might have been something to do with hardware
or processor requirements.)

I know there are some incredibly talented people working on Qubes, and a
great community surrounding it, so my fears are probably largely
unfounded; but I'm a bit afraid to invest in fully settling into and
committing to a system (which has been great so far), if the next major
release won't work for me.

Once 4.0 comes out, what happens to 3.2?  Will it be supported for awhile,
moved forward at all, or just marked as deprecated/EOL'd and more or less
abandoned?

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/429588c1db7fa0d2df95a73160c305e5.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] BTRFS?

2016-09-22 Thread johnyjukya

Has the Qubes team ever considered the use of btrfs?

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

It's been the default root FS for Suse since 2012:

https://www.linux.com/news/suse-linux-says-btrfs-ready-rock

While reading about its features (and using it) it seems like it would be
especially well-suited as a base for Qubes, giving unlimited snapshots,
nested overlays/unions (seeds), rollbacks, subvolumes, sparse files, plus
easy adding/removing of disks, raid, space balancing, and greater
reliability (with the raid and checksum of metadata/data). A win/win
situation.

It would make the template implementation a lot simpler, faster, and more
flexible. Instead of .img files, you'd just have subvolumes (and use of
seeds/unions). It seems like a more elegant, flexible, and extensible
solution.

Even doing things like multi-level templates would be possible (although
for root, I think package management would be problematic with more than
one level).

Cloning a given template or an appvm would be instant and require zero
disk space (due to the innate copy-on-write nature of btrfs) rather than
taking many minutes and doubling the disk usage. The only space used by a
cloned template/vm would be what was eventually modified. Booyeah.

If used as a rootfs, even without any further template integration, the
deduplication feature should automatically bring the same disk savings.

It also offers self-healing, online checking/shrinking/growth,
"deduplication" of blocks with the same content, ..., the list goes on.

The related btrfs support utility "Snapper" also seems like it would fit
in very nicely with Qubes:

https://wiki.archlinux.org/index.php/Snapper

Suse automatically creates a snapshot whenever packages are installed, so
it's easy to rollback any undesired changes. Again, that would be a great
feature for templates.

You can even convert an ext4 system to btrfs, and keep both available,
since btrfs keeps the data blocks in a compatible way and puts it metadata
in other unused space. It makes the existing ext4 metadata a separate
btrfs subvolume, you can later delete if you choose--very slick. (Or
similarly, you can revert to ext4-only as easily.)

I'm starting to use BTRFS for all my non-root/non-user devices, and I'm
loving it. The private.img/volatile.img structure seems primitive by
comparison. :)

I realize the ext* code is probably considered more mature, stable, and
safe for dom0, but btrfs seems to have been put through its paces quite
well over the years (and I'm sure ext4 itself has been having a lot of
code changes over the years, possibly making it no more secure than
btrfs?)

(I haven't checked if the Qubes install allows it as an option for root.
Even if it does allow its basic use, going further and leveraging the
seed/subvolume/snapshot for templates/appvms is the more exciting part to
me.)

I realize such a change would be non-trivial, but it does seem like a
natural way for Qubes to evolve.

Thoughts?

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

Re: [qubes-users] Re: NVIDIA GeForce

2016-09-21 Thread johnyjukya

> On Wednesday, 21 September 2016 02:25:15 UTC+10, johny...@sigaint.org
> wrote:
>> > On Sunday, September 11, 2016 at 11:11:28 PM UTC-4, Drew White wrote:
>> >> On Friday, 9 September 2016 18:58:51 UTC+10, Thomas Ernst  wrote:
>> >> > Hi all,
>> >> >
>> >> > Does Qubes support NVIDIA GeForce graphics cards? The reason for
>> >> asking is that I am planing to buy a Lenovo ThinkPad T460p Laptop,
>> >> which has a NVIDIA GeForce 940MX 2 GB graphics card.
>> >> >
>> >> > Best,
>> >> >
>> >> > Thomas
>> >>
>> >> I have a GeForce GTX630 and a Quadro 600 in my machine, and both work
>> >> well with no issues.
>> >>
>> >> The Thinkpads work well with Qubes.
>> >> the T530 is very nice and works well.
>> >> So the Pro T460 should also be quite acceptable.
>> >>
>> >> As long as you have 4 or more threads, you can use qubes easily.
>> >
>> > I have gtx 650 ti.  works great.   I would research how the card
>> perform
>> > with open source linux drivers in general before buying.
>>
>> I have a GeForce6100SM-M2.  It's on-board nVidia card crashes (diagonal
>> stripes) after a bit of usage (almost seems to happen when memory gets
>> low).
>>
>> I've tried all the BIOS settings, etc., with no luck.  (The same thing
>> occurs under Tails, FYI.)
>>
>> With a PCI GeForce7300 GT inserted (and the on-board video disabled),
>> things work just fine.
>>
>> (Note that in 3.1, and 3.2 up until rc2? I think, there was a bug where
>> the VM's would get screen corruption.  rc2 and beyond have fixed this
>> problem.)
>>
>> Cheers.
>>
>> JJ
>
> I only got screen corruption AFTER upgrading to 3.2, then I did a full
> update of Dom0 to get rid of that because there was a fix that came out
> for it.
> However it didn't happen often. I never found out the reason why it
> happened, because I saw there was a fix for it.
> 3.1 didn't EVER have the screen corruption for me.
> And I was using Dual Monitors and dual Quadro600's

The screen corruption problem I was seeing was in 3.2 (rc1 I think), and
the fix was in the VM's (Debian-8/Redhat-23) not dom0.  (It was something
to do with accessing freed/reallocated memory once swapping started, if I
remember correctly.)

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/9a30f6877dcb0bd489005ee6bdd19a8d.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Failed device allocation

2016-09-20 Thread johnyjukya

Quite frequently, under Debian-8, when I go to assign a device, it quietly
appears to work (Qubes Manager shows it assigned), but the device never
shows up, and the VM's dmesg shows things like this:

[Tue Sep 20 13:17:09 2016] xenwatch: page allocation failure: order:5,
mode:0x240c0c0
[Tue Sep 20 13:17:09 2016] CPU: 0 PID: 16 Comm: xenwatch Tainted: G   
   O4.4.14-11.pvops.qubes.x86_64 #1
[Tue Sep 20 13:17:09 2016]  023a 37654cb4
880004b6b928 813b06f3
[Tue Sep 20 13:17:09 2016]  0240c0c0 
880004b6b9b8 811a58fa
[Tue Sep 20 13:17:09 2016]  00010040 04b6b950
37654cb4 0005
[Tue Sep 20 13:17:09 2016] Call Trace:
[Tue Sep 20 13:17:09 2016]  [] dump_stack+0x63/0x90
[Tue Sep 20 13:17:09 2016]  [] warn_alloc_failed+0xfa/0x160
[Tue Sep 20 13:17:09 2016]  []
__alloc_pages_nodemask+0x349/0xb40
[Tue Sep 20 13:17:09 2016]  []
alloc_pages_current+0x8c/0x110
[Tue Sep 20 13:17:09 2016]  [] alloc_kmem_pages+0x19/0x90
[Tue Sep 20 13:17:09 2016]  []
kmalloc_order_trace+0x2e/0xe0
[Tue Sep 20 13:17:09 2016]  [] ?
xenbus_read_otherend_details+0x62/0xd0
[Tue Sep 20 13:17:09 2016]  [] blkfront_probe+0x8e/0x236
[xen_blkfront]
[Tue Sep 20 13:17:09 2016]  [] xenbus_dev_probe+0x89/0x160
[Tue Sep 20 13:17:09 2016]  []
xenbus_frontend_dev_probe+0x48/0x50
[Tue Sep 20 13:17:09 2016]  []
driver_probe_device+0x222/0x490
[Tue Sep 20 13:17:09 2016]  []
__device_attach_driver+0x71/0xa0
[Tue Sep 20 13:17:09 2016]  [] ? __driver_attach+0x90/0x90
[Tue Sep 20 13:17:09 2016]  [] bus_for_each_drv+0x67/0xb0
[Tue Sep 20 13:17:09 2016]  [] __device_attach+0xdc/0x170
[Tue Sep 20 13:17:09 2016]  []
device_initial_probe+0x13/0x20
[Tue Sep 20 13:17:09 2016]  [] bus_probe_device+0x92/0xa0
[Tue Sep 20 13:17:09 2016]  [] device_add+0x40b/0x680
[Tue Sep 20 13:17:09 2016]  [] device_register+0x1a/0x20
[Tue Sep 20 13:17:09 2016]  []
xenbus_probe_node+0x172/0x190
[Tue Sep 20 13:17:09 2016]  []
xenbus_dev_changed+0x1c9/0x1d0
[Tue Sep 20 13:17:09 2016]  [] ?
register_xenbus_watch+0xf0/0xf0
[Tue Sep 20 13:17:09 2016]  [] frontend_changed+0x25/0x50
[Tue Sep 20 13:17:09 2016]  [] xenwatch_thread+0x91/0x140
[Tue Sep 20 13:17:09 2016]  [] ?
wake_atomic_t_function+0x70/0x70
[Tue Sep 20 13:17:09 2016]  [] kthread+0xd8/0xf0
[Tue Sep 20 13:17:09 2016]  [] ?
kthread_create_on_node+0x190/0x190
[Tue Sep 20 13:17:09 2016]  [] ret_from_fork+0x3f/0x70
[Tue Sep 20 13:17:09 2016]  [] ?
kthread_create_on_node+0x190/0x190
[Tue Sep 20 13:17:09 2016] Mem-Info:
[Tue Sep 20 13:17:09 2016] active_anon:7391 inactive_anon:8741
isolated_anon:0
 active_file:11006 inactive_file:10713 isolated_file:0
 unevictable:2407 dirty:0 writeback:0 unstable:0
 slab_reclaimable:4436 slab_unreclaimable:2617
 mapped:4353 shmem:444 pagetables:1547 bounce:0
 free:504 free_pcp:0 free_cma:0
[Tue Sep 20 13:17:09 2016] Node 0 DMA free:480kB min:268kB low:332kB
high:400kB active_anon:736kB inactive_anon:824kB active_file:1312kB
inactive_file:1116kB unevictable:16kB isolated(anon):0kB
isolated(file):0kB present:15996kB managed:15912kB mlocked:16kB dirty:0kB
writeback:0kB mapped:988kB shmem:20kB slab_reclaimable:2700kB
slab_unreclaimable:1632kB kernel_stack:224kB pagetables:304kB unstable:0kB
bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB
pages_scanned:0 all_unreclaimable? no
[Tue Sep 20 13:17:09 2016] lowmem_reserve[]: 0 38 38 38
[Tue Sep 20 13:17:09 2016] Node 0 DMA32 free:1536kB min:668kB low:832kB
high:1000kB active_anon:28828kB inactive_anon:34140kB active_file:42712kB
inactive_file:41736kB unevictable:9612kB isolated(anon):0kB
isolated(file):0kB present:1028096kB managed:216048kB mlocked:9612kB
dirty:0kB writeback:0kB mapped:16424kB shmem:1756kB
slab_reclaimable:15044kB slab_unreclaimable:8836kB kernel_stack:2032kB
pagetables:5884kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB
free_cma:0kB writeback_tmp:0kB pages_scanned:8 all_unreclaimable? no
[Tue Sep 20 13:17:09 2016] lowmem_reserve[]: 0 0 0 0
[Tue Sep 20 13:17:09 2016] Node 0 DMA: 68*4kB (UE) 18*8kB (UME) 4*16kB
(UM) 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB =
480kB
[Tue Sep 20 13:17:09 2016] Node 0 DMA32: 67*4kB (ME) 33*8kB (ME) 17*16kB
(ME) 17*32kB (UME) 3*64kB (UE) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB
0*4096kB = 1540kB
[Tue Sep 20 13:17:09 2016] 23086 total pagecache pages
[Tue Sep 20 13:17:09 2016] 924 pages in swap cache
[Tue Sep 20 13:17:09 2016] Swap cache stats: add 9783, delete 8859, find
3262/4914
[Tue Sep 20 13:17:09 2016] Free swap  = 1024996kB
[Tue Sep 20 13:17:09 2016] Total swap = 1048572kB
[Tue Sep 20 13:17:09 2016] 261023 pages RAM
[Tue Sep 20 13:17:09 2016] 0 pages HighMem/MovableOnly
[Tue Sep 20 13:17:09 2016] 203033 pages reserved
[Tue Sep 20 13:17:09 2016] 0 pages hwpoisoned
[Tue Sep 20 13:17:09 2016] vbd vbd-51856: 12 allocating info structure
[Tue Sep 20 13:17:09 2016] vbd vbd-51856: 12 xenbus_dev_probe on
device/vbd/51856
[Tue Sep 20 13:17:09 2016] vbd: probe of

Re: [qubes-users] Re: Booting Cubes, Migration

2016-09-20 Thread johnyjukya

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 2016-09-19 13:36, johnyju...@sigaint.org wrote:
>>> I've finally got Qubes set up in a way I'm comfortable working every
>>> day.
>>>
>>> Now I wanted to move that same installation to another drive for its
>>> permanent home.
>>
>> Oh, I also meant to ask this:
>>
>> Does all of the Template/VM state live in /var/lib/qubes?  Obviously the
>> machines' disks do, and it appears that the metadata associated with
>> them
>> lives in /var/lib/qubes/qubes.xml (not human readable, tho').
>>
>> Is this correct?  If I do a fresh install of Qubes, and (with no VM's
>> running) bring over my whole /var/lib/qubes directory from another
>> installation, reboot, would I be good to go?  Or are there other subtle
>> things in dom0's root drive that would be out of kilter?
>>
>
> I'm not sure whether this would work (never tried it). If possible, I'd
> recommend using the built-in backup/restore system instead. This is the
> recommended way to migrate to a fresh installation.
>
> https://www.qubes-os.org/doc/backup-restore/

Understood.  I just find the backup/restore painfully slow as compared to
a quick (and incremental, as I work) rsync.

And I did try to do the backup/restore thing, but my destination drive had
some partitions on it I wanted to preserve (as mentioned), and I just
couldn't get the layout I wanted (partition->luks->lvm->swap/root, plus a
sda1 bios boot).

I guess I'll move those three existing encrypted partitions (1.5T, ugh) to
another drive (external USB, blah), do a fresh stock install of Qubes,
then copy those partitions back.  See ya in a week or two.  :P

I'll probably toy around with (and study up on)
grub/dracut/luks/crypttab/initrd a bit more first, though, since I'm so
close.  A little more debugging might do the trick.  I have a perfect
image of the old encrypted swap/root and bios boot partitions on the new
drive.  So it's just a matter of the right grub/dracut magic.  So close,
to avoid a couple of days of copying.

If I do find the magic tweak to make systemd roll along further, I will
follow up here.

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/8380b617dfdff766d79a0ba3cc25488b.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: NVIDIA GeForce

2016-09-20 Thread johnyjukya

> On Sunday, September 11, 2016 at 11:11:28 PM UTC-4, Drew White wrote:
>> On Friday, 9 September 2016 18:58:51 UTC+10, Thomas Ernst  wrote:
>> > Hi all,
>> >
>> > Does Qubes support NVIDIA GeForce graphics cards? The reason for
>> asking is that I am planing to buy a Lenovo ThinkPad T460p Laptop,
>> which has a NVIDIA GeForce 940MX 2 GB graphics card.
>> >
>> > Best,
>> >
>> > Thomas
>>
>> I have a GeForce GTX630 and a Quadro 600 in my machine, and both work
>> well with no issues.
>>
>> The Thinkpads work well with Qubes.
>> the T530 is very nice and works well.
>> So the Pro T460 should also be quite acceptable.
>>
>> As long as you have 4 or more threads, you can use qubes easily.
>
> I have gtx 650 ti.  works great.   I would research how the card perform
> with open source linux drivers in general before buying.

I have a GeForce6100SM-M2.  It's on-board nVidia card crashes (diagonal
stripes) after a bit of usage (almost seems to happen when memory gets
low).

I've tried all the BIOS settings, etc., with no luck.  (The same thing
occurs under Tails, FYI.)

With a PCI GeForce7300 GT inserted (and the on-board video disabled),
things work just fine.

(Note that in 3.1, and 3.2 up until rc2? I think, there was a bug where
the VM's would get screen corruption.  rc2 and beyond have fixed this
problem.)

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/0a18031fd71f38c8919da886087ef75a.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Booting Cubes, Migration

> Anaconda is notorious for messing up specific requests for volume
> layout. You would stand a much better chance of getting help in a fedora
> or redhat forum... they have many more people experienced with this.

Cool, thanks.  I guess it is a more general grub/luks/lvm issue, and not
necessarily Qubes-specific.

> As for copying all of /var/lib/qubes, I'm not sure its a 100% clean way
> to do it transferring old qubes.xml directly would be a concern (but
> I may be wrong). Qubes does make it possible to copy a vm's folder into
> /vm-templates or /appvms, then run qvm-add-template or qvm-add-appvm to
> add vms one-by-one into the current system.

Interesting.  In the past, I have had success in moving a single VM by
creating a new VM with the same settings as the old one, then replacing
the files in the vm's directory.  (Sort of the reverse order of what you
mentioned.)

Now, if I can only get the booting working . . .  :)

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/6b7c4e837761ed4ab91e0070d33f8c07.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] USB hotplug messing up other USB devices?

Qubes 3.2rc3-testing (and earlier), AMD Athlon X2, GeForce motherboard,
NVidia MCP61 USB controller:

I'm currently running Qubes from an external USB drive. (Moving to
internal drive as soon as I figure out how to smoothly migrate it.) For
now, it works great in general.

In the meantime, I've noticed the odd corruption where the root drive
flips into R/O mode (and the system obviously becomes useless). A reboot,
fsck, reboot gets me back on track, usually with just a journal recovery,
sometimes with the odd recovered inode/count of some recently created
files. (No major file corruption yet, thankfully.)

I believe one thing that seems to kick in this problem, is
plugging/unplugging *other* USB devices (on same USB bus). It seems to
sometime upset existing USB drives.

Has anyone else experienced this?

The next time it happens, I'll post some logs. I think it's fairly
reproducable. I'm scanning through some old USB drives tomorrow, so I'm
sure it will re-occur, and I'll post some more details.

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/709e74ac4195b0c9a175d71b17c4dce4.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Booting Cubes, Migration

> I've finally got Qubes set up in a way I'm comfortable working every day.
>
> Now I wanted to move that same installation to another drive for its
> permanent home.

Oh, I also meant to ask this:

Does all of the Template/VM state live in /var/lib/qubes?  Obviously the
machines' disks do, and it appears that the metadata associated with them
lives in /var/lib/qubes/qubes.xml (not human readable, tho').

Is this correct?  If I do a fresh install of Qubes, and (with no VM's
running) bring over my whole /var/lib/qubes directory from another
installation, reboot, would I be good to go?  Or are there other subtle
things in dom0's root drive that would be out of kilter?

(It'd be nice to see the VM's and their state not being tied to anything
beyond /var/lib/qubes.  Seems a lot cleaner that way.)

Thanks.

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/8eab0f3d61be02c5d52b065607832d5b.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Booting Cubes, Migration

I've finally got Qubes set up in a way I'm comfortable working every day.

Now I wanted to move that same installation to another drive for its
permanent home.

The current drive has a standard bios /boot partition (sda1), and an
encrypted extended partition (#5) containing lvm with swap and /.

The destination drive has a few existing partitions on it, #2 - Extended
partition containing #5/#6/#7 which are a few encrypted partitions
containing some data I'd like to keep.

The destination drive has a 500M empty space at the start ready for
partition #1 (/boot) and 550G at the end, ready for partition #8, a future
encrypted partition, which will contain a physical volume/volume group
containing the logical volumes for swap and /.

1) First attempt to migrate, I created the new /boot partition by hand,
rsync'd from the old. Similarly, I created the new encrypted partition,
added the pv,vg,lvm's for swap/root, and rsync'd all the data from the old
root to the new root.

I tweaked up the UUID's in /boot/grub2/grub.cfg, /etc/crypttab,
/etc/fstab, and (I think) in the initrd.

However, that failed to boot. It got as far as dropping into the dracut
shell, and when I manually set up the qubes_dom0/root to be /dev/root and
exited, systemd went a little ways, but then went into some loop where it
kept saying target paths were ready, but did nothing further. Argh.

2) Second attempt was a raw DD of both /boot and the whole encrypted lvm
partition. (The destination partitions, luckily, were bigger.)

I then unplugged the original drive (since there'd be conflicting UUID's
now), rebooted, and same deal... The boot wouldn't mount the crypted
drive, and went into some loop.

Third attempt, I figured I'd do it the more official way, and do a fresh
install of Qubes, and then restore a backup from my old setup.

But with 3.2rc3, I couldn't get the installer to do what I wanted.
Occasionally I'd get a weird pop-up error about "e not being defined yet"
or something like that. :S

I tried and tried to coax it into creating a biosboot partition in
/dev/sda1, and making a /dev/sda8 as an encrypted, lvm-containing
partition, to no avail.

The closest I came, when it described the steps it was about to take (nice
feature!), it said it was going to create a partition in /dev/sda8, put an
LVM in that, and then create two Luks partitions, one for swap and one for
root.

That's not what I had before, and not what I wanted. I wanted the
encryption outside the LVM, which I thought was the standard way of doing
things.

If I choose "automatically partition the drive", will it preserve my
existing #5/#6/#7 extended partitions and just add new partitions as
needed? I don't want to nuke everything by mistake.

Any suggestions?

Also, on my first attempt to set it up, for the heck of it, I made the
/boot partition encrypted.
http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/

That part seemed to work fine; asked for passphrase right away, decrypted
/boot, loaded xen/vmlinux/initrd and started things rolling. But the same
systemd failure happened as described above. So I went back to
non-encrypted /boot. I do think encrypted /boot might be a good default
or optional feature for Qubes. Why leave more attack surface than
necessary, and the /boot partition is a pretty big glaring one.

(Why would an attacker care if root is encrypted, or bother with it, if
they have free reign to tamper with an un-encrypted /boot with all it's
kernel-ey and initrd goodness. It's like locking your front door, but
leaving your basement door wide open.)

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/4a13a2407f863a5b6a6a6f0ee6d225e4.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: epoxy on ram to prevent cold boot attacks?

2016-09-02 Thread johnyjukya

> On Wednesday, August 31, 2016 at 10:40:23 AM UTC-7, grzegorz@gmail.com
> wrote:
>
>> An actual protection would be some kind of a chemical that would destroy
>> the ram chips if they ever reach certain (lower than room) temperature.
>
> the epoxy is likely to damage them in most means of removal.

I guess most people have shinier (literally, on the contacts) new hardware
than I do, but I know now and then I need to re-seat my RAM chips when the
system gets cranky.  Epoxy would a pretty costly measure (probably
destroying the motherboard as well as the RAM).  I guess I'd have to get a
shinier new mobo in that case.  :)

I think case security and case (and room) intrusion detection is a bit
more "civilized."

> i know of things that can do their damage when they reach a certain
> temperature or higher. never heard of one set off by going below a certain
> temp.

While interesting, that seems like a bad idea.  Unless you're UPS'd up and
never need to modify your hardware, insert/remove a card, whatever, you're
gonna have a bad day eventually and lose your ram/mobo.

> erasing on power loss would be good too, esp if the attacker doesnt know
> about it.

This, I do like, possibly hooked into case intrusion.  I might just look
into that myself, see if there's certain RAM pins that can be safely
grounded to wipe the RAM in a case of power outage.  I expect it's more
difficult than that, and that the RAM would have to be actively wiped,
since a power-off should basically be more or less equivalent to grounding
all the RAM pins, no?

Now, frying the memory with a high voltage zip from a charged up cap, say,
on some chip-enable line or whatever, if there is a case intrusion without
the proper trick done to disable it (such as a 16-dip-switch combination
lock that has to be set properly) might be kind of cool.  :)  You'd want
some gate to isolate that line (or thew whole chip) from the motherboard,
to protect it.

Maybe a capsule of acid on the ram chips (and contained to only affect
them) that gets popped on command.  It'd be fun to burn the sticky fingers
of any intruder, too.  :)  Getting a bit fanciful here...

On that same line of thought, sending 120V to the case if it's opened
while the power is on (which is the mode of action for a cold boot attack,
I assume?) might be fun.  You might want to remove your Underwriter's Lab
logo from the PC if you rig that up, lol.  Getting into "Home Alone"
territory.

If you keep your PC on when you're away from it (which I think is safer,
and I guess is the situation when you need protection from a cold boot
attack), you could do something like immediately start wiping the RAM upon
case intrusion.  That'd be harmless in the case of legitimate maintenance,
too.  Seems much cleaner.

I wonder what the most straight forward method of stopping all
multi-tasking and starting to wipe the ram would be.  Could a dom0 bash
script, watching an intrusion detection device, simply do an "xl pause" or
whatever on all VM's and start writing to some /proc memory device?

(That's probably not going to work, you'd need something more
ring-zero-ey...?  Perhaps in a device driver.  When I try to use my
on-board NVidia, it does a good job of locking up the computer and wiping
the RAM itself, after awhile, lol.)

It'd have to be reasonably fast at starting its work.  And writing to
4g/8g of memory is going to take some time, in the best case.  Which adds
points in the favour of the more destructive high-voltage zap method. 
(Maybe not a sequential write, but a bit more randomized one would thwart
any attacker better?)

There may be some existing work done on this for xen; I might do a bit of
research and report back if I find anything useful.

Interesting subjects to ponder.

In my case (pun intended), there's not anything sensitive or incriminating
on my drive or in memory; it's more a matter of protecting privacy and
attempting to stop ongoing harassment and illegal surveillance.

Stealing some work designs or code or personal information would be
annoying, but it wouldn't jeopardize my life, land me in jail, or have me
detained for waterboarded or anything.

So knowing someone was tampering is good enough for me, and what I have
personally focused upon.

I'd be interested in others' thoughts on leaving the PC on versus leaving
it off.  Lately, I've been leaving it on, but with an alternative OS
(another Linux) whose sole purpose is to know if somebody's been mucking
around.  My actual useful drive, data, passwords, go with me.

It's only slightly inconvenient, but so far it has been the quickest route
towards some peace of mind until I'm 100% confident in physical security
and tamper detection.

Sorry for any digression.

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

Re: [qubes-users] Re: epoxy on ram to prevent cold boot attacks?

2016-09-01 Thread johnyjukya

>> https://freedesktop.org/wiki/Software/PulseAudio/FAQ/#index15h3
>
> I've looked at it few years ago and it was outdated/unmaintained at that
> time already. I gave up on setting this on Win 7. I bet now it's even
> harder.

Yes, weird how neglected it is.  Do people not write utility software for
Windows now?  Is it too locked down by MS (expensive signing) or too
insecure for anyone to bother coding?

Remote sound seems like the type of thing a lot of power users would want,
even on Windows.

>> When I assign a single USB drive to a VM, is dom0 still really in charge
>> of the USB bus, and just shuffling stuff back and forth to the VM(s)?
>
> If you assign a single USB device to VM (using qvm-usb or qvm-block),
> then yes - all the nasty USB stuff is still handled in dom0/sys-usb.
> Only assigning the whole USB controller (PCI device) to a VM will move
> USB processing out of dom0.

So other than the potential of bugs in the stack, and faking a
keyboard/mouse, there's really nothing a USB device could do to provoke
any action (break-in attempts) in dom0?

Would a USB Wifi dongle auto-configure as a second adapter on Qubes?  (I
might check that myself later.)

Mass storage devices will be noted by dom0, but nothing silly like autorun
could happen (unless you set it up manually).  Device impersonation is a
threat, I suppose.  Can one USB device effectively "bus master" to probe a
disk or something like that?

Any other device type that could be a threat via USB?

As long as you have a solid stack and reject HID/network, USB might not be
quite as scary as I thought.

Once you get your keyboard/mouse off of USB.  That recipe for rejecting
HID in one of those links worked great,
/etc/udev/rules.d/99-disable-usb-input.rules:

ACTION=="add", SUBSYSTEM=="input", SUBSYSTEMS=="usb",
ATTRS{authorized}=="1", \
   ENV{PARID}="$id", RUN+="/bin/sh -c 'echo 0
>/proc/bus/usb/devices/$env{PARID}/authorized'"

Any new attempts to insert HID devices are ignored.

I suppose there's a window at boot time before udev configures where a
rogue USB device could impersonate a HID device and try to hijack the
system (e.g. right at grub).  But supervising any boots for any oddness is
trivial (and a good idea).

>> https://dkopecek.github.io/usbguard/blog/2015/USBGuard-vs-UDev
>
> Very interesting project indeed. And it is packaged in Fedora!

N!!!  Lol, I spent hours trying to get that to build.  I had
checked for packages under debian-8, found none, so figured Fedora was
even less likely to have it (being more conservative).

I was even building it under a bare-bones Fedora-23 VM.  I could have just
dnf'd it.

That's a great thing, presumably having undergone review from the Fedora
folks to be in the main repositories.  (If Qubes can't in turn trust
Fedora and its repo, it's toast from the start.)  But I assume you still
don't increase the amount of running dom0 software lightly.

Installing it only brought in libqb (102k) and itself (206k), so it's
fairly lightweight.  Might see how well it agrees with dom0.  :P

> But as you've noted below, if all we need can be done using udev rules,
> it's better to not introduce another complexity.

With Fedora's review (and a fairly small package), I feel a lot more
comfortable with it, perhaps as an option.  Making it easier for people to
track/configure USB devices is a pretty compelling selling point. 
Possibly outweighs the risk of the minimal additional of dom0 software.

> The whole idea of having separate USB VM is to not care about USB
> related compromise. It isn't fully possible with all kind of devices (like
> USB camera - compromised USB VM will be able to sniff the traffic), but
> it is surely an improvement.

Leaving any camera or microphone connected at all isn't for the highly
security conscious.  :)

> It would make sense to have Disposable USB VM - I hope we'll manage to
> have it in Qubes 4.0.

That's interesting.  So, for example, you could possibly configure it such
that if a certain device is inserted, a disposable VM could pop up,
attached to that USB device, that could then run an app (such as keepass).
 When you're done, the DVM goes away.  That's rather tidy.  And safer.

I assume memory freed from a dead VM is wiped upon freeing by Xen?  Or at
least wiped before allocating it elsewhere?

>> Some discussions online argue that USB white-listing isn't helpful,
>> since
>> a BADUSB could just emulate your actual keyboard.  Well, it would have
>> to
>> know the device ID's first.
>
> Yes. But then, such device would be able to communicate with
> only one driver - of that keyboard. Not arbitrary chosen one of hundreds
> of them -> large reduction of attack surface.

I suppose even a brute-force search of device ID's through the relatively
few vendors is feasible (without some protection).

> Of course, if it hit unlocked system (or locked, but know the password),
> controlling keyboard means controlling the whole system. But you can
> guard against such attacks

Re: [qubes-users] Re: epoxy on ram to prevent cold boot attacks?

2016-09-01 Thread johnyjukya

> This is scary:
>
> https://hakshop.myshopify.com/collections/usb-rubber-ducky/products/usb-rubber-ducky-deluxe?variant=353378649

Related, and (disturbingly) informative:

https://github.com/brandonlw/Psychson

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/c2872d8b7c663d10b867f7b43b735ad3.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: epoxy on ram to prevent cold boot attacks?

2016-09-01 Thread johnyjukya

> On Wed, Aug 31, 2016 at 10:05:59PM -, johnyju...@sigaint.org wrote:
>> I'm curious to some mentions-in-passing about Andrew's hate for USB
>> keyboards.  USB-anything isn't good for security, but what in particular
>> so much worse about USB?  Both USB and PS/2 can keylog, or play
>> predefined
>> scripts to try and exploit the system.  One of the dangers of rogue USB
>> devices is that they can suddenly pretend to be a keyboard (which Linux
>> will accept without confirmation, something I'm not thrilled about).
>
> It is mostly not about the keyboard itself, but other devices on the
> same bus. Anything that can control the bus to which keyboard is
> connected, can control the keyboard / pretend to be a keyboard.

I can understand pretending to be the keyboard, but seeing the keyboard's
traffic, controlling the keyboard is really possible from another device
on the bus?  If so, what a fatal flaw in the design of USB.

> In addition, USB is quite complex and as with all complex code there are
> bugs.

I hear you.  I've bit-banged PS/2 protocols myself, and it's not that
hard.  VUSB has achieved the same with USB, but its a *huge* project (and
can barely achieve HID use).

> If you (or someone else) plug a malicious USB device that will exploit
> some bug in one of million USB device drivers, it can do whatever it
> want with the other USB devices on the same bus. And if that USB
> controller live in dom0, it's game over even without injecting malicious
> keystrokes.

Yikes.  USB really needs to get out of dom0 all together, just as
networking has.  I'd also like to see the sound card in its own VM.  With
Pulse's networkability, it shouldn't be that hard.  One could use the
Pulse network ability instead of virtualization of the sound card.

That might also be the best route to getting sound working in Windows
HVM's, although some work is needed on Windows Pulse clients:

https://freedesktop.org/wiki/Software/PulseAudio/FAQ/#index15h3

When I assign a single USB drive to a VM, is dom0 still really in charge
of the USB bus, and just shuffling stuff back and forth to the VM(s)?

> PS/2 is much better, because you can't connect anything else than input
> devices there, and attack surface is much smaller.

Agreed.  It's all I use for mouse/keyboard.

> Some mitigation would be to use separate USB controller for USB
> keyboard/mouse and have it in dedicated VM (separate form all-purposes
> sys-usb).

Another possibility is some built-in Qubes support for building udev rules
(similar to how the firewall makes iptables rules), or perhaps adding
USBGuard to dom0 (or any USB Qube).  A good comparison of the two options
is here:

https://dkopecek.github.io/usbguard/blog/2015/USBGuard-vs-UDev

Seems like a great idea for Qubes in mitigating USB dangers, since in
practice it is so hard to avoid USB all together.  And that problem is
only getting worse.

One dodgy USB device from the dollar store, and your pwned.  Or an
NSA/syndicate-implanted commercial hard drive with alternate identities
lurking.

I'm always tempted, but ultimately avoid, unusually low-priced USB
devices, lol.

I've been passed USB keys from some rather suspect individuals in the
past; I've quarantined them, and should (carefully, on a non-critical
system) take a more detailed peek someday, lol.

Some discussions online argue that USB white-listing isn't helpful, since
a BADUSB could just emulate your actual keyboard.  Well, it would have to
know the device ID's first.

Even if it gloms my keyboard's USB vendor/device ID's and tires to imitate
it, the system could spot the fact that there's a second similar device
but on another USB port, no?  Or is USB so stupid that the system couldn't
differentiate the two (or the fact that there is two)?

While the USBGuard project looks admirable, I'm guessing the more
attractive option would be for Qubes to add support for creating custom
udev whitelists, as the less software in dom0, the better.

Although USBGuard isn't a huge project (the tarball is <1M) and if you're
going to otherwise have to write the code yourself, it might be better to
just audit USBGuard and include it in some form.  If someone else has
already put in much of the required thought and effort . . .

Even a pop-up notification when a new HID device is added could be useful.
 The fact that keyboard/mice are silently accepted is a bit scary.  I
might add some scripts to watch dmesg for such events, and more actively
warn me.

All just food for thought.

I'll be adding udev whitelist rules to dom0 very shortly.

Another idea I saw was restricting HID devices to *one* keyboard and *one*
mouse, so if a BADUSB comes along trying to be another keyboard, it
doesn't work.  Or even better, alarm bells go off.

I was thinking earlier that some form of a "USB Firewall" hardware device
might be cool to create; one that goes into each USB port in between each
device and the PC, and only passes a specific device, or only a HID device
(and doesn't

Re: [qubes-users] Qubes 3.2 rc3 has been released!

2016-08-31 Thread johnyjukya

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Details here:
> https://www.qubes-os.org/news/2016/08/31/qubes-OS-3-2-rc3-has-been-released/
>
> As usual, you can download new image from:
> https://www.qubes-os.org/downloads/
>
> Users of R3.2 rc1 or rc2 can just install updates, no need for full
> reinstall.
> For older releases check above page for upgrade instructions.

Congrats on another milestone.

For those of us tracking testing, we're automatically swept along with our
updates (just as users of rc1/rc2), correct?

Sorry if that's a stupid question.

JJ

>
> - --
> 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
>
> iQEcBAEBCAAGBQJXxzpPAAoJENuP0xzK19cszD4H/j4jPpG9aEaa6xx+FoDN+7cI
> 4P3PU3GtvDO+k97O9at/4Gsq5ziUgyFcJxD+3KId7gTsDML5w7ge93Zyvc5lRms/
> cu+skFnrLpeOKSv+aeRTzeeZQ6EbEePLqXLpgMcLIN93hKiPqN6UPPUJ0ya5Ijhg
> qol6fbEwLYdyazq378QcEmgqAE9C3iEmVpthLl3qw+vITJHIutHtxJgzV7kYR6q+
> euF0dVjijY/qeu0R/Jds6WYlB9WCdzuDRfRGO5BYEc3PtjvrCLW0g02SGyplQwDk
> nFqnrB69czNPMgs6Gsb5arIKco4tm6a9VOUyT+XCgPX5Vbw+4FSH7pw7EsRK4bk=
> =Uo8f
> -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/20160831201304.GH9166%40mail-itl.
> For more options, visit https://groups.google.com/d/optout.
>


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

[qubes-users] Adding individual partitions from Manager

2016-08-31 Thread johnyjukya

While qvm-block is a wonderfully handy tool for adding individual
partitions to a VM, the Qubes VM Manager can only add entire devices from
its GUI.

I think that it's a pretty strong argument Qubes' spirit of "protecting
the user from him/herself" to make sure this feature (maybe in a nested
menu or something) is added at some point.

Keeping a VM from pooching a partition table and a whole drive, and at the
very worst messing with a single partition, is a pretty significant
protection of the user from himself, as well as prevention of escalation
of any VM compromise.

If a compromised VM can tamper with the partition table (to hide away its
payload, trash partitions), or worse, modify the boot sector of a drive,
it's a *way* worse end result that's possible that messing with an
individual partition. (Although they have boot sectors of their own.)

e.g. on a typical Linux drive, mounting /dev/sdx5 with the data to play
around with, while preventing /dev/sdx1 (the /boot partition) or /dev/sdx
(the boot sector/paritition) from being corrupted is a major win for
security (and stupidity) in my books.

I know 4.0 is going to rework (deconstruct?) this stuff a lot, but it'd be
nice to make sure some equivalent feature is in 4.0, in not sooner.

Also, is there a limit to the # of devices you can add to a VM? I seemed
to hit the wall at /dev/xvdl, which the Qubes VM Manager and qvm-block
seemed to think had been assigned to my VM, but the VM never saw it, and
there was some strange error in dmesg. (I neglected to save it, sorry.)

Granted, I was doing way more in that one VM that I should have been
(things just got out of hand, lol) and I restarted things and split up the
tasks, and all is well. Just curious if there is a hard limit. 3 is a
fairly low limit for devices (xvdi/xvdj/xvdk), although there were a lot
of partitions about (one had 7 partitions, another had 5).

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/d0c8e8cd831a1dc106bc771febeea5a5.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] qvm-run only available from dom0?

2016-08-31 Thread johnyjukya

> On 2016-08-30 01:16, johnyju...@sigaint.org wrote:
>> Say someone compromises the dom0 encrypted drive password, and
>> then goes shuffling through the private.img file of the AppVM's to
>> get at Firefox's passwords...?  The VM itself wouldn't have to be
>> running corrupt code for that, and keeping the passwords out of
>> Firefox prevents that attack.
>>
>> (Firefox's master password could also help prevent such attack, I
>> guess. Is strong crypto used for that?  It's still a single point
>> of failure, but so is the keepass master password.  At least with
>> keyfiles and physically taking the device with me, that keepass
>> single point of failure is mitigated.)
>>
>
> Qubes is designed with the assumption that if dom0 is compromised, the
> whole system is compromised. So, from a "standard" Qubes perspective,
> it doesn't really make sense to talk about protecting Firefox
> passwords when dom0 is assumed to be compromised. If your threat model
> differs significantly from this assumption, then you may need to
> specify it in more detail.

Understood.  I think most of my security violations in the past were done
remotely, and with dom0 having no networking, that risk is quite low. 
There have been occasions where I suspected physical access and a
keylogger/camera, however.

Notwithstanding "dom0 is compromised and you're screwed," there is one
threat model where Firefox passwords are less safe, possibly:

With a hardware keylogger or an over-the-shoulder-camera, one can glom the
root disk password (and any Firefox master password).  Then when you're
out (or via a network card management mode, BIOS trojan, whatever) get
into the system, go through the .img files to find the Firefox passwords. 
All of your online passwords are revealed at that point.

If the passwords only existed in keepass on a removable USB drive, then
they're safely with you.  Even if that keylogger grabbed your keepass
password, it's no good to any attacker.  And the passwords have never been
typed, so any keylogger/camera doesn't have them.

Yes, an attacker who gets into the system could at that point plant
trojans, but if you have in place other intrusion detection mechanisms
(not necessarily just on the computer) you can be aware of that fact, and
redo the system from a backup.  Your computer may be toast, but your email
and online world is still safe.

I guess if you never typed your Firefox master password, but used keepass
for it, too, and assuming Firefox's password storage is strongly
encrypted, then your passwords are still pretty safe in case of a dom0
violation.  Whenever you start stacking "if's" like that, though, I start
feeling less secure. :)

I do know the passwords can't be stolen if they're not on the system and
have never been typed, short of the system already having been
compromised.  I don't know enough about Firefox's master password
encryption to trust it 100%.  Faulty assumptions have cost me dearly in
the past, so I try to make as few as possible these days.

> P.S. - Please keep the list CCed (unless there's a special need for
> privacy, in which case, use PGP).

I definitely will share the results with the group.  There's won't be
anything in the setup whose revelation would reduce my own security.  :) 
But I appreciate the sensitivity.

> I've noticed that you keep CCing
> "qubes-users@goog" instead of "qubes-users@googlegroups.com".

Apologies.  I'll be more careful cleaning up the To/Cc on mailing list
replies in the future.  sigaint was truncating the field, and I neglected
to notice (until the bounce).

Hey, at least I'm not still top posting.  :)

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/31e6bb44f35bf1ca07a10ddc3c8bb34f.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: OSX

> Hey, does anyone have any luck with getting any form of OSX to fire up
> under Qubes?
>
> After several other failures, I was able to get some iPC ISO build to get
> to a certain point in an HVM, but the mouse didn't work, so I couldn't do
> much, and I couldn't figure out how to get it to any kind of command line
> (single user or otherwise).
>
> Not looking for the full OSX experience, just want to fsck_hfs some legacy
> drives that are too cranky for Linux.  Get a successful fsck done, and
> turn off Journaling so Linux is a bit friendlier with them, until I can
> copy/retire them.
>
> Anyone?

I was able to get what I needed done with a single-user boot of an osx86
build.  I might make it a bit of a fun side-project to play with osx86
under Qubes, though, and will obviously report back here any results.

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/736822dbddcf9d60992435684c1dd153.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes VM Manager Suggestions

> But I'll Joanna's page a more detailed read when I'm a bit more refreshed.

Sorry, not just "Joanna's" page; on a quick scan, I see you contributed to
it significantly as well.

I very much look forward to giving it a proper read and review tomorrow.

Cheers, and thanks, Andrew.  :)

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/ff7eefd239a9541aaed1d8a4be7b927e.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes VM Manager Suggestions


> Thanks for the suggestions. Our goal for Qubes 4.0 is to "decmopose"
> the current Qubes Manager by integrating its functions more seamlessly
> into the desktop environment:
>
> https://github.com/QubesOS/qubes-issues/issues/2132
>
> We hope that this approach will take care of the kinds of issues that
> you and others have pointed out regarding the current Qubes Manager.

Hm.  That's interesting.

I'm not 100% sure I comprehend what "decomposition" means here.

I'm not sure splitting stuff out into different parts of the window
manager makes things less confusing, or more confusing.  And potentially
harder to maintain.

I hate trying to hunt around and find things when they could all be in one
place.  In the past when I've seen stuff like that, it means a lot more
work finding stuff.

I like what Qubes does, and I think the Qubes VM Manager sums it the state
of things pretty nicely, currently.  I really don't have a problem with it
and the way it's tied to main Qubes menu.

But I'll Joanna's page a more detailed read when I'm a bit more refreshed.

Thanks.  :)

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/441974ba840cb5033821e153a452e3ea.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Security Best Practice: Cache web passwords in custom VM's or not?

> On Saturday, August 27, 2016 at 1:50:22 PM UTC-7, johny...@sigaint.org
> wrote:
>> BTW, keepassx rocks.  I'm working on some scripts to make it a little
>> less
>> painful with all the Ctrl-Alt-C and Ctrl-Alt-V'ing (which also conflicts
>> with the standard konsole paste shortcuts).
>
> I have no problem with the special cut/paste. Doesn't mean I don't screw
> it up on occasion, but I do like the assurance of having to do the step
>
> Actually you betray yourself with the correct solution above;

Speaking of "betraying yourself," that's why I am working on a few scripts.

More than once, I've thought I've copied they URL (from sigaint, for
example) and gone to paste it, but I copied/pasted the password instead
into the URL bar.  D'oh!  Even if I didn't load the page, with SIGINT
stuff, I don't like having my password show up on the screen.

Some scripts to let keepassx in a non-network VM interact with a networked
VM's browser could avoid such betraying-yourself screwups.

A few Qubes features are described as not protecting you from others, but
protecting you from yourself.  This falls into that category, IMO.

> the Qubes
> shortcut to copy/paste between VM's is Ctrl-Shift-C/V which conflicts. I,
> like you, map that to Ctrl-Alt-C/V so no conflict. I've wondered why that
> isn't the default since the other is such an obvious conflict.

Agreed.  It's way too obvious a conflict.  There's just not enough key
combos on the damn keyboard it seems sometimes.  :)

>> Using keepassx on Tails is so much more streamlined, without the extra
>> level of copying/pasting.  It'd almost be nice if there were some
>> explicit
>> dom0 support for it somehow.
>
> Yeah but Tails suffers from the same thing other OS's do which is one big
> system. So if it was theoretically compromised your streamlined copy/paste
> is exactly what you don't want.

I'm a bit torn on that issue.  Calling it "one big system" when Qubes is
arguably more complex, I'm not sure is correct.  I guess it depends upon
your perceived threats.  There have been times when things got "weird" on
Qubes, and retreating to a Tails DVD-rom felt safer.  But the Xen-on-top
(with IOMMU protection against DMA attacks, etc.) ultimately should be
safer.  So confusing at times.

> Nothing you don't know, but I don't want the inter-VM copy/paste to change
> a bit. It's a small burden for a huge benefit. It also has an additional
> benefit of each VM having it's own Paste buffer, which ends up being very
> convenient.

I hear ya.  Right now, I *trust* the inter-VM copy/paste mechanism.  I
don't want features introduced that make it more complex/less trustworthy.
 And I think the tools are there with qrexec and the permissions system
implemented to do what I want it to do, without changing the core.  So
yeah.  :)  If it's working, don't break it.

>> Agreed.  I keep my keepass database on one removable device, with a
>> keyfile on a separate removable device plus a password.  Some cowardly
>> creep/crook wants to tamper with my system while I'm out, they're not
>> going to get very far.
>
> I'd argue that your actually less secure with that scheme. Johanna made
> some comments to that effect, what you are doing is a kind of air-gapping,
> but you have a large attack surface through USB.

Trust me, every time I hear those three letters, U.S.B., I think "security
compromise."  Why they ever let programmable firmware and stuff into the
mix totally escapes me.

If WW3 every happens, I swear it will be triggered by some USB security
screwup.  :)

I actually load most of my keys off of 3.5" diskettes.  :)  Sometimes
retro feels more secure, less hackable.

> If an Evil Maid controls
> your system it does you no good to bring in your passwords on a USB.

No TPM here, just BIOS, so I don't think anti-evil-maid is something that
applies to me.  I could be wrong, need to research it more personally.

I have a couple of personal anti-tampering approaches I use myself in lieu
of that, which I might suggest as additions to Qubes at some point; but I
won't talk about them just yet.

> So,
> if you're really concerned with that you should be implementing
> Anti-Evil-Maid on your system as the only defense - not keeping passwords
> separate.

I'll read up on that more.

Can't afford a maid, but I think there are other evil actors about.  :)

>> Since moving to that approach, I've noticed a lot more "noise" from the
>> ones I suspect of being involved in my harassment.  Ironically, probably
>> a
>> good sign.
>
> OH, OK then you have a situation with a probably not too computer
> sophisticated opponent. Never mind then.

The biggest mistake I've made (repeatedly) is underestimating the
opponent.  I have been totally naive throughout a lot of the grief.

(In reality, I think there's a mix: one or more sophisticated opponents;
and mostly likely expensive hired help.  And one or more obviously
not-to-sophisticated actors, that make obvious screw-ups now and then. 
Which makes things all

[qubes-users] Qubes VM Manager Suggestions

These are fairly minor cosmetic issues, and if I ever get some of my
current struggles under control, I'll submit patches instead of
suggestions. :)

I think the Qubes folks work on the VM Manager (and install process, which
is amazing) has made major strides in making the system more accessible to
all. Which is, in turn, key to making a secure work/personal computing
environment available to the oppressed, or those who are simply security
conscious.

In that spirit, here are a few minor things I'd like to see tweaked in the
VM Manager:

1) Column resizing. I like to toss my windows into one of four
"quadrants" on the screen. xfce shortcuts make that pretty easy to do.
But it'd be nice to see the whole VM Manager, not truncated, with the
fields I want to see, each given the column size they deserve.

2) Current CPU % takes up wa to much space for a simple two-digti
number. You don't need a bar graph to go along with it.

3) The CPU graph itself could easily add the current CPU % to it
(centered, perhaps), without compromising the display.

4) Custom ordering. I like to stack my VM's in the order I want them.
(Maybe even nested. :P) Currently, I use my own coloring scheme to
achieve that, and sort by color. But it'd be nice if there were better
support for arranging the multitud of VM's.

(Just FYI, if you sort by color, the order is
red-orange-yellow-green-gray-blue-purple-black. I usually sort by color,
and use red for system stuff; orange for dicey stuff with no firewall
protection; green for stuff that's nicely protected by Tor or a VPN; blue
for stuff that has *no* network and is just a lot safer; black for
templates; grey/purple for VM's I either no longer trust or no longer
use).

5) It'd also be nice to be able to hide certain VM's (or certain colors,
perhaps) no longer of interest, but that you want to keep around for
reference. (Like the "internal" flag, but separate). The color mechanism
is a great cue to the level of security you've flagged certain VM's to be,
so that might be a good way to hide/show certain classes of VM's.

6) It'd be handy to have the application list for a VM (as you see on the
main Qubes menu) be accessible when you right-click on a VM. Right-click
on WorkVM, choose Firefox, kinda thing. (There's a "run command", but
having the configured app list show up would be a lot handier.)

7) Are there any thoughts to support "hibernation" in VM's? (Not just a
pause, but something that could survive a reboot?) "xl save/restore" does
it, and I've had a bit of success with that, but I think it freaked out
the VM Manager on a couple of occasions. :P

Especially when memory is tight, it'd be nice to be able to hibernate a
less-critical VM or two, and fire up something more important.

I think I've read that disposable VM's use that save/restore feature,
although not having explored that feature thoroughly yet (and that fact it
takes up precious memory), I have that disabled for now.

I think that's it for now. Sorry for the brain dump. :)

Cheers.

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

[qubes-users] OSX

Hey, does anyone have any luck with getting any form of OSX to fire up
under Qubes?

After several other failures, I was able to get some iPC ISO build to get
to a certain point in an HVM, but the mouse didn't work, so I couldn't do
much, and I couldn't figure out how to get it to any kind of command line
(single user or otherwise).

Not looking for the full OSX experience, just want to fsck_hfs some legacy
drives that are too cranky for Linux.  Get a successful fsck done, and
turn off Journaling so Linux is a bit friendlier with them, until I can
copy/retire them.

Anyone?

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/9a1f0c7e6499db733ffcb5cbb5641e33.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Security Best Practice: Cache web passwords in custom VM's or not?

> On 08/27/2016 07:36 PM, Cube wrote:
>> On Saturday, August 27, 2016 at 9:31:31 AM UTC-7, Alex wrote:
>>> On 08/27/2016 05:59 PM, Cube wrote: For specific services (say, the
>>> mentioned Amazon) I keep a keepassx database on the specific AppVM
>>> in which the service is expected to be used - the Amazon account I
>>> use to buy work stuff is saved in the keepassx database in the Work
>>> appVM, the personal one is saved in the personal appVM.

BTW, keepassx rocks.  I'm working on some scripts to make it a little less
painful with all the Ctrl-Alt-C and Ctrl-Alt-V'ing (which also conflicts
with the standard konsole paste shortcuts).

Using keepassx on Tails is so much more streamlined, without the extra
level of copying/pasting.  It'd almost be nice if there were some explicit
dom0 support for it somehow.

While it'd be more convenient to put keepassx in the same VM as your main
browser, keeping keepassx in a network-less vm makes so much more sense.

(Some day, true feature-by-feature access isolation for apps will be
possible, kind of like what Android "promised."  Cough, cough...  Stupid
Google.  But for now, the VM isolation is the way to go.)

And to digress further, does anyone have opinions on Keepass2?  It looks
"shinier," but I'm not sure needing to haul in all of Mono *adds* to one's
peace of mind...?

> I see, this may be a personal preference. Me being obsessed with
> architectural research, I like to explain this with "isolation". Actual
> benefits may be that I can share the personal keepassx database with
> another device with simple tools, say - the laptop I use to only watch
> cat videos on youtube when I'm done at the workstation.

You have a dedicated cat-video laptop, too?  Awesome.  :)

One thing in my paranoia-induced-retreat-to-Fedora made me notice, is how
conservative Fedora is with regards to playing videos and such.

I realize some of the factors are licensing issues, but having to go to a
non-Fedora-approved, non-Fedora-Reviewed, repository (Fusion) to simply
view mp4 videos with mp3 audio didn't sit well with me.

And half the "howto's" about adding that repository involved a
--nogpgcheck flag, which isn't cool with me, either.  :)  I guess there
are signing keys around, and people say "yeah, sure, you can trust
rpmfusion, it's been around forever" but it just doesn't seem as provably
trustworthy as the core repo.  It'd be a great vector for attack.

(Which gets one looking at how debian can play mp4/mp3 videos/audio by
default, by trusting nonfree/contrib repos by default...  H.)

I've settled on the compromise of having all those
non-free/contrib/non-reviewed stuff in AppVM's with no network
connectivity.  Any exploits can have their fun nuking my downloaded cat
videos.

For work + personal browson and email, I stick to core Fedora AppVM's with
no third party non-certified add-ons.  Feels right.  :)

>>> And there are some types of password I keep in a
>>> non-internet-connected AppVM, together with some OTP generator
>>> scripts.

I'd really like to see some default OTP stuff for the major distros and
Qubes.  I'll probably hook in otpw or oath myself for fun, but it'd be
nice to see some of these more powerful authentication systems supported
"out of the box."

>>> They are meant to be used for targets that may be
>>> sensitive to large scale attacks

These days, I think anyone is subject to attacks on a mass scale, for
anyone who is willing to pay to get access to the hacks.  Many a time I've
been led to believe that things are simply hacked by default, and up for
sale if the price is right, to anyone with enough money or craziness to
invest in it.

Just my cynical point of view.  :)

>>>  (say, home banking credentials,
>>> amazon AWS otp generators, etc.) where attackers may have the
>>> financial power to aggressively attack the target AppVM - so my
>>> line of defense here is to be sure not to have the sensitive
>>> information available on the filesystem at all.

Agreed.  I keep my keepass database on one removable device, with a
keyfile on a separate removable device plus a password.  Some cowardly
creep/crook wants to tamper with my system while I'm out, they're not
going to get very far.

Since moving to that approach, I've noticed a lot more "noise" from the
ones I suspect of being involved in my harassment.  Ironically, probably a
good sign.

(It's funny when you change a password on a certain site, and suddenly
several people contact you that you haven't heard from in ages. 
Similarly, after cleanly changing a password without any errors, and then
seeing several "sorry you're having trouble logging into your account"
messages is another pretty good indicator that someone's actively messing
with you.)

>> Well they're in the AppVM though so are on the filesystem, aren't
>> they? What you buy is network isolation, effectively air gapping, but
>> even better.
> It depends on the point of view; yes, they are on the same dom0
> filesystem, but they are on

Re: [qubes-users] Qubes VM compromised? - Follow up

>> Whether using an "isolating proxy" (multiple machines) or not, using a
>> white-listing proxy like Corridor can help ensure all of your traffic
>> passes through Tor (Entry Guard, at least).
>>
>
> That's right. Also, using Firefox with those extensions is *not* the same
> as
> using Tor Browser:

Understood.  I do take a few more precautions (with iptables, bridges,
etc.) but Torbrowser certainly does take care of a lot of important things
for you.

> https://www.torproject.org/projects/torbrowser/design/

Wow, that's a great resource, thanks!

I think I still prefer to "roll my own" versus using TBB.  (And that link
is great for tips on doing that.)

There are four (probably reasonable and legitimate) things about TBB (and
tails) that are red flags to my overly-paranoid mind:

1) Not a problem in Tails (being a bit "read-only), but the normal
Torbrowser Bundle is very stubborn about doing an update check every time
it starts.  I understand the reasoning behind it, keeping up with 0days as
they're discovered, and at least one exploit in the past would have been
avoided by anybody who stayed updated.

Sure, notify me, but forcing that "phone home" on every start is a bit too
much like MS-style tracking to me.

I could be wrong (I often am), but even turning off the update check in
settings didn't seem to work for me.  Although I might have screwed up
somehow or it might have been an artifact of non-persistence in an AppVM.
Having that update check/download on by default, I don't like.

Finding the actual tor browser binary to launch is a major pain.  It
almost seems intentionally hidden.  :)

2) JavaScript on by default.  I understand the convenience for the general
public, but TBB isn't really for the general public but the
security-conscious.  And the security-conscious shouldn't turn on JS
unless necessary.  (And with Qubes, one can keep their JS-dependant sites
to a separate VM, whoohoo!)

In Tails, having JS on plus automatically loading Tails home page (which
could be subverted by someone with CA ability) is a bit of a risk, IMO.
To avoid having a JS-enabled load of the Tails home page, you have to
start it without networking, disable things, then enable networking.
Blah.

3) Default search engine set to Disconnect.me.  And disconnect.me seems to
do nothing but redirect your search to duckduckgo.  Why are they even in
the loop then?  Supposedly they financially support the tor project.  So a
company founded by a former NSA person paid money to be able to capture
all the searches that are eventually done by DDG in TBB/Tails.  Oky...

Whenever I do launch Torbrowser, the first two things I do is disable
global javascript, and change the default search provider.

4) It's not really fair to include this one, as I have nothing to back it
up with, but I remember something in the past that made me a bit uneasy
about Torbutton.  I'll follow up if I can remember/find my concern.

Interested in hearing others opinions on those points.

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/d21ff94ceb2ed97c456bc3e127f1318a.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes VM compromised? - Follow up

> Am 25.08.2016 um 21:33 schrieb johnyju...@sigaint.org:
>
>> While it's a bit slower, I prefer booting from DVD, a read-only medium.
>
> There are verifyably hardware-controlled (physical switch) unwritable
> USB storage devices. A bit expensive but you can get one.

I might look into that, it would be a lot more convenient (and faster)
than DVD.

In case anyone's not aware, the slider on "secure" digital media cards is
just an advisory for the software to not write to the SD card, and not
enforced by hardware, so very easy for malware to bypass.

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/5d85ce7a951b0b438891c9f46aaa3f5b.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] qvm-block by UUID?

2016-08-25 Thread johnyjukya

Most standard Linux utilities that refer to block devices, allow you to
specify by uuid as well (mount, cryptsetup are two examples).

The documentation for qvm-block is sparse, but probably because it's a
striaght-forward utility.

There's no support in qvm-block to assign a device to a VM by UUID, is there?

Could be handy for some of the automation I'd like to put in place on
firing up the system.

One can always lsblk|grep|sed|cut|whatever in a sh script, and then use
the resulting block device for qvm-block, but it'd be a lot cleaner and
less error-prone if one could say

   "qvm-block -a Florp UUID=kasdjflaksjdfaklsdf"
or "qvm-block -a FLorp --uid asdfkasjdlfkajsd"

Just a suggestion.  (And for any other qvm-* that refer to block devices,
perhaps.)

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/2554d22727f99f1b2ce2d7444cc2b901.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes VM compromised?

2016-08-25 Thread johnyjukya

> On 08/23/2016 07:25 PM, Chris Laprise wrote:
>> What threat model does this fit? If a skilled attacker tricks you into
>> thinking you created an account at sigaint, but you later cannot use
>> it... what is the advantage of that? The possible gain seems to be
>> little or nothing.
>
> Well, (s)he has changed all its passwords. Tricking someone into
> changing all passwords has been done before.

Indeed.  Psyhchological harassment can often by the goal, not necessarily
theft of credentials.  (There's nothing left to take, in my case, lol.)

And when I said I had a psycho ex, I truly meant that she has truly shown
all the signs of being a textbook psychopath or sociopath, and invested
heavily in having me harassed online.  (I don't think she's a genius
hacker herself, lol.)

When you're dealing with a psycho/socio-path, logical and rationality
doesn't always factor into things, which can be hard to get your head
around at times.  Sheer destruction can be the goal (in her case, a stated
goal).

That being said, I can believe that the recent password weirdness was
probably PayPal anti-fraud mechanisms being careful (or confused) with
Tor.  (I'd say it could also be someone trying to grab all credentials
from a dodgy exit node, but the fact I saw the SSL lock/certificate and
the real PayPal URL makes me doubtful, unless the browser was compromised
and lying.)

Part of the leverage of psychological harassment is that you start seeing
unrelated screwups as part of the harassment.  It's good to be careful to
try and separate the two.  Not always easy.

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/72e45af0b5117271fbbff0ae7e40d5c8.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes VM compromised? - Follow up

2016-08-25 Thread johnyjukya

> I am too paranoid for using tails other than the reccomended method (two
> usb drives updating each other - I have two pairs of three).

No aware of the two drive method.  Is that just updating to the next
version from the previous version, onto another USB drive?

While it's a bit slower, I prefer booting from DVD, a read-only medium. 
(A bit of a pain to update, having to boot to a USB stick to write the
newer version, but it has to be done infrequently.)  There's peace of mind
in a true read-only medium, that you keep with you.

> I just use Whonix within Qubes and I like it. I'm glad it comes out of
> the box since 3.1

I've retreated to only using Fedora.  Setting up Tor and Firefox (with
noscript, ssl observatory, adblocker) to use it as a proxy is essentially
the same effect as Whonix (or tbb).  Even if tor/firefox are on the same
vm rather than separated, you're behind sys-net and sys-firewall, so your
real world address isn't going to leak.  Another two VM's on top of that
(whonix-gw and whonix-ws) is a bit of overkill IMO, and a memory pig.

(I've wondered if it might be more natural to have tor running in
sys-firewall; it is kind of a fire-wall-ish thing.  But having the
firewall separate is a nice additional barrier in case of compromise.)

> Also, I would never use tor for banking, unless the banking wouldn't
> involve my real world name - understand that one how you want.

Yeah, exit nodes are too scary.  Okay to keep reduce cyberstalkers, but
for financial transactions, it seems a bit risky unless you got a solid
HTTPS connection (and trust the govt and crooks not to abuse CA's; I guess
that's not something seen in the wild much.  For a high value target,
maybe; for someone being harassed by an ex, less likely.)

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/9a51f2eb8dd6a8744cf6411ed09cae47.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes VM compromised? - Follow up

2016-08-24 Thread johnyjukya

> My guess is that Paypal is giving you a hard time just because of the
> tor exits you use to interact with their website.

Could be.  At first I didn't see how/why, but I guess refusing a legit
password from what they judge as a dodgy IP address is a possibility.

(Although accepting the password change on a Tor exit, and then refusing
that on a non-Tor https: connection was rather weird.  Would they silently
fail a password change?  Oh well, I won't stress over it, but will keep a
close eye on things, for sure.  Ever vigilant...)

> So it seems to me all that you are saying is really related to
> using tor via sys-whonix or manually trough the traditional means.

Yes.  I guess it really isn't necessarily anything to do with Qubes,
unless there is some dom0 compromise somewhere.  That's probably pretty
unlikely, and I've only seen weirdness in Tor-based VM's, so I won't give
up on Qubes.

I've been using Tails for awhile, and never had strangeness like this; but
the new factors aren't necessarily Qubes, but the TorBrowser bundle (not
the Tails-reviewed/tested one) and Whonix.

Worst case, I could (and have successfully) just run Tails inside Qubes,
and it should be no worse (safer, actually) than Tails standalone, for
banking or email.  (I was reading that the IOMMU protection prevents DMA
attacks, which is sweet.)

> The sigaint episode is easily explained through the e-mail you provided.

Certainly.

> But yes, the Paranoia is our shepherd and nothing shall lack.
> Paranoia is what justifies the development of a operational system
> of this nature, it shall never die.

Beautiful.  I think I'll put that on a plaque for my wall.

Respect for paranoia, awesome.  I guess a mailing list for a
security-focused operating system is a bit more sympathetic to my concerns
than the general public.  Feels like home, man.  :)

If I tell family and friends about the sad state of computer/network
security these days, the hacks I've seen, and the Snowden stuff, they
think I'm bonkers.

Now why I didn't receive your response (posted a few hours ago) via email
but only see it on the Google Group's page. . .  I'll just assume SIGAINT
is still dealing with some capacity issues.  :)

(I wonder if their surge in signups is possibly a denial of service. 
They've been targeted with at least one significant exit-node attack in
the past. 
https://lists.torproject.org/pipermail/tor-talk/2015-April/037549.html )

Thanks for your reply.

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/871a2a68cefc1b3ebf7af8df53bc5ffb.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] timesync on by default in debian-8 template (3.2-testing)

2016-08-24 Thread johnyjukya

I would say so, yes.

I think exim, cups, and possibly some gvfs-samba thing were also all
enabled on both the Fedora and debian-8 templates.

I personally don't like having those on by default in all the VMs,
listening on ports and poking around the network or Internet, as they
really should only be installed or enabled when you need them.

The samba browser thing was making name resolution requests to some
Internet server which (from some brief googling) appeared to owned by
Microsoft.  Not particularly cool.  :)

(It's possible the Samba thing was dragged in by some other packages I
installed, although I'm fairly sure exim/cups were on in the default
fedora/debian templates.)

I know the firewall should prevent incoming connections to any listening
daemons (exim/cups/samba), but they're free to call out, as the samba
browser was doing.  (And I hadn't done anything referring to a smb address
on the system.)  Even with the firewall, why increase any attack surface
on unused services.

JJ

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 2016-08-22 08:37, johnyju...@sigaint.org wrote:
>> I notice in the debian-8 template that network time synchronization
>> seems
>> to be on by default in systemd.
>>
>> systemd-timesyncd.service  loaded active running   Network Time
>> Synchronization time-sync.target   loaded active active
>> System
>> Time Synchronized
>>
>> It's disabled in fedora-23 by default, and rightly so, as I believe it's
>> unnecessary given the dom0 driven /etc/qubes-rpc/qubes.SetDateTime
>> mechanism, and it's kind of "leaky" sending requests unnecessarily to
>> the
>> Internet.
>>
>> Paranoidly yours,
>>
>> JJ
>>
>
> Would that fall under this issue?
>
> https://github.com/QubesOS/qubes-issues/issues/1928
>
> - --
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> -BEGIN PGP SIGNATURE-
>
> iQIcBAEBCgAGBQJXvg6zAAoJENtN07w5UDAwkZgP/2P/jWqOseHVrJ+X0ogVa/U4
> lFTIG5AzBt9oLx7BaBy0arsKHRyHGkWGbW1fVzDnCAzkCDKrpq3eNQX6FesMmn8e
> IIPyg7UqTnC29PZvKeZd/DlRGBM5q9jj6HMEcjTDWuc3jD1fKTe2GiDc7Cj4U6Bf
> /aIKtgvdZAZAh0OBINcAezmeOsm6Lc1k0HEPzhdF4iUQUUNgmU+RTdMarZxSReR6
> KxEQmxki568ccbxH0oUtifX8so8+1hAQCnB8yzhw6U/CjDl0TVWtpuHZ/P+hMARO
> EHu7vJDWCbgSr9hf0w4sfZA5LVXaVySbFfC2s9PwIFchmJnD/kg11o9jX+aa2ZuU
> qERxpTihpa2fqWEZ1fk4bQttgbcIzgAoAAVq6rcDOVuGFo+aVMgu+TmJSCU4ybs5
> +3TDvAQJez2z8dvQYvn6kgjQ5MP0PfMZALZSGAdVaTy2B0dNFsnhmiVnzLNLeJKo
> iI/k4EB8qxKcYfOR4wqS0OW9q+stAX8Dq3JO2uWZTnz5NVUacreW6h48WBM/7KCd
> VOtD+3DG/n1n4LNcBqYsZKWVd7/RqRv6+p4z6sICAanY09m87qpnRkeb8wQ7BTWw
> qOFhRZ/cZgjJnaw/qukt9kmU9BZdiAsENDiroCdHGDYJbEqINfV6dCdxL8UyoA1h
> U+t8DDt9iZrZKWU0tl6/
> =tGyU
> -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/5fe9f924-88e4-1820-ddf3-927095c699ca%40qubes-os.org.
> For more options, visit https://groups.google.com/d/optout.
>


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

Re: [qubes-users] Qubes VM compromised?

>> On 08/23/2016 06:01 PM, johnyju...@sigaint.org wrote:
>>> Wow, what a weird day.
>>>
>>> A rather bizarre story, which is possibly a good example as to how
>>> Qubes
>>> can help protect you from hacking, or at least spot the effects of it.
>>
>> What threat model does this fit? If a skilled attacker tricks you into
>> thinking you created an account at sigaint, but you later cannot use
>> it... what is the advantage of that? The possible gain seems to be
>> little or nothing.

Oh, I should add, that on the dodgy VM, I tried accessing a few different
onion addresses, and they all failed.  But cleartext http sites worked
fine.

Once again, maybe just a technical glitch, but combined with the other
weirdness, one has to wonder, and follow up a bit.

It reminded me of awhile back, when I downloaded from (presumably) the
Apple store, a Tor browser/Onion browser.  In viewing the actual traffic
on the network coming from the iphone, the first few pages it loaded went
over tor, then the rest went cleartext over the Internet.  Innocent
screwup, or malware?

After awhile, one would be a bit stupid not to wonder a bit.

I hope you never have to deal with it.  :)

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/ba6d2d8244e628dcfe81ae0c1f05e805.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Qubes VM compromised?

Wow, what a weird day.

A rather bizarre story, which is possibly a good example as to how Qubes
can help protect you from hacking, or at least spot the effects of it.

I use a sigaint address, because of a psycho ex and her corrupt cop buddies.

Anyhow, I created another sigaint address today, to keep identies
split/anonymous as much as possible, to share with a (supposed :P) friend.

It said it was successfully created, and I logged in to test it. It was
fine.

Went out for a couple of hours (including giving my buddy, ironically also
a police officer, the email address).

When I returned home, I tried logging in again, but from a different VM.
Failed repeatedly. I figured I must have messed up the password. No luck
trying other possibilities.

Eventually, I tried creating the same email address again, and it worked!
WTF?

So I tried logging into the sigaint account for *this* address, that I use
with qubes-users. It also failed repeatedly, until I attempted creating a
new account. That worked!

Went to the other VM, and the other old account was there. Two different
views of sigaint, with different accounts with the same name, from two
different VMs!!!

>From the VM that let me (re)create the two accounts, I attempted to email
sigaint's support to ask if they were having problems, and that email
repeatedly failed. So if there is a shadow sigaint on a hacked VM, I'm
suspecting that one.

Where I was on testing, in case there's a dom0 vulnerability, I've
retreated to another OS for now, and I sent the info to sigaint support
with no problem, and this sigaint account and the other one I created seem
to be as expected.

It's entirely possible that sigaint is having server issues, and different
routes through tor hit different load-sharing servers, and it's all
innocent. But dayum, it seemed odd.

One was a Qubes-Whonix VM, and one was a "torbrowser-launcher" package
from Debian-8 (and qubes 3.2-testing).

The latter (Debian-8/torbrowser-launcher) had JavaScript enabled on some
possibly dodgey sites, which is why it was in its own VM. That separation
may have paid off on not getting my whole system pwned (yet again).

Creating the new sigaint account from that VM was sloppy, but might have
revealed a hack. (Again, if it's not an innocent glitch.)

I'll report back when I hear from sigaint (if I'm talking to the real one!
:) ), in case they just had some temporary service issues or something.
But all signs point to a VM compromise from what I've seen.

Will do a bit of amateur forensics from a safe offline OS tonight to see
if I can spot any weirdness in either of the VM's.

If it was actually compromise of the
Debian-8/3.2-testing/torbrowser-launcher VM, that would mean there's
possibly a 0-day vulnerability in there somewhere (or a boot sector virus,
or a comporomised bios, or . . . :P). I don't think intercepting an
.onion address in the network is possible these days.

If it is a real compromise, it is confirmation that Qubes VM separation is
one of the few hopes for sanity on this crooked thing we call the
Internet.

I think I'll go work in another industry. This one isn't fun any more.

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

Re: [qubes-users] Qubes for running virtual servers

> How does Qubes perform as the host OS in a virtualised server environment?
>
> I'm thinking of a configuration where the host OS is Qubes with VM's
> running for things like a virtualised email server, IDS server, perhaps a
> Tor relay etc. I've used Qubes as a desktop host, I'm just curious about
> whether it's a practical host for virtualised serviers?

I would think it would perform wonderfully as a virtualized server.  Most
commercial places that rent you virtual servers use Xen, and Qubes is
based upon Xen, so . . .

And the separation of server to prevent cross-contamination is a great
feature.

I used a Xen-based virtual server at Rackspace for years, and it performed
wonderfully.

Now, if you have a server that's going to be handling a high level of
traffic, you're going to want some correspondingly powerful hardware and
memory behind it.

But the success of running servers under Xen is a proven thing.

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/d52df9a98a73e0cef0c7fed08e9eabb8.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Memory saving techniques

I know I may be in the minority with an under-powered machine (4G), but I
thought I'd share some tips for getting more room for additional AppVM's
that worked well for me:

I guess I should state that this really would "void your warrantee" and
you shouldn't hassle the Qubes folks with problems you occur in a system
with these changes.  :)  But it lets me do more with Qubes, so I thought
I'd share.

Being tired the "insufficient memory" error when starting an AppVM, I
initially started on an experiment to make sys-net/sys-firewall
"headless," without an X server, using ssh to access these system VM's. 
("systemctl disable qubes-gui-agent.service" to stop the X server from
starting.)

That took a lot of juggling, setting up local ssh config's in
/rw/config/ssh (linked from /etc/ssh), etc., and appropriate templates,
passwords/certificates, iptables for safety, and so on.  Quite a pain to
set up, with potential security risks if not done correctly.

It worked well for sys-firewall, got it working well with 100M, versus the
300M it normally sucks up.

sys-net was a lot crankier, being a lot more "special" to dom0 with a
systemctl startup in dom0, hooks to the network manager in dom0, need to
access the ethernet device, and so forth.  Really quite painful.

In getting this working, I found that /usr/lib/qubes/qrexec-client was my
friend, allowing to run commands in the VM's when ssh wasn't working
properly or whatever.

Which got me to thinking, if my main goal was to stop the GUI/X server,
one could simply do *that* from dom0 via qrexec-client on the existing
net/firewall VM's, without all the ssh configuration hassle, and creating
new net/firewall VM's.

And with VM's having swap space by default, even killing the GUI isn't
really necessary.  Reduce the start/max memory for the VM's should be
enough to keep the useful networking stuff running, while the generally
unused X server being swapped out within the VM.

(Might be a little slower starting up, as things need to swap out, but
once the system settles and the net/firewall VM's just run networking
code, it's just as fast.  It might also reduce the amount of memory
available for buffers/cache in these service VM's, but they're not file
intensive to start with, so that shouldn't be an issue, either.)

Much simpler, doesn't require modifying or creating VM's, and achieves the
goal.

I'm on a smoothly working system now, with sys-net and sys-firewall each
taking up 100M instead of 300M each, and sys-whonix (the gateway) taking
up 220M instead of the normal 600M-ish.

So for my normally way of working, that's 420M used instead of 1200M,
saving 780M (60%!).   That good-chunk-of-a-Gig is enough to fire up
another couple of work AppVM's over what I used to be able to, a
significant productivity boost for me.

At the most simple, it involves setting the start/max memory in sys-net
and sys-firewall to 120M, and restarting, and you're good to go.

Some handy commands (sys-firewall can be substituted for sys-net in any of
the commands of course):

/usr/lib/qubes/qrexec-client -d sys-net 'root:free'

In a standard running VM, checking the among of memory actually "Used", as
a reasonable maximum memory limit for the VM:

You might want add 20M to that value for safety.

/usr/lib/qubes/qrexec-client -d sys-net 'root:ps axl'

To check out what's using real memory, under the RSS (resident set size)
column.

/usr/lib/qubes/qrexec-client -d sys-net 'root:systemctl'

To see what services are running.  Stopping unneeded services is good way
to reduce the memory footprint.

/usr/lib/qubes/qrexec-client -d sys-net 'root:systemctl stop
qubes-gui-agent.service'

Stop the gui/X-server on a running VM.  Note that the green Status button
in Qubes manager will turn yellow because of this, and you won't be able
to run windowed commands in that VM any more.  Replace "stop" with "start"
to get it going again, if you need a Window for some reason.

/usr/lib/qubes/qrexec-client -d sys-net 'root:systemctl disable
qubes-gui-agent.service'

Make that disabling of the GUI persistent across VM restarts.

As mentioned, this might not be necessary/useful since the server should
swap out if not used.

xl mem-set sys-net 120 && xl mem-max sys-net 1200M

Sets current/max memory to a running sys-net to 120M.  I think Qubes
manager might override this at times, so you'll want to change it in the
manager as well as using the xl commands to make it happen immediately.

Important: If you're going to fire up any Konsole/Terminals in
sys-net/sys-firewall/sys-whonix, or anything else with a Window, you're
going to swap that X-server back in, increasing memory demands, and things
might get slow/unsable/unusable.  But for sys-net/sys-firewall/sys-whonix
that are generally untouched and quietly doing their netorking thing, it's
fine.

Obviously, the same technique could be applied to any other user AppVM's,
based upon their needs, to keep them from sucking up resources they don't

Re: [qubes-users] vif in user ProxyVM?

> On 08/22/2016 10:47 AM, johnyju...@sigaint.org wrote:
>> I'm trying to create a ProxyVM of my own, to replace sys-firewall.
>>
>> I'm on 3.2rc2-testing.
>>
>> When I create a ProxyVM in either fedora23 or debian-8, eth0 shows up,
>> but
>> no vif interface appears.
>>
>
> vif interfaces appear when you connect downstream vms to the proxyvm.

Well, how about that!  Right you are, there it is...

Thanks.  :)

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/0a89b85336364ee982c4483064a30776.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] /rw/config/rc.local on debian-8

> On 2016-08-22 07:52, johnyju...@sigaint.org wrote:
>> /rw/config/rc.local doesn't seem to be run on startup in debian-8
>> (3.2-testing).
>>
>> What is supposed to launch this?  systemd, another startup script, or
>> something dom0-related?
>>
>> I added "/rw/config/rc.local" to "/etc/rc.local" and it works, but was
>> wondering what might be the official way to do this, and if this is a
>> bug.
>>
>> Thanks.
>>
>> JJ
>>
>
> Did you make it executable?
>
> # chmod +x /rw/config/rc.local

Yes, I did.

And it seems to be working.  I must have been confused at some point with
too many windows open in different VM's.  :)

Apologies for the mistaken report.

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/cc28d56b8823423ab20448878bedd5dd.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] timesync on by default in debian-8 template (3.2-testing)

I notice in the debian-8 template that network time synchronization seems
to be on by default in systemd.

systemd-timesyncd.service  loaded active running   Network Time
Synchronization
time-sync.target   loaded active activeSystem Time Synchronized

It's disabled in fedora-23 by default, and rightly so, as I believe it's
unnecessary given the dom0 driven /etc/qubes-rpc/qubes.SetDateTime
mechanism, and it's kind of "leaky" sending requests unnecessarily to the
Internet.

Paranoidly yours,

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/b9f04934f4dc333b3afc24e995a77fc3.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Oddness in sys-net's VIF startup

> In trying to figure out why my ProxyVM has no VIF (on Qubes 3.2-testing) I
> was looking at the dmesg's of the servicevm's, and noticed something that
> looked a bit odd (running rapidly through vif interface #'s) in sys-net
> (fedora23 template).
> Similarly, iptables-save shows duplicate rules for the vif's:
>
> -A PR-QBS -d 10.137.1.1/32 -p udp -m udp --dport 53 -j DNAT
> --to-destination x.x.x.x
> -A PR-QBS -d 10.137.1.1/32 -p tcp -m tcp --dport 53 -j DNAT
> --to-destination x.x.x.x
> -A PR-QBS -d 10.137.1.254/32 -p udp -m udp --dport 53 -j DNAT
> --to-destination y.y.y.y
> -A PR-QBS -d 10.137.1.254/32 -p tcp -m tcp --dport 53 -j DNAT
> --to-destination y.y.y.y

Whoops, there's one each for tcp and udp, so the iptables rules are cool. 
But the duplicate interfaces still seem weird.

Also FYI, /proc/net/dev:

Inter-|   Receive|  Transmit
 face |bytespackets errs drop fifo frame compressed multicast|bytes   
packets errs drop fifo colls carrier compressed
lo:6788  73000 0  0 0 6788
 73000 0   0  0
enp0s0: 229463366  16497200   70 0  0 0
19397772   61227000 0   0  0
vif104.0: 3336560   22909000 0  0 0
83284242   57902000 0   0  0
vif107.0:  3094491216000 0  0 0  
1332291840000 0   0  0

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/c72427d3b153c2163d08e799f6ac165c.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Screen corruption on nvidia

> Added testing repos to (clones of) debian-23 and debian-8 templates (as
> well as whonix-gw/whonix-ws), did upgrades/dist-updates, restarted, loaded
> up a bunch of AppVM's, and have been pounding on things awhile.
>
> No sign of screen garbage yet!  :)
>
> Looks promising.

Day 3 of banging on r3.2-testing, and zero sign of any screen corruption.

I think it's safe to mark this one as fixed.

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/1be991f810cc2019d7e056e5749c0504.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] vif in user ProxyVM?