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 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 :) -- 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 https://groups.google.com/d/msgid/qubes-users/aae908a6-43f6-434f-b45c-2a66add40baf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
