Re: [qubes-users] Re: Kicking the sudoers dead horse
Unman wrote: > (You can configure the mime and default associations to use > qvm-open-in-dvm, so you can double click on a file and it will > automatically open disposableVM and display it there.) If you ensure the > disposableVM is spawned offline there is (almost) no chance of data being > exfiltrated. Very nice & seducing construction. Is that easy to set up mime-types in a graphic mail client like icedove or do you use mutt/pine for this? I would be interested to know how to do ensure a link sent by mail be opened in a disp-vm ... Cheers, Bernhard -- 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/627f7ffd-53b1-490f-83ed-8d0dd3fa7ed5%40web.de. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Kicking the sudoers dead horse
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2017-03-13 16:00, Unman wrote: > On Mon, Mar 13, 2017 at 11:50:59AM -0700, hib0...@gmail.com wrote: Four, I am aware of disposable VMs but for a working desktop these are of marginal use outside experimentation, malware testing, untrusted web browsing, etc. They are not practical for a work environment where you need persistent configurations, caches, etc. Perhaps this would indicate QubeOS is just not intended or currently a good candidate for such an environment if their use is the expectation which is not how I understood its overall intent. >>> >>> You should read the thread more carefully. You are simply wrong >>> about this. Again, more experience in working with qubes may >>> change your mind. I have set up working desktops for many users >>> where all the heavy lifting is performed in disposableVMs, and >>> the persistent qubes are used only for storage. Look at >>> something like Bromium, which uses the equivalent of >>> disposableVMs in a working desktop. It's a viable model and >>> works right now. >>> >> >> I do need to look at how this would work for my scenario more >> deeply as its admittedly a paradigm shift but the practicality of >> maintenance of so many DispVMs seems overwhelming to me and the >> value of that overhead questionable. >> > > The beauty of it is that there isn't maintenance of many dispVMs - > you can do almost everything with ONE DVMTemplate. > > Let's take a concrete example: You run a storage qube based on a > minimal template - if you insist put in a basic file manager. > Configure a DVMTemplate with pdf viewer, libreoffice, image > viewers, vlc, anything you like. Browse the web in a disposableVM - > save any files you want and qvm-copy them to the storage qube. Now > it doesn't matter if you have backdoored files, malware, or what. > It doesn't matter because it will never be RUN in the storage > qube. (You can configure the mime and default associations to use > qvm-open-in-dvm, so you can double click on a file and it will > automatically open disposableVM and display it there.) If you > ensure the disposableVM is spawned offline there is (almost) no > chance of data being exfiltrated. That seems like a valuable result > to be gained from configuration of a single file - mailcap, mime > type - and there's almost no overhead. > I'm still struggling to see significant security value in this setup that can't instead be gained through careful compartmentalization in normal AppVMs without the significant effort, expertise, and costs required to script and use the DispVM setup. (See my reply to 7v5w7go9ub0o for details.) Would you mind explaining what the specific benefits of this setup are (over and above careful compartmentalization in normal AppVMs) and why they outweigh all the costs? > Most users who have this sort of set-up don't find anything to > comment on - I think they see the "starting dispVM message" just > as another splash screen. That's just anecdotal evidence, I > know,but it's my experience. Even the start up speed doesn't seem > outrageous. > > Two things to get used to are NOT saving under a new name in the > DisposableVM, and having to create a new document in the qube > before it can be edited in the disposableVM. I've got round this by > a simple script associated with a Menu Item that prompts for the > file name, creates an empty file with that name, and opens THAT in > a disposable VM for editing. > - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJYx5H4AAoJENtN07w5UDAwCbYP/jl+njqDMSRsfIW2PKY2LfWw b/tZ+mrMV/C5QMK/rGp8xOFrufXptgD3r0qVUISKPbDy4GV1FQa+kekmsdrL/k3b Gqi4epjC0WHpAfwnIygQ6SSeN6NGzb2Js31Hha589QC14XPst9/DW7Qr8YFK3/tK UFZQjIfZrwVTqFkh3zkNg7RhvlkNLZkIcrCwNGk4dC17rvtmNrMIJa56yR0qw8h8 R6u4VcgDjMNX6GYdtzhFUvUCjB7AulYjnNVilPYUbpG7Qkt1qSwywH/r/WicyY96 xk6vhLU4hwOSuZpC7piRO931/sBndfCqFb3zYfFgwfRe5zch9o/5x2K03dvuPYRH LwSFybikZ3d2to+NKuzVm5lXww9f4uhurqZxx3+WwJyWPdblrOGK4kmz6HQUolKQ NzrPtiVxBN+a36gd+6xIvwrLZnVXYfAdNqJC90FbReW1swK37CXgiqllUla3S5Km 844r1v9/gNaE4f0fvQ2wcOhqFO90G2P4fbK8Eej/3ahmgZiUZ3idAoNp/RKHle/H ZTzrmJT2Jl3Q5clIpXDFrQ87RKOhpjzP/qp9wZuHdt2g6UueTMaHLytpWwBwjKGb r2LpM8Vpc0UhtoGfHmOL8ZaEO2FEKexb3lTwj8/Gn6v+oP3/yU9jNwpsjWh2fEYZ LRDXdBzUa6+BhmVMzp9Y =p4u0 -END PGP SIGNATURE- -- 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/8c7a8b22-f739-3997-cfa6-84f43abdd324%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Kicking the sudoers dead horse
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2017-03-13 10:37, Unman wrote: > On Mon, Mar 13, 2017 at 08:13:31AM -0700, hib0...@gmail.com wrote: >> I only skimmed the thread so I apologize for my laziness up >> front if I missed something but I think a few clarifications need >> to be made about my experiences thus far. The following >> statements are with reference to the fedora-24 template which was >> downloaded 05/10/17. > > It's a shame you've only skimmed the thread you kicked off, because > there is a good deal of interesting information there, and many > interesting perspectives. > I agree. Kicking off a discussion thread, then sending very verbose replies without really reading the thread to which you're replying sends a certain kind of message, something like: "What I have to say is more important than what you have say. Therefore, it makes sense for me to spend little time reading what you have to say and instead spending more time writing what I have to say." Sometimes, this is right. For example, if one is a leading expert in a certain field, it might make more sense for that person to focus on disseminating his or her knowledge. But that's generally a position that has to be earned first. > Over at qubes-issues, Joanna commented on the dom0 control, (NOT as > password as Chris rightly stressed, but a mechanism in dom0 for > requiring user acknowledgement before granting root rights in a > qube: > > "I'd worry more about sending a false-sense-of-security signal that > (presumably) Dom0 is able to strictly control user -> root > escalations within VMs (which it really cannot 100% as explained > in the linked page)." > > Of course, hers is just another voice, but it's one worth > listening to. > In the sense that we should not blindly accept arguments from authority, I agree. However, in every other sense, I disagree. Regardless of whether one shares Joanna's opinions, one must admit the facts: Joanna founded Qubes, she sets the road map for Qubes, and she controls the Qubes Master Signing Key. In this sense, hers is clearly not "just another voice," but a very special one. > [...] > > Look at something like Bromium, which uses the equivalent of > disposableVMs in a working desktop. It's a viable model and works > right now. > I think we should be very careful with such comparisons to Bromium, lest we start giving people the wrong idea. Bromium "micro VMs" are definitely not the equivalent of Qubes DispVMs. (Perhaps the most fundamental difference is that Bromium itself has to run on top of Windows.) - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJYx5CVAAoJENtN07w5UDAwJ6AP/2KV4FXFpAIqpEc5Z+nwKCIP bpnfKOzktWbxmflCWvZoT2ByTDU2BAW+KXxjm1/kZAkG3q2FPIBt1+Uj2/QaZwX0 M2r0rSFuq0O+6peIbFwniPmz0dGVk4h4Z5cSj6WWAiA5RKwA84DHDaNRvikmK8kU 9T85r2LgV9zUJDK3s4NLJP5SXqxnt72KHBe9waArmGLi1SPL5ishYIlBGyKQ0tJ9 IqWdweVJJ07lqCC6hG0fEpGOrYs3wx2rj2w7ygBYPNd23xB65u0vTfbi6Rj9Tztm CbXDFuUOu68HgLoFVYXcZ3eYybVLsaNWtjO3VytMZniIG5pXN3V0XxCA9KsoziTv EflwAoBo0joqjXCd/lQwgMnbIzHcFb2cRCqS+Gcyon0p/a3cScI/z/x0yHC3OkC5 /llNxKgMW/MFGdvxVQYWneDjIltOKuNbw4a6ypCDcHZhj0fuRi/gr4eOcnJ8A/p4 cJKwYlW6mIvyIKzXapYYY/tTxvbYKzq/PVtjdmClIDGIJAyD+izp5lhhoShAE0W1 cO5t+FiuXwpw3YWsSnzPlwgO9mRKSMy7D1AOlCygfyypUXj4Ze6iZ/lJzBnNqB/c wgF5izlgdIdwpNPOmn4Ch7NceeA9f+n64EWl5EkHhsQFGyxgIEuUOl8+Mexmo1Sl gwopXtu5fPRHwnhEMhE6 =y1uh -END PGP SIGNATURE- -- 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/47e296e8-09fd-d2cd-027a-f42331ea8b32%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Kicking the sudoers dead horse
On Monday, March 13, 2017 at 5:00:22 PM UTC-6, Unman wrote: > On Mon, Mar 13, 2017 at 11:50:59AM -0700, hib...@gmail.com wrote: > > > > > > > > Four, I am aware of disposable VMs but for a working desktop these are > > > > of marginal use outside experimentation, malware testing, untrusted web > > > > browsing, etc. They are not practical for a work environment where you > > > > need persistent configurations, caches, etc. Perhaps this would > > > > indicate QubeOS is just not intended or currently a good candidate for > > > > such an environment if their use is the expectation which is not how I > > > > understood its overall intent. > > > > > > You should read the thread more carefully. > > > You are simply wrong about this. Again, more experience in working with > > > qubes may change your mind. > > > I have set up working desktops for many users where all the heavy lifting > > > is performed in disposableVMs, and the persistent qubes are used only > > > for storage. > > > Look at something like Bromium, which uses the equivalent of > > > disposableVMs in a working desktop. It's a viable model and works right > > > now. > > > > > > > I do need to look at how this would work for my scenario more deeply as its > > admittedly a paradigm shift but the practicality of maintenance of so many > > DispVMs seems overwhelming to me and the value of that overhead > > questionable. > > > > The beauty of it is that there isn't maintenance of many dispVMs - you > can do almost everything with ONE DVMTemplate. > > Let's take a concrete example: > You run a storage qube based on a minimal template - if you insist > put in a basic file manager. > Configure a DVMTemplate with pdf viewer, libreoffice, image viewers, > vlc, anything you like. > Browse the web in a disposableVM - save any files you want and qvm-copy > them to the storage qube. Now it doesn't matter if you have backdoored > files, malware, or what. It doesn't matter because it will never be RUN > in the storage qube. > (You can configure the mime and default associations to use > qvm-open-in-dvm, so you can double click on a file and it will > automatically open disposableVM and display it there.) If you ensure the > disposableVM is spawned offline there is (almost) no chance of data being > exfiltrated. > That seems like a valuable result to be gained from configuration of a > single file - mailcap, mime type - and there's almost no overhead. > > Most users who have this sort of set-up don't find anything to > comment on - I think they see the "starting dispVM message" just as > another splash screen. That's just anecdotal evidence, I know,but it's my > experience. Even the start up speed doesn't seem outrageous. > > Two things to get used to are NOT saving under a new name in the > DisposableVM, and having to create a new document in the qube before it > can be edited in the disposableVM. I've got round this by a simple > script associated with a Menu Item that prompts for the file name, > creates an empty file with that name, and opens THAT in a disposable VM > for editing. When you mentioned dispvms I was thinking more along the lines of them applying to all of my "work environments". For example, I use a LOT of ssh tunneling and adding the keys and configurations back in every time would be a real pain in the rump. I might post another thread (if one does not exist) asking about managing ssh keys. One thing I played around with in SELinux was the ability for a command to gain access to the keys but nothing else could. That is, X process and Y user were the only ones with access and they would spawn the tunnels other processes and users ended up using. Regarding my issues with /usr/bin not rewriting it was a standalone vm. (PEBCAK) No idea how but I somehow unintentionally deployed one of the AppVMs as a standalone. -- 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/6fb0ff29-800a-4aee-8b0c-cacd86d826bf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Kicking the sudoers dead horse
On Mon, Mar 13, 2017 at 11:50:59AM -0700, hib0...@gmail.com wrote: > > > > > > Four, I am aware of disposable VMs but for a working desktop these are of > > > marginal use outside experimentation, malware testing, untrusted web > > > browsing, etc. They are not practical for a work environment where you > > > need persistent configurations, caches, etc. Perhaps this would indicate > > > QubeOS is just not intended or currently a good candidate for such an > > > environment if their use is the expectation which is not how I understood > > > its overall intent. > > > > You should read the thread more carefully. > > You are simply wrong about this. Again, more experience in working with > > qubes may change your mind. > > I have set up working desktops for many users where all the heavy lifting > > is performed in disposableVMs, and the persistent qubes are used only > > for storage. > > Look at something like Bromium, which uses the equivalent of > > disposableVMs in a working desktop. It's a viable model and works right > > now. > > > > I do need to look at how this would work for my scenario more deeply as its > admittedly a paradigm shift but the practicality of maintenance of so many > DispVMs seems overwhelming to me and the value of that overhead questionable. > The beauty of it is that there isn't maintenance of many dispVMs - you can do almost everything with ONE DVMTemplate. Let's take a concrete example: You run a storage qube based on a minimal template - if you insist put in a basic file manager. Configure a DVMTemplate with pdf viewer, libreoffice, image viewers, vlc, anything you like. Browse the web in a disposableVM - save any files you want and qvm-copy them to the storage qube. Now it doesn't matter if you have backdoored files, malware, or what. It doesn't matter because it will never be RUN in the storage qube. (You can configure the mime and default associations to use qvm-open-in-dvm, so you can double click on a file and it will automatically open disposableVM and display it there.) If you ensure the disposableVM is spawned offline there is (almost) no chance of data being exfiltrated. That seems like a valuable result to be gained from configuration of a single file - mailcap, mime type - and there's almost no overhead. Most users who have this sort of set-up don't find anything to comment on - I think they see the "starting dispVM message" just as another splash screen. That's just anecdotal evidence, I know,but it's my experience. Even the start up speed doesn't seem outrageous. Two things to get used to are NOT saving under a new name in the DisposableVM, and having to create a new document in the qube before it can be edited in the disposableVM. I've got round this by a simple script associated with a Menu Item that prompts for the file name, creates an empty file with that name, and opens THAT in a disposable VM for editing. -- 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/20170313230019.GA7137%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Kicking the sudoers dead horse
On Monday, March 13, 2017 at 1:37:04 PM UTC-4, Unman wrote: > On Mon, Mar 13, 2017 at 08:13:31AM -0700, @gmail.com wrote: > > The main purpose of this or any security system is to mitigate risk. I > > suspect we all agree on this? > > > > One advantage of having sudo restricted is it reduces the attack foot print > > to installing a root level compromise on the system which will persist and > > could then be used as a launch pad for further surveillance and attacks. > > Root level access also means it could be extremely stealthy which a > > compromise as user@ would be far less capable of. > > > > The problem is while only my user data has been compromised vs the entire > > system it is a persistent threat. Every boot its a threat. For all intent > > and purpose I will have no clue this is sitting there watching me and > > waiting. Waiting for what? How about another VM escape attack? They have > > already been exposed and frankly they will continue to be. Or how about a > > cross-vm row hammer attack? To think that mere isolation via > > virtualization is enough is, as I think someone above commented, foolhardy. > > It *may* be a persistent threat - I think you need to read more about > how the qube file system is built up. > > > > > Personally at this point I would rather remove sudo from the system, grant > > root a password then have the user "su -". I tried this, other than > > removing sudo, and it worked until a reboot at which point it recreated the > > sudoers file and reset the password. The one thing I think would have > > increased security of the system, was very easy, did not seem to have a > > negative impact, was erased. > > If you really want to do this, then you have to make that change in the > template, not in a qube. Of course, you are free to do so. It's a matter > of some concern that you haven't realised this. > > > > > I only skimmed the thread so I apologize for my laziness up front if I > > missed something but I think a few clarifications need to be made about my > > experiences thus far. The following statements are with reference to the > > fedora-24 template which was downloaded 05/10/17. > > > It's a shame you've only skimmed the thread you kicked off, because > there is a good deal of interesting information there, and many > interesting perspectives. > > Over at qubes-issues, Joanna commented on the dom0 control, (NOT as > password as Chris rightly stressed, but a mechanism in dom0 for requiring > user acknowledgement before granting root rights in a qube: > > "I'd worry more about sending a false-sense-of-security signal that > (presumably) Dom0 is able to strictly control user -> root escalations > within VMs (which it really cannot 100% as explained in the linked > page)." > > Of course, hers is just another voice, but it's one worth listening to. > > > > > First I read the reasons for allowing sudo but if VM isolation was enough > > then frankly there is no point to running SELinux or sudo restrictions on > > servers and I am going to wager few people would agree with this. While I > > realize there is a difference here in that no other real people should be > > on your system the fact is that is precisely what will happen if a DomU is > > compromised. Just like not trusting the infrastructure you should never > > trust the unprivileged user accounts as much as possible. This > > configuration, effectively, makes user@ == root. I could use the argument > > you might as well run single user or everything as root. The only thing you > > are really stopping at this point is an attempt to violate MAC as user@ > > within the DomU. > > I haven't heard anyone who is concerned about the absence of a password > for root access suggesting that they should institute user passwords in > their qubes. Why is this? > Many users, as is evident from their postings, DONT trust user accounts > in their qubes, (which means in practice that they DONT trust that > qube. > > > > > Second I also read about how you can re-enable a password on sudo and I > > think, by in large, I understand why this could be problematic to the > > operations of the system. I will definitely be testing this but if its > > going to be unsupported I see very little point in doing so. A system which > > is used for production that becomes unstable in the name of security is > > border line worse than a less secure system. That is, enabling this could > > render the system unusable upon updates etc. > > You can re-enable a password , or follow the suggestion which will > provide a dom0 prompt. It's not unsupported, and wont make the system > unusable. > > > > > > Third, adding /usr/bin/evolution remains after a restart of the VM. I dont > > know if I pressed the "Create a new VM" button wrong or what but its clear > > the "root filesystem" does not, at least entirely, get rewritten. At least > > not the above mentioned template. Assuming I didnt zig
Re: [qubes-users] Re: Kicking the sudoers dead horse
On Mon, Mar 13, 2017 at 08:13:31AM -0700, hib0...@gmail.com wrote: > The main purpose of this or any security system is to mitigate risk. I > suspect we all agree on this? > > One advantage of having sudo restricted is it reduces the attack foot print > to installing a root level compromise on the system which will persist and > could then be used as a launch pad for further surveillance and attacks. Root > level access also means it could be extremely stealthy which a compromise as > user@ would be far less capable of. > > The problem is while only my user data has been compromised vs the entire > system it is a persistent threat. Every boot its a threat. For all intent and > purpose I will have no clue this is sitting there watching me and waiting. > Waiting for what? How about another VM escape attack? They have already > been exposed and frankly they will continue to be. Or how about a cross-vm > row hammer attack? To think that mere isolation via virtualization is enough > is, as I think someone above commented, foolhardy. It *may* be a persistent threat - I think you need to read more about how the qube file system is built up. > > Personally at this point I would rather remove sudo from the system, grant > root a password then have the user "su -". I tried this, other than removing > sudo, and it worked until a reboot at which point it recreated the sudoers > file and reset the password. The one thing I think would have increased > security of the system, was very easy, did not seem to have a negative > impact, was erased. If you really want to do this, then you have to make that change in the template, not in a qube. Of course, you are free to do so. It's a matter of some concern that you haven't realised this. > > I only skimmed the thread so I apologize for my laziness up front if I missed > something but I think a few clarifications need to be made about my > experiences thus far. The following statements are with reference to the > fedora-24 template which was downloaded 05/10/17. It's a shame you've only skimmed the thread you kicked off, because there is a good deal of interesting information there, and many interesting perspectives. Over at qubes-issues, Joanna commented on the dom0 control, (NOT as password as Chris rightly stressed, but a mechanism in dom0 for requiring user acknowledgement before granting root rights in a qube: "I'd worry more about sending a false-sense-of-security signal that (presumably) Dom0 is able to strictly control user -> root escalations within VMs (which it really cannot 100% as explained in the linked page)." Of course, hers is just another voice, but it's one worth listening to. > > First I read the reasons for allowing sudo but if VM isolation was enough > then frankly there is no point to running SELinux or sudo restrictions on > servers and I am going to wager few people would agree with this. While I > realize there is a difference here in that no other real people should be on > your system the fact is that is precisely what will happen if a DomU is > compromised. Just like not trusting the infrastructure you should never trust > the unprivileged user accounts as much as possible. This configuration, > effectively, makes user@ == root. I could use the argument you might as well > run single user or everything as root. The only thing you are really stopping > at this point is an attempt to violate MAC as user@ within the DomU. I haven't heard anyone who is concerned about the absence of a password for root access suggesting that they should institute user passwords in their qubes. Why is this? Many users, as is evident from their postings, DONT trust user accounts in their qubes, (which means in practice that they DONT trust that qube. > > Second I also read about how you can re-enable a password on sudo and I > think, by in large, I understand why this could be problematic to the > operations of the system. I will definitely be testing this but if its going > to be unsupported I see very little point in doing so. A system which is used > for production that becomes unstable in the name of security is border line > worse than a less secure system. That is, enabling this could render the > system unusable upon updates etc. You can re-enable a password , or follow the suggestion which will provide a dom0 prompt. It's not unsupported, and wont make the system unusable. > > Third, adding /usr/bin/evolution remains after a restart of the VM. I dont > know if I pressed the "Create a new VM" button wrong or what but its clear > the "root filesystem" does not, at least entirely, get rewritten. At least > not the above mentioned template. Assuming I didnt zig when I should have > zagged, a nasty could copy a file to /usr/bin and it would persist across > reboots, upgrades, etc. This could then be easily enabled to start on any app > start and run as root. It would also be difficult to detect.
[qubes-users] Re: Kicking the sudoers dead horse
The main purpose of this or any security system is to mitigate risk. I suspect we all agree on this? One advantage of having sudo restricted is it reduces the attack foot print to installing a root level compromise on the system which will persist and could then be used as a launch pad for further surveillance and attacks. Root level access also means it could be extremely stealthy which a compromise as user@ would be far less capable of. The problem is while only my user data has been compromised vs the entire system it is a persistent threat. Every boot its a threat. For all intent and purpose I will have no clue this is sitting there watching me and waiting. Waiting for what? How about another VM escape attack? They have already been exposed and frankly they will continue to be. Or how about a cross-vm row hammer attack? To think that mere isolation via virtualization is enough is, as I think someone above commented, foolhardy. Personally at this point I would rather remove sudo from the system, grant root a password then have the user "su -". I tried this, other than removing sudo, and it worked until a reboot at which point it recreated the sudoers file and reset the password. The one thing I think would have increased security of the system, was very easy, did not seem to have a negative impact, was erased. I only skimmed the thread so I apologize for my laziness up front if I missed something but I think a few clarifications need to be made about my experiences thus far. The following statements are with reference to the fedora-24 template which was downloaded 05/10/17. First I read the reasons for allowing sudo but if VM isolation was enough then frankly there is no point to running SELinux or sudo restrictions on servers and I am going to wager few people would agree with this. While I realize there is a difference here in that no other real people should be on your system the fact is that is precisely what will happen if a DomU is compromised. Just like not trusting the infrastructure you should never trust the unprivileged user accounts as much as possible. This configuration, effectively, makes user@ == root. I could use the argument you might as well run single user or everything as root. The only thing you are really stopping at this point is an attempt to violate MAC as user@ within the DomU. Second I also read about how you can re-enable a password on sudo and I think, by in large, I understand why this could be problematic to the operations of the system. I will definitely be testing this but if its going to be unsupported I see very little point in doing so. A system which is used for production that becomes unstable in the name of security is border line worse than a less secure system. That is, enabling this could render the system unusable upon updates etc. Third, adding /usr/bin/evolution remains after a restart of the VM. I dont know if I pressed the "Create a new VM" button wrong or what but its clear the "root filesystem" does not, at least entirely, get rewritten. At least not the above mentioned template. Assuming I didnt zig when I should have zagged, a nasty could copy a file to /usr/bin and it would persist across reboots, upgrades, etc. This could then be easily enabled to start on any app start and run as root. It would also be difficult to detect. Four, I am aware of disposable VMs but for a working desktop these are of marginal use outside experimentation, malware testing, untrusted web browsing, etc. They are not practical for a work environment where you need persistent configurations, caches, etc. Perhaps this would indicate QubeOS is just not intended or currently a good candidate for such an environment if their use is the expectation which is not how I understood its overall intent. If I was attacking a QubeOS system I would very likely first start by compromising the DomU's, clearly the largest target to hit, and having direct access via the user with zero restrictions to root is a perfect place to start to plant my "observation rootkit". If I was attacking any system one of the first things I would try is gaining root the easiest way. sudo or su. ie: Engine wont start? Check gas. It seems obvious to me this will increase security of the system overall. Outside of technical problems I also think the argument for ease of use for the user (ie: patching) is a very weak stance vs the security that would be gained. Perhaps at least having the supported option to "enable sudo password" or probably better "disable sudo and use su only" is of merit. Anyhow, much appreciate the chat and thanks! -- 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
Re: [qubes-users] Re: Kicking the sudoers dead horse
On Sat, Mar 11, 2017 at 01:10:32PM -0800, Daniel Moerner wrote: > On Friday, March 10, 2017 at 9:55:08 PM UTC-5, Unman wrote: > > So yes, in a very real sense, it doesn't matter > > to me if the qube where I collect mail, (which isn't the qube where I > > read it) is compromised in some way. > > Hi Unman, > > Could you explain your setup for collecting mail in one Qube and reading it > in another? I currently use Qubes for each mail account, running mutt and > offlineimap, and opening links in disposable VMs. But collecting mail in one > Qube and reading it in another is interesting to me. > > Daniel > Hello Daniel It was interesting to see someone else in the thread refer to a similar setup. (Look at 7v5w7go9ub0o earlier.) They use a disposableVM to process the mail. I use a number of different mail servers: like you I use mutt and offlineimap,(and rsync and notmuch). I use mini templates in different flavours, mailcaps to open files in disposableVMs. (Lots of people will hate everything about this.) I use more than one TorVM. I have multiple dispVMTemplates, some online and some not. A mail archive is not network connected and is based on a mini template. Like 7v5w7go9ub0o I use simple scripting - fire up disposableVM, run rsync/offlineimap, qvm-move mailfile in to reader. Process mail, with any attachments opened in disposableVM, as you do, using Split GPG. Outgoing mail is copied to a mailqueue in another qube, and sent from there. As far as use is concerned, it just feels like any other mutt session. Everything is scripted, (and tied together with bits of string) but it works. The only difference from what you are doing is that your mutt qube is network connected. and mine isn't. Of course, in other cases I'll ssh to a box and use mail from there - or use some webmail - that's straight forward I'm sure there are many users doing something similar. 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/20170312002806.GC25808%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Kicking the sudoers dead horse
On Friday, March 10, 2017 at 9:55:08 PM UTC-5, Unman wrote: > So yes, in a very real sense, it doesn't matter > to me if the qube where I collect mail, (which isn't the qube where I > read it) is compromised in some way. Hi Unman, Could you explain your setup for collecting mail in one Qube and reading it in another? I currently use Qubes for each mail account, running mutt and offlineimap, and opening links in disposable VMs. But collecting mail in one Qube and reading it in another is interesting to me. Daniel -- 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/21ad2eab-051e-43b2-afd6-5c3c0edcc34a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Kicking the sudoers dead horse
Hello! The "open" root behavior seems a little strange to me too. But, thinking coldly, what would change in your scenario if root was protected? The attacker would not be able to modify /usr/bin/audacious, or install muhbackdoorz to system. But she/he could still delete all your home data, or send it through web, or install something inside home and add it to .bashrc, or ... Considering all important data in a DomU is owned by one user, and neither root nor the non-root user can leave DomU, the damage caused by any of them seems almost the same. More info: https://www.qubes-os.org/doc/vm-sudo/ Regards! -- 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/bd734ccd-61ca-4be7-a590-46de944a9324%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
