-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 unman: > On Wed, Jan 23, 2019 at 10:02:00AM +0000, Patrick Schleizer wrote: >> Many users already upgraded APT in a vulnerable way without ever knowing >> about this issue. >> > > Yes, and many will have installed the update before Qubes is able to > push out a resolution. So, not meaning to put down efforts, it seems to > me that working on a scripted solution is not the best way to go.
One of the main motivation for the scripted solution was to cover users who don't read the announcements (Also it's reused for template builds). > I dont know what is the readership of qubes-users, but should > announcements not be sent there for widest coverage? Particularly where > the fix is already available and could be installed by anyone capable of > copying commands. (Please, no adverse comments about our users.) What do you propose exactly. Pre-announce the QSB? Notify about the Debian announcement? Something else? We should consider some quicker reactions than a full QSB. But then you also need to consider that creating such announcements in a hurry is tricky, especially if you try to provide copyable command. I'm sure Debian has put some thoughts into their message and still it wasn't that clear to some users. >> What about introducing a security on/off switch that a subset of Qubes >> developers can trigger? >> >> Before apt-get (or other package manager) does actually anything, a >> simple script could fetch a file from Qubes clearnet domain (and/or >> onion) and ask "is it currently secure to update"? >> >> In most cases, the server would provide a cryptographically signed file >> by a Qubes developer which says "ok". Otherwise in situations such as >> now with APT security vulnerability DSA 4371-1 a Qubes developer could >> put a cryptographically signed file saying "not safe" there. In such >> cases, updates would be blocked until a new file is provided. >> >> Things to keep in mind related to such a file: man-in-the-middle attack >> - infinite freeze atttacks; rollback attacks; perhaps more. Can think >> about this more if this sounds interesting. > > I think that you have already identified many of the reasons why I > wouldnt favour such a process. > Another major issue is that it relies on users responding to the > inability to update, and once the resolution is posted, updating as > instructed. As opposed to simply doing nothing and then updating as > normal. (Whatever the Qubes scripted solution may be it must rely on > users updating and installing it before using apt again.) The note about installing with apt is true. But if "updating as normal" is through the Qubes Manager they are covered. > I'm generally not in favour of mechanisms that push to users. I have > seen these implemented in various networks and they sometimes work well. > I'm not convinced that they work any better than passing information by > posting messages on mail or website. Users who dont follow those are > likely also to ignore pushed messages - classic click through without > reading. I think having some way to notify users directly in Qubes (a widget or something) would reach a lot more users than any MLs. >> Of course there should be options to: >> >> - disable this mechanism entirely >> - manually override by user >> >> These override option is useful for: >> >> - to stay flexible in case of bugs of this mechanism itself and, >> - to not give Qubes developers too much power. No advanced adversary >> should be able to ask Qubes developers to remotely brick all Qubes >> installations (mostly theoretic at this point and not important for now >> but still easy to implement and good to have), >> - other unforeseeable things. >> >> This idea could be seen as a subset of the emergency project news >> mechanism that is currently missing in all distributions. In short: >> distributions have no mechanism to communicate with their users >> effectively in situations such as this one. More info: >> >> https://www.whonix.org/wiki/Dev/project-news >> >> Cheers, >> Patrick > > Almost every project has such mechanisms, but they rely on user opt in > and response. I've had a quick look at the proposal and I cant see how > it will overcome the obstacles that bedevil existing schemes. > > I have seen this sort of mechanism implemented on private networks, > where users HAD to perform certain actions before being able to access > company resources. Sometimes it worked; sometimes not. Only the threat > of the policy handbook would make some users do the right thing, and even > then there was considerable kick back. More effort went in to > circumventing controls than in to compliance - some people are like > that. > (I recognise that you mention an opt-out/override option.) I think Qubes OS users has much more users who not ignore such instructions than in a classic cooperate environment. And if users intentionally ignore our advice, that's fine, I think. It's their decision. Simon -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE3E8ezGzG3N1CTQ//kO9xfO/xly8FAlxIpg0ACgkQkO9xfO/x ly/WXA/+IX6A5gpbPWdIgpUKTRcS77IYHR1Y2ibEJwKpFe8vHWicTG/QW+M6X+cz fnKuZwKOjntVHKIflXELKmfybtRmizD8AMri342OsrYxD7qdG1KBnnP/XNzjwhz4 R6UKKm54evjaZbY4T9C0nh8nwqFdS52hXM3N+9swQ9GqYkiTh0P2CNMMW/KDRRSR 1RHQQCWkMTLb6rIu4z/MtluIAuOK2caAfZLJnGYmMi6KVsS+OK9rK/aOQtz/u1w8 IGnqxuwj7CI6Tk/rD0iAtR34zHxhGHPYTi9rNrvTXIVkD69FY8HlWbGZtheheLyn SzocHaUib4oVXpRCc03N37TMMTQbmzvESqoOo+BRsVEkuXeP219S61gZPMHEqNFT iTg/9oMXviDLIWykqitqhMh4r5DCHc02hcbEPFAdkiNHOQTa22+R2Adi9lRlIvuq vvXNbKy5dO3gzYvFuhCDwV0szbp4F5xo7ljzdXzEQ6asGks8OifuKzFathR9HgCt rBMdCNTQIhHTyyFp8l2PzZLcETc+qpETmW6Kbax3+ZtnM9C+tQu5SFIsSNtTzL7j X+MmJ1hAhsBwe4VUMH9w8ICocVGittk6g7thclDCY582aaSYee53pj02MrvWXa1k IBYmyIAoos8rbQCHrhl1h5F45BVj0OGPOIjGLRJPMCpYJLvHUx8= =LjAK -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/87aefef5-0bbe-41db-45f9-152747dd15bb%40invisiblethingslab.com. For more options, visit https://groups.google.com/d/optout.
