On Tuesday, March 6, 2018 at 7:42:40 PM UTC+1, sevas wrote:
> I wasnt going to say anything... lol. But I was leaning towards debian. But 
> fedora. Thats Red Hat. They are the leading administrative suite as far as I 
> know. Or were. They must have good security or whos going to throw up a 
> server?
> >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.

> 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 :)

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 

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 :)

You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to