wifi password storage

[Daniel Allcock]

Dear All,

Have been settling into my new qubes laptop and found that sys-net keeps my
wifi password in plaintext in a file in a single directory
(/rw/config/NM-system-connections) that survives reboot. Presumably as I
add wifi networks such files will accumulate. This surprised me, since
sys-net by design is untrusted and isolation is the whole point of qubes.
If I understand right, when RandomMotelWifi corrupts my sys-net,
the corruptors can then get onto almost any other wifi I've ever logged into.

Is the idea that I should run different sys-net's to separate wifi's from each
other, according to some scheme that I need to keep track of? Maybe, home
on one, work on another and everything else on a third?

Or is there a mechanism for storing certain wifi passwords in a vault VM?
Perhaps I should sometimes use a disposable VM in place of sys-net?
Or perhaps something else that I am missing? Maybe I just haven't internalized
the qubes way.

Thank you for any thoughts and recommendations,
Daniel

PS: VERY impressed with qubes---everything works out of the box.
(thinkpad carbon X1 5th gen. Many thanks to the qubes team for ironing out the few difficulties that marmarek encountered back in Dec 2017 !)

[Alex]

On 9/12/18 6:53 PM, Daniel Allcock wrote:
> Dear All,
>
> Have been settling into my new qubes laptop and found that sys-net keeps my
> wifi password in plaintext in a file in a single directory
> (/rw/config/NM-system-connections) that survives reboot. Presumably as I
> add wifi networks such files will accumulate. This surprised me, since
> sys-net by design is untrusted and isolation is the whole point of qubes.
> If I understand right, when RandomMotelWifi corrupts my sys-net,
> the corruptors can then get onto almost any other wifi I've ever logged into.

Your reasoning is right, but defending contents of sys-net is *not* in
the main scope of the Qubes project. It's even "written on the tin", as
in "the default color for sys-net is red" and in all the documentation
it is described as a sacrificial Qube, to protect -by isolation- the
other Qubes.

Still, the issue that you raise is true and sensible: an isolated WiFi
password management could be a nice addition of functionality for Qubes.

Moving the debate to an upper level, it could be argued that if you are
so paranoid about security you should not connect to insecure WiFi
networks altogether... But that would not be answering to your question ;)

> Is the idea that I should run different sys-net's to separate wifi's from each
> other, according to some scheme that I need to keep track of? Maybe, home
> on one, work on another and everything else on a third?

It can be done; please be aware that this would mean disconnecting and
reconnecting the PCI device once you want to start a connection to
another network, and this could easily become hard to manage.
Furthermore, network connections are usually "architecturally
orthogonal" to your Qubes (home, work, banking, etc.), in that you
typically connect to the internet from all qubes at the same time, on
any network that is available at the moment. You only typically isolate
TOR traffic from the non-torified one.

I'll throw in another option: what about using the PCI WiFi adapter only
for "safe" networks, and using a separate external USB one (with a
separate sys-net-unsecure Qube) for any unsecure connection, that you
periodically purge of any WiFi settings? This way you could usb-proxy
the adapter to the unsecure sys-net - I don't even know if it can be
done, I only use Qubes on desktop workstations, but it may be easier to
manage with existing tools than invent a full-blown NetworkManager
secrets management system...

> Thank you for any thoughts and recommendations,
> Daniel

Thank you for your contribution; bye

--
Alex

[daniel]

Thank you for your advice and quick reply, Alex.

My question isn't just abstract security paranoia. Most wifi passwords don't really matter.
But my university in its wisdom uses a one-per-user username/password combo for *everything*.
So someone who gets my work wifi password can also change student grades and redirect
my paycheck. (There is 2FA for some things, but still.) And I can't do anything about this policy.

So I'd rather not have that particular password stored in a VM which qubes expects to be subverted.
I don't think this is paranoia, just part of the data-flow thinking that qubes users are expected to do.

I like your suggestion for a separate usb wifi device. Then when I want to connect at work I would
just change the networking VM for sys-firewall from sys-net to sys-net-work. Would appreciate any
pointers to docs helpful for actually doing this. (Haven't delved into the usb system yet.)

And still open for suggestions from all, to my original broader question as well as the current how-to-protect-a-single-wifi-password question.

Best,
Daniel

[Stuart Perkins]

I would do this without a separate network device. Create a clone of a clean (no saved passwords) sys-net.

First set sys-net and sys-firewall to NOT autostart. Starting an appVM which uses them will start them first anyway.

Create a shutdown script which...

stop all appVMs
stop sys-firewall
update sys-firewall to use the insecure, general sys-net
complete shut down

Use this shutdown script for all shut downs.

Then when you turn your machine on "not at work", it will be using the insecure sys-net by default...you won't accidentally expose your work wifi credentials.

Startup at work will require running a script from dom0 to...

stop all appVMs if any are running
stop sys-firewall
stop sys-net
update sys-firewall to use work-sys-net
start work-sys-net
start sys-firewall
start usual work appVMs

All done without an additional network device

Clear out any saved work wifi credentials in sys-net

This is how I would approach this issue.

[daniel]

Thank you very much Stuart. This feels like it is clearly the solution for now. So marking as complete
even though I haven't actually implemented it yet.

Impressed not only by qubes itself but also the help two strangers have offered.

Though it may be just a noob opinion, it seems like a reasonable idea to have sys-net be disposable, so
that every time you start it you know you are getting something clean. Inter-VM communication then needed
to store credentials. Of course it is easy to say such things.....! :)

Daniel

[Chris Laprise]

On 09/12/2018 03:44 PM, Stuart Perkins wrote:
> I would do this without a separate network device. Create a clone of a clean (no saved passwords) sys-net.
>
> First set sys-net and sys-firewall to NOT autostart. Starting an appVM which uses them will start them first anyway.
>
> Create a shutdown script which...
>
> stop all appVMs
> stop sys-firewall
> update sys-firewall to use the insecure, general sys-net
> complete shut down
>
> Use this shutdown script for all shut downs.
>
> Then when you turn your machine on "not at work", it will be using the insecure sys-net by default...you won't accidentally expose your work wifi credentials.
>
> Startup at work will require running a script from dom0 to...
>
> stop all appVMs if any are running
> stop sys-firewall
> stop sys-net
> update sys-firewall to use work-sys-net
> start work-sys-net
> start sys-firewall
> start usual work appVMs
>
> All done without an additional network device
>
> Clear out any saved work wifi credentials in sys-net
>
> This is how I would approach this issue.

Its a decent suggestion. You could have versions of sys-net for home,
work and public. However on R4.0 it isn't so complicated: you can keep
all your dependent VMs running if you use 'qvm-run -u root sys-net
"halt"'. Then when you start the other sys-net* and set sys-firewall's
'netvm' property to use it, the connection should be usable.

Another alternative would be to configure a single sys-net with either
dispVM or Qubes-VM-hardening so that neither passwords nor malware would
be retained when sys-net is restarted. Then you could control wifi
connections from a dom0 script. This would be like having a separate
sys-net for each wifi connection, if you restart sys-net whenever the
wifi connection was changed.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[awokd]

On Wed, September 12, 2018 8:39 pm, Chris Laprise wrote:

> Another alternative would be to configure a single sys-net with either
> dispVM or Qubes-VM-hardening so that neither passwords nor malware would be
> retained when sys-net is restarted.

Was going to suggest a dispVM as well, per
https://www.qubes-os.org/doc/dispvm-customization/#using-static-disposable-vms-for-sys-

.

> Then you could control wifi
> connections from a dom0 script.

How would you do that? qvm-run some nmcli command(s), passing along the
wifi credentials?

[Stuart Perkins]

My approach is with the presumption that he does not want to have to re-enter his work wifi credentials every workday morning. Making sys-net disposable would forget everything every reboot...which would work...but he would have to re-enter work credentials every workday morning.

By separating work and general sys-net instances, he would not expose his work wifi credentials and would also not have to re-enter them every workday morning. By creating a shutdown script to set to the generic sys-net on the way down, it would prevent accidentally connecting to an insecure wifi with the work sys-net instance.

I have zero 4.0 experience, as I rely on my machine far too much to attempt an upgrade from 3.2 at this time. My approach would work well with 3.2, and would likely also work with 4.0.

[zamanha...@gmail.com]

12 Eylül 2018 Çarşamba 19:53:18 UTC+3 tarihinde daniel yazdı: