[qubes-users] Re: Recommended laptop?
My own longterm Qubes primary has been a used W520 quad core with four 8GB DIMMs for 32GB of RAM. Not bad for 2012 era laptop. [Avoid the dual core versions: they only have two memory slots and can only support 16GB Max.] Storage: 1 x mSATA (300MB/s) slot; 1 x SATA (600MB/s) main bay; 1 x SATA (600MB/s) in media tray replacing optical drive; 1 x eSATAp (300MB/s) external port. Additional 1 x eSATA (300MB/s) on some docks. So plenty of fast-enough storage options. Plus an SD card slot. VGA. DisplayPort. Ethernet. WiFi. Modem. 2 x USB 3.0. 2 x USB 2.0 (1 is part of the eSATAp connector). More on some docks. FireWire and Expresscard (you’d generally want to disable both in bios for security reasons). Though...expresscard can be used to add another usb controller if two is not enough (e.g. to work around usb pass through issues with usbip). Core unit generally $250-$300 on eBay in ok shape (sans ram and storage which you can add yourself). Bit heavier than the x230, but I appreciate the additional RAM and cores most of the time. Install in legacy mode, disable discrete GPU. B -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c953df6c-145a-4380-b395-d49b2f4699b8%40googlegroups.com.
[qubes-users] Re: HOWTO: Enable screen poweroff (instead of blanking)
On 12/22/19 4:45 AM, Claudia wrote: > I just wanted to drop a note here before I forget. Out of the box, Qubes > blanks the screen after a few minutes, but never powers off the screen, even > though it's configured to do so in the XFCE Power Manager. I've had this > problem on several machines, all the way back to R3.2, and I always blamed it > on lack of hardware support. > > Turns out, it's because Qubes comes with Xscreensaver enabled which overrides > the XFCE Power Manager settings. Xscreensaver is only configured to blank the > screen; I'm not sure if it even supports powering it off. To return control > to XFCE, go to Menu > System Tools > Session and Startup > Application > Autostart, and uncheck "Screensaver". Then you can logout, reboot, or go to > Menu > System Tools > Screensaver > File > Kill Daemon. You may have to also > open Menu > System Tools > Power Manager > Display, and switch "Display power > management" to off and then on again. > > Note this will disable the lockscreen. This is not recommended if you use a > USB keyboard or mouse and a USB Qube, or if someone has physical access to > your computer while it's on. Otherwise, I recommend enabling screen poweroff > in order to conserve energy and lengthen the lifespan of your screen's > backlight. > there Does seem to be another session> application autostart item called Screensaver (Launch screensaver and locker program)(not just xscreensaver) that is 'checked' to start , maybe I'll leave it alone for now -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ce83b375-1bcc-2690-887d-deb5661b9097%40riseup.net.
[qubes-users] Re: HOWTO: Enable screen poweroff (instead of blanking)
On 12/23/19 12:23 PM, Defiant wrote: > > > On 22. 12. 19 15:45, Claudia wrote: >> >> I just wanted to drop a note here before I forget. Out of the box, Qubes >> blanks the screen after a few minutes, but never powers off the screen, even >> though it's configured to do so in the XFCE Power Manager. I've had this >> problem on several machines, all the way back to R3.2, and I always blamed >> it on lack of hardware support. >> >> Turns out, it's because Qubes comes with Xscreensaver enabled which >> overrides the XFCE Power Manager settings. Xscreensaver is only configured >> to blank the screen; I'm not sure if it even supports powering it off. To >> return control to XFCE, go to Menu > System Tools > Session and Startup > >> Application Autostart, and uncheck "Screensaver". Then you can logout, >> reboot, or go to Menu > System Tools > Screensaver > File > Kill Daemon. You >> may have to also open Menu > System Tools > Power Manager > Display, and >> switch "Display power management" to off and then on again. >> >> Note this will disable the lockscreen. This is not recommended if you use a >> USB keyboard or mouse and a USB Qube, or if someone has physical access to >> your computer while it's on. Otherwise, I recommend enabling screen poweroff >> in order to conserve energy and lengthen the lifespan of your screen's >> backlight. >> >> > > I have also noticed this annoyance on several machines and different > linux distributions so it must be an Xfce problem, not a Qubes problem. > > You're probably asking yourself why do we even need xscreensaver when we > can instead use a screen locker like lightlocker. I think I read on the > issues tracker that xscreensaver is the most secure screen "locker" for > X11 which is why it is used in Qubes, and if you would want to use > something stronger you'd have to go wayland. > > I hear Qubes 4.1 will use the new Xfce 4.14 though I am unsure whether > this bug has been fixed in that version. > > > Kind regards! > thanks for this, always wondered ... had given up on any systemwide changing things -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/aa633cc9-1de5-232c-18d3-a3ce8173ebc9%40riseup.net.
[qubes-users] Re: Recommended laptop?
On 12/25/19 1:03 PM, brendan.hoar-re5jqeeqqe8avxtiumw...@public.gmane.org wrote: > Insurgo is providing a service. > > If one can do the steps themselves, that’s fine. > > If I were advising a somewhat less technical journalist or a potentially > targeted human-rights worker or politically targeted activist who just wanted > to get stuff done and had the resources, I’d point them to Insurgo. > > Brendan > +1 thinkpads think mine is a x540 or something, +1 16gb RAM and SSD, bought my thinkpad used year ago for like $200 add the RAM and SSD , apparently some feel Intel isn't really trustworthy but might have to pay more for non Intel machines, and roll dice if it has the VT-d or Iommu required minimums, personally I don't use the TPM though I have it, fear I'll likely lock myself out , and don't know what I'm doing in general :) -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f0dfb38f-d19e-1076-2e8a-645e3d9a99e6%40riseup.net.
[qubes-users] Built arch linux template and installed but app can't be running?
Hello. I just built archl inux template and moved to dom0 and installed the template. Then I treid to open a terminal in arch linux template VM, but It shows nothing. Can you please check this logs and please tell me what is wrong. Thanks I searched the word 'Failed" and found few. [0m] Failed to start. Initialize and mount /rw and /home see 'systemctl status qubes-mount-dirs.service' for details [0m] Failed unmounting /usr/lib/modules ... msg='unit=qubes-mount-dirs comm="systemd" exe="/usr/lib/systemd/systemd" hostname=" addr=? terminal=? res=failed' tsc: Fast TSC calibration failed failed to mount moving /dev to /sysroot/dev: Invalid argument failed to mount moving /proc to /sysroot/dev: Invalid argument failed to mount moving /sys to /sysroot/dev: Invalid argument failed to mount moving /run to /sysroot/dev: Invalid argument when I tried to run terminal, in log says audit: type=1131 audit(some number): pid=1 uid=0 auid=some number ses=some number msg='unit=systemd=tmpfiles-clean cmm="systemd" exe="/usr/lib/systemd" hostname=? addr=? terminal? res=success' -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e2eb621d-3ae7-49b5-a121-1bdcc67c7915%40googlegroups.com.
[qubes-users] Re: Building gui-agent-linux failed while building Archlinux template.
I don't know that this is correct solution for this but I resolved this issue by doing this In qubes-builder/example-configs/qubes-os-r4.0.conf I just uncomment last three lines that says *DISTS_VM += archlinuxCOMPONENTS += builder-archlinuxBUILDER_PLUGINS += builder-archlinux* and it works. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1163e10a-dea5-4f10-95ae-b0b5c55d5dfa%40googlegroups.com.
Re: [qubes-users] upgrade: latest stable -> latest testing RC
One additional thing: certain install-related, VM-creation or volume-creation “fixes” across versions won’t be applied after an upgrade. E.g. there were volume mis-alignment fixes, that lead to better SSD and LVM performance, made after 4.0, that aren’t auto-fixed for existing VMs or templates. Presumably the template building process means that removing templates and redownloading more recently built templates then creating new VMs will lead to fixes for domUs. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/fec476e6-e341-4a19-b77e-dfd205799e85%40googlegroups.com.
[qubes-users] Re: Recommended laptop?
W dniu wtorek, 24 grudnia 2019 10:43:08 UTC+1 użytkownik Ondřej Šulák napisał: > > Hello pals, > for the last release of Qubes, what laptop would you recommend? Is there > any cheaper option which does have HW compatibility with latest Qubes > (ideally with shipping from EU), than this one: > > https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/ > > ? > > Thanks for any tips! > > Ondrej > Insurgo isn't really doing anything you can't do yourself with an x230 so just buy a regular x230 (they're dirt cheap at this point), put 16gb of ram and an ssd inside and then flash heads on there -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/fa3b1fa1-2096-4276-b5d4-78a24ebdeba4%40googlegroups.com.
Re: [qubes-users] upgrade: latest stable -> latest testing RC
December 25, 2019 6:49 PM, taschent...@posteo.de wrote: > Hey. > > i have two questions: > > how can i upgrade from the latest stable release 4.0.1 to the latest RC 4.0.2- > rc3? The older upgrade guides, for instance > https://www.qubes-os.org/doc/upgrade-to-r4.0 look like i'd have to reinstall. You don't have to reinstall. Just use the built in Qubes Update tool. Point releases (the last digit) are not new versions of their own, they're just a "checkpoint" where the ISO is rebuilt with the newest packages. Installing 4.0.2 is the same as installing 4.0.1 and fully updating it (with a few minor exceptions occasionally, see below). Note that rc releases might contain a few packages that are newer than what's available in the stable repos. If you want, you can switch to the current-testing repos for the latest packages. Even rc releases only update from the stable repos, though, unless you manually change it. You only have to reinstall for a minor or major version upgrade, e.g. 3.1 -> 3.2, or 3.2 -> 4.0. The article you referenced is about upgrading an existing R3.2 installation to R4.0, as I recall. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ebc938978d83c0d7c80de222fb9655a4%40disroot.org.
[qubes-users] upgrade: latest stable -> latest testing RC
Hey. i have two questions: how can i upgrade from the latest stable release 4.0.1 to the latest RC 4.0.2- rc3? The older upgrade guides, for instance https://www.qubes-os.org/doc/upgrade-to-r4.0/ look like i'd have to reinstall. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a50a63540784aec2a559915e8f316d104affe872.camel%40posteo.de.
[qubes-users] QSB #56: Insufficient anti-spoofing firewall rules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Qubes Community, We have just published Qubes Security Bulletin (QSB) #056: Insufficient anti-spoofing firewall rules. The text of this QSB is reproduced below. This QSB and its accompanying signatures will always be available in the Qubes Security Pack (qubes-secpack). View QSB #056 in the qubes-secpack: https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-056-2019.txt Learn about the qubes-secpack, including how to obtain, verify, and read it: https://www.qubes-os.org/security/pack/ View all past QSBs: https://www.qubes-os.org/security/bulletins/ View the Xen Security Advisory (XSA) Tracker: https://www.qubes-os.org/security/xsa/ ``` ---===[ Qubes Security Bulletin #56]===--- 2019-12-25 Insufficient anti-spoofing firewall rules Summary === The firewall configuration in Qubes OS prevents IP address spoofing in downstream interfaces (e.g., network-providing qubes, network-consuming qubes, and `vif*` interfaces). However, it does not prevent IP spoofing in upstream interfaces (normally `eth0`, but in the case of VPNs or other configuration, there may also be others). Impact == Configurations with inter-VM networking allowed [1] or additional interfaces created (e.g., VPNs) are vulnerable to IP spoofing. Combined with other vulnerabilities, such as the procedure described in the CVE-2019-14899 report [2], this could allow an upstream qube (e.g., sys-net) to inject data into an established connection. Discussion == The anti-spoofing firewall rules in a network-providing qube look like this: *raw ... -A PREROUTING ! -s 10.137.0.5/32 -i vif12.0 -j DROP -A PREROUTING ! -s 10.137.0.6/32 -i vif17.0 -j DROP -A PREROUTING ! -s 10.137.0.7/32 -i vif18.0 -j DROP -A PREROUTING ! -s 10.137.0.8/32 -i vif21.0 -j DROP COMMIT Each `vif*` interface drops packets if its source IP does not match the one assigned to the qube behind that interface. However, it does not ensure that the source IP does not appear on any other (non-`vif`) interface. The other property could, in theory, be achieved by this FORWARD chain: *filter ... -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -j QBS-FORWARD -A FORWARD -i vif+ -o vif+ -j DROP -A FORWARD -i vif+ -j ACCEPT -A FORWARD -j DROP COMMIT These rules should reject packets not belonging to established connections on non-vif interfaces. Moreover, without seeing other packets in the connection, it should be prohibitively difficult to forge packets that would be considered to be part of an established connection. However, methods like the one described in the CVE-2019-14899 report [2] allow one to guess the required parameters. Note that if a connection normally goes through a given qube (without any further protection like TLS), that qube can always manipulate the traffic without guessing anything. The default Qubes configuration is secure, since network traffic either goes directly to the upstream qube (which, by definition, has access to that traffic), or it is an inter-VM connection attempt, which is prevented by the third rule (meaning that there are no connections in the conntrack table that the upstream qube could try to hijack). However, once the user departs from the default configuration, e.g., by introducing inter-VM communications [1] (allowing traffic between some `vif*` interfaces), or VPN-like interfaces, the default rules are no longer sufficient, since an upstream qube can inject packets (by spoofing the source IP) into connections that normally do not pass through it in the clear. Our solution to this problem is twofold: 1. For Qubes OS 4.0, whenever a running qube is connected to a network-providing qube, an additional firewall rule is added that blocks the running qube's IP as a source on other network interfaces. 2. For Qubes OS 4.1 and later, we will modify the firewall mechanism so that it maintains aa list of connected qubes and their addresses, even when they are not running. All such addresses will be rejected on upstream network interfaces. The main difference between these two solutions is that fix for Qubes OS 4.0 does not protect against spoofing the addresses of qubes that are not running. However, since 4.0 is a stable release, we must consider the impact of such a solution on the stability of this release. This fix is a much simpler change that carries a considerably lower risk of introducing a regression. Patching The specific packages that resolve the problems discussed in this bulletin are as follows: For Qubes OS 4.0: - qubes-core-agent version 4.0.51 The packages for domUs are to be installed in TemplateVMs and StandaloneVMs via the Qube Manager or via their respective package managers: For updates to Fedora from the stable repository (not immediately available): $
[qubes-users] How to load .ISO while HVM is running
I have a HVM with a bootloader .ISO loaded in the VM. I would like to swap the cdrom and point it to another .ISO located in an AppVM. I cannot detach the device since i get an empty response from qubesd(see journalctl in dom0 for details). Is there any way to load two .ISO as --cdrom simoultaneously? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/52963db1-1913-4a6d-a6a0-83fa8ea052d3%40googlegroups.com.
