Chris Laprise: > On 03/14/2017 09:13 AM, sm8ax1 wrote: > > >> I still haven't heard any rebuttals against how sudo can help mitigate >> attacks against the virtualization (persistence aside). Without sudo, >> unprivileged processes can access /proc/xen/privcmd, raw sockets, memory >> mappings, etc., and load kernel modules that have even greater >> capabilities. We can be naïve and just assume that Xen and the kernel >> are completely secure, or we can be realistic and do a cost-benefit >> analysis of enabling Dom0 approval of sudo access. >> >> How often does the average user really have to elevate privileges >> anyway? Considering most directories not writable by user:user (with the >> notable exception of /usr/local and /rw) are non-persistent anyway, I'm >> not sure there's very much legitimate use for sudo. I can't figure out >> what use cases would require it so often that clicking "yes" in Dom0 >> would be especially inconvenient. And I'm speaking in the general case >> here; there's nothing to prevent someone from installing a specific VM, >> elevating via Dom0 once, and overriding /etc/sudoers via bind-dirs in >> that VM (or template) if they have a need for it. > > I think if you leave out use of the 'mount' and 'umount' commands, root > access tends to be pretty rare. Even so, this is not something that > regular users of Linux or Mac desktops complain about often (and they > have to type the passwords). > >> >> And I'll say it again: all this is in the absence of MACs like SELinux, >> AppArmor, or Grsec, or internal firewalls e.g. to restrict access to >> localhost. Obviously, if anything like that were enabled, it would be >> useless without requiring sudo approval. Since AFAIK there are no plans >> to enable anything like this in any of the stock templates, one could >> argue that /etc/sudoers should be overridden by specific templates that >> need it (have MAC or internal firewalls), but I don't know enough about >> the template building process to say. > > Well stated. > > But I'll add a small caveat: That dash and bash are naive toward their > init files (like ~/.profile) which are writable by user. This means an > attacker's /home/user/.bin/sudo (or su) script can be substituted for > the real sudo (or su or other auth tools) or some other script via > 'alias'. Obviously, this is bad (I have a theory about the Unix > psychology behind this well-known issue) but its easily remedied by > making the init files immutable: > > # 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 > > I have put this in my Debian /etc/rc.local. Alternately, you can set > those files one time in your templates using the above sequence and VMs > that are created with that template (after that point in time) will > inherit the settings. Note that you cannot just set files that already > exist and ignore the missing ones, hence 'touch' will create the missing > ones. > > This also has the nice side-effect of addressing that old cautionary > note about malware persisting through shell init scripts; it would have > to find another way which IMHO might not exist or not for very long. >
First, I did acknowledge that ~/.bashrc and friends can trivially be infected and can be used to gain persistence, but it would still only be unprivileged persistence. That is enough to accomplish some goals, but in those cases the sudo policy is irrelevant in the first place. Like I said before, persistence and privilege are independent of each other. You can have one without the other, both, or neither. A lot of people are treating them as one and the same issue, so if I am wrong for making this distinction, someone *please* point that out. The reason I brought up the non-persistence of files not writable by root was just to express that there's little need for sudo because modifications made to files owned by root would be lost on restart. E.g. installing software or making changes outside /home are probably not common tasks because those changes would be lost on restart. There definitely are exceptions to this rule, but they are infrequent enough that clicking "yes" would not be inconvenient. Second, you mention that ~/.bin/sudo could be overwritten with the attacker's binary or a script. I'm not sure I understand what you mean exactly... the real sudo works by virtue of being owned by root with suid. An attacker running as user cannot create a file owned by root, so neither the real sudo nor a fake one could elevate privileges. If you mean that `sudo` could be aliased to something else, I'm not sure what that would accomplish; the underlying command would still run as the invoking user. I'm just not quite getting what you're saying. Setting the shell startup files to immutable is a good idea I hadn't thought of. Actually I think setting them to root:root mode 755 would be sufficient, wouldn't it? That would make it one step easier to modify them as needed. Of course, then there are many other files in $HOME that are parsed in some way by various applications. Perhaps install a malicious browser extension in .mozilla/ directory. Arguably not quite as persistent or stealthy, but you get the idea. Once again, this is the persistence debate -- a case for using DispVMs -- not the sudo debate. ------------------------------------------------- ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands! $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options! -- 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/e6c630cc-9d33-6ece-0f8e-0bfd5f6888e1%40vfemail.net. For more options, visit https://groups.google.com/d/optout.
