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

[johnyjukya]

> 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] Why are Ethernet and WiFi in sys-net..?

[neilhardley]

I guess the only other thing I would add is.

With Firefox, you have a page "Security Advisories", which lists the history of 
Firefox exploits.

I wonder if such a thing exists for WiFi drivers + firmware.

Or even a list of any major audits of WiFi drivers + firmware.

If there is some really easy way to see which WiFi devices are the most secure.

Something like "security advisories", but for WiFi devices.

But I guess if no eyeballs are even looking at the code, then no one will find 
any bugs.

Ultimately, what's needed is a Truecrypt-style major audit.

If we could crowd-fund an audit of a major WiFi chip(s), that may be the key.

-- 
You received this message because you are subscribed to the Google Groups 
"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/6848617d-b373-48f5-b103-eb3b634dde65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[neilhardley]

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

thanks for your replies though... very detailed and very useful

-- 
You received this message because you are subscribed to the Google Groups 
"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/91ed9119-b5dd-49bd-9152-f141d126c3ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[johnyjukya]

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

[johnyjukya]

> 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 

[qubes-users] Snapshots - Use of CoW

[Drew White]

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?

-- 
You received this message because you are subscribed to the Google Groups 
"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/5516b73d-8b1b-481c-a0dd-61afa2f59d0a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] System still freezes, still no resolution.

[Drew White]

On Friday, 23 September 2016 18:05:39 UTC+10, Simon  wrote:
> Hello Drew,
> 
> > I'm tired of having to re-do the work that gets lost if files get 
> > corrupted
> > or not saved properly, and also browsing information from things I'm 
> > doing.
> 
> I share your frustration. Which computer are you using? Are your 
> applications
> still running in the background (ie. only the graphical interface is 
> frozen)
> or is it a complete system freeze?
> 
> On my side I'm running Qubes on a Lenovo Thinkpad T500 and I just wrote 
> a
> similar request as yours just a few days ago:
> 
> https://groups.google.com/forum/#!topic/qubes-users/O4UO9CjO4TM
> 
> On my side the graphical display is frozen, and with KDE I managed to
> workaround the issue by setting KWin to use XRender instead of OpenGL as
> compositing engine. After that the system became rock-solid and I never
> encountered such freeze anymore for months, while it happened about once 
> a
> week until that.
> 
> The sad thing is that Qubes has now switched to XFCE, the freezes came 
> back
> and I do not know any equivalent setting on XFCE. I recently tried to
> completely disable compositing and am now crossing my fingers.
> 
> Regards,
> Simon.

Mine is weird.
I have a cron running in the background.
This allows me to find out what happens while I'm not here to see the PC stop 
and lock.
It locked again over the weekend.
I can't get to a terminal/console/shell/prompt or whatever you want to call it.
Others can ALT+F2 and get a shell, some can't. And I can't.

I've attached the log file for running processes and memory usage at the time 
of me arriving here to find it locked up. So it's not completely locked up, 
things still are running. But it s3eems all input devices may have stopped or 
been disabled.

This happens every time I leave the PC for a day or so.

Hope someone can help.

It doesn't have the issue if I'm on the pc during the day since upgrade to 3.2 
, only if I leave it for a day, (more than 12 hours)

-- 
You received this message because you are subscribed to the Google Groups 
"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/e7e03868-aa8e-4c97-a870-60e31c087b0a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

==

Mon Sep 26 10:10:01 AEST 2016

--
Filesystem  Size  Used Avail Use% Mounted on
devtmpfs2.0G 0  2.0G   0% /dev
tmpfs   2.0G  8.1M  2.0G   1% /dev/shm
tmpfs   2.0G  1.7M  2.0G   1% /run
tmpfs   2.0G 0  2.0G   0% /sys/fs/cgroup
/dev/sda324G  2.9G   20G  13% /
tmpfs   2.0G   16K  2.0G   1% /tmp
xenstore2.0G  256K  2.0G   1% /var/lib/xenstored
/dev/sda1   485M  114M  346M  25% /boot
/dev/sda2   211G  143G   58G  72% /var/lib/qubes
tmpfs   393M 0  393M   0% /run/user/992
tmpfs   393M  8.0K  393M   1% /run/user/1000
--

top - 10:10:01 up 2 days, 18:41,  3 users,  load average: 0.00, 0.00, 0.00
Tasks: 370 total,   1 running, 369 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.1 us,  0.1 sy,  0.0 ni, 99.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.1 st
KiB Mem :  4021248 total,43140 free,   817852 used,  3160256 buff/cache
KiB Swap:0 total,0 free,0 used.  3086124 avail Mem 

  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
 2546 %uname20   0 1066044 203512  55316 S   0.0  5.1  61:26.53 
/usr/bin/python2 /usr/bin/qubes-manager -session 
22e377861-de6d-4a80-bcbb-bca633662d3a_1473145497_828268
 2415 root  20   0  503664 08  46156 S   0.0  2.8  20:37.22 /usr/bin/X 
-background none :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp 
vt1 -novtswitch
  515 root  20   0  160628 101244 100876 S   0.0  2.5   0:24.84 
/usr/lib/systemd/systemd-journald
 1362 root  20   0 1194384  91964  16456 S   0.0  2.3 121:32.11 
/usr/sbin/libvirtd
 2533 %uname20   0  723912  69496  37820 S   0.0  1.7   0:13.11 xfdesktop 
--display :0.0 --sm-client-id 20f7090c4-72bd-4a35-835a-cef95d8d23a7
 2529 %uname20   0  512576  36528  20284 S   0.0  0.9   0:07.31 xfce4-panel 
--display :0.0 --sm-client-id 29b506d82-70ff-48be-8d61-f796aa02cdc8
 2528 %uname20   0  498660  36412  19876 S   0.0  0.9   3:33.63 xfwm4 
--display :0.0 --sm-client-id 20396542a-441a-4b46-b663-130920bb
 4418 %uname20   0  445452  33208  18504 S   0.0  0.8   0:00.75 
/usr/bin/python /usr/lib/qubes/icon-receiver
 4825 %uname20   0  445452  33176  18476 S   0.0  0.8   0:00.25 
/usr/bin/python /usr/lib/qubes/icon-receiver
 3393 %uname20   0  445452  33140  18436 S   0.0  0.8   0:00.31 
/usr/bin/python /usr/lib/qubes/icon-receiver
 2663 

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

[johnyjukya]

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

[johnyjukya]

> 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] Switching from UEFI to BIOS after installation...

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, Sep 26, 2016 at 12:02:01AM +0200, Mara Kuenster wrote:
> Hmm yeah with that I managed to boot through BIOS mode, unfortunately the VMs 
> don’t start (randomly, different ones fail on each boot attempt). So 
> basically something seems to go wrong. The disks get decrypted and I can 
> login with the manager etc. but the system is more or less a complete failure 
> ^^. When I go back and boot in UEFI mode, everything works just fine…
> 
> This seems kinda odd xD.

Just to clarify - does any VM start at all?
If not, check if Xen is started. The easiest way is to call `xl info` in
dom0. If not, make sure you select grub boot entry containing "Xen".

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

iQEcBAEBCAAGBQJX6F72AAoJENuP0xzK19csLNcIAIJry9faT2BpdtxRqthd2QuK
ZE+jWf93MBDydoMX0vvGUptFBobYfRb4Qzyu0yihXT/a+uH2UbDKI7RskGISVU3I
BlhXbRcspfG1evnykOcOWAQ5wyPXDZrwB9+cztR4FuB48n6Ib3zLrPuJzqSFDiVZ
LrEg5OvUO+I1e1Bj//PyTCYTzApNWFmVcsC1+6DOchkeoNfnHNqtZlkhNGj+3580
2Se3XYCgTaLQ26MEoi1HYXJe5Gf9P3XLFdmiCoc7Ehjs3Cv3jK0Xq/knILiLvuV/
o8xGFxMHHseTVfyQUUafE4xt1PoqOp28aziWMJf6MY7EHpVNhaZmFe0zAh6oIKw=
=dsD5
-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/20160925233414.GS31510%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

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

[johnyjukya]

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

[johnyjukya]

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

[johnyjukya]

> 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] Switching from UEFI to BIOS after installation...

[Mara Kuenster]

Hmm yeah with that I managed to boot through BIOS mode, unfortunately the VMs 
don’t start (randomly, different ones fail on each boot attempt). So basically 
something seems to go wrong. The disks get decrypted and I can login with the 
manager etc. but the system is more or less a complete failure ^^. When I go 
back and boot in UEFI mode, everything works just fine…

This seems kinda odd xD.


On 25/09/16 23:27, "Marek Marczykowski-Górecki" 
 wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, Sep 25, 2016 at 02:22:49PM -0700, mara.kuens...@gmail.com wrote:
> Hi,
> 
> I just discovered that AEM needs a BIOS boot. 
> Is there a way to install grub into the MBR of an USB drive after Qubes 
was already installed in UEFI mode? If so... How? Like any other Linux 
distribution or does Qubes need something special?
> 
> I would want to avoid re-installing Qubes if possible.

Just installing grub2 package and calling grub2-install should be
enough. At least in theory...

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

iQEcBAEBCAAGBQJX6EEvAAoJENuP0xzK19cshs0H/3YSRCfl4eTGRiZaYgor1cOb
lLfywbI5WMlJnICZkvpj5cwd3Ar1MxfEAHkWv+yvqPq9YH+80yxYPv3QyyrMsA8t
IfwWJXLFc0Av5L3wkO5CN7BrKdLlbQf4J/LAb/QEWpbTKz9odLxoXLPkuNOKgm3/
r5yWbkQOisGuHiK66ao6Hdn1pCCthLub1+4dA/vtSzai/37rv5LFOU1TbwLktd+J
JmglqpA5WUNqmgX2QtzILWTOhdeHPb0CepGv61x58g2SP4OqOVUKs6cqETZkjLCc
0BX8haa/D8/gWoFjU3/+Af4xKBWom8uWJG7H0dBee7e6pbUqtigYoQGGWixeeFc=
=QEHr
-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/BCDEB0A1-CE53-477C-B439-E101059087BA%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[neilhardley]

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"

-- 
You received this message because you are subscribed to the Google Groups 
"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/6b5e42ea-e2dc-420d-933a-3c591b75639d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[neilhardley]

NET VM
--
--
- WiFi device-
--
- Ethernet device-
--
- Tor ethernet hotspot script-
--
--
-
-
-Ethernet crossover cable
-
-
LAPTOP 2-
---
- -
- -
- -
-   Web browser, apps etc -
- -
- -
- -
- -
---


Question:

Could a DMA attack on WiFi device or Ethernet device then take over the entire 
Net VM, modify my Tor script, and then do whatever, like, leak my real IP, pass 
all data to the hacker, etc?

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

Re: [qubes-users] Switching from UEFI to BIOS after installation...

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, Sep 25, 2016 at 02:22:49PM -0700, mara.kuens...@gmail.com wrote:
> Hi,
> 
> I just discovered that AEM needs a BIOS boot. 
> Is there a way to install grub into the MBR of an USB drive after Qubes was 
> already installed in UEFI mode? If so... How? Like any other Linux 
> distribution or does Qubes need something special?
> 
> I would want to avoid re-installing Qubes if possible.

Just installing grub2 package and calling grub2-install should be
enough. At least in theory...

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

iQEcBAEBCAAGBQJX6EEvAAoJENuP0xzK19cshs0H/3YSRCfl4eTGRiZaYgor1cOb
lLfywbI5WMlJnICZkvpj5cwd3Ar1MxfEAHkWv+yvqPq9YH+80yxYPv3QyyrMsA8t
IfwWJXLFc0Av5L3wkO5CN7BrKdLlbQf4J/LAb/QEWpbTKz9odLxoXLPkuNOKgm3/
r5yWbkQOisGuHiK66ao6Hdn1pCCthLub1+4dA/vtSzai/37rv5LFOU1TbwLktd+J
JmglqpA5WUNqmgX2QtzILWTOhdeHPb0CepGv61x58g2SP4OqOVUKs6cqETZkjLCc
0BX8haa/D8/gWoFjU3/+Af4xKBWom8uWJG7H0dBee7e6pbUqtigYoQGGWixeeFc=
=QEHr
-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/20160925212710.GQ31510%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Switching from UEFI to BIOS after installation...

[mara . kuenster]

Hi,

I just discovered that AEM needs a BIOS boot. 
Is there a way to install grub into the MBR of an USB drive after Qubes was 
already installed in UEFI mode? If so... How? Like any other Linux distribution 
or does Qubes need something special?

I would want to avoid re-installing Qubes if possible.

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/9bc6c0b8-bc24-4b1b-b39b-26bae14004d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[entr0py]

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"
> 
> 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.
> 
> What is rpcbind, avahi-dae and why you got this ipv6 bound to systemd on PID 
> 1 ? Looks suspicious, I thought Ipv6 was disabled by default on Qubes.
> 
> Regards
> 


"all" never worked for me. Disable each interface separately as documented here:

https://wiki.debian.org/DebianIPv6#How_to_turn_off_IPv6

`netstat -anltp` shows ports that are (L)istening.

-- 
You received this message because you are subscribed to the Google Groups 
"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/5e1f765f-ee22-1752-69fc-6ff0f4e8c2d9%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[neilhardley]

OK.. here we go This is my question with a DIAGRAM to help you visualise it:

http://imgur.com/a/CTbLk

-- 
You received this message because you are subscribed to the Google Groups 
"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/e5651253-3453-4fa4-8795-1639d599e62f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] InputAttach in dom0

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, Sep 25, 2016 at 01:55:47PM -0700, Andrew David Wong wrote:
> On 2016-09-25 04:09, johnyju...@sigaint.org wrote:
> > (Apologies if this is a duplicate; I could have sworn I already submitted
> > it, but I don't see any sign of it on the list or my outbox.  Weird.)
> > 
> > USB is generally considered evil/risky as compared to the simpler/safer
> > PS/2 protocol; in that spirit, it might be handy to have "inputattach" in
> > dom0, to allow connecting older/safer serial devices (mice) to Qubes.

What exactly do you have in mind? Serial ports are already in dom0 (and
in most cases it isn't possible to isolate them in separate VM, as it
isn't PCI device). So the only thing needed would be to configure the
system to actually use such mouse - most likely edit xorg.conf.

On the other hand, very few new hardware (especially laptops) have
serial port...

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

iQEcBAEBCAAGBQJX6D4IAAoJENuP0xzK19cs7TYH/0WWz0ETr2XtiGE18U6YUzf+
KUd66CsDhf9dSwug9Hv0zIJ9ajRTkheRmq9bxnhsmVeXiQE4y77yR15ULT3cI7Th
oNlo05c+CmfHpU6cOJNEAD2wGWm7LiDa2z75B1AkUtT4KbHS0XpNLJidzxlznfZN
K7yPkquFh/ej2wZPyqPr7DISgKDya+GoGxkSkUBvD4X9C35F8bPXh4biRkQQOs7s
Uh1oqowIBpVgUYuVYQLqE2MQxM37drRYpy7Yhpvw/L/cMZgqV0o/LzxmTZXO/v7g
ylAOvWbu7SZ5oRzhfaEBSKZekClsJeP+oBFHkDJUmJcpdCtM3KJmzG+GSe3v5Uw=
=MaPx
-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/20160925211344.GO31510%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] InputAttach in dom0

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-09-25 04:09, johnyju...@sigaint.org wrote:
> (Apologies if this is a duplicate; I could have sworn I already submitted
> it, but I don't see any sign of it on the list or my outbox.  Weird.)
> 
> USB is generally considered evil/risky as compared to the simpler/safer
> PS/2 protocol; in that spirit, it might be handy to have "inputattach" in
> dom0, to allow connecting older/safer serial devices (mice) to Qubes.
> 
> It's a fairly simple, useful, and mature utility, which shouldn't pose any
> risk to dom0.
> 
> Thanks.
> 
> JJ
> 
> 
> 

Tracking:

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

Thanks for the suggestion!

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

iQIcBAEBCgAGBQJX6DneAAoJENtN07w5UDAwDx4QAJP9I0hM10eUkXmhzmnuAGxU
hGmSNwNGHvCXyQJQ1fzr/zhR2fOpWgiGBEAwhCb+G6qF70c7hJ8adGDuVBWy3F8A
lw97KtoZEeylHdF1Q9JXK8jvC7J4XsZ1fp+11U3+M7u1MMKaLZYjDcT5o+6pmjK7
KQmNXhiSLrquCIXLsabY88vkacQEGF7Vh98FrHUqfKYJ/jIqY2UxWSsVFNXC/OYd
IesUE4ty1DJgOtsIjvIwVvVMVJn+/kSKVIeGINKIm1KW3OSocfT5sKEJGcEtOup+
nW0d619hf/t4WzEDh8Bml9ndqXo/9yJlunc6Gwo2KaKwd93ScdngIuGyfkxfPiLg
3/HHpYJMeINTlXly9xlI8J+ZTe3onfhwzBFepSTDJBEEkrjoyJvCj7EESB0Ji6qz
7Yt36dK6iEgw68VGyODTjc4grxWHRBEnb4wSe1Jo7wiQBewxzwvLsev9IfrI0M3r
uWCl60L+7T5M6xYw2vMpzBO5vmdYatp3pQz/96KKhIOKXlBQH+4Hw49f9355arH4
6jly1fIlKsdAnQqTZsnahQB2DycGF/E515tN6kIPe5JJm0JhrIYY2+dhwAC9vnYF
qVTJECO/xCyZvD891qlknQNMLOlMK4SPQd4jA3XY1kv9XHTrEJbiXAKW3M3O0LtQ
RMRjAlqrMpJe1oxN+bpm
=Dvh9
-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/b2274ffa-798d-4eca-722e-13b9a19fd778%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Network-manager takes too time to start

[katerimmel]

Hello
Is it normal that after installed macchanger and made all the steps to
anonymize mac address, have to wait network-manager that start for more
than 1 minute when I run a proxyVM? (it didn't happen before, now shows
two monitor in the icon with a red x)

Regards

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

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

[Jean-Philippe Ouellet]

And it works!? Please do share how! :)

I also have a brand new 4th gen x1 carbon and have spent the past week
struggling to get it to a usable state.

Do you have the horrible rainbow screen on resume?

What kernel are you running in dom0?

Was there some magic bios settings combination required to get R3.2 to
actually boot post install?

Are you on a sata ssd? or nvme?

What model exactly? Mine's a 20FB-CT01WW.

I've wasted so much time on this that I'm considering just returning
it. I really hate supporting lenovo since they seem hostile and/or
incompetent (the "lets ship the same root ca w/ private key on every
machine", the LSE bios-sideloading of vulnerable crap into windows,
now the dubious yoga raid thing, etc.), but their hardware is still
the best option I am aware of. I *want* to like librem, but since
their coreboot support is (so far) vaporware, I see no real difference
between them and lenovo except for lenovo having a
generation-more-recent cpus at a lower price. I support their claimed
ideology, but so far it seems like just marketing hype that remains
unrealized.

I'm still holding on hope that one day I might have a risc-v novena
running genode and actually be able to get my work done on it...
*sigh*

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

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

[johnyjukya]

> 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

[johnyjukya]

> 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] 4th gen X1 Carbon graphics issues

[jpo]

On Saturday, September 24, 2016 at 10:36:11 PM UTC-4, Chris Laprise wrote:
> Have you tried using the grub boot menu to select another kernel 
> version? You can also adjust some kernel parameters there by pressing 'e'.
> 
> Does your x1 have an option for legacy boot instead of UEFI? That may 
> work better.
> 
> Chris

I never get a grub boot menu, and I have no reason to believe that grub ever 
loads.

It appears to be booting from nvme0n1p1 which contains EFI/qubes/xen.efi, and 
all the grub-related files (theme, etc., but interestingly no grub config file) 
are in nvme0n1p2.

Setting Startup->UEFI/Legacy Boot = Legacy Only in the BIOS options appears to 
have no effect (except for showing "Intel boot agent ..." while booting instead 
of only the lenovo splash screen.

-- 
You received this message because you are subscribed to the Google Groups 
"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/ae7e0875-e454-45a2-aa9b-1eca5918c3db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[neilhardley]

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

-- 
You received this message because you are subscribed to the Google Groups 
"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/62d3ca97-2e26-41a8-90e3-4b50f28be1d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Blank screen after 10 minutes

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, Sep 25, 2016 at 05:05:36PM +0300, Eva Star wrote:
> On 09/25/2016 01:36 PM, Andrew David Wong wrote:
> 
> > Sure, that could make sense. Some desktop environments already support
> > something similar. For example, in KDE you can assign different power
> > settings (including timeouts) to different "activities," then assign
> > hotkeys (or use a GUI widget) to switch between "activities."
> > 
> 
> i explore the problem. is is not so hard to do (send new settings to
> xscreensaver at dom0):
> 
> 1. when key combination pressed: change .xscreensaver file at user home and
> notify xscreensaver daemon about that.
> 2. then wait 130 mins and change them to the defaults.
> 
> The only one problem is unexpected system reboot, when temporary settings
> will be stored as defaults. It's bad.
> 
> Maybe the scheme:
> 1. when key combination pressed: change .xscreensaver file at user home and
> notify xscreensaver daemon about that.
> 2. then IMMEDIATELY change .xscreensaver file to defaults WITHOUT daemon
> notifications will work. I think, that daemon will read new configuration
> from .xscreensaver file automatically after 130 mins, but I'm not sure that
> it will not read it before... Need some testing...

What about disabling xscreensaver completely for 120 mins?
Something like:

xscreensaver-command -exit
sleep 7200
xscreensaver &

No settings are changed, so unexpected system reboot isn't a problem.

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

iQEcBAEBCAAGBQJX5+DiAAoJENuP0xzK19csUE4IAJqOXctIjWD41JhauRy6PyH1
56vpsjIbduQIhjeS1JpXD4Tn7Cu4vVN+t6CFTROD23yzvcCmbCHUvJN/PfqzUPKb
hAkDS2ts0q5QErJ/z/Ys69pMxQiqDZiuP8UXY7xrLpq4N3UF/zfC1pXrapDokYnu
b33dTlk54yFDTarrIa2DK89cFZt8hwLGwncZc/Hhjbh0omUHf/+7yRBo8CpoWHXu
onRZuvYLn9fIkXHiOb65VLjuR94/KHJJTwmjGXfNvn6NNNC6rVECl+xc43SPKCbg
tBu3OS6vcTtLgn+EcoT5ZgGful0e5kKQPVJ7eKI8KL2L/7Mpk4wwecFKZ+KyLO0=
=Yp0t
-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/20160925143618.GN31510%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

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

[Clark Venable]

On Sunday, September 25, 2016 at 8:42:08 AM UTC-4, Clark Venable wrote:
> Nope. Allow local data to be set is enabled.

It all works as I expect in Firefox, So I'm happy to leave this alone and just 
use Firefox rather than Chrome (which is probably what the devlopers intended 
by including Firefox in the distro. :-)

-- 
You received this message because you are subscribed to the Google Groups 
"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/c32c3580-b168-48de-baa1-6baa9342134e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Blank screen after 10 minutes

[Eva Star]

On 09/25/2016 01:36 PM, Andrew David Wong wrote:


Sure, that could make sense. Some desktop environments already support
something similar. For example, in KDE you can assign different power
settings (including timeouts) to different "activities," then assign
hotkeys (or use a GUI widget) to switch between "activities."



i explore the problem. is is not so hard to do (send new settings to 
xscreensaver at dom0):


1. when key combination pressed: change .xscreensaver file at user home 
and notify xscreensaver daemon about that.

2. then wait 130 mins and change them to the defaults.

The only one problem is unexpected system reboot, when temporary 
settings will be stored as defaults. It's bad.


Maybe the scheme:
1. when key combination pressed: change .xscreensaver file at user home 
and notify xscreensaver daemon about that.
2. then IMMEDIATELY change .xscreensaver file to defaults WITHOUT daemon 
notifications will work. I think, that daemon will read new 
configuration from .xscreensaver file automatically after 130 mins, but 
I'm not sure that it will not read it before... Need some testing...


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

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

[Chris Laprise]

On 09/25/2016 08:12 AM, johnyju...@sigaint.org wrote:

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.

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.


I guess I was thinking in terms of using a single NIC/netvm. Having a 
second NIC/netvm only for the other laptop does offer hope that one DMA 
exploit can't carry over to the other netvm (and thus the other 
laptop) but that protection is probably due not only to vt-d but to 
some filtering done by an intermediate proxyvm or such.


Its quite true about Qubes' network "layering" offering both greater 
simplicity and security. I think this is because potential leaks around 
a tunnel are more easily dealt with in a vm that's devoted to the tunnel.


Chris

--
You received this message because you are subscribed to the Google Groups 
"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/605b6a87-b40e-132f-803b-a7260a520846%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

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

[nishiwaka46]

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"

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.

What is rpcbind, avahi-dae and why you got this ipv6 bound to systemd on PID 1 
? Looks suspicious, I thought Ipv6 was disabled by default on Qubes.

Regards

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

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

[johnyjukya]

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

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

Re: [qubes-users] What is the purpose of sys-firewall..?

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, Sep 25, 2016 at 08:09:34AM +0200, Fabian Wloch wrote:
> > What is the purpose of sys-firewall..?
> > 
> > I noticed that every App VM has its own "Firewall Rules" > inside of VM
> > Settings.
> > 
> > So therefore, what is the purpose of sys-firewall..?
> > 
> > Thanks
> 
> The reason I am aware of: VMs should not see each other. firewallVM allows
> them to see/connect to netVM, but not to other appVMs etc that are running.
> Also, if the netVM gets compromised over a bug in the network driver of your
> wifi/ethernet card, it only sees firewallVM and not your appVMs, on which
> may run services, which would increase the attack surface of your system.

Yes. And in addition to this, firewall rules set in VM settings are
actually enforced by sys-firewall. This means VM itself has no control
over its own firewall rules - for example can't disable them.

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

iQEcBAEBCAAGBQJX58OrAAoJENuP0xzK19csDEIIAIKxEUEosI1E/ba2dALDH4RJ
QScg9bwDhGyzty/1d7i42tJRNMHnhQmDFHh9C7+LSshhtSCVeL9tPh7SZbC4wFI0
cDDAkVi5cz+ys5sJsbHpQ++yHzAzDMbXFicvoN+tTFSZ5rrTQg5THPFRTnbALTjN
KdVYUrRdgmElOflV+/qfz4h4WUMYyJTt7Y4Et7Zhc9wgUYUbcDi+1PX4wFqO8xD3
I3/pI741GmgceNqZKuv83b64TkeVp/AAdMqOkQd3jqBYagAxp6oTaHo+lOaBYBU3
JHY1R3txDdVhok5lXAbXyrz9nwFg1jcnUaswgmD5kGHLJABtm8K49U6V7w2Cvrk=
=Mdlj
-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/20160925123138.GJ31510%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

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

[johnyjukya]

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.

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.

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

Re: [qubes-users] 3.0 to 3.1 in place upgrade broke USB VMs

['Vincent Adultman' via qubes-users]

Sounds like it could have been introduced in R3.1 Xen 4.6 for you
specifically due to your hardware. If that's the case, it wouldn't
be a good idea to note this on the page, since it might not apply
to others.

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


Thanks Andrew. That's interesting, I'd assumed it was a binary proposition 
introduced in 4.6 having only briefly scanned 
http://www.gossamer-threads.com/lists/xen/devel/391684

If not I take your point however I still feel it should be referenced in some 
way on the upgrade instructions page to stop others potentially wasting the 
same time I did, and subsequently the lists time IF they run into it.

If the issue does not apply to users hardware, user will simply have no problem 
with their existing device to VM assignments and proposed note is ignored. 
Without a note, if it does apply to their hardware they may (stupidly) like me 
read the existing FAQ entry and assume pci strictreset is not the problem as 
otherwise problem would have begun in R3.0...

So perhaps it's the FAQ entry that needs clarifying? From a naive point of 
view, it makes sense that USB controllers might share some resources but on 
what appears to be "sensible" hardware that has one controller for USB ports 
and another for webcam etc it came as more of a surprise.

Best

Vince

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

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

[johnyjukya]

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

[Chris Laprise]

On 09/25/2016 07:08 AM, johnyju...@sigaint.org wrote:

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.


I think this should be clarified...

Qubes users' typical idea of a DMA attack is one that's initiated as a 
network-bourne attack against the NIC. Then, once malware has control of 
the NIC, the actual DMA attack can take place against whatever processes 
are running in the machine.


Inside Qubes, that's not a huge deal because the NIC's DMA is contained 
in sys-net and the other (downstream vms) don't have hardware NICs that 
can also be attacked. The netvm can try to mess with the traffic of your 
connected vms, but you might be using a proxyvm gateway (running openvpn 
or whonix/tor) in which case the netvm malware is pretty helpless... it 
could try to do sidechannel attacks but the topic here is DMA attacks.



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.


That's why applications should use SSL/TLS just as a routine matter. In 
some vms, you might even want to set 'Https Everywhere' to only allow Https.



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.


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



--
You received this message because you are subscribed to the Google Groups 
"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/c65148ba-d1d8-2955-3284-19a09e3faa41%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

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

[johnyjukya]

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

[johnyjukya]

> 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] Setup VPN, DNS script and iptables

[Chris Laprise]

On 09/25/2016 06:35 AM, asdfg...@sigaint.org wrote:

Hello
After setup my VPN in network manager (but not in config/vpn like the
tutorial says) I have configured DNS script (in my client and like
qubes-vpn-handler.sh file) and iptables (only the 2 lines that block
forwarding connection). Do these work the same  although I have used
different VPN setup?

Thank you



It could work mostly the same (hard to say without details), but you 
will probably end up with your vpn vm configured to use the vpn's DNS. 
Some might consider that less functional or secure because, after the 
connection is made, anything inside the vpn vm that tries to access the 
net will end up going through the tunnel instead of clearnet. OTOH the 
doc setup has the vpn DNS used only by downstream vms, not the vpn vm 
itself.


Also, with the vpn doc script config, essentially nothing is allowed as 
(vpn vm) in/out traffic except the vpn connection itself. The forwarding 
rules you added are great for protecting downstream vms, but they don't 
help protect the vpn vm in this way.


Chris

--
You received this message because you are subscribed to the Google Groups 
"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/12f6f671-9564-fc29-adbb-45e03fcc9667%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

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

[Chris Laprise]

On 09/25/2016 02:34 AM, neilhard...@gmail.com wrote:

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

Thanks



The former is true: A Qubes netvm (e.g. sys-net) is like having a 
separate router device. If its compromised it could launch (non-DMA) 
attacks against other devices on the net... AND against your appvms.


But proxyvms can help protect your other vms in various ways: A 
sys-firewall can filter packets with hardly any risk of being attacked 
itself. A VPN gateway can reject anything that doesn't belong to the 
encrypted packet stream. Etc...


Of course, non-networked VMs are the safest of all.

Chris

--
You received this message because you are subscribed to the Google Groups 
"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/96df4645-8bc9-cbbf-ee29-a9951591b3c0%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Blank screen after 10 minutes

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-09-24 15:48, Eva Star wrote:
> On 09/20/2016 03:42 PM, Andrew David Wong wrote:
> 
>> Note: Watching a movie, even in fullscreen mode, will not affect
>> this timeout, since dom0 doesn't "know" about that type of
>> activity. This is arguably a security feature, since if an AppVM
>> were able to delay the timeout by starting a movie, an adversary
>> could exploit this in conjunction with physical access to obtain
>> your machine in an unlocked state.
> 
> 
> What is about the tool that will override default 10 minutes to 130 minutes 
> for one period by keyboard combination or shortcut?
> 

Sure, that could make sense. Some desktop environments already support
something similar. For example, in KDE you can assign different power
settings (including timeouts) to different "activities," then assign
hotkeys (or use a GUI widget) to switch between "activities."

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

iQIcBAEBCgAGBQJX56ilAAoJENtN07w5UDAwSBgP/i5DlqYoHdOHFHZrZ8p2+CIn
NRU0hnegECGhFd+PHwMqe88Nzd+5vw1UCkV2SOrF+QAbnbGLovZ8016WLWEtc1MQ
juYTqs4zJqK3pZY1z5pbIGRGRK68yXPqWhLbT6/mVIFcATWiQTXKlpco1EEJ2qo+
Kqp7Mfmer+5yP0xrYTWMtbtscjT+tNZKHP2+U20ydpbL1ypJ40N+jdzq6k8WwKi4
nS9uSiR0VEV4nINgxTrd0jsg4WZ6ZKRW35oCt+t7P81nhYIHvrdf8Rlq46SFJ8FZ
+Z+n5KjGfrlwHupCV35NPdj7riv3i5hxOsdaOpG8VPVNTkeoXlg64gLy+/hI/8Zw
p4KTjyKpj+3q2kTJNQGAgP8oCrRtxqjzizeQTOxA3IxJ8woogEiFU8xNKv6dIZne
f/GqOgIIy0uw0q/NHgFX/JN2YEnw8ASqVBUT+inQj5lFFvZHci0O+ZwyEE+a1j93
wq+4rSfPoytnc21+R19rci47ZOaLIMaFy43xzcdHDTpZIapWgn8M2zC+7gw2Av8Y
gupJU/atBGPrpuExiYY442EmzMgp1CIKRu/CRe6u1/hDeK4Dfbp28kzAB6YG7Yhu
xj1ORySItowCEKdDZTrXAl+6eP9q85nIJwnB7di9qY1vAvehmiOFn0FKDSQH9pCT
7O5DlBTl74VUMgvpxCeB
=Wh6p
-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/f40e2924-77b1-6301-0d19-c21209a3e1a7%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] What is the purpose of sys-firewall..?

[Fabian Wloch]

What is the purpose of sys-firewall..?

I noticed that every App VM has its own "Firewall Rules" > inside of VM 
Settings.


So therefore, what is the purpose of sys-firewall..?

Thanks


The reason I am aware of: VMs should not see each other. firewallVM allows 
them to see/connect to netVM, but not to other appVMs etc that are running.
Also, if the netVM gets compromised over a bug in the network driver of 
your wifi/ethernet card, it only sees firewallVM and not your appVMs, on 
which may run services, which would increase the attack surface of your system.


-Fabian


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