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
> 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
> 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.
Very useful info, but what I meant is whether the Ethernet drivers/firmware etc
are more secure than the WiFi ones.
I wasn't really talking things like RF leakage etc.
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this
> 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
> 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
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.
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,
> 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
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
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
> 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
> 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
> 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:
>
>
> 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 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
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
NET VM
--
--
- WiFi device-
--
- Ethernet device-
--
- Tor ethernet hotspot script-
-
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
> 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
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
> 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
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
23 matches
Mail list logo
