[qubes-users] RE: Spoofing CPUID to AppVM?
Hello, I am wondering if there is a straightforward way to spoof the CPUID to an AppVM, more specifically, to remove the "XenVMMXenVMM" string? I am aware of these patches: https://gist.github.com/dylangerdaly/2ec8172116e63fd56feb0cf95f4d5a69 https://gist.github.com/dylangerdaly/74be3f316ce8f0ddfb27b0202aa5ec2d But was hoping for a solution that did not introduce additional maintenance burdens. I have searched online to no avail. Many thanks for any answers. Regards, N -- 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/NbCtGb43XoN6csXEzBLUVpgbA9kFVFrW_RzUoysc5FYuBoaHAaXqUUTLPstnRaybSkJE60dwpNiIaMf_zunPsOYc9LbmnBaMUYax3hAE3Xc%3D%400x00.email.
Re: [qubes-users] Qubes/Whonix as an Internet Gateway for a client machine
Another option, depending on the machine, is add another ethernet nic or wifi dongle. Create a vm that 'provides network' and enable network manager in that vm (im calling it sys-lan here). Then assign the new nic or dongle to sys-lan. Assign netVMs like usual sys-net>sys-firewall>sys-whonix>sys-lan Traffic will then flow through qubes normally with sys-lan assigning ip and dns settings to whatever is on the sys-lan nic. -- 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/7786f1ae-3069-4293-9b9c-e0c98fed4f76%40googlegroups.com.
[qubes-users] Re: Help needed diagnosing poor IP camera performance with only 'some' hvms
I did find one thing that may or may not be related. The NICs on my machine are Realtek 8111E and there is some chatter on the Internets that the standard driver for this NIC family are buggy. During install debian and fedora default to the driver 'r8169' which is suspect. The correct driver should be r8198 for this family of cards. Some of these r8198 drivers are available in the debian non-free section. But enabling by enabling this repo in qubes, or installing the debian package 'firmware-realtek' does not update the driver firmware. I tried to build the driver following these instructions: https://unixblogger.com/how-to-get-your-realtek-rtl8111rtl8168-working-updated-guide/ Using apt install r8168-dkms and this seemed to conflict with qubes itself because I suspect it is trying to build into 4.19.84.pvops.qubes.x86_64 instead of what it thinks is going to be the debian kernel. It throws "error bad return status for module build on kernel: 4.19.84.pvops.qubes.x86_64 downloading the drivers from realtek and using their auto installer also runs into a problem trying to generate latent entropy at ./include/linux/random.h:26:31 giving an error for latent entropy undeclared. Perhaps this is to do with the qubes method of generating randomness being different as well. Either way this may all not matter because the data rate from these cameras is fine in fedora, which is using the same or similar r8169 driver. But the 8111 and 8168 network chips are pretty common so maybe their correct drivers should be added into qubes itself at some point. -- 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/8242f3f5-16b3-458a-9098-bdf7b7c94892%40googlegroups.com.
Re: [qubes-users] Choosing a TemplateOS for security
What about a rolling release model for all qubes like arch linux? This way there is one static state for all VMs, in their default state. No need to retool for version upgrades on at least two different distributions, three if you count dom0. One standard template can be maintained like a service model rather than release based model. Qube templates could be backed up and branched off from(via clones) as needed by the user. Devs and others interested would only have one code base to review and improve on. -- 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/58bee203-2683-462f-8483-af36e02beaf7%40googlegroups.com.
[qubes-users] Re: debian-10-minimal as vpn proxy with qubes-vpn-support
I know this is not what you are asking for, but I was able to get a deb-10-minimal vpn vm by following the vpn write up in the qubes docs. The only problem is the little pop up window for VPN UP or DOWN does not work properly but I did not bother finding out why. On Friday, January 24, 2020 at 10:23:31 AM UTC-5, Dominique St-Pierre Boucher wrote: > > Good day Qubes OS Community, > > I am trying to get a vpn proxy run based on the debian-10-minimal. I a > trying to connect to protonvpn. I was able to do it with a fedora proxy so > I know it works. > > I was able to install everything needed in the template, I configured > qubes-vpn-support on my vpn proxy but when I try to connect, I got error > related to the update-resolv-conf script. > Getting this error message: > resolvconf: Error: Command not recognized > Usage: resolvconf (-d IFACE|-a > IFACE|-u|--enable-updates|--disable-updates|--updates-are-enable > > Can someone point me in the right direction with the difference between > resolvconf on Fedora and resolvconf on Debian? > > Thanks > > Dominique > -- 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/631f73c9-316d-4cc8-af26-c0fec2302c2b%40googlegroups.com.
[qubes-users] Help needed diagnosing poor IP camera performance with only 'some' hvms
I had three cameras attached to a PoE switch, which was plugged into a NIC on a qubes machine. They ran through an OpnSense hvm(standalone) and out through sys-net. Performance was fine but I wanted to move to a qubes template-based vm to control the NIC. So I created a Debian-10-minimal template, installed qubes-core-agent-networking and qubes-core-agent-network-manager(the only non stock things installed), assigned the NIC to the AppVM(in HVM mode), and configured the camera facing NIC(ens7 in this case) as "Shared to Other Computers". I gave the debian vm the same ram(4gb) and vcpus(2) as the OpenSense hvm. Performance was terrible. On an external wifi I could typically get a stream of 4000 kbps with the OpnSense hvm routing the cameras through Qubes. Now, I am getting at best 100kbps and the connection drops off. To test, I attached the NIC to a Fedora 30 vm running an apache server and was able to connect to the cameras at 4000kbps. In all cases, the cameras have been routed through the same sys-net and sys-firewall vms whether they are coming from OpnSense, debian, or fedora. I have a similar setup connecting other computers to Qubes, where their NICS are run by a copy of the debian-minimal hvm and browsing and downloading is unaffected. I can usually get about 90% of my network connection speed, through a vpn, with it set up this way. For my own education, what could be causing the differences in the connections with these cameras? Are the cameras saturating a buffer I could tweak? -- 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/418b1440-da32-4062-9e15-05734d9cff88%40googlegroups.com.
[qubes-users] High latency between VMs
I noticed some services were a bit laggy lately and pinged from an APPVM to sys-net. There appeared to be a .500ms delay per hop to sys net. So APPVM > sys-firewall > sys-net = about 1ms delay. This becomes fairly substantial if there are other ProxyVMs like a sys-vpn or whonix. This occurs using all debian minimal vms, or fedora 30(full or minimal) vms for sys-net etc. This was not like this before(Qubes 3.2 and early releases of 4). For instance, I have security cameras that were perfectly usable going through a machine running qubes, out to the web, and viewed on a phone from anywhere. Now, the connection is a crawl to the point the framerate cant be maintained and the connection drops out. Is there something I can do to correct this issue? Or run further tests? This is occurring on a laptop and desktop at about the same rate. -- 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/34a76946-0cc9-49d7-9db6-1acc1d80911c%40googlegroups.com.
Re: [qubes-users] One of the configured repositories failed (Fedora 20 - x86_64)
> I've setup a machine running R2 since i need audio working on Windows HVM. > > I would like to install QWT but when i run sudo-qubes-dom0-update i get the > following error: > > One of the configured repositories failed (Fedora 20 - x86_64) > ... > Cannot retreive metalink for repository: fedora. Please verify it's path > and try again. > > Do i need to configure qubes-dom0.repo? > Fedora 20? It should be Fedora 30. -- 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/47hZJf6z5gz6tm7%40submission01.posteo.de.
[qubes-users] What is the proper firewall rule(s) to use dnscrypt-proxy?
Good day, I have dnscrypt-proxy working in sys-net only. But I am stuck on how to forward dns requests moving from sys firewall and the vms behind it so that sys-net can route them out via the proxy. I only have dnscrypt-proxy running, it is not combined with unbound or dnsmasq. The firewall rule in sys-firewall is Chain PR-QBS (1 references) pkts bytes target prot opt in out source destination 169 DNAT udp -- * * 0.0.0.0/0 10.139.1.1 udp dpt:53 to:10.139.1.1 0 0 DNATtcp -- * * 0.0.0.0/0 10.139.1.1 tcp dpt:53 to:10.139.1.1 0 0 DNATudp -- * * 0.0.0.0/0 10.139.1.2 udp dpt:53 to:10.139.1.2 0 0 DNATtcp -- * * 0.0.0.0/0 10.139.1.2 tcp dpt:53 to:10.139.1.2 and in sys-net it is Chain PR-QBS (1 references) pkts bytes target prot opt in out source destination 16 960 DNAT udp -- * * 0.0.0.0/0 10.139.1.1 udp dpt:53 to:127.0.0.1 00 DNAT tcp-- * * 0.0.0.0/0 10.139.1.1 tcp dpt:53 to:127.0.0.1 14 840 DNAT udp -- * * 0.0.0.0/0 10.139.1.2 udp dpt:53 to:127.0.0.1 00 DNAT tcp-- * * 0.0.0.0/0 10.139.1.2 tcp dpt:53 to:127.0.0.1 My firewall routing is self taught and not great but from the looks of it dns requests from sys-firewall are being forwared to sys-net on 10.139.1.1 which is receiving them and forwarding them to 127.0.0.1 which is what dnscrypt is using. Yet with it running I cannot resolve any dns outside of sys-net. thanks in advance -- 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/c8911f36-ad79-4275-8b07-52cbfb7da7f0%40googlegroups.com.
Re: [qubes-users] Problem with NextCloud-Client App-VM (unable to login on 2nd boot)
oh I am dumb, perhaps try logging in with your template vm, do the key exchange, and then shut it down. It may stick into the appvm? On Thursday, August 15, 2019 at 11:15:46 AM UTC-7, 799 wrote: > > Hello, > > *Null* ** > schrieb am Do., 15. Aug. > 2019, 19:12: > >> OCC commands: >> >> >> https://docs.nextcloud.com/server/16/admin_manual/configuration_server/occ_command.html#user-commands-label >> (...) > > > Now I understand what you've meant, regarding the movement of directories. > This was related to running a Nextcloud Server within Qubes OS. > In my case I am connected from an AppVM (Qubes OS) to an external > Nextcloud-Server (not running Qubes OS). > > As all Client-settings _should_ be safe in an AppVM I don't understand why > I need to login after the first boot of the AppVM and why even after login > in, the synchronization is not working again. > > [799] > -- 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/899c309f-be2a-47c9-a1e9-b83061518976%40googlegroups.com.
Re: [qubes-users] Problem with NextCloud-Client App-VM (unable to login on 2nd boot)
Oh yeah /home is saved too... I thought just /rw. It is advised on the nextcloud hardening guide to not keep it in the default location and on my setup I had to move it anyways because of how the machine is set up. -- 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/274990d8-a2fa-4854-bebb-55c18557fb9d%40googlegroups.com.
Re: [qubes-users] Problem with NextCloud-Client App-VM (unable to login on 2nd boot)
OCC commands: https://docs.nextcloud.com/server/16/admin_manual/configuration_server/occ_command.html#user-commands-label In qubes you have to specify the file path to occ(in the docs it lets you call occ by itself). So for a typical fedora/apache/nc install in the template you would enter: Sudo -u httpd(or apache) php /usr/share/nextcloud/occ [enter commands] OCC is your main way of administering nextcloud in qubes so that link will help. Qubes appvms do not keep anything outside of /rw so you would need to migrate the storage folder into /rw (https://help.nextcloud.com/t/howto-change-move-data-directory-after-installation/17170) Or you can declare certian folders or files to be persistent. https://www.qubes-os.org/doc/bind-dirs/ This is done in the appvm. Dont designate all of nextcloud to be persistent or if someone hacks the nextcloud appvm its there forever. It is bad enough you are doing it to the file folder. I assume you installed nextcloud in the template and set up an admin account in the process. So when you fire up the appvm anything you do in there will be erased until you add your users via occ in the template and preserve the file folder. Once you do all that it will work fine from your home network, exposing it to the world is a bit of a pain and introduces an attack vector obviously. -- 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/b7f8b6a3-1961-46a4-a095-5e987188f93f%40googlegroups.com.
[qubes-users] How to upgrade fedora versions, but exclude certian apps
I upgraded a fedora minimal based template using the qubes docs guide but one program i was using gor downgraded in the process. Manually upgrading it is a huge pain. Is there an option to exclude a certian app from the process? -- 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/e64f3e12-8746-4963-8ee3-a071398d9db6%40googlegroups.com.
[qubes-users] Problem with NextCloud-Client App-VM (unable to login on 2nd boot)
Sorry my initial reply was the wrong answer. To set up a login that is persistant you need to do it in the template with the occ commands. Any user made in the appvm will not survive a reboot. The nextcloud storage area needs to be made persistant using the qubes-bind-dirs directory in the appvm, the qubes docs cover that. I am able to stay logged in with the nextcloud app and sync via webdav between reboots in this manner. Are you also trying to sync other appvms? -- 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/5787f646-e605-453e-9522-b4205b834377%40googlegroups.com.
[qubes-users] Problem with NextCloud-Client App-VM (unable to login on 2nd boot)
Youve got to set up your user names in the template. So fire up httpd in your template and use the occ commands to add users. Its inconvienent, but the appvm non persistance is the secuity feature that is also preventing anyone from embedding anything too nasty in your system. I have tried to find where specifically user data is stored if you really wanted to allow users to add themselves while the server runs and between reboots, but I recall not finding out much. This has been asked about on the NC forums as well. Youve also got to set up the storage area to be persistant between boots. This is easier to make non persistant. Follow the NC hardening guide to move the folder somewhere else, and then use qubes-bind-dirs to make that folder persistant. You would need to do the move in the template, but set up the bind-dirs in the app. -- 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/d1f13c0d-d849-4d65-b453-4d04d969962b%40googlegroups.com.
Re: [qubes-users] Cannot reach FreeBSD from Qube but can reach Qube from FreeBSD
On Sunday, July 14, 2019 at 7:21:08 AM UTC-7, unman wrote: > On Sat, Jul 13, 2019 at 02:09:14PM -0700, *Null* ** wrote: > > I have a FreeBSD HVM connected to a firewall VM. I also have a Fedora Qube > > connected to the same firewall VM. Networking between these was enabled > > using the iptables instructions from the Qubes documentation. > > > > I can ping and access resources on the Fedora Qube from FreeBSD(I can > > transfer files to and download files from the Fedora VM). > > > > However, I cannot do the same from the Fedora VM. It can ping the firewall, > > but not FreeBSD. Nor can it access resources on the FreeBSD system. > > > > This confuses me because I would assume file transfer(from bsd to fedora) > > implies there is some bi-directional communication. But it seems to only > > work when initiated from one direction(from BSD). > > > > All VMs can connect to the internet, FreeBSD can ping any vm, other VMs can > > ping other qubes based vms, but cannot ping FreeBSD. > > > > What else must be done? > > > This works as advertised. > Can you check on your HVM that you are allowing incoming requests? > That's the obvious explanation for the scenario you have. Ah, I had set ipv4 accept any, figuring that would be fine. But I wrote another for icmp and it worked to ping it. Thanks -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/aa390f94-9d3b-4cae-92b0-a734e6290d5f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Cannot reach FreeBSD from Qube but can reach Qube from FreeBSD
I have a FreeBSD HVM connected to a firewall VM. I also have a Fedora Qube connected to the same firewall VM. Networking between these was enabled using the iptables instructions from the Qubes documentation. I can ping and access resources on the Fedora Qube from FreeBSD(I can transfer files to and download files from the Fedora VM). However, I cannot do the same from the Fedora VM. It can ping the firewall, but not FreeBSD. Nor can it access resources on the FreeBSD system. This confuses me because I would assume file transfer(from bsd to fedora) implies there is some bi-directional communication. But it seems to only work when initiated from one direction(from BSD). All VMs can connect to the internet, FreeBSD can ping any vm, other VMs can ping other qubes based vms, but cannot ping FreeBSD. What else must be done? -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/87057d29-56b8-4819-9306-4a37528ba2ea%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
