On Tue, Dec 19, 2017 at 10:55:46PM +0100, 'Tom Zander' via qubes-users wrote: > On Tuesday, 19 December 2017 16:33:49 CET Unman wrote: > > Tom > > > > Ive suggested before that if you give this advice you should > > clearly state the consequences. > > Ok, no worries. Here you go: > > The consequences is that the template, which has no personal or identifying > information, can be used to run apps that make outbound connections. Don’t > worrry! No inbound connections are possible. > > In short; > * There is no possibility of loss of private data (since there is none). > * There is no possibility of a remote hacking attack (b/c no > listening services). > * There is no possibility of a hacker installing bad software in > your template (only you can do that). > > Bottom line is that there is no additional risk when a user uses a corporate > firewall and a http proxy to allow him to download updates. > > Unman, being paranoid is fine, but making users unable to update their system > unless they do it the very complicated way you approve of will not help > security. > We are dealing with people, lets keep that in mind. > Specifically, the result of being too strict on this is that they will end up > either not updating (and missing security updates) or maybe just giving up > and using the simple route of throwing security out the window and just > getting the job done. > > Perfection is the enemy of good enough. > > > And since I’m being nasty today, lets focus on another illusion in this > email. You wrote; > > sys-net will not enforce a firewall > > Basically true, sys-net indeed bypasses sys-firewall. > But you are mistaken if you think that sys-firewall adds security. > Sys-firewall adds the _option_ of allowing you to _manually_ add security. > IF you have the know-how on how to do so. Which most people don’t. > sys-firewall allows you to block remote hosts by IP-address, manually. And > optionally. > > Making people believe that having sys-firewall makes them more secure is > selling an illusion of security, which is really bad for actual security > because it follows that people will believe they are magically secured. > In reality the configuration of the firewall is a highly specialized and low- > level task that most people without sys-admin-training will simply not do. > > Security is not about following a rulebook, it is about people first and > foremost. Lets not lose focus of that, please. >
Tom, I don't want to get involved in a personal spat but I think that your reply is completely misleading. As op was a self confessed noob and it's possible that other newcomers to Qubes might come across your post I think it's important to correct some misconceptions. First, people come to Qubes for all sorts of reasons. It's reasonable to assume that they want some level of security and, perhaps, privacy. They may really need those things.Given that, I dont think it's helpful to bandy around words like "paranoid". Second, your reply is completely misleading about the role of Templates in 3.2. Since templates can be customised by the user it is not true that they cannot contain private data. It's a moot point to what extent Templates do contain identifying material, even when not customised. It isn't true that Templates CANT contain listening services, or services that make outbound connections without user intervention. Debian Templates will start some services on installation, for example, and there are other "aids" that may initiate outbound connections without the user's knowledge. There are circumstances where this could be extremely undesirable. If (e.g) you use a web browser in a Template there is every chance that a hacker may install bad software without your knowledge. Why does this matter? Because although the Template *may* not contain private data, the AppVMs based on it will do. If the Template is compromised then all the AppVMs that use it will be compromised. If you are a new user with just one or two templates, then you risk compromising all your AppVMs, even the ones you deem to be most precious. It's for this reason that Qubes limits what can be done in a Template by using the qubes firewall. Notice that this doesn't need to be set up by a new user: I think you misunderstand the position here. Qubes enforces the necessary rules for them, restricting access for Templates to the update proxy by default. This helps protect against user error - for example, opening a browser in Template by mistake, and using it to browse the web. It also helps to train users NOT to use their Templates like other qubes. At one time the proxy restricted access to what looked like Debian (or fedora) repositories. I preferred this set-up and use it myself, but it has been removed from the default config. It can be reinstated by editing tinyproxy.conf. So Qubes recognises the fundamental importance of Templates by providing a mechanism to protect them to some extent. By connecting directly to sys-net you remove that protection. This is misguided, particularly because in almost every case, (and particularly in op's) it's unnecessary, since there are ways of accessing the company proxy without completely removing the default template protections. I completely agree that security isn't about following a rule book. The best way to help someone secure themselves is to provide tools and enable them to learn how to use those tools. Qubes is one of those tools, and having some understanding of the use of Templates, the qubes firewall and the proxy mechanism is important, even if not necessary. unman -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20171221180223.rna26qimwuwr4xcj%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
