"Now You're Thinking with Qubes"

I like the idea from here: > 1. By default, there is no need for an attacker to find a local exploit to get... | Hacker News. I would probably call it split root.

I agree that it should be harder to go from domU user to domU root. However I think having to manage passwords for every AppVM also negates a lot of the benefits of the template setup in qubes (I currently have about 30 AppVMs).

My ideal solution to this problem, which I might implement at some point, would be to implement a PAM module for domU that asks dom0 whether escalation to root is okay. That way, dom0 can prompt the user whether to allow it or not, and no per-AppVM passwords have to be remembered.

There’s actually already a documentation for that:

Never used it myself, though.

2 Likes

I’ve used this in StandaloneVM’s because there the logic for the passwordless root AFAIK doesn’t apply.

it’s neet. Even though a propt shows up, it’s still faster and more convenient than having to type out a password :slight_smile:

2 Likes

As a desktop user, I’d find exportable qubes extremely useful. My laptop is Mac and it cannot run Qubes.

1 Like

Just realised that I could do that also to separate “real” work from personal stuff, by letting the Qube that I work from connect to ETH only.

Makes for a very neat routine of plugging in before starting work at home & then unplugging, rituals like these have a lot of impact.

Added security and splitting up possible data harvesting is a great plus too, but for me its mostly about workflow & blocking big data surveillance which I hate with a vengeance.

1 Like

2 posts were merged into an existing topic: Graphene OS Template?

When we can say “Qubes now suitable for the Normal People”?

Is it a good idea or it is risky for noops?

I’d say that this has absolutely wrong premise. Can you imagine a youngster first to be introduced to a modern car, telling him that it is not for young people because it has a lot of safety features he/she can’t use because the features are complicated?

You want to drive? Especially beginners should start with modern car with as much as possible safety features.
You want to compute? Especially beginners should start with as much as possible Qubes computer.

Using your logic, would you call people who drive cars without seat belts. airbags, ABS, all the working lights, without bumpers, shatter resistant glasses and without both side view mirrors - normal? Probaly no. And you are calling people who are using computers without even more safety features - normal. It just ain’t right to us using Qubes. :wink:

3 Likes

Yes, I agree with you…
(People caring for Privacy without advanced experience )
But I think about the “the future of qubes” and “The concept of simplicity” I think we can see soon qubes is simple for all the people …
Why I say that ?
Some features in qubes are simple more than linux distribution (of course qubes depend on linux templates):

  • you can see how it’s simple to install qubes and update the templates.
    I don’t know if the aim of the developers of qubes wasto make it simple for the normal user.
  • I think the idea of qubes is “The Ultimate privacy” and “compartmentalization
  • To illustrate, when I say for the normal people I was thinking of the people who are caring of privacy and " don’t have a lot of experience with programing and linux "
    So I hope we could see qubes more simple for the "Normal User " in the future…

“Now You’re Thinking with Qubes”

The toughest concept for me to grasp was the bare metal virtual machines offered by Xen, and how beautifully Qubes built a collection of OS’s and VM’s to leverage them all, especially the chaining of VM’s providing networking services to other VM’s. Once I swallowed the pill, and made myself comfortable with it, I went hog wild.

I love lots of networking options, and this is where Qubes excels. As a linux junkie, I like renting VPS servers from various providers around the world, and using those servers for whatever I want. For $5/month each, they are dirt cheap, but gives me lots of great experience. I usually put a private VPN server on each one, to access it that way. Sometimes I’ll also install a tor entry-node server on it, to play around with tor. Most VPS providers don’t mind entry-node servers, they just don’t like exit nodes, so it’s not a problem.

I like to create a variety of networking options, frequently changing too, like:

sys-net-eth
sys-net-wifi
sys-vpn-losangeles
sys-vpn-chicago
sys-vpn-tokyo
sys-vpn-amsterdam
sys-tor-vpn-losangeles
sys-tor-vpn-tokyo
sys-tor-vpn-amsterdam

then work/play VM’s to access each of those, easily changeable, like:

play-vpn-tokyo
play-tor-vpn-amsterdam
work-vpn-losangeles

Qubes makes it so easy, that once you get used to it, the sky really is the limit. As new things pop up, like wireguard, I’ll play with those too.

As a rule, I don’t put anything sensitive or important on the laptop. It’s just for fun learning really. If it gets screwed up, I’ll just wipe the drive and start over.

I played around with “minimal” installs, minimal firewall, blah blah blah. In the end, it’s just not necessary, for me anyways. A Debian template and a Fedora template give you more than enough to handle almost anything. Sure, there are niche situations, and multiple templates can be necessary. We all do different things, which is another reason why Qubes is so great. The flexibility to do things so easily that other platforms do poorly, if at all, to me, is the greatest appeal.

Sorry I’m late to this thread. Couldn’t resist!

2 Likes

A post was split to a new topic: Why Use Minimal Templates?

A post was split to a new topic: Which one is more secure: sys-usb sys-net as sys-usb

Not sure if you’re logged into facebook or trying to view posts without an account, but if you’re logging into facebook, they have a .onion domain that you could use in whonix.

A post was split to a new topic: Qubes trick: 2-slot clipboard

Network interfaces are always assumed to be compromised, yes?

So is the benefit of this approach that it gives you the flexibility to chose the device, or is there a security benefit of isolating two network devices from each other?

Perhaps hypothetically if you had an external WiFi adapter that you used to connect to public wifi’s for sensitive journalistic uploads, and an ETH or onboard WiFi for home network, would having them separate prevent some kind of leak or some kind of log of useful data that your more trusted network device gained from its home connection that could be accessed or exported by your riskier external adapter device? This may be completely ridiculous just trying to understand any security gains from isolation here.

@Brainhack Can you tell me what the added security is of the setup you mentioned?

Thanks.

Did you have a look at my original post that @fiftyfourthparallel is refering to?

Maybe this can give you more ideas when such a separation might be useful.
What I wrote there is basically what we still use today.
Of course, with the whole pandemic situation our work has shifted to more home office in the last years, and this setup can handle such a situation perfectly fine.
When I am not in the office, I can connect “sys-firewall-lan” to a VPN Qube which then goes out through either sys-net-lan or sys-net-wlan, depending on whether or not I have an Ethernet cable connected. I am currently thinking about renaming the firewall VMs to “sys-firewall-trusted” and “sys-firewall-untrusted” to better reflect their versatility.

I think the most benefit of this setup can be drawn if you have a physical network setup that supports your segmentation approach, such as in our situation (see my post from 2020).

1 Like

Yes.
I always recommend separating network devices to distinct qubes for this
reason.
There is some cost in convenience: if you are travelling and want to use
WiFi you may have to change a qube’s netvm if you want to be online.
This is no bad thing since it may make you think whether you really
need that qube to be online at all in this case.

I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
2 Likes

Or you could use an intermediate routing-only VM between the appVMs and the netVMs.
This would allow to “swap” connections without restarting any VM and changing no VM setting in the manager.

To add to what everyone else is saying:

Don’t assume what is known is all that is out there; it’s a good way to get nasty surprises (hello Log4Shell). Keep the unknown unknowns in mind–especially when it comes to infosec. Risk management is the real name of the game.

2 Likes

Awesome :slight_smile:
Maybe this forum can be upgraded into the same mindset with disposable forum accounts!
Now we first have to create an email address, create a new forum account, wait for an email to be sent… before we can write a post. Very cumbersome.
It would be handier if we would have a choice: log into our non-disposable forum account, or log in as guest with a randomly assigned username, which becomes inactive after use. If that isn’t thinking with Qubes :smiley:

Other idea’s that would be handy :

adjustable titles for disposable qubes.
Now, if you have a dozen or more disposable qubes in use… things get consing… what disposable is run from what template and connected to what network? Now we have to open qubes manager and look at the numbers, for example:

  • disp4399 anon-whonix-dvm via sys-whonix
  • disp5028 whonix-ws-16-dvm via sys-whonix
  • disp544 debian-11-dvm via VPN1
  • disp6844 debian-11-dvm via VPN2

Maybe the titles of disposables can be changed in something like [disp# $templ $exit-node] $webpage-title Tor Browser
with $templ maybe something like:
$templ=d11 # for debian-11-dvm
$templ=d11min # for debian-11-minimal-dvm
$templ=fXX # for fedora-XX-dvm
$templ=anon # for anon-whonix-dvm
$templ=who # for whonix-ws-16-dvm
and $exit-node maybe a country-code, and ‘no-net’ for isolated disposables?

Extra colors
and maybe add extra colors… => 50 shades of red?
Now all disposables are the same kind of red… so are the other untrusted qubes

Being able to reboot a proxy-vm
now if we want to reboot a qube, for example a disposable [sys-VPN], we first have to disconnect everything that is connected to it before we are able to shut it down and/or reboot. I can see the point of this with a shutdown… but not so much with a reboot.
Like: sys-whonix hangs? Though luck as we have to change the network settings of each and every disposable qube we wanna keep using, reboot sys-whonix, then reconnect all those disposables again.

bonus
same as last suggestion but instead of rebooting the proxy-vm, first boot a new version of the (of course disposable) proxy-vm and replace the old proxy-vm with no network down time.

Yes, I love disposables! Best inventions ever!
I actually practice the same technique in my non-computer life: while working on a project, I’m 100% focused on the task. But as soon as the project is finished, it’s deleted from memory!
“Thinking with Qubes” = “living in the moment”
The only time is “now”, the only place is “here”. Time and locations are merely illusions…
The hubby/wife hates it though… “hey hon, how was your day?” => “hmmm… I don’t remember, project must have been finished…”

Awesome! You have my vote! (although disposable forum accounts don’t get to vote :p)

3 Likes