Security questions (templates and kde)
sevas
Does installing KDE have any tactical disadvantage to security?
Yuraeitha
> Does choosing a TemplateVM have any tactical advantage to security?
>
>
> Does installing KDE have any tactical disadvantage to security?
First you would want to split up the comparison further first, for example the security that prevents an attacking from breaching fedora/debian/whonix and gain unauthorized access to dom0 "should" be about the same no matter which template you choose for your AppVM's, it should be the same hard to breach security. Of course an attacker would first have to breach an AppVM before they can try breach dom0, but the way I understand it, if dom0 can be breached, then so too can the AppVM's security which is supposedly easier to attack, than it is to attack dom0 from the VM. But having extra security in the AppVM won't harm and adds some extra layers of protection to dom0. If you're a low profile target, then it may not be worth the trouble for the attacker to get at you without some kind of pay-off or reward at the end. The more tricky you make it for them, with the less motivation incentives, the more secure you are. Of course making it too tricky might also serve as a challenge to be broken, so don't become a target by making yourself stand out as a challenge to be cracked either. Try mingle in the crowd, i.e. act the same way as other Qubes/Linux/WWW users do. It may also be worth it to hide that you're a Qubes user, or even that you're Linux user, whereever possible, so that you don't attract unwanted challenge attention.
As for the templates, Fedora has more frequent release cycles, while Debian is more slow release cycle based.
Debian - As far as I'm aware, the Debian Project Leader is voted on annually by a democratic community of developers and maintainers. Debian is more slowly releasing, and generally focus on stability and reliability.
Fedora - On the other hand, is acting like a test-bed for Red Hat Enterprise and CentOS, and release updates and new features quicker in order to test them out. Some of the leaders, including the Project Leader, are appointed by Red Hat, while seemingly a lot of the leadership is community based.
In general it seems Debian relies on longer testing periods to ensure reliability, while Fedora puts in more effort and does it quicker. Which is best is probably a matter of which approach you deem more reliable. If you trust open source review, editing and testing, then debian is more reliable and secure. But if you trust experts to be able to put it together better than open source reviews can manage in a relatively short time-frame, then fedora is more secure. Generally the belief that many open source projects take time to review, which goes to say that Fedora can act quicker on issues than Debian can do, because Fedora is more centralized and focused, while Debian is more decentralized and community dependent.
Personally, I don't believe the open source aspect is always living up to its name, code is not always being reviewed and checked for errors and security flaws, and maybe some are so sophisticated that the reviwer don't see them until years later when someone else discoveres them, and in all that time in-between you have no idea if some skilled hackers, groups or organizations have used these exploits to their own gain and interest. More time won't nessicarily change open source code reliability and security, it also needs people actually looking at the code too, which is a given but often forgotten element. Fedora is in that sense better as more ressources are initially invested into the test-bed, but it still preserves the open source aspect as well for long-term open source reviews from third-parties. The pre-zero-day attacks disvocered from Fedora are also less likely to be spread wide and far, and may likely be exotic among the group of the very, very skilled hackers/orgnisations, but not so common-place on the internet. The odds of you being the target of a zero-day here is therefore less.
Debian also patch up security issuered discovered as time go on, but is as I understand it less quick to have their own code reveiwed, and features are slower released too. The stability is a strength towards Debian, security updates from third-party code is also quick, but the review of own code is likely not as fast as Fedora's. But with fedroa you have to sacrifice some stability, although not much, but some nonetheless.
It's an subjective evaluation, but honestly I feel fedora is more secure, while debian may be more stable, but in the end they are still somewhat close to each others in terms of security and reliability.
Of course beyond that, the normal firewall policy and security oversight implemented in normal Linux use-cases, should also be done in the Qubes templates too. While much of the templates are cleared when the AppVM is restarted, some scripts and code remains in-tact between restarts, like /rw files, and the Home folder in general. This is mostly a shared issued for all templates though, although you can manually lock down some of the AppVM's by moving the border of which can be preserved between AppVM reboots, and what cannot be preserved. For example making some parts of the Home folder unchangeable in the AppVM, so they revert back to default the next time you start it.
As for KDE, there are two things to consider here, one Linux general consideration, and one Qubes specific consideration. In Linux general, the user-interface is run under the init of user control, which means it has no root access, and should not have it if it has. Which means it's very limited what can be done even if KDE (or any other GUI) is exploited and attacked. The second consideration, from a Qubes perspective, is that KDE (or any other GUI) are locked inside dom0 without internet access, and they are not involved in the VM/AppVM processes, which can run just fine without a GUI loaded (no x-server running).
I think KDE is probably less stable on Qubes 4 and maybe recent updated Qubes 3.2? because the developers focus a lot on the future of Qubes atm by re-shaping Qubes in Qubes 4 release, which is taking a lot of work and effort. I don't think KDE is being very maintained right now (but I could be wrong about that). In general I recommend you modify XFCE4 instead, with some tricks and creativity, you can make XFCE4 look very nice, stylish and good looking.
Does that help a bit?
Chris Laprise
> Does choosing a TemplateVM have any tactical advantage to security?
>
>
> Does installing KDE have any tactical disadvantage to security?
>
security profiles with varying advantages. Some specific points:
* Debian is probably your best choice for all-around security and
functionality, particularly for people asking the above questions.
The Debian template currently, however, comes in a fairly 'minimal' form
which is more secure out of the box but needs a bit of attention to make
it more functional. A shortcut to adding desktop features to Debian is
to use 'tasksel' and choose a desktop type such as KDE, Gnome, etc.
* KDE is used in the Whonix templates distributed with Qubes. Its fine
for use in template-based VMs.
* IIRC, Fedora was initially chosen by Qubes developers out of
expediency and they have stated an intention to eventually move away
from Fedora toward something like Debian.
In particular, Fedora's downfall is that its one of the very few distros
that don't sign/secure their overall software manifest; a MITM attacker
can prevent you from receiving specific bug fixes without you realizing.
* The fedora-minimal templates may enhance security for some users and
admins familiar with Linux, but the above software security problem
still exists even there.
* Some specialized and experimental templates exist that (supposedly)
have security advantages. You can do a search for 'unikernel' for
example and try that if you're apt.
* Template security can be enhanced in other ways that are not very
complicated. For example, you can enable sudo authentication[1] in VMs
and enhance that further by adding a service like Qubes-VM-hardening[2].
AppArmor and other measures can also be enabled, but they're not distro
specific.
Finally, Qubes is designed so that the biggest factor in maintaining
security is always how you divide up your data and workflows between
VMs; Choice of template isn't as critical.
--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
sevas
We speak of stability. Stability and vulnerability go hand in hand, dont they?
I love the kde plasma desktop and I would like to have it. But it looks like a complicated GUI that probably is not as secure as something more simple. But again, the non-root GUI is not going to connect to the internet.
My previous feelings were to use one template for internet access and one for background/desktop/personal use. But that may not be needed since applications available in a template are not necessarily used in the appVM. Is that correct or would there be some data leak?
XFCE is something I havent used in a long time, but I will surely look into my customization techniques before I make a big move.
Yuraeitha
I recommend you listen to Chris here though. As mentioned some people are much more knowledgeable than I about security while I'm still only an early learner (and he's one of those who are much more knowledgeable). I also learned from reading his post as well. You can use my post to put forward new questions though (keep learning and dig deeper over time), but use Chris post for actual answers here regarding the security, he's way more credible. Notice too how he legit dismantles my argument "that Fedora is the slightly more secure one", when it turns out Debian appears ahead of Fedora in terms of security, and it seems like it might not be by just a little either. I stand corrected, I need to read more on this topic.
Keep learning though, it's awesome you ask and try find answers to questions like these.
Yuraeitha
About the stability going hand in hand with vulnerability, I view it the same way too, though it's not always the case if it isn't possible to exploit it, which also isn't always possible too.
Qubes once used KDE btw, you can find the discussion that made the change from KDE to XFCE5 here https://github.com/QubesOS/qubes-issues/issues/2119
Some of these issues I believe have changed though, what is perceived as "ugly" was back then a bit of an unlucky controversial statement due to different subjective opinions and it caused a bit of a stir in the KDE community. But I believe KDE also corrected some of those issues since then?
It's a good idea to keep your critical offline app's and data in an offline VM btw, keep doing that. You can also find multiple of official Qubes recommendations suggesting this offline AppVM move. For example the Split GPG guide in the Qubes doc's recommend this approach in order to keep your GPG keys more secure from being hacked. For example if only one application makes an outgoing opening in the firewall in the AppVM, then data in that AppVM might be opened to risk through exploits and attacks to that established connection. I have about 15-17 AppVM's which I use, not including the ones I don't use or templates, and I'm probably a light AppVM user compared to the more extreme ones. If it seems overwhelming though, try start with a set smaller number of VM's, then as you get used to it, try expand with a couple of VM's at a time. Think about what it adds to security or practical use-cases, and keep reviewing your VM layout :)
I believe there should be no issue switching between XFCE4 and KDE though, since the guide to KDE doesn't mention deleting XFCE4, just disabling it (at least it didn't at the time I read it). So presumably you should be able to switch between them with 2-3 commands in the tty terminal. You mihgt want to double-check that though, for example can you keep switching between them multiple of times without causing any harm to the system?
Tim W
Correct. I have had both on and functioned fine.
For secuirty I see little difference other than maybe the amount of code. The more code ,all things being equal, the more possible holes errors surface area to attack.
Yuraeitha
The big issue with Fedora that Chris pointed out worries me though, with man in the middle attacks on the updating/install processes. Potentially anyone could then be targeted very easily, or are such attacks more exotic and tricky to perform in a real life setting? I don't suspect they are as easy as to allow script kiddies to do it, but it might not take the most skilled hackers around either? We're not even talking about infecting packages here, but just preventing critical updates from reaching the targeted update system. This seems like a very big deal, and appears to hurt fedora's reliability, trust and security. Maybe I'm blowing this out of proportion from reading this, but it just seems "Bad!" with a big fat capital letter B!.
If I was an attacker, this is certianly a method I would find feasible by the sound of it and try look into. Seen from an attackers PoV, why wouldn't an attacker use this method? It seems ideal and effective, which is what scares me about it.
If there is a way/method to circumvent and avoid this issue, then it needs to be made an issue that more people are aware about?
Yuraeitha
The strength of Qubes is that it takes resourceful and skilled attackers to get through, and maybe some social engineering to boot. It's not as straight forward as exploiting fedora seems to be. If something like this is "this easy", then it's very off-putting and worrisome, because then "anyone" could do it, and that to me seems to just undermine "everything". It probably matters less for dom0 though, but I'm certainly considering replacing fedora for debian on my sys-net, sys-firewall, and other online VM's with critical infrastructure, though not jumping to conclusions "just yet" either.
Amilton Justino
> Does choosing a TemplateVM have any tactical advantage to security?
>
>
> Does installing KDE have any tactical disadvantage to security?
I agree with Chris Laprise: the choice of the model is not critical.
I use some distros in Qubes:
Debian, Fedora, Ubuntu, slackware, blackarch
More important than distro is their mindset for workflow, segmentation and security issues.
Thank you for the explanations Yuraeitha and Chris Laprise.
sevas
>In particular, Fedora's downfall is that its one of the very few distros
>that don't sign/secure their overall software manifest; a MITM attacker
>can prevent you from receiving specific bug fixes without you realizing
The above statement reminded me that it says that in the docs. And that does seem like a make or break statement for template choices. Key signing is a fine implementation on qubes.
ha, I did read that one too about the ugly kde.
@Yuraeitha
I havent quite tackled the security through compartmentalization part yet. I have put some thought into it though, and after dividing my attack surface between functions (keyring, passwords, misc files, etc) I realized that each function has only one app to go with it. So I may as well just have one app running in each VM. Or in the case of splitVMs, multiple apps for each program!
I would love to hear how you divide your VMs up. I was looking for examples online, but I couldnt find any; aside from an (ITL?) essay I read last year. But starting easy and growing is good advice.
>In particular, Fedora's downfall is that its one of the very few distros
>that don't sign/secure their overall software manifest; a MITM attacker
>can prevent you from receiving specific bug fixes without you realizing
The above statement reminded me that it says that in the docs. And that does seem like a make or break statement for template choices. Key signing is a fine implementation on qubes.
@Tim W
>Correct. I have had both on and functioned fine.
Thats good to know. I know I read somewhere that it was buggy with 3.2, I think?
As far a attack surface goes, I like using konsole better than xterm or uxterm and when installing that on debian or fedora, it required many dependencies. I removed it, but Im going to take a second look.
Steve Coleman
> I havent quite tackled the security through compartmentalization part yet. I have put some thought into it though, and after dividing my attack surface between functions (keyring, passwords, misc files, etc) I realized that each function has only one app to go with it. So I may as well just have one app running in each VM. Or in the case of splitVMs, multiple apps for each program!
>
> I would love to hear how you divide your VMs up. I was looking for examples online, but I couldnt find any; aside from an (ITL?) essay I read last year. But starting easy and growing is good advice.
own VM compartmentalization with two use-cases, work and home.
At Work:
One VM is specifically designated for "Internet" browsing, and it has
every security plugin that I could find that offers any additional
measure of security. That's of course a balance of risk, because
somebody whom I do not personally know had to write that plugin. But
again that's why I believe programs like IDA Pro and radare2 were
written, for us insanely paranoid software geeks. In some rare cases I
simply use a DVM for browsing the darker corners of the Internet, or for
researching/checking any kind of untrusted URL's I might be weary of. I
can't use whonix here so the DVM is the next best thing for this.
Each "project" I work on with any kind of "need-to-know" associated with
it (specific contract, internal documents, preliminary research,
Wan/Intranet search, timecards, etc) gets its own VM by default. Its
better not to mix some things, so keeping them separate is often safer.
Because the SMTP infrastructure was not designed with
compartmentalization in mind, and I only get my one email account to
work with, this single "email" VM is highly isolated. It gets its own
software locked down configuration and is firewalled with a default-deny
network policy. The only services that this VM can get to on the network
is the required SMTP services, network authentication, and the necessary
signing key management. No internal websites, no external sites, only
the email App runs here. Well, Ok, the calendar too. Anyway, there
should be no "phoning home" from here, other than through per use 2fa
outbound email. Should any rouge malware be received, all attachments
are first scanned and "tested" in a DVM instance before being separated
and pushed across to the appropriate project VM for storage management.
All project related historical emails are then migrated to an off-line
but searchable storage by project. This specialized email VM essentially
sorts, filters, prioritizes, and bins any incoming data/mail for easy
processing.
At Home:
Each member of the family gets one VM for the Internet. Personal email
comes to each individuals account. These accounts are not used for any
financial purposes.
One email account is used for household billing receipts and
collecting/separating tax related documents, which may then get pushed
to a "Vault VM" used for eventual tax preparations or long term archival
storage. This VM gets limited use as it never browses the Internet and
rarely ever sends email.
One VM is for general Purchasing, and is used only for that. You find
what you want on the Internet then cut and paste the URL here. Its an
intermediate level of security because credit cards have a limited
personal financial obligation if the number gets away from you. Its very
inconvenient if it does, but life does not end if that happens. Still
you want to be cautious here by limiting your overall exposure to the
Internet to just the sites you actually buy from.
One VM is for Banking and only that. No searching for anything, no
email, nothing. If a bank account number gets away you re generally
toast. Your not getting it back unless somehow you can claim it under
some kind of insurance coverage. Its a much higher risk for loss and
therefor needs to be treated as such.
One optional VM is allocated to general Investments monitoring, but it
has no financial accounts associated with it. It only keeps track of
numbers for things you want to monitor, and does financial computations.
Basically its for planning retirement. This is an idea I'm still toying
with but have not settled on any particular set of tools, as I may be
writing what I really want, but who has the time?
The Vault VM, with no network, meant for off line storage of important
documents, before being archived off line in cold storage. Things like
this years tax receipts might be a good example.
Steve.
sevas
So, another infosec question Im trying to figure out...
Templates Vs AppVMs.
I find myself with, currently, 8 templates and growing.
This is because I am installing different programs in different VMs
and Im not wanting to install all my programs into a single VM.
Of course, one solution is to install all my programs into a single
templateVM and only enable the programs I need in the AppVM.
But it seems more secure to me if I keep different templates for
different needs and then create a AppVM to run them in. Is this
good or am I wasting my time and hard drive space?
For instance I have a template specifically for one set of
sys-net/sys-firewall and another template for sys-net2/sys-firewall2.
And another the vault and more to come.
awokd
> Of course, one solution is to install all my programs into a single
> templateVM and only enable the programs I need in the AppVM.
>
> But it seems more secure to me if I keep different templates for
> different needs and then create a AppVM to run them in. Is this good or am
> I wasting my time and hard drive space?
large approach to TemplateVMs.
Small- doesn't even need a desktop manager like GNOME; xterm only;
required utilities only for sys-* VMs
Medium- the standard fedora-26 or debian-9 template with a handful of
small utilities for password mgmt. etc., for most non-sys-* AppVMs
Large- Medium plus Java, Libreoffice, photo editing etc. AppVMs based on
this never get a network connection and are used for document mgmt.
Yuraeitha
Before that I should probably mention how I initiate them too. From the beginning of using Qubes, I transitioned from the default Qubes XFCE4 menu to the Whisker menu, and then finally from the Whisker menu to a handful of Launcher plugins. I still use the Whisker menu, but only lightly for things I didn't put in the launchers. Both the XFCE4 launcher and the XFCE4 whisker menu plugins are included in Qubes 4 RC-2 and RC-3. I'm not sure about RC-4 and RC-5, but it's probably there too. Qubes 3.2. doesn't include Whisker menu, but it includes the Launcher. Also both Whisker menu and Launcher allows you to change icons, name and even the path to files. This gives you a LOT of flexibility. You can also easily add scripts to launchers or the whisker menu, but it's even more easy with the launcher because it essentially creates copies rather than linking to the original shortcuts. So if you for example take a random shortcut in launcher, and you edit it by changing the icon, name or the path, then it will not change the original shortcut. This is one of the reasons I like launcher's so much, though, not the only reason. It can also be done in a way that it looks very stylish if you're creative with it, and it's also much quicker to access your various of apps. Furthermore it's easier to keep track of all the Apps you use this way. Some of these might be subjective taste, others may apply to everyone. But give launchers or even whisker menu a try and see if it fits you after you modified them to fit your needs.
I put some 6 to 7 launchers next to each others at the upper left corner. There are different ways to do this with Qubes in mind, for example two clean methods are to either put a single AppVM or similar AppVM's in a single launcher and then have multiple of launchers for different AppVM's, or instead put all browsers in a single launcher, all file-managers in another, all system tools and various VM terminals in another, music players and things like these in a mix launcher, work tools like libreoffice and similar in yet another one. To add a finish to it, I changed the color to dark, and found some cool looking stylish icons free to download and use, i.e. from devianart. Only get the png or jpg formats, preferably png though. Moved them to an offline AppVM, and then selected some 15 at a time, and right clicked and used the convert to trusted img. Which is like using the qvm-convert-img command. This way you can remove exploits that might be hiding in pictures, and since it's an offline VM without internet access, no new threats harm the new picture icons. From there, you can move them to dom0 with using the Qubes doc guide. Still, be careful, even if you cleaned them, moving things to dom0 shouldn't be done too carefree, and it's habit forming. Try not to fall into the habit to do much in dom0, though sometimes you'll need to of course, but one of Qubes major fundamental ideas is to isolate dom0 as far as possible. Though this isolation might be more feasible with future Qubes when move is moved out of dom0 and into sub-VM's, like what is planned to be implemented in Qubes 4.1., where we hopefully will get AppVM's that can run discrete powerful graphic cards without introducing new security holes. So until then, some things still needs to be done in dom0, but be very careful if you want to keep it secure on a somewhat trusted level.
About templates, I always keep mission critical AppVM's on clean templates, sometimes even minimal templates which Qubes also offers as an extra download. For example sys-net and sys-firewall AppVM's and similar, I always put templates with as little installed clutter as far possible. Then I keep extra cloned templates that hold special repositories, like for example RPMFusion for fedora, and similar. For example RPMFusion allows you to easily install html5 support in firefox through ffmpeg package, to name an example. Such extra packages may not always be desired in other AppVM's though, so I keep clean versions of important templates, and an extra repository version as well for those that are needed. Beyond that I sometimes make templates with unsafe code, rather than installing such code in a clean or semi-clean templates with extra repositories. An example is Skype, which I definitely don't trust. So I put the likes of Skype on a template of its own, maybe with other untrusted code. If I know the code is harmful, or my trust in it is even worse off than the above example, then I make a template for that as well. Essentially try not to mix bad code together, but also try to avoid too much redundancy, the segmentation should make sense.
There are also things like bitcoin or GPG tools, these might also warrant a template for just those, in order to keep the clean templates clean, and also not to use the others with either unclean code or extra repositories. So these better have a template on their own as well.
All these templates are hard to keep up-to-date though, that's why I'm working on an update script, which will keep everything up-to-date. But it's not fully done yet, though it's close. Nothing too advanced though, and some more skilled people should probably have a look at it to criticize and find issues, before sharing it with others.
As for AppVM's, as mentioned, the splitGPG is one of those. You can do something similar with Bitcoin too. That's 3 AppVM's already. I use an AppVM for Qubes community, as well as one each for my studies, work, and shopping. I got one for Chat's too, so that potential chat exploits are isolated, but at this point you will need at least 16GB RAM or you'll run out of RAM too easily by having AppVM's running in the background for single things like these. I manage to get by with 8GB RAM laptop, though it requires to shutdown un-used Apps, so I get by. (Planning to buy minimum 16GB laptop soon though as 8GB just isn't enough even though I can get by with it).
I also have an AppVM for shopping, which then isolates all the tracing these companies love doing to their customers. AppVM's like these can also easily be cleaned or even just delete the whole thing and make a new one, without having to do all the other browser restoring again, like passwords, etc. You can also more easily disable cookies and java-script here, and only enable it if you need them to view some single website using it, or when buying. If you push this to the extremes, then you can have a second buying AppVM where you copy/paste your buying items, so that you have a shopping-discovery AppVM, and a buying AppVM. But it might tire you out after a while if you do that, though, it's certainly an improvement, albeit, maybe minor (depending on the websites you visit of course, as well as bad luck).
You can also have an AppVM for banking (not buying, bot to access your bank accounts online). Here you can also keep it clean and free from other things. You can even use firewalls to lock everything down, so that you only allow the connections between your AppVM and your bank. It sucks if your bank use many different web addresses and ports though, but it might be doable depending on your bank service. These firewall rules are probably minor security though, since if there is nothing else in the AppVM, then the NAT firewall rules should be sufficient enough. On the other hand, extra firewall rules might help you prevent accidentally doing other browsing stuff in your banking AppVM.
I got an AppVM for streaming websites as well, and also one for youtube and such online services for media streaming. The reason I made another for Youtube and not just merge the two is to cut down on the different businesses spying. For example Netflix won't know about my Youtube'ing, and Google won't know about my Netflix'ing. Although Netflix probably won't be able to spy anywhere near as much as Google or Facebook website scripts can do though.
Facebook and similar is another example, while I'm not a big user of social media, it's sometimes needed. By blocking everything social media in all other AppVM's, I keep some AppVM's for social media, which are also segmented for each company to cut the ties between them.
I got an AppVM which is purely offline and has no internet, which is running background apps, like offline music, taking screenshots (I made a script that automatically moves all dom0 screenshots to my offline AppVM as I take screenshots), and other offline stuff like this.
I got a printer AppVM as well, where I can open any files from another AppVM, and print from it. My plan is to eventually make a second disposable AppVM which holds printers, and another disposable AppVM which is clean. But I haven't gotten that far yet, I'm still improving and working on how I use and manage all my AppVM's, and it will probably keep changing over the coming years, especially as I learn and more Qubes features are introduced, as well as new thirdparty services become available.
Of course I got an AppVM for regular browser needs. Like some other AppVM's, the strength here is that its easy to clean it all up.
Some of these can be run over TOR with a wonix-ws AppVM, though be careful, the end-nodes of TOR are generally not secure (trust worthy). It's a swarming place for organizations with a lot of resources to try keep track of everything coming in and out. I.e. don't rely too easily on TOR for anything with identification information on you, or with services that has poor end-to-end encryption. For example hackers could at one point see what people watched on Netflix, despite that it was supposedly end-to-end encrypted. I'm not sure if that even got fixed today, it wasn't too long ago either. But it goes to show an example where encryption fails. Even if the mathematics of encryption can be reliable, the applications and services making them tick? not so much. Be careful, and take that into consideration too when you build your AppVM environment.
I also got an AppVM for smartphone, so that it can't infect my Qubes system. And stuff like that. I haven't mentioned all my AppVM uses here, but you get the picture I think :)
Yuraeitha
I also made a launcher for all my Qubes scripts that I didn't keybind. They are definitely valuable for purposes like that as well :) You can also make scripts that sends commands into an AppVM from dom0, so essentially, you can securely control it from a secure domain, but also at the same time link keybinds in AppVM's to your keyboard or XFCE4 shortcuts. Scripting in Qubes is awesome. But be mindful of running dangerous or unknown scripts, they can do a lot of harm, in particular in dom0.
I suspect at some point we might be able to move scripts out of dom0 though, actually, it might even be possible now with USB keyboards? I'm not sure, I have to check that one day, it would definitely make scripts that control AppVM's more secure. But the issue here is probably the few scripts that control actions within dom0 though. For example changing screen resolution and move the screen to left or right, i.e. when plugging in an extra HDMI TV monitor or projector. This too might change in Qubes 4.1. as well when how graphics works in Qubes is changed. Well, there is definitely a lot of things to think about and reflect on, but that too in and on itself can be fun if you enjoy solving small puzzles like these.
Yuraeitha
heck even dating is becoming a new huge business these days, especially with all these new tools and algorithms to pair people. It makes sense to make an AppVM for stuff like that too, don't use your phone for it, and stay clear of the advanced dating sites.
This is a good example of data mining, where people might forget their privacy. It's essentially a gold mine for data mining, and we're probably gonna see huge industries in the coming years, privacy traded for love. It's a sad development. Nevertheless, AppVM's serves as a good use here too to minimize the profiling companies whom seek to profile everyone and know everything about you, so that they can sell your profile for profit to anyone who wants to buy.
Mike Keehan
Yuraeitha <yura...@gmail.com> wrote:
>
> > I would love to hear how you divide your VMs up. I was looking for
> > examples online, but I couldnt find any; aside from an (ITL?) essay
> > I read last year. But starting easy and growing is good advice.
>
> Sure :)
>
> corner. There are different ways to do this with Qubes in mind, for
> example two clean methods are to either put a single AppVM or similar
> AppVM's in a single launcher and then have multiple of launchers for
> different AppVM's, or instead put all browsers in a single launcher,
> all file-managers in another, all system tools and various VM
> terminals in another, music players and things like these in a mix
> launcher, work tools like libreoffice and similar in yet another one.
I had been looking at editing the Qubes menu to sort it more to my
liking, and wasn't getting anywhere. But your method of using xfce's
Launchers is just what I needed. Five minutes work and now I have
a much better "menu" system. Just what I want.
Thanks again,
Mike.
Steve Coleman
> Cool. That gave me some ideas. Thanks for sharing your setup.
>
> So, another infosec question Im trying to figure out...
>
> Templates Vs AppVMs.
to limit access to, and what I do or do not trust....
I want to limit sys-net to the absolute bare minimum of tools and
functionality, because I want any adversary to have a really really hard
time trying to leverage my sys-net to get to the next hop on the
network. Your sys-net is the public attack surface which is available
24x7 for attack on your host system. If somehow an adversary were to get
a foothold on sys-net then they could set up shop and start attacking
Xen, sys-firewall, or your network neighbors. You reall do not want a
root-kit flashed into your NIC, trust me.
I want the tools for those tasks to be as limited as possible, and if I
could remove everything right down to the kernel and network drivers, I
would do that. Unfortunately we do need a shell environment to make
networking to work, so not providing any tools or applications that
would make their life easier is the goal to work towards.
For this reason I give sys-net its own stripped down software template.
I want existence there to be painful if not impossible. I would like to
even remove sudo and other convenience tools, and make that environment
even more primitive, making it that much harder. For admin privs one
could use dom0 and "qvm-run -u root sys-net ..." to manage maintenance
tasks, but I have not had the time to test if this would even work in
the long run. If I could have a single binary monolithic executable
image that would work for me.
The other concern is what I do I trust, in that I trust the
fedora/redhat distribution much more than I trust the fedora "fusion"
project. If I had a vm where I needed some mp3 player from fusion, I
would not want my Banking VM to be exposed to share libraries running
from this other distribution. Keep the risky software out of AppVM's
that you need to trust, while its Ok to provide the risky software to
VM's that are only there for your pleasure and amusement. Draw a big red
line down the middle, and never let the two meet.
So my Templates are divided as:
"fedora-26-net" Stripped to the bone
"fedora-26" general use VM's
"fedora-26-trusted" Banking, Purchasing, etc
"fedora-26-fusion" Web browsing, youtube, multimedia, social media, etc
For each AppVM I will personalize the dom0 menu to place the apps I
intend each VM to use. Keep the menus clean, concise, and for the
purpose. If an extra app exists in that VMs file system but does not get
used, that's Ok by me. What I don't want is rogue software that I don't
trust running in the wrong VM, hence their template'd separation based
on what I do or do not trust.
Steve
sevas
There is some stellar advice in here! Im going to have to go back later and read this whole thread and write down bullet points...
Heres what I have so far.
Templates 3 catagories.
1) original (stripped of programs I dont want)
2) default (default template with minimal added functionality apps added)
3) network enabled
#2 is divided into
a. default (default template with minimal added functionality apps added)
b. EVERYTHING (everything that doesnt need internet access)
#3 is divided by program.
One for GPG keyring,
one for browsing,
one for banking,
one for keepassx...
and sys-net/firewall in one (which Im going to split now, Thanks Steve!)...
although keypass is not networked.
But thats all templates.