If this is using Debian. Does the Wireless Adapter need to be one which works with Debian?
Hi. I’m late for this thread but I’ve been following it from the beginning.
Wow. For quite a while now I’ve been thinking about jQubes (before this thread existed) and considered making some some “Trail Guides”. So it seams we are looking in the same solution space and came up with something quite similar.
The first things first is understanding journalist’s general workflow. I’d assume it’s goes from sourcing to publishing but there are many things in between in a journalist’s toolbox (think audio transcription software, VPNs, videoconferencing etc.). Then threat modeling and according to the 2 previous stages deciding on a decent configuration. For sure it’s not possible to have the perfect setup. But a good enough starting base would go a long way…
Ah. I had not noticed this was a project that was already planned. I’d be keen to share some thoughts or go for a synchronous meeting about the topic.
The tutorial’s code is published but needs documenting. I expect to have more news around September.
Thanks a lot for sharing your insights into the HRD’s field. I think there is a clear distinction between journalist’s thread models and HRD’s. Qubes does send out a lot traffic (e.g. when updating VMs) and doesn’t have MAC randomization and other kinds of protections that may be essential for HRDs and certain journalist’s. The simple fact that Qubes is not on a hidden volume can be life-threatening if the device is inspected and using something like Tails could be a better solution in those cases.
I don’t think Qubes only ready for this. It’s like regular organizations. Non-technical organization members need tech support and if we encourage others to venture in this direction we should make it clear that either we need to support them or that it will require some extra time and willingness to do extra work. When organization have the capacity to help with tech support then it’s another thing.
Yes, there is some talk about this: https://github.com/QubesOS/qubes-issues/issues/1019
@deeplow Wifi MAC randomization is default since 4.1, thanks to Accessible Security project and Nlnet.
I have saw that @unman has deployed new salt recipes for apt-cacher, another project that should get more love to be deployed by default to economize that precious bandwidth and URLs sanitized in some ways per Qubes, so that packages are downloaded once even if Templates are cloned.
I’m really interested in HRD, journalist and source personas myself. If some working group happens there, Harlo from FPF should definitely be on the call. Could reach her let me know.
This is amazing @unman. But i cannot get the next question out of my mind… Why are those not centralized, reviewed and upstreamed into Qubes? That would be the best solution, really. Just like your notes on how to write salt scripts. If there was a github Qubes project, where PR would be pushed and reviewed by you and others from this community, salt scripts would begin to be the norm under Qubes, and could even be packaged and deployed from dom0 repositories.
Why is that not happening? My dream and notes on persona on github addressed that before. The ideal would be to have those linked and regrouped per personas after. And later on: proposed directly at Qubes installation, with the installer, networked to get the latest versions of the Templates, in between releases, and newer versions of those packaged salt recipes. And therefore propose to the user collapsed categories of tested salt scripts preparing everything to be ready on next boot.
@unman do they… Really do run on installation?!? How do you do that!!! That is a long time dream come true if that is thr case and i definitely missed an episode.
@deeplow, this is EXACTLY what I had in mind. Seriously well done.
Next up, documenting it so the community can make their own “Trail Guides”!
Let me know how I (and anyone else) can help
@Wissam, would this be helpful for HRDs, like as a failsafe?
Thank you everyone for your suggestions, feedback and ideas.
I had not seen @deeplow’s tutorial and @unman’s “shaker.” The visual first-use tutorial would be very helpful. Integrating the “shaker” as well as other 3rd party scripts and salt stuff into Qubes would be very helpful. Maybe even a Qubes OS 4.2 that includes these suggestions as well as a < “create sys-vpn,” import VPN settings, put “username and password here” and “connect these Qubes to sys-vpn” > would be wonderful
@alzer89 that wish list sounded too technical for me.
This said, if journalists and human rights defenders/workers are the target, someone needs to reach out to them as well as to non-profits supporting cyber security for other non-profits, or supporting FOSS, or advocating for privacy as a human right, or defending HRDs. This is not the mission of Qubes OS organization, but few others have the credibility and know how to do so. Insurgo and Nitropad could do that as support for civil society and an investment in social causes? Maybe Qubes OS laptops should be available via groups such as www.techsoup.org www.stifter-helfen.de www.stifter-helfen.at www.stifter-helfen.ch www.techsoupafrica.org/en ? These are some thoughts.
Thanks again. Grateful for the work behind Qubes OS and for the community here on this forum.
Hi folks, just wanted to say that we at FPF are following this discussion as well–usability for journalists (and HRDs, but we work most often with journalists) is top-of-mind and it’s great to see this conversation taking place.
SecureDrop Workstation was mentioned earlier in this thread; as the name suggests, its primary focus is on providing a QubesOS-based SecureDrop client, but we’re also looking to work on other Qubes-based tooling that will be helpful to journalists generally. (That work is still in the very early stages.)
@Wissam - everything you shared is very interesting and helpful. It would be great to hear more about your experiences using and/or teaching Qubes to HRDs.
@catacombs - It sounds like a good next step could be to continue gathering some information from your target users–what tools and platforms are they using now to do their work? Do you have a deep understanding of their threat model(s)? Unless you’re familiar with their context/region, you might be surprised by the tools that a lot of HRDs use day-to-day, and that information will inform whatever tooling or guides you want to develop.
Will be following this conversation, interested in feedback from others working in this space.
In plain English:
- You want to go on Facebook or some shady website to watch free movies (as an example).
- You see an open web browser on your Qubes computer.
- You think “all web browsers are the same, what’s the difference?”, so you go to the website in your work Qube (with the blue window) without realising it.
- Qubes then alerts you and says:
a. “Hey, you know you just tried to go to a shady website in your work Qube web browser, right….? You sure you want to do this, buddy…? ”
b. “You fool! You could got hacked by doing this! I’m stopping you from doing this and saving you!”
c. “Ok, you’re obviously drunk/fatigued/under duress, so I’m opening that shady website in a disposable VM for you ”
- You say “Oh thank you, Qubes OS, you’ve saved the day again!”, and continue with your day, not being pwned.
That’s probably the simplest way I can explain it
Risk for both Journalist, and the Person providing information to Journalist. Easy install and use of VPN may be the very top of the list for benefits.
I have never heard the use of terminology. A Qube is effectively an entire different computer than another Qube. Meaning the user, when using Qubes, has at his disposal a large group of different machines.
Must be a better way to say that.
I was going to stay away for some weeks. Some oddities interfered with my plans, so I came by here. You guys have an interesting discussion going. From the standpoint of an individual providing information to a Journalist. I would guess the informant is not technological highly aware. Can not easily install VPN with Terminal. Informant may not easily type on a keyboard. I am thinking of a few, very few clicks to install a GUI for a VPN.
We should try to include in dom0, those copy and paste commands which are not likely to cause damage, should be included in dom0. For a newcomer, finding information online. Saving that to one Qube. Then ‘copy and paste’ commands from any Qube to dom0. Not fun.
My feeling is that computer security, actually involves both the sender and receiver of information being responsible for the confidentiality, the secrecy of information.
I think we need some person more technically aware than myself to suggest an encrypted Video chat. Wissam said, Zoom. What little I know is, all Zoom goes through servers in China. in 2018 the company which provides Zoom said they had improved encryption, but they would maintain control so they could provide information to police. I read that, if the Saudi government asked the Mainland Chinese government to tell them what was being said on Zoom. The Chinese would quickly provide it.
But I am usually wrong.
I feel I could follow the directions to implement VPN with OpenVPN and copy and paste. Not sure newbies could or would. That would seem a top priority. Not just another part of the list. But something that someone might suggest a way to create VPN connections with a GUI. Easily uninstallable for newbies.
Like always, I am usually wrong.
Thanks for the plain English version. Sounds interesting. Although it might add a layer of frustration that, together with other elements in Qubes OS, will make people throw their laptop out of the window
Glad to be of service. I will add a bit more about my experience using Qubes OS.
Once I was able to install Qubes OS, I had a year of time-consuming and frustrating hands-on learning. I was using it in the most basic format: work + vault. I had to invest an amount of time to figure out Dom0 commands, Linux install commands, where and how to install VPN, updating Fedora regularly (very annoying). Sometimes, the whole thing crashed. But I insisted. I also had to re-discover the Linux environment. I had last played with Linux in the 2000s. Back then, there were few videos and no forum. But the documentation was good. Some things didn’t work out of the box such as the camera (it was discussed here on this forum; increasing sys-usb RAM is required).
What was rewarding is actually receiving a virus in an email (Word file with Macro), and then sending it to a Disposable, and opening it there. I didn’t enable the macro, but it was fun. I also sent it to virus total from the disposable.
After a year, I felt more comfortable using it and I started testing minimal VMs.
During this journey, I tried to install Windows 7 a dozen of times and failed EVERY SINGLE TIME. I needed it for specific software. I kept a Windows computer on the side.
After two years, I convince 2 colleagues to use Qubes OS. After a month of helping them onboard, now things work. But they still need me to install a software because “apt install libreoffice” i a “template terminal” is a foreign language to them.
My experience is reflective of less than 10% of the journalists and human rights community. I interacted with over 100 key people over the past 2 years. Only one person understood when I described Qubes OS - a leader from India.
What my experience shows is the need of a nearby Qubes OS champion. Unlike a business environment where the company imposes Qubes on employers, journalists and human rights defenders are “free” to choose, but without much support to know what to choose. They need to be softly influenced.
One “solution” is proximity of the hardware and of the knowledge. People need to be able to purchase laptops with Qubes OS on them from trustworthy sources as I mentioned here.
And people need to talk to people for the on-boarding process (and as long as there’s not beautifully designed Dom0 level Qubes app store where you click on an app to install it a Qube). And they need information in their own language.
Another step towards a “solution” is some outreach and marketing to the human rights community, and the IT for HRDs community. That would be easy if you consider that many congregate in Geneva during the Human Rights Council, in Brussels around the European Union, in New York around the UN, in Nairobi and in Addis Abeba, and in other regional human rights meetings and events. Such outreach could include the Human Rights donor community, and human rights organizations based in the West, to get them on board in order for them to promote Qubes OS with the people who need it across the world, their partners and beneficiaries. I know a dozen of organizations in Europe that have networks, members, and affiliates all over the world. These are valuable networks to tap into to promote Qubes OS.
And I mentioned earlier, include in “Create Qube VPN” under Qubes Tools with easy to set up VPN Qube where OVPN settings are imported and iptables are preconfigured for leak prevention and re-routing Qubes via this Qube is simplified.
Journalists and human rights defenders need to demonstrate maximum flexibility and adapt to their networks and sources. I prefer Signal messenger for video calls. But in the past 2 months, I’ve had conference calls on Webex, Google Meet, Zoom, Jitsi and MS teams. Because I had to adapt to the people I’m interacting with, and to attend virtual events or large gatherings. Many people now rely on the Microsoft environment. And that environment works on Qubes but installing the right software is not straightforward. Neither is installing MS Exchange email on Thunderbird.
The ideal scenario of installing proprietary software in a dedicated template for a “video-conference-only” Qube, and where the proprietary software self-updates, is far fetched for HRDs and journalists.
I hope my suggestions are helpful and not just ramblings.
I would like to share some additional thoughts related to my experience in helping others use Qubes OS.
After installing and setting up Qubes OS for people and getting them to understand how to use their new desktop, there are milestones where I absolutely have to intervene. These milestones include user needing new software, upgrading Qubes from 4 to 4.1, Fedora templates change (install new template, install software, change templates). Major problems (Once, Debian 11 broke during update and I needed to re-install the template for a colleague). Minor issues that come up several months later (setting up dark mode, finding and installing a Linux software for generating QR Codes, etc.)
Qubes OS is incredibly helpful to prevent the human error and ultimately reduce the need for training for journalists and HRDs. This should be its main “selling” point. For example, a work Qube can be setup with to use Thunderbird IMAP email, Signal Messenger, a drive/cloud (could even be firewall-enforced), LibreOffice, and work on documents. This Qube would not have a web browser. URL website links from this work Qube can be re-directed (qvm-open-in…) to the untrusted Qube or to a disposable. The untrusted/disposable could even have a dedicated sys-VPN with a different exit server. Instructions can be given to NEVER input log-in information in the untrusted Qube (is there a firefox add-on for that?). An additional Qube is only for trusted browsing where log-ins are allowed. Another Qube is for proprietary conference software (see above). Etc. All this requires a Qubes expert to setup.
If someone is helping a journalist / HRD install, setup and use Qubes OS, they can opt for a complex setup from the beginning and invest time and effort to make it work. However, this means that journalists and HRDs need even more tech support than in my #1 paragarph. The most recent example of this is Signal Messenger. Signal messenger desktops only recently was requiring browser verification to combat spam. So if the Signal Qube does NOT have a browser, it’s impossible to do the spam bot “I am human” test. The journalist / HRD would loose access to use Signal. He/she need to contact tech support to get Signal to work again. It’s a simple intervention to fix Signal spam verification – sudo apt install firefox. It can be communicated remotely. But it’s not evident.
For a small subset of high-profile journalists and HRDs, evil-maid becomes a bigger risk after installing Qubes OS. In addition to other measures, an anti-evil-maid software/USB dongle is required. I never tested it because I don’t have TPM 1.2 hardware. I prefer latest hardware and speed over older hardware. This said, the main challenge here could be this procedure that comes up when Dom0 get some critical updates: “If you use Anti Evil Maid, you will need to reseal your secret passphrase to new PCR values, as PCR18+19 will change due to the new Xen binaries.” Maybe Insurgo/Nitrokey does’t require this? I admit, I don’t know what it means. But I read this in advisories and I if anti-evil-maid requires advanced technical procedure every few months when there’s a critical update. I may be wrong. Therefore, again, ongoing IT support is needed for HRDs and journalists.
Remote support works for me. I tried it via Signal. Someone holds the phone so I can see what’s happening on their screen. I was able to help solve problems via signal with people outside of the country. It’s tedious and included lots of typos in terminal on the other side. But it worked.
Backups and recovery. Someone might get his laptop stolen, or office raided and equipment seized. Or the laptop hard disk dies. How easy is it for HRDs and journalists to recover ASAP? A standard Qubes back requires a brand new laptop with a fresh identical Qubes OS installation. Depending on how complex the setup was, and the IT fluency of the user, this could require urgent and immediate IT support which may not be available immediately. This brings us back to square 1. UNLESS there’s a way to backup the whole Qubes system Dom0 + templates + Qubes and then import everything back to a fresh install. An easier backup option is to manually copy all files to an encrypted USB drive, or to copy using rsync. Recovery would need to be to Qubes or to a Linux laptop. So the question becomes: how easy is it to set up recovery procedures – acquire a new laptop, install Qubes OS or Linux, setup Qubes, copy files, and resume work?
With all this said, I need to repeat that Qubes OS is a mature OS that can work as a daily driver for demanding HRDs and journalists. This includes video editing, photo management and editing, advanced document editing and design, video conference, cloud drives, eBook management, etc.
Nope. That pretty much says it all. Excellent definition. Perfect for a regular person to understand.
All video chats are encrypted (and in 2022, if you’re silly enough to put ANYTHING unencrypted over the internet, you must assume that someone else has already seen it and tried to use it for something). That’s not the issue. The issue is who can decrypt them. The other issue is who can see it while it’s in transit, where it cane from, and where it’s going. For a whistleblower or HRD, the issue is the source and destination addresses of he data packets that are coming out of their machine.
A good analogy is the postal service keeping track of the delivery address and the return address of every letter and package they deliver to you.
What can they find out about you from that information?
- They can x-ray the mail to guess the contents
- They can measure the size and weight of the package
- They can keep track of how much mail goes between two addresses (and what type of mail)
Computer networks are exactly the same. If someone can see that you’ve sent/received a certain number of packets to a certain address, and nothing to any other addresses for an extended period of time, that’s a dead giveaway that it’s a VPN.
Also, if all your data packets are the same size, that’s a good indication that you’re using Tor or I2P.
How do they know? Because they’ve been carrying the data packets for you!
In some countries that’s enough justification for a search warrant, unfortunately.
Yes. There are things you can do to the data packets to make them more inconspicuous, but the point I’m trying to make is that encryption isn’t the problem here.
Because they’re getting potentially untrusted parties to transmit their messages for them.
That’s basically how the internet works, and why encryption is only half the picture (especially if someone is looking for you, like I’d imagine some journalists and HRDs would be…).
Yes. That’s true. They probably still do. And if they don’t, then it’s they probably have access to the servers outside China.
The location of the servers isn’t important. The issue is whether that server can decrypt whatever it’s relaying to each participant in the video room, or not.
If they can’t decrypt it, then it’s fine. But my guess is t that they can….
(If you’re selling a product, customers won’t accept “well, for protection of your privacy, we can’t actually access your data” as an acceptable excuse when their video room crashes… It’s not exactly good for business)
So that sounds like they can decrypt everything, so WHY ON EARTH WOULD HRDs USE IT?!?!?!?
You might as well be communicating over police radio… (a bit of an extreme analogy, but I hope it gets my point across that it’s a bit silly…)
You’re not wrong. There is always room for improvement in any piece of software. Keep the feedback coming.
The tiny misunderstanding comes from the way that VPNs are marketed, at least to the general public.
A VPN is simply encrypting your “stuff” before you send it over someone else’s network (usually the internet, but not always) to another computer. That stuff can be anything, but usually it’s network requests that you want that other computer to do on your behalf, and then “pass to you”.
I’m sure you already knew this
So what you need to create a VPN is:
- a destination IP address (Where do I connect to?)
- an encryption key (What secret code do we use to talk to each other?)
No special app. No fancy software. Just a config.
The issue with most commercial VPN providers is that some don’t want to have that config available. They want you to install their software.
NetworkManager already can read most VPN config files, and there is an option in the
nmapplet (the network thing in the top-right corner of the Qubes OS desktop that we all click to connect to a wifi network) to import a config but it’s not exactly prominently displayed.
So yes, I agree that unless you already know where to go, it wouldn’t come naturally….
Could have been Arch. That would have been much more frustrating
You always remember your first….
What software was that?
This is the information that would be extremely valuable in getting HRDs to adopt Qubes.
Destroying the notion that you “need” Windows because you need to run a specific program.
Then we will make a tutorial for this (and all the other things too).
Which is extremely difficult when tech companies keep throwing around meaningless jargon and “buzzwords” without ever explaining them properly…
I have a feeling that an “unattended install” ISO, or an option to do so, would go a long way in solving this.
Even if it’s incredibly bloated, so that it covers as much hardware as possible, that would still be a step in the right direction in getting Qubes OS adoption where it’s desperately needed.
If I had enough capital, I’d happily start a business in Qubes OS hardware, both ready to use, and “send us your own and we’ll set it up for you”. If only….
Yes, I agree. They also need to be able to have access to it, which I’d imagine would be difficult in some areas of the world with internet censorship….
But there is definitely a way to do it.
Do they ever have “trade shows”? Would a Qubes OS booth be worth considering?
It doesn’t matter what they use, as long as they understand how it works, where their data goes, and they’re ok with all of that.
Often times, the users haven’t got a clue….
Plus, sometimes it is good to “blend in”
Depending on the licences of the software, I’m fairly certain that a preconfigured Qube would be doable. Or at least an automated script that would make one.
The “Trail Guide” guided tutorial will address this.
For example, system updates could come with additional tutorials included on how to use them.
There could even be a guided tutorial on how to upgrade from 4.0 to 4.1. “Click here” “type this in.” “Well done. Now go get a coffee and we’ll do the rest”.
It can be automated, but we’d first need to know what sort of configuration would work best. But it can definitely be done.
They’re making excellent progress on getting AEM on TPM 2.0 chips, as well as AMD CPUs.
I’ve been testing them, and they look promising. Not ready yet, though, but soon
qubes-remote-support will help with this. Then all you need is someone you trust to help you.
That’s a good point.
sys-encrypted-backup, powered by
wormhole to sync encrypted backups somewhere.
Needs more investigation, but definitely something that could be automated.
I’m more then ready to train those organizations into having their IT dpt trained to prepare laptops by themselves and collaborate, train them into creating disk images that would fit their needs and training them into using Qubes, taking their direct inputs into modifying Heads/Qubes to make it better fit to their use cases.
There is even on-demand remote support (tor hidden service) that can be deployed under Qubes now, exactly to better understand and support them. With restorable states, journalists and HRD could get back to a safe state in minutes even if abroad. That safe state should match their exact software deployments and needed customizations though.
Have them ping me! This is exactly why I started Insurgo at the fist place. Those laptops should ideally be locally provisioned, and those journalists/HRD properly trained to use Qubes/Heads. And their usage and direct input and funding would help the whole ecosystem.
@Wissam : I really appreciate the distinction you are drawing between what we’ve called the “happy path” (daily driver Qubes usage, nothing wrong/no troubleshooting) and the ‘other’ path(s) (troubleshooting, reasoning about how to fix things). Our experience with training journalists on Qubes seems similar to yours: with a preinstalled/preconfigured system and a brief orientation, people can navigate the ‘happy path’ quite well, but the rough edges occur if something goes wrong; then, people do need 1:1 support, and this can be challenging especially if it’s happening remotely. Even a task like troubleshooting internet connectivity can present frustration for a new user without enough of a mental model of how Qubes works, especially if they don’t particularly enjoy computers in the first place, let alone a new system.
On a different level, one thing that we have struggled with conceptually is the level of responsibility we take on for a user’s threat model by providing them with preconfigured tooling. We have thus far not installed custom tooling (outside of SecureDrop Workstation) in specific VMs, and have instead given instructions to our users on how they can do so if they wish and at their own risk/discretion, because of the concern that shipping additional software/tooling would be seen as an indication of confidence in specific tools or workflows. (“This is safe to use–it came with my machine/it came from FPF!”). In reality we try to be really cautious when recommending tools/platforms/workflows because of how varied our users’ threat models can be.
So our current approach is erring on the side of caution (no misunderstandings about if we are endorsing a tool/workflow or not because we leave that up to the users), but also probably erring on the side of “less useful to end users.” It would be great to figure out if there are situations where we’d feel comfortable doing as @Insurgo, you, and others are describing in terms of easier-to-use/“out of the box” setups, and it would also be great to have some more cross-collaboration between HRD groups and Qubes users to discuss what some example best-effort configuration(s) could look like and who each one would be appropriate for. Just putting it out there that this concern is still an unsolved/ongoing one for us, and is something we welcome input on.
(Side note: The idea of a ‘best-effort’ configuration at a suite of tools reminds me of this project from a while back: https://github.com/equalitie/Caislean. I don’t know how well it got off the ground, because I think there was still a pretty big mismatch between people who could have benefitted from this vs their abilities to understand/configure/use it, as well as the trust required to do so).
Lastly: in terms of internationalization/localization, strongly agree with you that there needs to be more done to make tools and documentation accessible around the world. We have been incredibly fortunate to work with Localization Lab (https://www.localizationlab.org/) and their volunteers, and if you’re not in touch with them already you might be interested in connecting with them.
@rocodes, it would be incredibly helpful to have some examples “typical days at the office” or “a day in the life of a Human Rights Defender/Journalist in a hostile territory”.
I say this because I know I certainly don’t have a detailed understanding of their daily tasks, let alone their operational requirements, and I’m sure most of us wouldn’t. However, if we were given a scenario, would definitely have no difficulty in assessing what tasks would need to be done, how they would need to be done so that the user wouldn’t be compromised, and what third parties would need to be involved and how, in order to get those tasks done.
I think it would really go a long way in assisting those who design the tools to better suit their use cases, not just in the execution of those tasks, but also in the actual configuration and setup of those tasks by the end user.
As @Wissam explained about the two main categories of HRDs, this would be more focussed on the second group, who is forced to set everything up themselves, and doesn’t have the luxury of a big service provider who is available 24/7 to fix things.
Am I reasonably right in assuming that journalists could be classified in a similar fashion?
The key pieces of information for each task that would be extremely helpful would be:
What the goal of the task is, for example:
- Pick up a file from a whistleblower
- View that file in a safe way, without anything nasty in the file being used against you (phoning home, infecting your machine, etc.)
- Have a video conference with someone, and what the operational requirements of that video conference are
- Send/receive/store/view/convert sensitive information, either locally or remotely
- Purchase/book/reserve/pay for things online without leaking personal information
- The challenges of that task
- Are you being heavily monitored while you’re doing this task?
- Do you need to involve any third parties in order to complete this task, and how much do you trust them?
- Does the user need to “blend in”, or is it ok that they leak some information?
- Some examples of how these tasks are currently done
- Examples of software and service providers currently known to be used
- Are these approaches/methodologies something that your regular computer user would naturally do, or would they need to be consciously aware that they need to “do extra steps”?
- Is this way currently sufficient, or is there a better way?
The more examples, the better. Even niche ones. While they may not be worthy of a default configuration, they are definitely good to know, so that they could be factored into a flexible enough user interface, so they could be easily configured by by the end user.
Not only would it help in producing software designed specifically for that purpose, it would also greatly assist in adapting existing software to better suit their needs.
I am thinking about the method of implementation of additional Qubes for Journalists. That is, Qubes which are already prepared for use.
Seems likely a difficulty in terms of time, bandwidth. Security having two points.
Identifies user as using possibly using Qubes, unless they use a VPN. Even then. Possibly identifies them.
The size of the downloads being a giveaway to - a not so sophisticated government internet agency - or the NSA.
A huge aggravation to a non-sophisticated user. or anyone with a slower connection.
Is there a method to ’ use a script ’ to create a ‘Cloned Qube,’ and then download the software that is needed for that particular specialized clone Qube, resetting the name of the Qube - accomplishing this in a standard Qubes install. Still expecting the update system to properly update the newly installed software.
I have not written Salt. Does Salt do this?
I think we are at the point, where some of what I am thinking is needing for a Journalistic version of Qubes can be implemented in a short time.
AND: A few specialized Journalist-Qubes (and we can change that name) goes a long way to adding much security.
Can we make a short list -by type - to create? As like create a Clone’s (by name) of existing Qubes? List of Software that should be installed.
I recall seeing someone who create a specific Qube for using a VPN. Which other Qubes can be altered to point to. I guess I am thinking;
- If we are installing an App. Like the App for Linux provided by Mullvad. One must install the App each time, for which I have used the Qubes manager for that Qube to allow for the "Software manager to be turned on. To use the “Software” Manager to be used, one must allow the Software manager to download all its knowledge each time, (takes awhile) Then I can go to the place in files where the Mullvad App is - Right Click/Install with Software. Then one must install the Password each time. I doubt our developers have time to create a quicker method of install for Mullvad App. Which some can guess might have extra security risks - as opposed to “Open VPN.”
FYI: Open VPN is a standard Linux installer and programs for using VPN’s, which uses Terminal to have commands mostly copied out of text file somewhere, and Pasted into Terminal. Actually it is easier to use than it sounds.
That is, in the VPN Qube. We need to place a text file in which the instructions for using the Open VPN (for a particular VPN service) to be used.
I said for a particular VPN to be used. Which implies one has registered for service with one. Have obtained login Credentials.
My real point being: We don’t have to build a VPN Qube that works with all the possible VPN candidates. Lets select a few VPN services that are - trusted.
Anyone want add VPN candidates to list?
I will try to create a VPN-Qube for using OpenVPN with Mullvad, because as you can guess, I have login credentials.
Anyone want to point out how I am likely to mess this up? Like choose the wrong Qube to clone to create VPN-Qube. Oh yeah, most of the folks here on the forum tend to write in a kind of quick shorthand. Presuming the reader is knowledgeable enough to grasp a few details -like which Qube - to be inserted in the hierarchy of Qubes, (I think some call this the stack.) miss. Or what should be changed in the Qube to point to either Sys-Net, or would it be Sys-firewall?
For the time being, I also surrender my initial thought of installing inside dom-0 . As that has security implications to the ‘attack surface’ of Qubes I can not guess. Also might render a user where if something goes wrong with the VPN, he can’t use his computer at all.
Please criticize my approach. ?
- If you use something, and have an insufficiently specific/deep/technical understand of how it actually works, that is a recipe for pwnage
- A VPN is not a “magic bullet”, especially if you have no idea how a Virtual Private Network actually works, and what they were originally intended for
- Having a VPN client in its own Qube has advantages and disadvantages
- I really like @catacombs suggestion for a salt script to set up a
sys-vpnQube that can be placed anywhere in the
sys-whonix- AppVM stack, and I second the idea of its creation (if it hasn’t already been created)
- How can we make a pre-configured Qube for journalists when we still aren’t fully certain of what they actually do…?
- Don’t put anything in dom0 unless you really know what you’re doing
Only constructively, if i can find anything wrong with it
No, but in all seriousness, your heart is definitely in the right place, and all great things start with conversations like this
This assumes that all (or at least the majority of) journalists have the same workflow, use the same software, have the same work environment, and have the same understanding of “best practice”…
I really do like the idea of “purpose-built” qubes containing “everything you need” to get that task done, but I’m concerned that it will not be applicable to everyone that could potentially benefit from it…
Oh trust me, anyone who watches a 4k movie on <insert-streaming-service-applicable-to-your-territory> will download so much more than any Qubes template…
(the movie will be encrypted too, otherwise anyone in transit would be able to watch it for free without paying)
The internet is full of encrypted communications. It’s normal now. That’s not a red flag.
The giveaways for a VPN or Tor are usually:
- packet contents size (uniform, obfuscsted, non-standard, rotating, etc.)
- packet header (encrypted, unencrypted, standard, non-standard, matches a certain type of traffic)
- packet origin IP address
- packet destination IP address
- packet origin port
- packet destination port (which piece of software is likely to use it)
This is EXACTLY what salt does
We still have no idea what is actually NEEDED for a journalist to do their job. Sure, we can make educated guesses, but we could be totally wrong, and that would result in loss of the appeal of using Qubes OS as a journalist…
I second that. Or at least, the tasks that need to be done, and we can shortlist some software…
I would be very surprised if journalists didn’t have their own VPN server, particularly if they were working for a media organisation. Most big companies host their own for their employees, especially now, since so many people work from home.
If they were freelance, or if they wanted to blend in, then maybe they might get a third-party service…maybe…
This is one of the things that would be perfect for
qubes-onboarding-tutorial when it’s ready. We are working on it.
People would be able to create their own guided tutorials to set everything up, including different vendors’ VPN clients.
You won’t “mess up”… you just might end up with a different result than the one you are expecting. But the more you tinker with it, the more you’ll see that; and you’ll end up with a configuration that works for you (and a much deeper understanding of Qubes OS)
I’m not being sarcastic or cynical. I’m being genuine. Your enthusiasm is formidable. Just make sure you do it on a machine that you’re prepared to “brick” (ie a “testing” machine)
I’ll give you a quick rundown of exactly what you’re aiming to achieve, and why you’re wanting to achieve it.
All of this already exists in
sys-net in the default configuration. The Fedora template that the standard
sys-net is based on contains NetworkManager, which manages your NICs (Network Interface Card, basically the hardware your computer uses to connect to networks like LAN and the internet), as well as all the configurations needed to connect.
To add a VPN config in
nmapplet(the “NetworkManager applet”, or the red thing in the tray that you use to connect to wifi), and click on “Edit Connections…”
Click on “+” to add a new connection
Select your VPN type from the list and input the config
This assumes that you know:
- The IP address of the VPN server you want to connect to
- The port on the VPN server that you want to connect to
- Any login information required (username, password, certificate, key, etc.)
Either punch this information in manually, or input a config file (whoever is running the VPN server you’re trying to connect to will have made one of these for you, or they will definitely be able to give you one if they haven’t).
Yes, I know it’s not exactly easy to find, and I definitely agree that this could be made more accessiblle, but the fact remains that it already exists.
The whole reason that the standard Qubes OS configuration is like this:
Outside world → My Machine (via NIC) →
sys-firewall → AppVM
…is so that:
- Malicious NICs can’t see the AppVMs
- The network hardware can only see what is being transferred, but not to where
- To a lesser extent, AppVMs can’t tell where it is coming from
- Prevents malicious user software from being able to hijack your NIC and make it do things without being detected
If you put this in the same qube as your NIC (wifi, ethernet, zigbee, zwave, etc.), and you have malicious hardware that can somehow do things to your
sys-net like keylogging, digging around your storage, stealing encryption keys from your RAM, or a bunch of other things; then putting your VPN config inside the same Qube might not be the best thing to do…
On a sidenote, there is a potential that Intel vPro has that capability, and I will happily retract this statement if it is found to be false, and I will be very relieved to do so, too…
If this is the case, then having a separate Qube containing the VPN client would be better, because it will encrypt the traffic, and then pass it to
sys-net, and all
sys-net will see is this:
M�Ē�?�:���'ɜ��&0QQA���"�����_�4+~�����@��:� ����2��k���}��j��7�u��zBL:�����0��;���z�|3�9�*`��g6? �|p�[�)rHSGk'C�0�L�K�-.����ZT�J��kٌպY�j��O��,�HF���}P�m��ޛ\]j?� ���r�k����}&YV�Q�y� ,�?V(;�'�O�����p�jg�%l���$���bZ���P���E��
…basically indecipherable gibberish…
If your NIC is malicious, and can interact with your RAM CPU and/or storage, then it could potentially “fish around your machine” for the encryption keys (and send them to whomever your NIC is working for).
If your NIC is compartmentalised within
sys-net and cannot interact with the software that is encrypting your VPN traffic and storing your encryption keys, then that provides an extra layer of protection against self-pwnage and malicious hardware. At least, that’s what it’s supposed to do
That would work, too. In fact, it would allow different Qubes VMs to use different VPN servers. This can be very advantageous, because anyone monitoring the network won’t see your machine sending gigabytes/terabytes of data to just one IP address on just one port all day
It would mean that any malicious software you were running inside the same Qube as your VPN client could potentially grab your encryption keys…
That would work, but then every single open Qube would send everything through that VPN. Not necessarily a bad thing, but it’s important to know.
I’d say so. It would allow you to isolate the VPN client (in case it’s got nasty things in it), feed it data packets from another Qube, get it to encrypt them, and then pass it to
sys-net, and your NIC has no idea how it was encrypted (and your potentially malicious software in your AppVMs don’t know they’re using a VPN, either, which is good in some situations).
Dom0 is meant to do as little as possible, and that’s for your own safety.
It’s sole job is to boot your hardware, and then pass hardware resources to and from VMs. Nothing more.
Think of dom0 as like a BIOS/bootloader for your VMs
(yes, I know there’s a lot wrong with that definition from a technical perspective, but it explains dom0’s role perfectly)
It is an extremely stripped-down Fedora installation with a lot of things deliberately removed.
A lot of commands are deliberately uninstalled (
ssh, are all taken out). Sure, you can install them if you really want, but I wouldn’t recommend it unless you really know what you’re doing. You have potential to not only break stuff, but also leave your machine wide open…
Trust me, the less you do in dom0, the better
I think it’s safe to say that I clearly do not fit that description
Very interesting points in this post, which is a bit beyond my understanding though.
Can you expand on what Intel vPro is? Is this related to the Intel ME which is possible to disable?