Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign uphome folder of template not inherited by DispVM #1335
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Oct 14, 2015
Member
Generally we consider to stop private.img inheritance from the template
at all, which is sometimes counter-intuitive (why some changes done in
template are visible in VMs, but some not). Also /home in template
sometimes contains files which are unneeded in VMs (manually downloaded
packages etc), so carrying them to every VM create is pure waste of disk
space. But as you've noted, there are multiple consequences of such
move, which needs to be somehow handled.
As for initializing /home/user with some Whonix-specific configuration,
I think it can be solved by placing those files in /etc/skel (which is
the right place for default user configuration), then use this directory
to initialize /home/user in new VMs and also in DispVMs.
As for DispVM specific file needed, this is done to have /home/user as
small as possible in DispVM, to speedup the startup. Not that in DispVM,
home is copied from *-dvm's home, not the real template (this is somehow
two-layer template). We want to simplify this in R4.0, but we haven't
decided exactly how.
So back to the topic - I think the clearest solution would be to have
all the initial home content in /etc/skel, then adjust all the places to
use that (both new VMs and DispVMs - when no customizations were made).
What do you think?
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
|
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, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Oct 14, 2015
Member
The /etc/skel approach somewhat clashes with the sudo apt-get install whonix idea, where functionality is installed on demand by packages.
- Not necessarily a blocker. Just something to consider.
sudo apt-get install whonixdoes not work for Qubes TemplateBased-VMs anyhow. Once AppVMs are created and new home settings packages installed in the TemplateVM, those will not be inherited by TemplateBased-VMs anyhow.- Would all packages that populate
/etc/skelhave to be installed first, before useruseris created? - Then user
usershould be created at first boot, so skel is copied to home? - The
/etc/skelapproach relies on the build process or first boot?
|
The
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Oct 14, 2015
Member
- Would all packages that populate
/etc/skelhave to be installed first, before useruseris created?
Not really. When we end with private.img inheritance, this would be
handled at VM first boot (including TemplateVM itself). Here:
https://github.com/QubesOS/qubes-core-agent-linux/blob/master/vm-systemd/mount-home.sh#L15-L63
Instead of /home.orig (which is non-standard, somehow broken idea), it
would use /etc/skel. And BTW that touch /var/lib/qubes/first-boot-completed is totally useless and wrong.
- Then user
usershould be created at first boot, so skel is copied to home?
Something like this.
The whole issue mainly about private.img inheritance is about how to
distinguish between "default settings" in /home (which should be
inherited by AppVMs) and "just template private files" (which should
not).
Hmm... maybe instead of abandoning /home inheritance at all, /home/user
in TemplateVM should not be hold on private.img (/rw), but on the
root filesystem and used to initialize new AppVMs /home (maybe it should
be even /home.orig). And there should be some separate directory for "just
template private files"? Like /home/user/template-local or sth,
placed in non-shared private.img. What do you think?
Long time ago we had a code to update user files later:
https://github.com/QubesOS/qubes-core-agent-linux/blob/14cb955efc0e488c7bbea7d30d9e2cbf2197245f/vm-systemd/misc-post.sh#L48-L61
Somehow similar to how KDE handles configuration updates/migration. But
fortunately we don't need this anymore (at least not for Qubes itself),
because all the tools we use have some system-wide configuration. I
understand this is not the case for Whonix-configured apps, right?
Merging user-modified configuration with Whonix-provided defaults is
probably not something we want to do anyway...
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
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, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Oct 15, 2015
Member
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
"I agree with cprise. Some security and accessibility settings have to be configured in user's home."
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:
a)default settings in home by Qubesb)in case of Qubes-Whonix: default settings in home by Whonixc)customized default settings in home by users (ex: Firefox modifications)d)template private files
Could you please elaborate what you mean by d) template private files? Perhaps if the user downloaded third party packages (ex: newest chrome or so), stored it in their home folder, installed it, then forgot to delete that file or to move it outside of home? That would be a candidate for a d) template private file, that should not be needlessly inherited by all the AppVMs?
Let's see for example what files are in my Debian 8 TemplateVM's home.
user@debian-8:~$ find .
.
./Pictures
./Downloads
./.profile
./.gconf
./.gconf/apps
./.gconf/apps/%gconf.xml
./.gconf/apps/nm-applet
./.gconf/apps/nm-applet/%gconf.xml
./.xsession-errors
./.config
./.config/user-dirs.locale
./.config/fontconfig
./.config/fontconfig/fonts.conf
./.config/user-dirs.dirs
./.config/Trolltech.conf
./.config/yelp
./.config/yelp/yelp.cfg
./.config/dconf
./.config/dconf/user
./.config/pulse
./.config/pulse/d9b0844b2b3f46f59c6bd4bbd4ab0b78-card-database.tdb
./.config/pulse/cookie
./.config/pulse/d9b0844b2b3f46f59c6bd4bbd4ab0b78-stream-volumes.tdb
./.config/pulse/d9b0844b2b3f46f59c6bd4bbd4ab0b78-device-volumes.tdb
./.fonts.conf
./.bashrc
./Documents
./Videos
./.bash_history
./Desktop
./.cache
./.cache/fontconfig
./.cache/fontconfig/eeebfc908bd29a90773fd860017aada4-le64.cache-4
./.cache/fontconfig/e13b20fdb08344e0e664864cc2ede53d-le64.cache-4
./.cache/fontconfig/21a99156bb11811cef641abeda519a45-le64.cache-4
./.cache/fontconfig/cabbd14511b9e8a55e92af97fb3a0461-le64.cache-4
./.cache/fontconfig/CACHEDIR.TAG
./.cache/webkit
./.cache/webkit/icondatabase
./.cache/webkit/icondatabase/WebpageIcons.db
./Public
./.dbus
./.dbus/session-bus
./.dbus/session-bus/d9b0844b2b3f46f59c6bd4bbd4ab0b78-0
./.bash_logout
./Templates
./.local
./.local/share
./.local/share/keyrings
./.Xresources
./.kde
./.kde/cache-debian-8
./.kde/tmp-debian-8
./.kde/socket-debian-8
./.kde/share
./.kde/share/apps
./.kde/share/apps/kconf_update
./.kde/share/apps/kconf_update/log
./.kde/share/apps/kconf_update/log/update.log
./.kde/share/apps/konsole
./.kde/share/kde4
./.kde/share/kde4/services
./.kde/share/config
./.kde/share/config/drkonqirc
./.kde/share/config/katerc
./.kde/share/config/kwalletrc
./.kde/share/config/mailtransports
./.kde/share/config/okularpartrc
./.kde/share/config/kcookiejarrc
./.kde/share/config/kdebugrc
./.kde/share/config/systemsettingsrc
./.kde/share/config/kdedrc
./.kde/share/config/phonondevicesrc
./.kde/share/config/kglobalshortcutsrc
./.kde/share/config/kio_httprc
./.kde/share/config/kmailrc
./.kde/share/config/knoderc
./.kde/share/config/kconf_updaterc
./.kde/share/config/klipperrc
./.kde/share/config/akonadi_newmailnotifier_agentrc
./.kde/share/config/konsolerc
./.kde/share/config/kdeglobals
./.kde/share/config/kmail2rc
./.kde/share/config/kuriikwsfilterrc
./.kde/share/config/kioslaverc
./.xsettingsd
./Music
user@debian-8:~$
Anything you consider a d) template private file?
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:
document relationship of TemplateVM's and TemplateBasedVM's (home) folder(s)
#1336
I understand this is not the case for Whonix-configured apps, right?
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.
|
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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Oct 15, 2015
Member
On Thu, Oct 15, 2015 at 06:27:32AM -0700, Patrick Schleizer wrote:
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
"I agree with cprise. Some security and accessibility settings have to be configured in user's home."
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?
Most likely... At least random profile name.
So in a TemplateVM's home, we have:
a)default settings in home by Qubesb)in case of Qubes-Whonix: default settings in home by Whonixc)customized default settings in home by users (ex: Firefox modifications)d)template private filesCould you please elaborate what you mean by
d)template private files? Perhaps if the user downloaded third party packages (ex: newest chrome or so), stored it in their home folder, installed it, then forgot to delete that file or to move it outside of home? That would be a candidate for ad)template private file, that should not be needlessly inherited by all the AppVMs?
Yes, exactly. Also for example I keep "template-pkgs.txt" file there
with a list of manually installed packages, so I can easily redo this
when migrating to a new template version. This file is totally unneeded in
AppVMs (but harmless).
Let's see for example what files are in my Debian 8 TemplateVM's home.
Anything you consider ad)template private file?user@debian-8:~$ find . . ./Pictures ./Downloads ./Public ./Documents ./Videos ./Desktop ./Templates ./Music
Any files here, if present (reordered the list, to have them in one
place). Directories itself will be created on first user login. So no
need to keep empty directories either.
./.xsession-errors
This one.
./.config/pulse/d9b0844b2b3f46f59c6bd4bbd4ab0b78-card-database.tdb
./.config/pulse/cookie
./.config/pulse/d9b0844b2b3f46f59c6bd4bbd4ab0b78-stream-volumes.tdb
./.config/pulse/d9b0844b2b3f46f59c6bd4bbd4ab0b78-device-volumes.tdb
Surely those.
./.bash_history
This one too.
./.cache
Not sure about the whole .cache content. But most likely it shouldn't be
shared either, at least for privacy reasons.
./.dbus/session-bus/d9b0844b2b3f46f59c6bd4bbd4ab0b78-0
Those also.
./.local/share/keyrings
Not sure about this one - what is this?
./.kde
./.kde/cache-debian-8
./.kde/tmp-debian-8
./.kde/socket-debian-8
Those are specific to "debian-8" VM, but probably harmless to keep.
Generally I think it applies to any generated files. The only files
which would be inherited to the VMs are those configuration
deliberately created, either by user, or some package. In case of
packages - it would be "easy" - just move to other directory (/etc/skel
was invented specifically for this). But for user modifications it's
more cumbersome, because users are expecting to edit files in
/home/user. Any idea?
If we want to keep compatibility (or simply decided that gains are too
small for the price), we may move /home/user of the TemplateVM to the
root.img (simply not bind-mount /rw/home there), so we have both:
- full /home/user inheritance for new AppVMs (private.img
initialization in mount-dirs.sh needs to adjusted - currently uses
/home.orig/user) - not need to actually copy private.img while creating VM (so even
if the user left some unneeded files there, it won't be duplicated
for every new VM); also simplifies AppVM creation code
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
|
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, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Oct 15, 2015
Member
Maybe these security questions are a way to nail it...
-
- Do you think, that sharing template private files (have the AppVM inherit those) is a security risk generally? I mean, could an AppVM using that information do damage to other AppVMs or the TemplateVM?
-
- The configure Firefox by GUI, random profile name etc. thing. Is this something that should be actively discouraged because it could lead to a serious security problem?
If these answers is:
- a) yes:
- Then AppVMs should not have access to the TemplateVMs home either way.
- Not inherit it.
- And not have access to it later.
- Users could still do stuff like configuring Firefox by GUI and then manually move the resulted home profile folder to /etc/skel.
- That would encourage a cleaner AppVM home folder.
- But if the answer is yes for sharing home, are there other files in root that are a security risk for sharing...
- b) no:
- In the TemplateBased-VM creation window there could be a checkbox "inherit the TemplateVMs home folder" that shows an explanatory popup when hovering over it [or similar info/help machanism], that is unchecked by default
- TemplateBased-VM should get read access to its TemplateVM home folder (mount it to /home.something)
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:
https://www.whonix.org/wiki/Dev/Qubes#Handling_of_file_system_in_TemplateVMs_vs_TemplateBasedVMs
Current way:
- The /home folder of a TemplateVM is copied to a TemplateBasedVM at creation time of the TemplateBasedVM. From then, TemplateBasedVM's /home folder is left untouched.
Trying to come up with a simpler rule.
Proposal:
- TemplateVMs and TemplateBasedVMs home are always standalone.
- An AppVMs home folder is populated using /etc/skel on its first boot.
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!
|
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! |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Oct 15, 2015
Member
On Thu, Oct 15, 2015 at 03:43:48PM -0700, Patrick Schleizer wrote:
Maybe these security questions are a way to nail it...
- Do you think, that sharing template private files (have the AppVM inherit those) is a security risk generally? I mean, could an AppVM using that information do damage to other AppVMs or the TemplateVM?
I don't think so. Unless someone use TemplateVM to for example gpg key
generation, or sth. Which probably would be an user error (TemplateVM
shouldn't be used for that).
- The configure Firefox by GUI, random profile name etc. thing. Is this something that should be actively discouraged because it could lead to a serious security problem?
Probably not. But can be a privacy problem.
Hmm, think also about this use case:
- You have some custom software. Lets assume it is hosted on github
private repository. - You want to install it in the template, so you need somehow access
the repository - either using https (password), or ssh (ssh keys). If
you do this directly from the TemplateVM, credentials will be probably
stored there. So it shouldn't he inherited by the VMs.
Not sure how realistic is such scenario. Also there is a simple way to
handle it - use some AppVM (or even DispVM) to download the software and
then copy it to the TemplateVM. What do you think about this?
So I think the answer is:
- b) no:
- In the TemplateBased-VM creation window there could be a checkbox "inherit the TemplateVMs home folder" that shows an explanatory popup when hovering over it [or similar info/help machanism], that is unchecked by default
Yes, this is some option. Would not simplify implementation, but will be
probably most flexible from all the ideas here.
- TemplateBased-VM should get read access to its TemplateVM home folder (mount it to /home.something)
I like the idea of having template home still accessible from AppVM, not
only for initial AppVM setup. Of course if we decide to have it somehow
inherited at all.
Proposal:
- TemplateVMs and TemplateBasedVMs home are always standalone.
- An AppVMs home folder is populated using /etc/skel on its first boot.
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."
Yes, this is one of the reason why we're considering this at all :)
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
|
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, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Oct 15, 2015
Member
Hmm, think also about this use case:
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.
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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
NewQubesUser
Oct 24, 2015
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.
NewQubesUser
commented
Oct 24, 2015
|
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
enhancement
label
Nov 2, 2015
marmarek
added this to the Release 3.1 milestone
Nov 2, 2015
marmarek
added
C: core
P: major
release-notes
labels
Nov 2, 2015
marmarek
modified the milestones:
Release 4.0,
Release 3.1
Dec 21, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Dec 21, 2015
Member
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
- Actually template would not have private.img at all - user (and root) home would be stored on root.img
- TemplateBasedVMs would have access to the current user home of template (not only from VM creation time) - in some other directory, like
/home.orig(this directory currently exists, but have slightly different purpose - original /home from template build time) - Not yet decided: user home may be populated from
/etc/skelor template home [1] - User home in DispVM will be populated from template home (there will be no
TEMPLATENAME-dvmVM at all - DispVMs will be created directly from template)
Template "private" private.img
- TemplateVM will have its own
private.img(as it is done currently) - New VMs will not inherit that
private.imgat all - will start with empty one - User home of new VMs will be populated from
/etc/skel - DispVM (based on such template) will be populated from
/etc/skel
Notes and todos
- This means the same method for customizing DispVM and new VMs based on a template - should be much easier than the current approach
- [1] IMHO user home should be initialized from
/etc/skel(for consistency with the other option), but maybe we should provide some mechanism to sync some selected files from template's home? That mechanism may be also used for syncing selected also files after VM was created (so some files may be updated). That would be fragile, but if set in opt-in manner, may be an option. - The above mechanism may be even set to copy all the files from template's home at VM creation (effectively having new VM home initialized from union of
/etc/skeland template's home) - That mechanism should be configured allowing drop-ins approach - so packages can opt-in and opt-out selected files.
- Default value for the new setting - we were talking about "shared" approach, but it isn't final
cc @adrelanos
|
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 |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Dec 21, 2015
Member
|
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?
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Dec 21, 2015
Member
On Mon, Dec 21, 2015 at 03:15:14PM -0800, Patrick Schleizer wrote:
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.
Agree.
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.
This is also about sharing settings with already existing VMs (created
before the change was made in the TemplateVM). But yes - probably only
for advanced users. Or some mechanism which will sync selected files on
opt-in basis.
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".
Not yet. @bnvk, what do you think?
Other ideas for such an "advanced" menu would be "initially populate
/home/user from the TemplateVM's /home/user instead of from /etc/skel"
I think the most important use case for this would be DispVMs. Users
needs some (easy UX-wise) way to customize it. Editing settings just in
TemplateVM (possibly a clone) should be good for it. Editing files in
/etc/skel is somehow harder.
Somehow related: what would be the steps to configure Firefox for
DispVM? For example install some plugin. Ideally it should not require
the user launching Firefox in the template (both for security and for
privacy - firefox would create some unique data at first run, at least
profile ID). Is is possible at all?
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?
When /root will be moved into private.img, then yes.
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
|
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, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Dec 21, 2015
Member
[Preliminary remark: In my ideal imagination for some time now, to
create what we currently call DispVM would only be a check box called
"amnesic" [or better] in QVMM's 'Create VM' dialog.
Later 'amnesic' would be a check box in the VM settings. Setting the
setting makes it a DispVM. Unchecking the setting makes the VM a
TemplateBasedVM. I have some more ideas for the details, but it's
off-topic here.]
Marek Marczykowski-Górecki:
On Mon, Dec 21, 2015 at 03:15:14PM -0800, Patrick Schleizer wrote:
Other ideas for such an "advanced" menu would be "initially populate
/home/user from the TemplateVM's /home/user instead of from /etc/skel"I think the most important use case for this would be DispVMs. Users
needs some (easy UX-wise) way to customize it. Editing settings just in
TemplateVM (possibly a clone) should be good for it. Editing files in
/etc/skelis somehow harder.Somehow related: what would be the steps to configure Firefox for
DispVM? For example install some plugin. Ideally it should not require
the user launching Firefox in the template (both for security and for
privacy - firefox would create some unique data at first run, at least
profile ID). Is is possible at all?
Have a check box 'allow customization at [first|next] boot of this VM'
in QVMM's CreateVM dialog, which would boot the DispVM like a normal
TemplateBasedVM. The user could customize the VM then. For example
install any Firefox plugins / add-ons. On next boot, the VM would be
booted as DispVM. A wizard could guide the user through the whole process.
adrelanos
commented
Dec 21, 2015
•
edited
Edited 1 time
-
adrelanos
edited Apr 30, 2016 (most recent)
edited
-
Apr 30, 2016 (most recent)
|
[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' |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
andrewdavidwong
Dec 25, 2015
Member
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.
|
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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Dec 26, 2015
Member
On Fri, Dec 25, 2015 at 02:13:39PM -0800, Axon wrote:
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.
Agree.
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
|
On Fri, Dec 25, 2015 at 02:13:39PM -0800, Axon wrote:
Agree. Best Regards, |
added a commit
that referenced
this issue
May 31, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tasket
Nov 21, 2016
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.
tasket
commented
Nov 21, 2016
|
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. |
marmarek
referenced this issue
Oct 19, 2017
Open
Document change in TemplateVM home directory inheritance behavior #3196
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Oct 23, 2017
Member
To summarize what finally got implemented in Qubes 4.0:
- TemplateBasedVM (aka AppVM at API level...) do not inherit private volume from TemplateVM, it starts with a fresh one, and populate it from
/etc/skelat first startup. - DispVM are based on AppVM/TemplateBasedVM (similar to fedora-xx-dvm in Qubes 3.x, but more explicit), and they do inherit private volume from there.
- There is no more need to create
/home/user/.qubes-dispvm-customizedfile.
This approach should cover discussed here concerns/use cases:
- It is possible to store TemplateVM-private files inaccessible to AppVM, and at the same time it is possible to clearly mark customizations to be inherited by new AppVMs - using
/etc/skel. - It is easy to customize DispVM, by simply configuring related AppVM (like install firefox addon there).
|
To summarize what finally got implemented in Qubes 4.0:
This approach should cover discussed here concerns/use cases:
|
adrelanos commentedOct 14, 2015
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?