On Sat, Mar 11, 2017 at 08:49:10AM -0500, Chris Laprise wrote: > On 03/11/2017 08:10 AM, Unman wrote: > > > > >Anyway, it's a argument that could go on. I dont agree that "the > >chance for improved security comes for free". It's absolutely clear that > >Qubes aims to balance security with usability - some of the compromises > >that have been made seem wrong to me, this isnt one of them. I take > >steps to mitigate changes I dont like - you should do the same if you > >want a password on root access. > >But for most users (particulary new users) there is a cost to > >introducing passwrd access, and it's convenience. > > Its not based on passwords. Its the same Yes/No dom0 auth dialog that > controls qvm-copy. Except it remembers auth for a certain amount of time the > way sudo normally does. > > Notice the detractors haven't tried it and think it means assigning > passwords to VMs. > > > >Joanna refers to this > >in the explanation. It's clear from the forums that many users struggle > >with the Qubes ideas anyway - I cant see that this change would make > >things easier for them. (Presumably you would need to have different > >password across different templates.) > > Most are already used to UAC Yes/No prompt on Windows. This is pretty > similar. > > > >> > >>>There is another, much bigger issue: We don't want our systems to > >>>become a zoo of infected VMs with malware thrashing about in them > >>>(and on our networks!) with us as zookeepers. That would be > >>>irresponsible. > > > >The answer to this is encouraging users to make good use of isolation, > >qube use and Qubes features. That isnt irresponsible. It's a way of > >dealing with the problem. I think you would need to develop a much more > >detailed argument to convince me that the answer to malware infections > >is putting a password on root access. > > I didn't purport to provide "the answer"... strawman argument. > > What it comes down to is a matter of degrees and costs. > > > > > >As far as I can see most people, particularly new users with some linux > >background, just dont like the idea of passwordless root. That's fine. > >That's why there's a page devoted to it, and a solution. > > Well, its still passwordless with the vm-sudo auth. > > You should try it. :) > > > > >There's no real security > >advantage in enabling it but if you want to you can. > > I think its a mistake to deny that guest OS permissions can contribute some > additional margin of security. > > If it means a less attractive environment for script kiddies to raise > hell--- chewing up resources, attacking other computers, creating footholds > for more advanced threats--- then I can invest 3 min. to enable it. >
Chris There was no straw man argument here - you raised the issue of "malware zoos" in the context of a discussion of passwordless sudo - it's natural to think that you see it as an answer. I cant see it plays any role. This is particularly so given your suggestion that the root access "remembers auth for a certain amount of time" - decent targeted attacks would have a stub firing to check if sudo was enabled every few minutes, and would hit the target of opportunity you have opened for them. This really isnt a solution. (I see the same with people who think they are immune from viruses because they only connect to the internet for brief periods.) There are many things I havent tried, and I think this is going to be one of them. If Qubes policy were to change, then I would consider following it depending on what the reason was for the change, but that's a choice I would make. I still cant see that anyone has provided a reason why " guest OS permissions can contribute some additional margin of security". You think this is a mistake on my part. cheers 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 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/20170311171525.GD23720%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
