-
-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
don't really boot TemplateVM, only chroot into those #1306
Comments
I think it is a bad idea, for many reasons:
So, instead, I would suggest preparing some "blacklist" of packages known of creating unique initial data, which should really be unique for every VM. This list would be probably different for Whonix and non-Whonix templates. And then clean such data (it should be simple to create some service running at TemplateVM shutdown, which would remove/sanitize listed files). This isn't generic solution (neither is yours), but IMHO have much less potential for breaking random things (there are over 2k packages in template and probably only few of them require such treatment). Another solution would be to move such (selected) data to /rw partition (either using symlinks or bind-mounts). Then each VM would have its own, persistent copy. But this would be probably much more service-specific and require more work. |
Marek Marczykowski-Górecki:
Sure. The final decision is yours. Just trying to brainstorm here. I am
Maybe there is a contradiction here or lack of understanding on my side. If the user boots the template and installs packages, you prefer the But imagine a user just downloaded a fresh TemplateVM and created an
For system-wide changes: GUI tools, dbus in chroot: What I am suggesting is basically just to start in the TemplateVM what
I don't think so. This is same as 1. If we consider package installation
I see.
Ok.
On first thought, I think if anything, Whonix would just extend that
Hm. Cleaning sounds difficult, package specific, maintenance burdensome, If the unwanted files aren't created by post installation scripts, we
But there are X how many k packages available from installation from
Yes. Btw, there is such a bind-mount script. @nrgaway wrote it. |
We have our template builder which can apply some post-installation
Not really - because the template is started during package installation
Not sure if that's fully true. Calling dbus service requires that the
Hmm, I don't think even that would be enough. During template build This is mostly Debian-specific, because Debian policy is to start the
I have in mind mostly starting/running the process (all the surrounding
Yes, that was my thought.
I can't think of such example either for now. But I have in mind some
Yes. And consider it either Qubes-wide, or only for Whonix. Case by
Just double checked - currently chroot doesn't prevent host key
Good idea. Making it configurable seems to be quite easy, as in the Best Regards, |
Yes. (Added this to my plate - https://phabricator.whonix.org/T414 - but I not mind about anyone jumping in. A good, easy task for contributors to get started btw.) |
Closing this as wontfix then. Thanks a lot for all the explanation and your consideration! |
I think booting a TemplateVM directly is bad. During boot, various daemons start [custom installed packages] and create their data folders, random seeds are created and so forth. All that date is then shared with AppVMs, so it could happen, that those all share the same random seeds.
So I am suggesting to not "really" boot into the TemplateVM. From the point of view of the user nothing should change. But when one boots a TemplateVM, what really should happen under the hood, is creating a temporary AppVM based on that Template. And then
chroot
ing into the TemplateVMs image. When one would update or install new packages inside the TemplateVM, these services would not start up, hence not make the image "dirty".The text was updated successfully, but these errors were encountered: