Why are Ethernet and WiFi in sys-net..?

[neilh...@gmail.com]

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

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

Thanks

[Chris Laprise]

On 09/25/2016 01:07 AM, neilh...@gmail.com wrote:
> 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..?
>
> It's not clear to me whether the VT-D protection is occurring because you are putting these devices in sys-net.

Its not clear to you because there is no vm classification called
"hardware" or "vt-d". There is nothing in Qubes Manager's listing that
flags certain vms as having PCI devices (you have to look at the Devices
tab in settings). Its an interesting idea, though.

> Or whether the VT-D is implemented regardless of which VM the Wifi/Ethernet are in.
>
> I ask this because I want to run some programs in sys-net, and wonder whether a DMA attack could screw up these programs.
>
> Thanks

Anything you run in sys-net or other NIC-bearing vm (or USB-bearing vm)
should be considered vulnerable to DMA attacks, period. Probably most
other types of PCI devices carry that risk.

Chris

[johny...@sigaint.org]

> 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

[neilh...@gmail.com]

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.

[johny...@sigaint.org]

> 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

[neilh...@gmail.com]

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

http://imgur.com/a/CTbLk

[neilh...@gmail.com]

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?

[neilh...@gmail.com]

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"

[johny...@sigaint.org]

> 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

[johny...@sigaint.org]

> 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

[neilh...@gmail.com]

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

[johny...@sigaint.org]

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

[johny...@sigaint.org]

> 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

[neilh...@gmail.com]

You said:

"
Now, if the compromised sys-net can somehow otherwise breach other
AppVM's or dom0, you're screwed.
"

------

Yeah... and surely this is exactly what can happen, no..?

We had 2 Xen exploits in the last 1 year.

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.

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

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

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

Here is a comparison of open source wireless drivers

https://en.wikipedia.org/wiki/Comparison_of_open-source_wireless_drivers

Are there any particular WiFi chips on this list that anyone recommends..?

Are certain ones known to be more secure than others..?

Because to me, this is where this thread has now ended up.

[johny...@sigaint.org]

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

Putting on my tinfoil hat (okay, okay, I never really took it off), even
if the card doesn't appear to have a CPU, but some other signal processing
chip that is driven directly by the Linux driver, it's still possible that
the chip could be faked, actually having an internal CPU and a backdoor
that modifies its behavior upon reception of a magical packet from
outside.

A bland old common flash memory chip that holds the firmware could also be
rigged with an internal CPU and rogue code. The NSA's resources are
extreme. And with all those chips manufacturers use that are coming from
China and other countries, there's certainly no risk that those are
compromised by their security agencies or crooks, is there? :)

I'm always extra-hesitant when I see an unmarked chip or one buried in
epoxy. But a common-looking chip is no guarantee either, these days,
unless you scrape it down and analyze it with an electron microscope;
after which point it's rather difficult to use. :)

> Are there any particular WiFi chips on this list that anyone recommends..?
>
> Are certain ones known to be more secure than others..?
>
> Because to me, this is where this thread has now ended up.

I think we're down to using smoke signals for communication.

I'm certainly at the high end of the paranoia scale, and I'd tend to trust
Xen VM isolation *way* more than I'd trust card manufacturers, chip
manufacturers, etc., to be compromised by state actors or crooks and
hackers.

Xen *IS* fully open source and visible, even if there are bugs, they can
be found and fixed *far* more easily than a hacked or backdoored NIC or
proprietary firmware.

(Now, AMD and Intel have both come under suspicion for backdooring their
CPU's... In which case all bets are off. Where'd I put my old Z-80
machine...?)

I think the safest bet would be Qubes + one of those network cards that
supposedly doesn't have a CPU.

And if you don't trust Xen (which is a perfectly valid stance), maybe you
should have a more bland Linux firewall between your laptop and the
Internet.

But at the end of the day, nothing is perfectly secure any more.

Similar to software, maybe open-source hardware is the most promising
route. These may be of interest to you:

https://en.wikipedia.org/wiki/Open-source_computing_hardware
https://www.crowdsupply.com/sutajio-kosagi/novena

It's somewhat in the spirit of the less ambitious peripherals (and
pda/phone) I've been working on to improve security. If I built it
myself, I'm more likely to trust it. Sad that it has come to this.

JJ

[neilh...@gmail.com]

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

[neilh...@gmail.com]

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.

[johny...@sigaint.org]

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

And as always, enforcing use of https:// will buy you a bit more
protection (as the "GiveMeYourStuff" string only gets decrypted to
cleartext in the final destination, the browser).

Even a state actor or someone with CA forging abilities shouldn't be able
to force your NIC to see the cleartext magic string. They can imitate
another site (which reveals your content and exposes you to other threats
like 0days) but the data still flows through your laptop NIC encrypted, so
the magic string trigger/phone home threat is still contained.

(I guess in that case, where they control the https connection, they might
be able to make that magic string in the backdoor be an *encrypted*
version of some known content they send, encrypted with a known key. I
think most https key handshakes these days, Diffie Hellman and all, would
prevent even a forged certificate holder from being able to force a
specific encryption key, and thus specific encrypted content, upon you.
I'm a bit behind on the state of https these days, so I could be wrong.)

An https: page that redirects to a non-https page, or includes non-https
content (and you're strictly enforcing the https-only rule) does expose
you to that cleartext-to-your-NIC threat as well.

And who knows, there could be other backdoor triggers used, such as the
timing of the packets, rather than their content (in which case encryption
doesn't help). The possibilities are endless. :)

Personally, I'll never again use another NIC that isn't inside its own VM.

Cheers, and sleep well. :)

JJ

[neilh...@gmail.com]

You should realise, I don't actually care if the 2nd laptop is hacked.

I'm only trying to protect WHO I am, and not WHAT I'm doing.

So I don't care about DMA attacks on the 2nd laptop.

I only aim to protect the Tor hotspot thing that is set up in the Qubes system.

And for this, I think the solution is to use a safe WiFi/Ethernet device, if these things even exist.

Of course, this means that I don't even really need Qubes at all, which you pointed out in an earlier post.

I originally thought I needed Qubes for this system.... but in fact, VT-D simply doesn't do what I originally thought it did.

I originally thought VT-D isolated the networking devices themselves.

But in fact, VT-D simply allows networking devices to be inside the Net VM.

The Net VM still relies on Xen to separate itself from the rest of the Qubes system.

Hence, it all comes back to Xen. Maybe Qubes 4.0 and SLAT will make Xen secure.

But for now, I think using 2 laptops is more secure, so long as we can be sure there are no bugs in the networking drivers.

[entr0py]

Please read if you haven't already:

http://invisiblethingslab.com/resources/2014/Software_compartmentalization_vs_physical_separation.pdf

2 big takeaways:

1. A typical networking stack presents a huge attack surface.
2. The Physical Gateway needs to be secure not only from attacks from the Internet but also attacks from the client appVM.

After reading the paper, you may wish to re-evaluate your confidence in your physical separation setup (or not).

Some suggestions:

* Get rid of wifi from your system completely. Xen is surely more secure than a consumer wifi device. Xen undergoes much scrutiny (black & whitehat) since it powers many of the world's largest datacenters that actually host important (as in expensive) business operations. On the other hand, your wifi driver (even if open source) is unlikely to be audited ever since no one uses wifi for anything "important". (I can't tell how wifi fits into your operation but for an anonymity-centric setup, wifi can pose many problems. For example, a compromised wifi VM can make unwanted connections to arbitrary APs.)

* If you run Qubes, then put everything in one VM, that really defeats the purpose of using Qubes in the first place. If you want to proceed with your setup, it would be better to just use Whonix-Gateway in a physical isolation configuration without Qubes. You wouldn't lose anything relative to your setup but gain Whonix's 4? years of experience in protecting anonymity.

* Use Whonix Gateway. The devs have considered many threats that you may not have. Even simple things like Tor Control Port commands, such as GETINFO, can reveal your real ip to the appVM if your script doesn't filter it.

* I haven't tried myself yet, but this is how I would attempt this. Get a second ethernet adapter if needed.

Internet -- NetVM1 -- Whonix-Gateway -- NetVM2 -- Laptop

Whonix-Gateway is already designed to function in a configuration similar to this. See: https://www.whonix.org/wiki/Dev/Build_Documentation/Physical_Isolation

The main advantage of this over your proposal is that the Tor Gateway is isolated from both network adapters by Qubes "simpler" networking pipes, making this even stronger than a Whonix Physical Isolation setup. In this configuration, the Laptop will have greater difficulty attacking the Tor Gateway, and attacks from the Internet against the Tor Gateway will have less chance of success as well. However, a Xen vulnerability that gives up dom0 could succeed in rerouting traffic so that it bypasses the Tor Gateway altogether. To address this possibility, you could add a separate physical Corridor-gateway between the Internet and your Qubes box.

The bottom line here is that you need to assess the relative vulnerabilities of Xen vs your networking stack. I would strongly recommend relying on the advice of more knowledgeable security folks rather than relying on personal experience or intuition.

[neilh...@gmail.com]

Well, entr0py, you are correct.

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

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

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

In this setup, there is no WiFi at all.

Would that make things more secure..?

[neilh...@gmail.com]

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

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

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

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

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

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

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

Thanks

[johny...@sigaint.org]

> 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.
You can hear the dialing activity, clearly. It's a low-end phone, so I'm
not sure if it's just a crappy design with poor shielding, or, ahem, a bit
"suspect." It was given to me by a "potential client" whom I never heard
from again. :S I don't use it, lol. It's joined "Johny J's Museum of
Suspect Hardware.")

At the very least, with WiFi, even if they can't see the actual traffic,
an attacker can see that there *is* traffic or not. Which could let them
know when you're home or out, as well as doing traffic correlation
attacks. ("Hmmm, occupywallstreet.com gets hits corresponding to the
timing of Joe's WiFi traffic. Let's get him!")

Cable Modems seem very sloppy in their software design, in my experience.
I'd even recommend not using it to be the router, doling out DHCP
addresses, and such, but to run it in "bridged mode" which behaves more
like your PC is directly connected to your providers LAN.

And put a good, secure, controllable, open-source, updateable Linux
firewall between the modem and your users instead. Don't let a closed
source system do your personal DHCP, DNS, routing.

My cable modem repeatedly turns on "allow remote administration" which
shows up with a big red warning banner. I asked my ISP about that, and
they said it's normal, and they use it for remote maintenance. Um, okay.

(Assuming, of course, I was actually having an email conversation with the
actual ISP, lol. Not necessarily a safe assumption in my situation.)

Once again, sorry for the brain dump. I get excited when it comes to
security.

JJ

[johny...@sigaint.org]

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

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

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

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

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

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

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

Cheers,

JJ

[neilh...@gmail.com]

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

I wasn't really talking things like RF leakage etc.

[johny...@sigaint.org]

> 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
text data bss dec hex filename
41511 2968 49 44528 adf0 3c59x.ko

Ethernet driver for an ath5k card:

/net/wireless/ath/ath5k$ size ath5k.ko
text data bss dec hex filename
153545 1529 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
text data bss dec hex filename
529986 53348 64 583398 8e6e6 mac80211.ko

Oh, and also this, just for WPA:

/net/wireless# size *.ko
text data bss dec hex filename
380654 71395 3656 455705 6f419 cfg80211.ko
3688 1088 0 4776 12a8 lib80211_crypt_ccmp.ko
6696 1168 0 7864 1eb8 lib80211_crypt_tkip.ko
2166 968 0 3134 c3e lib80211_crypt_wep.ko
2132 992 4 3128 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

[neilh...@gmail.com]

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.

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

All this wireless stuff in general seems to be super super complex, and thus, prone to security problems.

[3n7r...@gmail.com]

On Monday, September 26, 2016 at 5:52:22 PM UTC, neilh...@gmail.com wrote:
> It does indeed come down, to either Xen, or my networking stack.
>
> Let me ask... what is the security like for Ethernet..?

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

When I suggested heeding the advice of more knowledgeable people, I wasn't referring to me. In terms of Qubes' networking, Joanna makes her opinion pretty clear in her paper. You can get opinions on "ethernet vs wifi security" by using your search engine.

One thing that's not debatable is that wifi can make connections without physically plugging cables - much harder to do using a cable-only network. JJ makes some good points.

On Monday, September 26, 2016 at 7:25:43 PM UTC, johny...@sigaint.org wrote:
> (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.)

sys-whonix doesn't require apt-transport-tor. All you need to do is edit your apt sources to use the Debian onion mirrors. https://forums.whonix.org/t/debian-starts-onionizing/2797/11

--------------------------------

On my previous reply, I came to some rather misleading (ie wrong) conclusions regarding the benefits of various setups. The 3 scenarios worth examining are the following:

A. Default Qubes-Whonix
Internet -- [NetVM -- Whonix-GW -- AppVM]
B. Whonix Physical Isolation
Internet -- [Whonix-Gateway Box] -- [Laptop]
C. Qubes + Whonix Physical Isolation
Internet -- [NetVM1 -- Whonix-Gateway -- NetVM2] -- [Laptop]

First, we assume that Whonix-Gateway is trusted and that the Tor protocol is safe. If one wishes to hedge this assumption, he can route Tor over a second anonymizing network such as i2p or Jondo.

In terms of Attacks from the Internet:

* Qubes is preferable to non-Qubes since the networking code / device is isolated from the rest of the system by Qubes networking. A successful attack against the Tor Gateway requires a general networking exploit plus either a Xen breakout or a flaw in Qubes networking. [A], [C] are big winners.

In terms of Attacks from the AppVM/Client:

* [A] is vulnerable to a deficiency in Qubes networking as well as a Xen breakout from the AppVM itself.

* [B] is vulnerable to the Ethernet networking stack.

* [C] requires a vulnerability in both the Ethernet networking stack AND either the Qubes networking code or a Xen breakout.

* A disadvantage of both [B] and [C] is that they have the full networking stack in the Laptop, making the machine that much easier to compromise. A compromise of the Laptop may or may not de-anonymize the user. Ideally, the Laptop should also be compartmentalized using Qubes or as a hedge, a different hypervisor.

[johny...@sigaint.org]

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

The affected devices have modems that use the Samsung IPC protocol, mostly
Intel XMM6160 and Intel XMM6260 modems. Note that despite this back-door,
the devices using these modems are most likely to have good modem
isolation, compared to other devices using Qualcomm platforms. Bear in
mind that this back-door is implemented in software and can easily be
removed by installing a free replacement for the incriminated software,
for instance by installing Replicant. Hence, we don't consider the
incriminated devices to be inherently bad targets because of this
back-door."

> All this wireless stuff in general seems to be super super complex, and
> thus, prone to security problems.

Indeed. It's unfortunate that some of the potentially more useful and
convenient devices and technology (smartphones, broadbands, USB, ...)
suffer from such bloat, complexity, and insecurity.

(One of my fears about Qubes 4.0, as discussed in other threads, is that
it will push me to use newer, more complex [and more likely
state/hacker-backdoored] hardware, rather than older, simpler, presumably
more secure stuff.)

JJ

[raah...@gmail.com]

On Sunday, September 25, 2016 at 7:34:28 AM UTC-4, johny...@sigaint.org wrote:
> > 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

anything listening to traffic is a security risk. wireshark is a known security risk in itself. But that is whats cool about qubes, the sys-net is considered untrusted anyways. so actually perfect for running something like wireshark.