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. 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 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.) 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. > > 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.) -- 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/20190123144300.icw6y572g7sv4pd6%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
