Re: [qubes-devel] Safe Arch install
On Sun, May 24, 2020 at 03:01:50PM -0400, Demi M. Obenour wrote: > > https://github.com/xaki23/rzqubes/blob/master/misc/installtemplate.sh > > > > can be run in either dom0 or (with a lot of policy adjustments > > or a bazillion manual approvals and minor changes) an adminapi-vm. > > > > it is also mostly trivial to install the template-root right > > from the buildvm. (skipping the "rpm" part entirely) > > How does one do that? That sounds promising. see above shellscript for the general basic outline of "how to turn a template rpm into a template vm". most of the qvm-something steps are also avail in appvms through the adminapi these days. (== can be called from a buildvm) for "skipping the rpm part" prototype see https://github.com/QubesOS/qubes-builder/pull/87 and related PRs/diffs. both the shellscript and builder integration are fully functional, but need cleanup before they can be merged. the main open issue is how to integrate a template-specific settings-file (the "tplspec" parts) with the build process. this is mostly needed for the mirage templates. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20200524191305.GS1079%40priv-mua.
Re: [qubes-devel] Safe Arch install
On Sun, May 24, 2020 at 02:36:00PM -0400, Demi M. Obenour wrote: > Is it possible to build an Arch install ISO in addition to the > TemplateVM RPMs? I would prefer to avoid copying the RPMs into > my dom0, whereas installing from an ISO has no such problems. that is actualy worse than copying a rpm to dom0. > Alternatively, is it possible to extract a root filesystem image > from an RPM and safely (without compromising dom0) import it into a > fresh TemplateVM? https://github.com/xaki23/rzqubes/blob/master/misc/installtemplate.sh can be run in either dom0 or (with a lot of policy adjustments or a bazillion manual approvals and minor changes) an adminapi-vm. it is also mostly trivial to install the template-root right from the buildvm. (skipping the "rpm" part entirely) -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20200524184902.GR1079%40priv-mua.
Re: [qubes-devel] Re: Rowhammer
On Fri, May 15, 2020 at 09:52:32AM -0700, Zach Lym wrote: > The only truly effective mitigation for ROWHAMMER that I am aware of is > encrypted memory, which is only available on some AMD processors. do you have any reference/paper/link for this? aiui pure "destructive" rowhammer will not be changed by "memory encryption" at all. a "privilege escalation / limited targeted write" rowhammer will only be a little harder and easier to detect. (depending on implementation details) and a memory encrpytion implementation that was designed with this problem in mind might make "rambleed / reading through reverse rowhammer" somewhat hard. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20200515174007.GJ1079%40priv-mua.
Re: [qubes-devel] Shared /home partition
> On Friday, February 28, 2020 at 7:00:13 PM UTC+5:30, unman wrote: > > Is it okay? No one mention the security implications? > > As soon as you share dom0 with another OS you open an unsavoury can of > > worms. > > If you're fine with undermining the Qubes security model, go ahead. On Fri, Feb 28, 2020 at 12:37:17PM -0800, saitaruninaganti wrote: > I mean, dom0 is not a container by itself, is it? It's a hypervisor, just > like any other install. For my purposes, I think it should do just fine. I > have a space issue on my computer and this is just a temporary solution. dom0 is not the hypervisor. qubes uses xen, and xen is an actual hypervisor, not a hv/dom0 hybrid like kvm. (aka "biggest layering violation since zfs") so, unman is very much right there, and i should have mentioned that in my initial reply. my summary there would be: by multi-booting your qubes host you are basicly reducing the qubes security to that of the weakest other-os you are using for many attack pathes. "unsavoury can of worms" is a fair summary too. whether that matters ... depends on your threat model. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20200228205915.GF8973%40priv-mua.
Re: [qubes-devel] Shared /home partition
On Fri, Feb 28, 2020 at 03:26:21AM -0800, saitaruninaganti wrote: > Is it okay to share Qube's home partition with a different linux > distribution? This isn't my first time doing something like that. In fact, > I managed to do it with Arch, Fedora and OpenSUSE (ext4) without any > issues. I only had to make sure they shared the same hostname and primary > username. qubes 4.0 default storage setup is just luks+lvm, so you can open+mount the partitions on whatever other linux you want. the other way around works too, just attach whatever blockdevices needed to the right VMs. and no, hostname or username should not matter at all... userid might, depending on the usecase. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20200228113738.GC8973%40priv-mua.
Re: [qubes-devel] Qubes 4.0.2 severe issue - dom0 kernel crash
On Sat, Jan 04, 2020 at 10:20:02AM +, 'awokd' via qubes-devel wrote: > > - R4.0.3 - next point release, just earlier one > > - R4.0.2.1 - point release of a point release, since the change is very > > minimal > Everyone's got those, including myself! How about R4.0.2b? However, I > vaguely recall some code (in some of the update components maybe) that > parses Qubes versions. R4.0.3 might be more readily digested by that code > than alpha characters or additional sub-points. very much in favor of 4.0.3 4.0.2.1 adds to the confusion of users who reliably mixed up "4.0.1" and "4.1" over the last year. and 4.0.2b is at least as confusing for both users and tooling. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20200104104453.GA8973%40priv-mua.
