home folder of template not inherited by DispVM #1335
Comments
|
Generally we consider to stop private.img inheritance from the template As for initializing /home/user with some Whonix-specific configuration, As for DispVM specific file needed, this is done to have /home/user as So back to the topic - I think the clearest solution would be to have Best Regards, |
|
The
|
Not really. When we end with private.img inheritance, this would be Instead of
Something like this. The whole issue mainly about private.img inheritance is about how to Hmm... maybe instead of abandoning /home inheritance at all, /home/user Long time ago we had a code to update user files later: Somehow similar to how KDE handles configuration updates/migration. But Best Regards, |
|
I don't know how this should best be designed. For a big part it is a design and usability question. In the related discussion handling of /home in TemplateVM vs TemplateBasedVM it has been raised, that (power) users want to modify files in the TemplateVM's home folder
And I agree with them. Not being able to have the AppVM at least at creation time inherit the TemplateVM's home folder would be bad, cumbersome. On the other hand, I don't know how sane it is to configure lets say a Firefox profile to your liking. I mean by actually starting the Firefox GUI and doing it there. And then reuse it in various TemplateBasedVMs. Would random seeds or alike data be shared in the profile and therefore weaken the security of Firefox? So in a TemplateVM's home, we have:
Could you please elaborate what you mean by Let's see for example what files are in my Debian 8 TemplateVM's home. Anything you consider a I think sharing kwalletrc, session-errors and a few others is not great. [But also no huge issue and no security issue. (I am personally not using kwallet in TemplateVM or at all.)] Related ticket:
Fortunately we didn't yet need to update files in home using the package manager. That would be difficult and even more hacky for Qubes. |
|
On Thu, Oct 15, 2015 at 06:27:32AM -0700, Patrick Schleizer wrote:
Most likely... At least random profile name.
Yes, exactly. Also for example I keep "template-pkgs.txt" file there
Any files here, if present (reordered the list, to have them in one
This one.
Surely those.
This one too.
Not sure about the whole .cache content. But most likely it shouldn't be
Those also.
Not sure about this one - what is this?
Those are specific to "debian-8" VM, but probably harmless to keep. Generally I think it applies to any generated files. The only files If we want to keep compatibility (or simply decided that gains are too
Best Regards, |
|
Maybe these security questions are a way to nail it...
If these answers is:
This is so difficult. I am still debating with myself. Approaching this from a different view. Trying to apply the principle of the least surprise. Sometimes it helps to document/visualize how things currently work first before trying to sketch a new proposal. I'll did that here: Current way:
Trying to come up with a simpler rule. Proposal:
I think this could lead to less confusion. As of Qubes R3, from a users point of view, it is "sometimes somehow [new] TemplateBasedVMs share the same content as the TemplateVM. I think when I make modifications in the TemplateVM, those will be inherited by the TemplateBasedVM." With this proposal, it would be clearer. "Only the root image is shared. Home is not." I not 100% like this so if anyone has better ideas I would appreciate this! |
|
On Thu, Oct 15, 2015 at 03:43:48PM -0700, Patrick Schleizer wrote:
I don't think so. Unless someone use TemplateVM to for example gpg key
Probably not. But can be a privacy problem. Hmm, think also about this use case:
Not sure how realistic is such scenario. Also there is a simple way to So I think the answer is:
Yes, this is some option. Would not simplify implementation, but will be
I like the idea of having template home still accessible from AppVM, not
Yes, this is one of the reason why we're considering this at all :) Best Regards, |
I think such a scenario is very realistic. Imagine you to install some custom software in your template. You git clone it, give your credentials, store it, install. Then you later forget about it, don't need it anymore, but create an 'untrusted' AppVM based on that TemplateVM. Boom. Maybe this hasn't happened to anyone yet, but with thousands of thousands new users, such minority use cases will happen more and more often. This is a reason for default opt-out TemplateVMs home sharing. |
|
imo, security should be priority No. 1. If there is any possibility of loss of privacy or security (even by user error), it should be avoided if at all possible. |
marmarek
added
the
T: enhancement
marmarek
added
C: core
P: major
|
Recently we had some discussion about it and came to conclusion that the best way would be to give the user a choice. It would be like this: Template "shared" private.img
Template "private" private.img
Notes and todos
cc @adrelanos |
|
Sounds good overall.
Using /etc/skel in all cases seems like the cleanest solution. For
consistency and simplicity.
To paraphrase it, "to sometimes copying some files from TemplateVM's
home to TemplateBasedVMs home" seems confusing.
For everything else, the 'let packages opt-in for files from
TemplateVM's home to TemplateBasedVMs home' I think we could wait for an
existing problem that needs to be solved if there isn't some yet and/or
for an actual feature request.
Template "shared" private.img /home.orig sounds good for advanced users.
If they forgot to copy files to /etc/skel or didn't do so for some other
reasons, they can manually copy files from /home.orig to /home/user.
I think this is difficult UX wise. Did you consult @bnvk yet? My
intuition tells me, to go with the default and to hide the other option
under some button "advanced".
Other ideas for such an "advanced" menu would be "initially populate
/home/user from the TemplateVM's /home/user instead of from /etc/skel"
and "skip populating /home/user". (Although the latter can be easily
done manually by simply deleting all files in home after the first
boot.) We can wait here for an actual feature request also.
Should then there also be Template "shared" private.img /root.orig for
consistency?
|
|
On Mon, Dec 21, 2015 at 03:15:14PM -0800, Patrick Schleizer wrote:
Agree.
This is also about sharing settings with already existing VMs (created
Not yet. @bnvk, what do you think?
I think the most important use case for this would be DispVMs. Users Somehow related: what would be the steps to configure Firefox for
When Best Regards, |
|
[Preliminary remark: In my ideal imagination for some time now, to Later 'amnesic' would be a check box in the VM settings. Setting the Marek Marczykowski-Górecki:
Have a check box 'allow customization at [first|next] boot of this VM' |
|
I think it's a mistake to focus specifically on the launching of Firefox in a TemplateVM compromising privacy. It surely would, but so will a thousand other things that will happen when a user configures a regular TemplateVM. This is precisely why Tor Browser exists. Regular Firefox simply isn't built to provide that kind of privacy, and extensive modifications are required to deliver it. Users who attempt to do this themselves by modifying vanilla Firefox typically end up shooting themselves in the feet in arcane ways they couldn't have predicted. We should take these lessons and apply them more broadly to the OS as a whole. Vanilla OSes like Fedora and Debian aren't designed to provide that level of privacy (esp., nonfingerprintability) out of the box. If we want to provide a private option to users (and we absolutely should), it needs to be at the level of a private TemplateVM. (Isn't this the point of Whonix-Workstation?) Otherwise, it's highly likely that any user configuration of a regular TemplateVM will compromise privacy in an unanticipated way. By now, privacy-conscious powerusers all know that the rule is: When privacy is a concern, you use Tor Browser, not vanilla Firefox. The Qubes equivalent should be: When privacy is a concern, you use a Whonix-Workstation-based VM (or whichever it ends up being), not a regular TemplateBasedVM. |
|
On Fri, Dec 25, 2015 at 02:13:39PM -0800, Axon wrote:
Agree. Best Regards, |
|
Trying to follow discussion: I think you're all saying that new appvm home dirs should be populated from /etc/skel or something similar that's easier to use. I'm not sure why the template's home can't still be used for this... because configuring apps by running them is 'messy'? I think you would have an easier time grappling with UX issues if use cases were formally expressed before trying to lay down rules. Here is a simple use case (which should be part of a large list): 'Firefox user adds popular extensions to template'IMHO, this conveys to developers a wide range of things such as the need to run the app in order to configure it. It also better set users' expectations in terms of what can or should not be done. |
|
To summarize what finally got implemented in Qubes 4.0:
This approach should cover discussed here concerns/use cases:
|
Qubes generally:
When one creates a TemplateBased-VM, its home folder, originally is inherited from the TemplateVM it is based upon. From then, the TemplateBased-VMs home folder is standalone. So anything a user preconfigured in the TemplateVM can be used in the TemplateBased-VM.
For DispVM's this is different.
DispVM customization requires special instructions:
Why is that?
I find that non-intuitive. Isn't that a usability issue? (@bnvk) Couldn't/shouldn't that be simplified?
Qubes-Whonix specific:
Whonix ships a few files in /home/user.
Because there is no other way to implement these things elsewhere.
So for Whonix DispVMs, the home folder of the template those are based upon, should be inherited. Depending on the outcome of my above question, how could this be implemented?
The text was updated successfully, but these errors were encountered: