Re: [qubes-users] Re: qvm-create-windows-qube 2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2020-01-23 23:10, Rafael Reis wrote: > Wow. This is just outstanding. > > Just installed windows 10 pro (manually downloaded) and it went without a > hitch. Only mistake I made was pressing no for the reboot prompt on the > first VM boot, but I managed to work around it and the script picked up > where it left off. > > Indeed the bugs mentioned on Readme.md are there. I had to take the steps > to do the fixes, especially the cmd to load the gui, otherwise it would not > appear. > > Thank you very much for the incredible contribution. Let me know if I can > debug / test anything, or help some other way. > > > Em segunda-feira, 13 de janeiro de 2020 06:49:12 UTC-3, Elliot Killick > escreveu: >> Thank you, Rafael. Glad it could help you! :) If you're itching to test out something new then I just pushed a new feature: - Followed (mainly) this Whonix documentation to create an (unofficial) Windows-Whonix-Workstation that complies up to the "Even more security" standard: https://www.whonix.org/wiki/Other_Operating_Systems "Most security" is to use a default Whonix VM and build it from source. And with that, another security/privacy improvement that further helps in the isolating of Windows which is that the installation process is now fully air gapped with the exception of installing any packages at the very end (if any are desired). It was mostly air gapped before but there was a small window of time during the "Completing setup of Qubes Windows Tools..." where Windows had access to the Internet before applying the disable telemetry script and now also the script for making Windows into a Windows-Whonix-Workstation. Fixing this was not as simple as just adding/removing the NetVM whenever due to Qubes Windows Tools being a bit finicky. The solution I implemented was to use the Qubes inbuilt Firewall to temporarily drop traffic which kept Windows securely air gapped while still allowing QWT and packages to install fine. Besides that just cleaning up a few things and a small bug here and there. -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQQBj7nebfoT+xj7VVL5uQ1E+D3V8gUCXi1FdQAKCRD5uQ1E+D3V 8p8UAP9IeLZUSpB+jOLt7QXHVzobnQPLhMwW4KhoHl1nKEWmFAEA8agqWjsuxBlP LR8aEjtynsagALcGAAnktHFWmq3XFwA= =35dc -END PGP SIGNATURE- -- 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/57ca48b8-10b3-ddd4-e433-798326b446b0%40zohomail.eu.
Re: [qubes-users] Disposable sys-usb creation fails with "unable to recet PCI device"
On Sat, Jan 25, 2020 at 05:35:20AM +0100, tetrahedra via qubes-users wrote:
On Thu, Jan 23, 2020 at 02:22:20PM +, 'awokd' via qubes-users wrote:
tetrahedra via qubes-users:
Following the directions here:
https://www.qubes-os.org/doc/disposablevm-customization/#create-the-sys-usb-disposablevm
In step 5, did you include the option?
I used the Qube Manager GUI to attach but -- since the USB controllers
were still marked as attached to disp-sys-usb when I ran `qvm-pci` with
disp-sys-usb powered off, I assume the answer is "yes."
Just in case I removed all the USB controllers from disp-sys-usb, then
ran the step 5 command with all USB controllers (including the
`--persistent` option) and tried starting disp-sys-usb.
The original error ("unable to reset PCI device...") still occurs when
trying to start disp-sys-usb.
The error is now also happening when I try to start sys-usb!
--
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/20200126071145.GA1509%40danwin1210.me.
VS: [qubes-users] feature request
DWM can do this for you.it has inbuilt mechanims to Lock app windows to separate tags (Virtual desktops). Also you can define on which monitor this tags is and where you want to Lock it. I'm using dwm on my everyday qubes thinkpads and it works great, all application windows goes there where I want them to go and they don't mess my currently active "window". Lähetetty Jolla Sailfish -älypuhelimestani. Alkuperäinen viesti Lähettäjä: haaber Lähetetty: lauantaina 25. tammikuuta 2020 13.15 Päättymisaika: qubes-users; Andrew David Wong Aihe: [qubes-users] feature request Hello, I have several virtual screens; I guess many user have. Is it possible to reserve one of them exclusively for dom0 and templateVM terminals -sort of a separated "admin screen"- to avoid other appVM-windows popping up and being able to capture input from keyboard? Bernhard -- 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/1c4a6f80-6f85-f1c1-4995-dc5f0cb0ab2b%40web.de. -- 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/20200126064945.4661302.71896.16030%40gmail.com.
Re: [qubes-users] Qubes OS Network installation - Possible to Mirror dom0 iso contents?
For us we boot everything in our menus off the internet , but we don't maintain any rpm/deb mirrors specifically, especially not something this customized. I just provided my goal as an example,but from a support standpoint for the Qubes team the goal would be to be able to provide a lean netinstaller CD and if they choose to , to directly host the kernel/initrd combo for internet booting. I am not saying this project needs to change anything to conform to other standards , but other distros like Fedora/Oracle/Suse provide this kind of installation option due to their default repo setup. The unique outlier in this case is that the ISO build process for Qubes packages machine 0 rpms that are only available in one place on the CD and not in an internet accesable repo. -- 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/86a8c1d6-fc9d-42f3-8d9f-8acfc61ba322%40googlegroups.com.
Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
I have tried to press Tab and also tried the options in the trouble shouting menu. Both ending with the same result... -- 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/c81cbaef-a3b8-46f9-8c40-e51a58adf793%40googlegroups.com.
Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
January 25, 2020 6:46 PM, "M" wrote: > Thank you very much ! - I’ll try that... > > By grub menu you probably mean this one: > https://www.qubes-os.org/attachment/wiki/InstallationGuide/grub-boot-menu.png > > But I do not get so far as it seems to first show after the installation. > > The menu I see is this: > https://www.qubes-os.org/attachment/wiki/InstallationGuide/boot-screen.png Grub doesn't work on R4.0 in UEFI mode, so the installer probably uses syslinux at least for 4.0, not sure about 4.1. Looking at the screenshot, it looks like you just have to press tab instead of "e" and the rest should be the same. Also the troubleshooting menu is probably worth checking out. -- 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/88796dec14c20580381b5b070f5f44ae%40disroot.org.
Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
Thank you very much ! - I’ll try that... By grub menu you probably mean this one: https://www.qubes-os.org/attachment/wiki/InstallationGuide/grub-boot-menu.png But I do not get so far as it seems to first show after the installation. The menu I see is this: https://www.qubes-os.org/attachment/wiki/InstallationGuide/boot-screen.png -- 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/f58911d4-140f-4e45-8d0a-330d7be1c922%40googlegroups.com.
[qubes-users] Does all internal drives that is going to be used with a Qubes OS installation have to be connected to the pc when the Qubes OS is being installed ?
Just to be certain before I begin installing Qubes OS (on my Lenovo ThinkStation pc with intel CPU once again)... 1) Does all internal drives that is going to be used with a Qubes OS installation have to be connected to the pc when the Qubes OS is being installed ? 2) Shall the internal drives which is going to be used together with the Qubes installation be chosen in the installer, or shall I in the installer only choose the internal drive which Qubes OS is going to be installed on ? If the first is correct please explain where in the installer the drives shall be chosen. If the last is correct: Then do I have to do anything else to use the other internal drives together with the Qubes OS installed on the pc ? -- 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/614e4112-5b88-4b9a-993a-fc401ff75e34%40googlegroups.com.
[qubes-users] Re: feature request
On Saturday, January 25, 2020 at 9:56:17 AM UTC-8, pixel fairy wrote: > > On Saturday, January 25, 2020 at 3:15:36 AM UTC-8, haaber wrote: >> >> Hello, I have several virtual screens; I guess many user have. Is it >> possible to reserve one of them exclusively for dom0 and templateVM >> terminals -sort of a separated "admin screen"- to avoid other >> appVM-windows popping up and being able to capture input from keyboard? >>Bernhard >> > > Simpler solution. Q menu / system tools / settings manager / window > manager > uncheck "New window focus" > KDE probably has something like this too. -- 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/22253799-734e-445c-9dbe-9091c2627604%40googlegroups.com.
[qubes-users] Re: feature request
On Saturday, January 25, 2020 at 3:15:36 AM UTC-8, haaber wrote: > > Hello, I have several virtual screens; I guess many user have. Is it > possible to reserve one of them exclusively for dom0 and templateVM > terminals -sort of a separated "admin screen"- to avoid other > appVM-windows popping up and being able to capture input from keyboard? >Bernhard > Simpler solution. Q menu / system tools / settings manager / window manager uncheck "New window focus" -- 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/6382fb15-0a0b-4f8e-ab8b-14c1bc7f4227%40googlegroups.com.
Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
January 25, 2020 4:09 PM, "M" wrote:
> 1) I have tried to install R4.0.3 in legacy mode with the same result. And I
> have also tried the
> other installation possibilities that the DVD offer with the same result.
> Can I somehow save the logs on a USB-drive as I’m running the installer from
> a DVD, or is it only
> possible to get access to the log files afterwards by installing Qubes OS
> from a USB-drive ?
>
> 2) I have tried to look for the “xen.cfg” file you mentioned, but can’t find
> a file with that name
> in the downloaded ISO-file. Where to find it or is it called something else ?
Make sure you're looking in the first partition (/dev/sdb1). I'm not sure what
directory it's in on the installer and I don't have a copy of it handy. On an
installed system it's under (/dev/sdb1)/EFI/qubes/xen.cfg. Note this is for
R4.0 only.
You might want to start a new thread about that, so someone with more
experience in the installer can help you with that.
> 3) By “R4.1 pre-release” do you then mean “R4.0.1” ?
No, R4.1 is an upcoming version that hasn't been released yet, but has unstable
builds available.
https://openqa.qubes-os.org/tests/5493/asset/iso/Qubes-4.1-20200113-x86_64.iso
R4.0.x versions are the same as R4.0, but with updates preinstalled.
> I have tried to load R4.0.1 in legacy mode and when the grub boot menu
> appears, there isn’t any
> option labeled “Qubes R4.1, with Xen Hypervisor”. Just the same installer
> menu as on the later
> versions. And if I press “e”, nothing seems to happen.
It might be called something different. It'll most likely be the default menu
entry which is already highlighted, usually the first in the list.
I have no idea why "e" doesn't work. Can you move up and down to different menu
entries?
> 4) I’m also not totally sure where to add “nomodeset” when you just say at
> the end of the kernel
> line (it looks something like “multiboot2 vmlinuz”)... Sorry, could you be a
> little more precise on
> where I shall write it? Maybe show it in a picture... Just to make sure I add
> it the right place.
Here's a copy from an installed R4.1 system, but the entry in the installer
should look similar. nomodeset is on the second-to-last "module2" line (don't
type the asterisks). In legacy mode this line will start with "linux /vmlinuz-"
(I think) but works the same way. If you add it in the wrong place, don't worry
just reboot and try again.
menuentry 'Qubes, with Xen hypervisor' --class qubes --class gnu-linux --class
gnu --class os --class xen $menuentry_id_option
'xen-gnulinux-simple-2136e4d1-da52-4921-90c1-f7617ab8a31f' {
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2
039dd247-6c6e-40c5-a8ec-890d4462da53
else
search --no-floppy --fs-uuid --set=root ...
fi
echo'Loading Xen 4.13.0 ...'
if [ "$grub_platform" = "pc" -o "$grub_platform" = "" ]; then
xen_rm_opts=
else
xen_rm_opts="no-real-mode edd=off"
fi
multiboot2 /xen-4.13.0.gz placeholder console=none
dom0_mem=min:1024M dom0_mem=max:4096M iommu=no-igfx ucode=scan smt=off
${xen_rm_opts}
echo'Loading Linux 4.19.89-1.pvops.qubes.x86_64 ...'
module2 /vmlinuz-4.19.89-1.pvops.qubes.x86_64 placeholder root=UUID=...
ro rd.luks.uuid=luks-... plymouth.ignore-serial-consoles rhgb quiet
**nomodeset**
echo'Loading initial ramdisk ...'
module2 --nounzip /initramfs-4.19.89-1.pvops.qubes.x86_64.img
}
--
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/cfcf581f7a52bbf3403fe30a609fd402%40disroot.org.
Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
1) I have tried to install R4.0.3 in legacy mode with the same result. And I have also tried the other installation possibilities that the DVD offer with the same result. Can I somehow save the logs on a USB-drive as I’m running the installer from a DVD, or is it only possible to get access to the log files afterwards by installing Qubes OS from a USB-drive ? 2) I have tried to look for the “xen.cfg” file you mentioned, but can’t find a file with that name in the downloaded ISO-file. Where to find it or is it called something else ? 3) By “R4.1 pre-release” do you then mean “R4.0.1” ? I have tried to load R4.0.1 in legacy mode and when the grub boot menu appears, there isn’t any option labeled “Qubes R4.1, with Xen Hypervisor”. Just the same installer menu as on the later versions. And if I press “e”, nothing seems to happen. 4) I’m also not totally sure where to add “nomodeset” when you just say at the end of the kernel line (it looks something like “multiboot2 vmlinuz”)... Sorry, could you be a little more precise on where I shall write it? Maybe show it in a picture... Just to make sure I add it the right place. -- 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/50050c57-f0d2-4998-a438-29b03d5b1b76%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] feature request
January 25, 2020 1:53 PM, "Chris Laprise" wrote: > On 1/25/20 7:15 AM, haaber wrote: > >> Hello, I have several virtual screens; I guess many user have. Is it >> possible to reserve one of them exclusively for dom0 and templateVM >> terminals -sort of a separated "admin screen"- to avoid other >> appVM-windows popping up and being able to capture input from keyboard? >> Bernhard > > KDE lets you confine windows to certain screens or virtual desktops > under System Settings / Desktop Management / Window Rules. You can > specify how it matches the window, such as pattern matching on the > window title. > > For example, if you set Window Title to 'Regular expression' and the > text to '^\[personal', then under Size/Position select 'Desktop', 'Apply > Initially' and 'Desktop 2' ... that will make windows from any VM > beginning with "personal" open only on Desktop 2. You can also use > 'Force' instead of 'Apply Initially' and that will prevent you from > moving those windows to a different desktop. > > I think the regular expression matching is probably powerful enough to > do what you want. For example, a rule for any window title NOT beginning > with '[' and NOT having also ']' would be a dom0 window. Another rule > could have the names of all your templates. 1) At least on my machine (XFCE), dom0 windows start with "[Dom0]". But I get your point. 2) The "[]" part of the window title is not actually part of the WM_NAME property. It's the WM_CLIENT_MACHINE property. But as long as you can match on that, it makes it even easier to write rules. You can see it with xprop: [user@dom0 ~]$ xprop -id 0x1614d7d | grep -i 'Dom0' WM_CLIENT_MACHINE(STRING) = "dom0" WM_ICON_NAME(STRING) = "Terminal - user@dom0:~" _NET_WM_ICON_NAME(UTF8_STRING) = "Terminal - user@dom0:~" WM_NAME(STRING) = "Terminal - user@dom0:~" _NET_WM_NAME(UTF8_STRING) = "Terminal - user@dom0:~" Interestingly, I don't actually see a property equal to the full titlebar of the window, so I guess that's constructed by the window manager. -- 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/ff15a51104bd134e89d4a4ae32a4e89f%40disroot.org.
Re: [qubes-users] Problem updating dom0
Hello Haaber, On Sat, 25 Jan 2020 at 12:51, haaber wrote: > On 1/25/20 12:28 PM, 799 wrote: > > I'm trying to upgrade dom0 but run into a SKIPPED message: > > This happens to me if I do not reboot after an upgrade and run the > upgrade command once more. Is this your case? > I have run the following commands several times in dom0: sudo qubes-dom0-update sudo dnf -y upgrade sudo dnf -y upgrade I still see the same message.when running qubes-dom0-update (sudo'd): [...] DNF will only download packages for the transaction. Downloading Packages: [SKIPPED] .rpm: Already downloaded [SKIPPED] .rpm: Already downloaded [...] Complete! The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Qubes OS Repository for Dom0 One7two99 -- 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/CAJ3yz2vO3DBT2aNdZoBw0ZmyYJmvsuN9OfBeJUjtmav4%3D1gwqA%40mail.gmail.com.
Re: [qubes-users] Can a compromised AppVM be made trustworthy by truncating its private volume?
On 1/24/20 6:07 PM, Demi M. Obenour wrote: If an AppVM is compromised, is truncating its private volume (which is documented) enough to restore it to a trustworthy state? Obviously, this loses all data on that volume, but the cases I have in mind are where a DispVM template was accidentally started itself, rather than a DispVM based on it. I'm not sure what the case is for a DispVM template. For regular AppVMs check out my Qubes-VM-hardening project at my github url below. It aims to make the initial startup state trustworthy by removing and controlling any hooks malware could use to persist on startup. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- 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/d0889b14-6249-8ff3-1608-31327c505463%40posteo.net.
Re: [qubes-users] feature request
On 1/25/20 7:15 AM, haaber wrote: Hello, I have several virtual screens; I guess many user have. Is it possible to reserve one of them exclusively for dom0 and templateVM terminals -sort of a separated "admin screen"- to avoid other appVM-windows popping up and being able to capture input from keyboard? Bernhard KDE lets you confine windows to certain screens or virtual desktops under System Settings / Desktop Management / Window Rules. You can specify how it matches the window, such as pattern matching on the window title. For example, if you set Window Title to 'Regular expression' and the text to '^\[personal', then under Size/Position select 'Desktop', 'Apply Initially' and 'Desktop 2' ... that will make windows from any VM beginning with "personal" open only on Desktop 2. You can also use 'Force' instead of 'Apply Initially' and that will prevent you from moving those windows to a different desktop. I think the regular expression matching is probably powerful enough to do what you want. For example, a rule for any window title NOT beginning with '[' and NOT having also ']' would be a dom0 window. Another rule could have the names of all your templates. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- 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/6b8a41fd-8abf-06ff-b70b-82fba2219478%40posteo.net.
Re: [qubes-users] feature request
January 25, 2020 1:40 PM, "Claudia" wrote: > January 25, 2020 11:58 AM, brendan.h...@gmail.com wrote: > >> I think some window managers allow one to pin certain applications to >> particular virtual desktops. >> But those aren’t really security features, more just window manager tricks >> to help users organize >> windows. >> >> My preference would be something along the lines of support for allowing >> multiple local x-servers >> in dom0 [or in future displayVM(s)] and options to allow mapping of dom0 and >> guests/domUs each or >> in groups to a particular x-server. Certain features would not work across >> x-windows sessions, e.g. >> inter vm copy/paste. One could also enforce it at the qubes policy level >> (e.g. no qvm-copy either). >> >> Useful if you want to reduce the chances of mistakenly leaking data across >> client work and/or >> personas. > > It seems to me like you could almost do this today, by starting another X on > another TTY each with > its own qubes_guid, optionally as different user. Each guid could probably be > patched* to listen on > different vchan "ports" (libvchan_[server|client]_init()), however I don't > think the vchan > infrastructure has any kind of real access control below the VM level. So in > order to really > isolate them on the dom0 side, you'd probably have to run a separate > xenstored for each X server, > so that you could control which server has access to the xenstore device > node. But I don't think > that would really be necessary if you're just trying to prevent accidental > leakage by the user. > > (*Currently it appears to use a hardcoded vchan "port" of 6000. See > qubes-gui-daemon/xside.c, and > qubes-gui-agent-linux/gui-agent/vmside.c. Note that gui-agent (domU) is > actually the server, and > guid (dom0) is actually the client.) > Actually, what was I thinking. If the VM is the server and dom0 guid is the client, they wouldn't have to use different ports, assuming the vchan semantics works like TCP/IP. You'd just have to come up with some way to control which domains can send MSG_CREATE requests to which instance of guid. -- 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/ef06df5178ac410b480ddae583002b04%40disroot.org.
Re: [qubes-users] feature request
January 25, 2020 11:58 AM, brendan.h...@gmail.com wrote: > I think some window managers allow one to pin certain applications to > particular virtual desktops. > But those aren’t really security features, more just window manager tricks to > help users organize > windows. > > My preference would be something along the lines of support for allowing > multiple local x-servers > in dom0 [or in future displayVM(s)] and options to allow mapping of dom0 and > guests/domUs each or > in groups to a particular x-server. Certain features would not work across > x-windows sessions, e.g. > inter vm copy/paste. One could also enforce it at the qubes policy level > (e.g. no qvm-copy either). > > Useful if you want to reduce the chances of mistakenly leaking data across > client work and/or > personas. It seems to me like you could almost do this today, by starting another X on another TTY each with its own qubes_guid, optionally as different user. Each guid could probably be patched* to listen on different vchan "ports" (libvchan_[server|client]_init()), however I don't think the vchan infrastructure has any kind of real access control below the VM level. So in order to really isolate them on the dom0 side, you'd probably have to run a separate xenstored for each X server, so that you could control which server has access to the xenstore device node. But I don't think that would really be necessary if you're just trying to prevent accidental leakage by the user. (*Currently it appears to use a hardcoded vchan "port" of 6000. See qubes-gui-daemon/xside.c, and qubes-gui-agent-linux/gui-agent/vmside.c. Note that gui-agent (domU) is actually the server, and guid (dom0) is actually the client.) Then, optionally you could implement some sort of policy to enforce which VMs are allowed to connect to which guid. Whether as a qubes-rpc policy of some sort, within guid, or just a simple X hook/script using the _NET_QUBESVM window property. https://www.qubes-os.org/doc/gui/ https://www.cs.uic.edu/~xzhang/vchan/ https://github.com/QubesOS/qubes-core-vchan-xen https://github.com/QubesOS/qubes-gui-daemon PS: I can't believe the devs are actually thinking about rolling out GUI domains by default in 4.1. It's hard enough to get Qubes running on a given machine as it is now, let alone the fact that VGA passthru is a total crapshoot even under the best conditions. I still can't even get sys-usb to work without corrupting memory space of my VGA controller and SATA controller. -- 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/30823052eccdc181ca9a0774fc3cd678%40disroot.org.
[qubes-users] Re: How does Microsoft Office in a Windows VM work ?
Sounds great. I look forward to try it myself in Qubes OS. But has to get Qubes OS working first... If running MS Office in Qubes OS also resulted in many problems, I probably would give up trying to make it work. But this makes me keep on fighting at least a little longer. -- 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/f83af70c-4914-4e34-8ad8-b6c43875b784%40googlegroups.com.
[qubes-users] feature request
I think some window managers allow one to pin certain applications to particular virtual desktops. But those aren’t really security features, more just window manager tricks to help users organize windows. My preference would be something along the lines of support for allowing multiple local x-servers in dom0 [or in future displayVM(s)] and options to allow mapping of dom0 and guests/domUs each or in groups to a particular x-server. Certain features would not work across x-windows sessions, e.g. inter vm copy/paste. One could also enforce it at the qubes policy level (e.g. no qvm-copy either). Useful if you want to reduce the chances of mistakenly leaking data across client work and/or personas. 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/fa793038-32f5-4891-bb70-3699f6ba88c8%40googlegroups.com.
Re: [qubes-users] Problem updating dom0
On 1/25/20 12:28 PM, 799 wrote: Hello, I'm trying to upgrade dom0 but run into a SKIPPED message: This happens to me if I do not reboot after an upgrade and run the upgrade command once more. Is this your case? -- 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/70af1780-183f-670a-7a29-c6edf6e4ce17%40web.de.
[qubes-users] Problem updating dom0
Hello, I'm trying to upgrade dom0 but run into a SKIPPED message: [...] DNF will only download packages for the transaction. Downloading Packages: [SKIPPED] .rpm: Already downloaded [SKIPPED] .rpm: Already downloaded [...] Complete! The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Qubes OS Repository for Dom0 Any ideas how to work arround this problem? This is the complete command & output: [user@dom0 dom0-scripts]$ sudo qubes-dom0-update Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time... Last metadata expiration check: 14:01:13 ago on Fri Jan 24 22:22:42 2020. Dependencies resolved. Package Arch Version Repository Size Reinstalling: libvirt-python3 x86_64 3.3.0-2.fc25 qubes-dom0-current 269 k python3-kickstartnoarch 1000:2.32-4.fc25 qubes-dom0-current 370 k qubes-anaconda-addon noarch 4.0.10-1.fc25 qubes-dom0-current 34 k qubes-releasenoarch 4.0-8 qubes-dom0-current 50 k qubes-release-notes noarch 4.0-8 qubes-dom0-current 8.1 k xorg-x11-drv-ati x86_64 18.0.1-1.fc25 qubes-dom0-current 168 k xorg-x11-drv-intel x86_64 2.99.917-32.20171025.fc25 qubes-dom0-current 696 k xorg-x11-drv-nouveau x86_64 1:1.0.15-4.fc25 qubes-dom0-current 99 k Transaction Summary Total size: 1.7 M Installed size: 6.7 M DNF will only download packages for the transaction. Downloading Packages: [SKIPPED] libvirt-python3-3.3.0-2.fc25.x86_64.rpm: Already downloaded [SKIPPED] python3-kickstart-2.32-4.fc25.noarch.rpm: Already downloaded [SKIPPED] qubes-anaconda-addon-4.0.10-1.fc25.noarch.rpm: Already downloaded [SKIPPED] qubes-release-4.0-8.noarch.rpm: Already downloaded [SKIPPED] qubes-release-notes-4.0-8.noarch.rpm: Already downloaded [SKIPPED] xorg-x11-drv-ati-18.0.1-1.fc25.x86_64.rpm: Already downloaded [SKIPPED] xorg-x11-drv-intel-2.99.917-32.20171025.fc25.x86_64.rpm: Already downloaded [SKIPPED] xorg-x11-drv-nouveau-1.0.15-4.fc25.x86_64.rpm: Already downloaded Complete! The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Qubes OS Repository for Dom0 - One7Two99 -- 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/CAJ3yz2us%2BCh2XXJONNtR5P3bKsmX%2B6OQ3L4hB%3DdwKYKGPwvJhQ%40mail.gmail.com.
[qubes-users] feature request
Hello, I have several virtual screens; I guess many user have. Is it possible to reserve one of them exclusively for dom0 and templateVM terminals -sort of a separated "admin screen"- to avoid other appVM-windows popping up and being able to capture input from keyboard? Bernhard -- 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/1c4a6f80-6f85-f1c1-4995-dc5f0cb0ab2b%40web.de.
[qubes-users] Re: How does Microsoft Office in a Windows VM work ?
On Saturday, January 25, 2020 at 4:14:27 AM UTC+13, M wrote: > > Now that it seems that several got Windows 10 running in a VM in Qubes OS, > I wonder what the experiences are with running Microsoft Office in that > Windows 10 VM ? > > Does it runs nicely without any problems, almost, a little bit unstable, > quite unstable or is it completely terrible ? > used for past few years - runs nicely for me without any problems. i regularly run office 2001, 2007 & whatever the latest one is and haven't had any issues. . -- 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/203d8db4-8470-4707-b6c6-3a1db0ce52c1%40googlegroups.com.
[qubes-users] Re: Installer crash: IO-APIC + timer doesn't work (Dell XPS 7390)
Le mercredi 25 décembre 2019 23:25:41 UTC+1, Aaron Janse a écrit : > > Hello all, > > I'm trying to install Qubes on a Dell XPS 7390 (the XPS 13 developer > edition). > I've found someone else with similar issues in a reddit thread [1] made a > few > days ago. I'm u/qubes-xps13. > > # Hardware > Dell XPS 13 (7390) > - Intel i7 (10th generation) > - 16GB RAM > - all the necessary virtualization features (according to Qubes docs) > - only UEFI boot; afaik there isn't a way to boot in legacy mode > > # Software Version > Qubes 4.0.2-rc3 > > # Problem > I've been unable to get to the GUI installer screen. > > # Things I've tried > > The original cause of the crash: > ``` > IO-APIC + timer doesn’t work > ``` > > Following [2], I decided to tinker with the boot options on the USB > installer > medium. > > I first tried `noapic`, got an `x2apic` error, then added `x2apic=off`. > > My options line so far looks like this: > ``` > options=console=vga efi=attr=uc noapic x2apic=off > ``` > > At this point, I got the black screen described in issue #5165 (3). > Following > the advice there, I updated my options line to the following: > ``` > options=console=vga efi=attr=uc noapic x2apic=off loglvl=all efi=no-rs > iommu=no-igfx dom0_mem=min:1024M dom0_mem=max:4096M ucode=scan > vga=current,keep guest_loglvl=all > ``` > > With the newly verbose output, it looks like I'm back to square one: > ``` > Kernel panic - not syncing: The noapic parameter is incompatible with Xen > ``` > > # Ideas I have > - try with a newer kernel version (I don't know how to go about trying > this, > and it sounds like a lot of work) > > --- > > Where should I go from here? > > Thanks! > > [1] https://www.reddit.com/r/Qubes/comments/edqrab/qubes_and_ice_lake/ > [2] > https://groups.google.com/forum/#!searchin/qubes-users/noapic%7Csort:date/qubes-users/PIyz7BEV1mg/0SBJTnoAAwAJ > [3] https://github.com/QubesOS/qubes-issues/issues/5165 > Hi, so i also have this laptop with the same specs and i ran into the exact same issue, i still couldn't find a way to make it up to the installer but i got closer to it when i disabled sleep mode in the bios. When doing that it the installer looks like it starts correctly but you just end up with a blank screen and no sign of life. I guess the issue is around battery and power management that has been put in place by dell. I am so disappointed because on paper this laptop looked ready to handle qubes (no nvidia and fairly good specs). Putting different kernel parameter didn't seem to influence anything, i tried any combination of acpi=off, noapic and nolapic but without any success. So for now i have to get back to Parrot-OS but i am really missing Qubes, if anyone can find a way, please share it, i will obviously do the same. -- 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/4626c38f-6bf2-434f-82e4-7dff360f2fe1%40googlegroups.com.
[qubes-users] Re: NVIDIA RTX 20XX
On Saturday, January 25, 2020 at 12:56:57 AM UTC+13, Frédéric Pierret wrote: > > Hi, > > Does anyone succeeded to have a working/non-crashing system with a > nvidia RTX 20XX, > i'm running on an rtx 2070 on kernel-latest with no issues. previously also put in an old ATI card to get things working but when i moved to kernel-latest a month or so back to get something else working, foudn out that the 2070 was working under it too. -- 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/913ddb9a-e281-4bb3-a9a2-3d7bf772bf06%40googlegroups.com.
[qubes-users] Re: Installer crash: IO-APIC + timer doesn't work (Dell XPS 7390)
Le mercredi 25 décembre 2019 23:25:41 UTC+1, Aaron Janse a écrit : > > Hello all, > > I'm trying to install Qubes on a Dell XPS 7390 (the XPS 13 developer > edition). > I've found someone else with similar issues in a reddit thread [1] made a > few > days ago. I'm u/qubes-xps13. > > # Hardware > Dell XPS 13 (7390) > - Intel i7 (10th generation) > - 16GB RAM > - all the necessary virtualization features (according to Qubes docs) > - only UEFI boot; afaik there isn't a way to boot in legacy mode > > # Software Version > Qubes 4.0.2-rc3 > > # Problem > I've been unable to get to the GUI installer screen. > > # Things I've tried > > The original cause of the crash: > ``` > IO-APIC + timer doesn’t work > ``` > > Following [2], I decided to tinker with the boot options on the USB > installer > medium. > > I first tried `noapic`, got an `x2apic` error, then added `x2apic=off`. > > My options line so far looks like this: > ``` > options=console=vga efi=attr=uc noapic x2apic=off > ``` > > At this point, I got the black screen described in issue #5165 (3). > Following > the advice there, I updated my options line to the following: > ``` > options=console=vga efi=attr=uc noapic x2apic=off loglvl=all efi=no-rs > iommu=no-igfx dom0_mem=min:1024M dom0_mem=max:4096M ucode=scan > vga=current,keep guest_loglvl=all > ``` > > With the newly verbose output, it looks like I'm back to square one: > ``` > Kernel panic - not syncing: The noapic parameter is incompatible with Xen > ``` > > # Ideas I have > - try with a newer kernel version (I don't know how to go about trying > this, > and it sounds like a lot of work) > > --- > > Where should I go from here? > > Thanks! > > [1] https://www.reddit.com/r/Qubes/comments/edqrab/qubes_and_ice_lake/ > [2] > https://groups.google.com/forum/#!searchin/qubes-users/noapic%7Csort:date/qubes-users/PIyz7BEV1mg/0SBJTnoAAwAJ > [3] https://github.com/QubesOS/qubes-issues/issues/5165 > So do you guys think this could be working on the future ? I have the same laptop and i am really disappointed by this. -- 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/986d812b-0dd6-4cd1-b50e-c81e3053de43%40googlegroups.com.
