[qubes-users] connecting to an app on an appvm from lan
How does one go about connecting to an appvm from another device on your LAN? Is there any documentation on this? Just to avoid confusion a device on the same network as where sys-net gets it's network from. -- 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/4c2b5156-ccf3-803b-bbda-d28660cf5e6c%40ak47.co.za.
Re: [qubes-users] Update templates in parallel
On 8/3/20 1:05 PM, Chris Laprise wrote: On 8/3/20 4:11 AM, fiftyfourthparal...@gmail.com wrote: Your Qubes-VM-Hardening tool was one of the first things installed into my first Qubes, but I'm still not very familiar with how it works. I think vm-boot-protect might be blocking me from adding a .desktop file into ~/.config/autostart, as Steve suggested (Steve: does this need to be done in templates? If done in an appVM, wouldn't it get purged upon restart?). BTW, I think the appVM is the right place to make the .config/autostart change if the custom .desktop file is being applied on a per-VM basis. If you want it for _all_ VMs based on that template, that's a little harder. Putting the .desktop file in /etc/skel would only make the change when an appVM is first created, so existing VMs using that template would not benefit. However, vm-boot-protect-root has the ability to copy or "deploy" files into /home on each boot; you would have to save the .desktop file under /etc/default/vms/vms.all/rw/home/user/.config/autostart in the template. Chris, do I understand you correct. The /etc/default/vms/vms.all/rw/home/user/.config/autostart directory (structure) needs to be created? My debian-10 templateVM only has /etc/default/grub.d, there are no other directories. Another idea is to use rc.local to launch the app via 'systemd-run' using its "timer" features or some other way to delay execution. Or you could even try adding the .desktop file to /home using rc.local. -- 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/ae407b54-b5bd-e91c-8d6e-1be0a511226a%40ak47.co.za.
Re: [qubes-users] Re: sys-usb issues recognizing devices & maintaining drive connections
'Антон Чехов' via qubes-users: > I don't need the Personalization Tool very often. On the contrary, once the > slots are configured they usually stay that way for a long time. > > My conclusion for now is, that I can live with this message. Or is this not > the expected behavior? What do you think about it? > It may be connected with some policy file for the Yubikey but I don't know > and didn't have the time to seriously investigate these policy files & > documentation. I've been meaning to try out a Yubikey or equivalent, but haven't gotten there yet. Hopefully someone else has more thoughts on it. > I am thinking about setting up 'sys-usb' as a disposable VM along the lines > of the following documentation. > https://www.qubes-os.org/doc/disposablevm-customization/ > Have you or others tried that out and is this documentation up to date? > Yes, it worked when I tried it. Don't think much has changed in that regard since, so it should still work. -- - don't top post Mailing list etiquette: - trim quoted reply to only relevant portions - when possible, copy and paste text instead of screenshots -- 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/fa313650-8621-8b3c-b7c1-5b7fd8055a46%40danwin1210.me.
Re: [qubes-users] Problem with VMs not launching
BGW: > I have a personal debian app vm that starts automatically with qubes. I > can't launch anything within the vm. If I stop the vm it will then restart > automatically without being told to do so. But I still can't launch > anything in the vm (browser, files etc). Temporarily disable autostarting this appvm in case there's some type of race condition, then reboot and retest. > Other vms which do not start automatically, when manually started do not > work. And, like above, if I stop the vms once I have started them they will > will restart themselves by themselves. Are the sys-* ones working correctly? -- - don't top post Mailing list etiquette: - trim quoted reply to only relevant portions - when possible, copy and paste text instead of screenshots -- 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/8add2e14-f29b-517b-87d3-6bfe4cf77e60%40danwin1210.me.
[qubes-users] mouse wheel / button configuration
How do we configure mouse wheel and button behavior on Debian? I have found one for Debian imwheel, perhaps that's what people are already using on their Debian systems? I am busy ditching Fedora for Debian, but I wouldn't mind knowing how we would do it on Fedora as well if someone knows just so that I can document it. -- 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/a1617d41-2037-a7c1-0365-0433a6b990fc%40ak47.co.za.
Re: [qubes-users] Why Fedora?
Great discussion, In many industries a vendor analysis is conducted on a multitude of parameters to indentify the best vendor. As many from outside the Qubes world have gravitated to Qubes for those reasons. >From what I am reading, we need all hands on deck and a war chest. >Ideologically, you are doing what most IT enterprises whish they could do. >From a user stand point, updates are a risk if you can't roll them back. There was a mention of a 3rd party vendors that provides installation bridges and how they need to be trusted. Currently, I am trying to figure out how to install and application directly from the vendor in order to limit the possible number of attackers. Is this above my proficiency level? Very likely, but the alternative is to have a 3rd party decide what/when/where to update a scrip or what to copy, delete, and modify my data. Let me give you another example: did you know that SIM cloning and credit card scams can occur because of insider access? Will paranoia become the new normal? Or can we make good assumptions or decissions based on past experiences? Let's keep moving forward, -- 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/4772a5c3-72a1-4ca3-8386-29ab7d280bc6o%40googlegroups.com.
[qubes-users] Suggestions as a user
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello guys, I would like to suggest a few changes and while you may not have them in qubes by default, I ask you to give an option to the users such that they be able to make it easily. With GUI VM coming in 4.1, I request you to have linux-libre in dom0. Linux-libre for every template by default would be even better and certainly my choice. (atleast Freedora instead of Fedora). KDE instead of XFCE would be a better default option since it provides a better UI. It provides a premium feel and is a level above XFCE. Shifting focus to GNU recommended OSes like Hyperbola, Parabola, Guix is also a step ahead in my view. I state this because GNU has also had an aim to make a completely free software to be used on a computer. While they approach with security by correctness and by actively trying to demotivate nonfree software, I feel they might not get to the end. Also, they don't make it difficult for the user to install a problematic software by mistake like Qubes does. If Qubes combines such OSes (especially recommend Hyperbola, they are highly critical of any contaminating packages) with it own security by compartmentalization, it will be a step ahead. Thanking you Sagar Acharya P.S. I dream of having a stateless computer (Joanna 2015) with libreboot+Qubes having HyperbolaBSD in dom0 and Parabola, Guix and Hyperbola as available template VMs, with plasma as a DE. That would be ideal and a nightmare for malicious crackers. -BEGIN PGP SIGNATURE- iQGzBAEBCAAdFiEEeMyXyyr6L/PtWnZUnZv6jjOfaEIFAl8z+voACgkQnZv6jjOf aEJqFwv9Eb8RioP2sHOp91g2AtNxCRXcs88HvrJYwCBJWPuQBqAax+yWIcgB24F0 bmYsHewPWPYzguOVZ565C1ma1PbmAjUi0UYriv4ddstEbWpKnX6I2VtfsTeCpP9s j3NtDBXtbQXEAY+10soubiNm/CjLNNaCYidgkubnOXaXHAIgUukIchINA/Zxp/dz aw8VNapGzoayCFDATiz8rJXYCI4eGe3mRngjAcsXVNwPoxPVnUlMlGAf8RzRUXle /dsczJvk6jgyQoYETWgntfqG+er0dZm6D3whN4rVxqtqxO+9SR1rwi5Fi5Ly4AS3 yEeWo7fum7x6stJnp1N5CnQENN0heqev2qEcsvMniq1MRuGnKit4AmP8H2mVSwtm Oor2W6vZCivMB4dPkoeSBZ+zjjkPQwb5x3ljBoa3465BGeXnAGxblfW3RFM50Ml7 yQsxN3G1FsrGOcwz5GpdSzDCm7sMF/0P77VYBqtTgBEkSvOI/gWLEIeIHWzi7oAT enJPiihw =61lG -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/2ff65e29-d9f1-46a7-92cc-21a7410f25e0o%40googlegroups.com.
Re: [qubes-users] Re: socks5 redirect all connected appvm traffic to socks5 port in vpnVM
On 2020-08-12 14:55, Eva Star wrote: > sudo iptables -t nat -A PREROUTING -p tcp -j REDIRECT --to-ports 1080 > > this rule not work :-( > Maybe your proxy should be running in some kind of transparent mode. Have you tested before with an iptables redirect? -- 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/95c9fd13-1df3-d22e-a138-473cc932d37a%40riseup.net.
[qubes-users] Re: socks5 redirect all connected appvm traffic to socks5 port in vpnVM
sudo iptables -t nat -A PREROUTING -p tcp -j REDIRECT --to-ports 1080 this rule not work :-( -- 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/4c7c8851-f56b-4862-b8f2-903d2b6a422do%40googlegroups.com.
Re: [qubes-users] Why Fedora?
Sven Semmler: > On 8/10/20 11:05 AM, Toptin wrote: >> I'm currently digging my way through the exceptional good Qubes >> documentation. Everything is nicely explained as to why a certain >> decision / implementation was made, except for the use of Fedora as >> main distribution. > > This issue is a good starting point to understand what would be needed > to move away from Fedora (to e.g. Debian): > https://github.com/QubesOS/qubes-issues/issues/1919 Thanks Sven. That's what I was looking for. > > ... if you skip to the end you'll see the project lead commenting: > "That isn't decided yet, but at the point when we'll be minimizing > dom0, more likely option would be something capable of building light > system images, for example Yocto." > > This refers to an ongoing effort to move the GUI and other functions > out of dom0 and into a dedicated GUI qube among other things. > https://www.qubes-os.org/news/2020/03/18/gui-domain/ > https://github.com/QubesOS/qubes-issues/issues/4186 > >> I wonder what's the rationale of that decision; Fedora 25 isn't >> even supported anymore. No offense or critic intended, just >> curiosity. > > R4.1 will probably be based on Fedora 32 > https://github.com/QubesOS/qubes-issues/issues/5763 > > /Sven > > -- 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/c8e93169-1381-4e94-3e90-e2b88ebece3b%40riseup.net.
Re: [qubes-users] Why Fedora?
Mike Keehan: > On 8/11/20 7:21 PM, Mike Keehan wrote: >> On 8/11/20 7:13 PM, Toptin wrote: >>> Mike Keehan: On 8/11/20 6:08 PM, Toptin wrote: > Toptin: >> Dear Qubes Users, >> >> I'm currently digging my way through the exceptional good Qubes >> documentation. Everything is nicely explained as to why a certain >> decision / implementation was made, except for the use of Fedora >> as main >> distribution. >> >> I wonder what's the rationale of that decision; Fedora 25 isn't even >> supported anymore. No offense or critic intended, just curiosity. >> >> Regards, toptin. >> > > I still look for the rationale; what was/is the technical necessity to > use Fedora. I do not look for ideologies, because I don't have one in > regard to an OS. I choose an OS based on the objective I have in mind. > This subject has been discussed many times on this list, plus there are documented reasons for this on the website. You will have to search for them, I can't remember the urls. >>> >>> I actually did search the webpage and even read the architectural design >>> paper and the website, but I couldn't find anything in regard technical >>> necessity. >>> >>> What I found was this: >>> >>> " >>> But why trust Fedora? >>> >>> Because we chose to use Fedora as a vendor for the Qubes OS foundation >>> (e.g. for Dom0 packages and for AppVM packages). We also chose to trust >>> several other vendors, such as Xen.org, kernel.org, and a few others >>> whose software we use in Dom0. We had to trust somebody as we are unable >>> to write all the software from scratch ourselves. But there is a big >>> difference in trusting all Fedora packages to be non-malicious (in terms >>> of installation scripts) vs. trusting all those packages are non-buggy >>> and non-exploitable. We certainly do not assume the latter. >>> " >>> Taken from https://www.qubes-os.org/doc/templates/ today. >>> >>> So, if that's all than it wasn't a technical decision just a choice, >>> probably just because the developer was used to it: see 3rd reply by >>> Jeff Kayser. >>> Mike >>> >> The reasons why the developers believe an old Fedora release is >> safe in dom0 has been explained before. I think it was Marek >> who replied to an email question. It made perfect sense at the >> time, but I couldn't quote it after all this time. >> >> Mike. >> > > A bit of searching found this - > > https://www.qubes-os.org/doc/supported-versions/#note-on-dom0-and-eol > Thanks, must have overlooked it. So, so far I gather the rationale to use Fedora is less a technical but more a trust (signed packages) rationale and with which distribution the developers were comfortable. -- 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/1ecb3b49-50fa-c15f-e874-07013f29d1dc%40riseup.net.
Re: [qubes-users] Re: sys-usb issues recognizing devices & maintaining drive connections
On Sunday, August 9, 2020 at 10:07:25 PM UTC+2 awokd wrote: > 'Антон Чехов' via qubes-users: > > > I have a handful ob Yubikeys (v.2 to v.4) and I really want to make use > of > > them with Qubes as well. So the next thing will be U2Fproxy and > > YubikeyLogin. > > There is some weird (?) behavior when attaching a Yubikey and the > > Personalization Tool in sys-usb is open. The key is recognized but I get > a > > never-ending loop of warnings: "Denied: qubes.InputKeyboard > > Denied qubes.InputKeyboard from sys-usb to dom0" > > > > I think that this is the right behavior but as long as I switch to the > > Personalization Tool these warnings never stop. Elsewhere I get this > > warning just the one time when I plug the key in. > > From > https://www.qubes-os.org/doc/usb-qubes/#enable-a-usb-keyboard-for-login > under Manual setup, I wonder if you can edit > /etc/qubes-rpc/policy/qubes.InputKeyboard to something like sys-usb > sys-usb ask,default_target=sys-usb. Should be more documentation on that > file somewhere out there. > > -- > - don't top post > Mailing list etiquette: > - trim quoted reply to only relevant portions > - when possible, copy and paste text instead of screenshots > Sorry for the late response. I tried that but the warning remained. Thinking a while about it I am of the opinion that it wasn't bad seeing this message. It only shows up once when plugging in a Yubikey (or I guess any device that is recognized as a keyboard) together with the message that a Yubikey is available. I don't need the Personalization Tool very often. On the contrary, once the slots are configured they usually stay that way for a long time. My conclusion for now is, that I can live with this message. Or is this not the expected behavior? What do you think about it? It may be connected with some policy file for the Yubikey but I don't know and didn't have the time to seriously investigate these policy files & documentation. I am thinking about setting up 'sys-usb' as a disposable VM along the lines of the following documentation. https://www.qubes-os.org/doc/disposablevm-customization/ Have you or others tried that out and is this documentation up to date? -- 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/a495d0a9-9845-48f0-946c-f40b3f538762n%40googlegroups.com.
[qubes-users] socks5 redirect all connected appvm traffic to socks5 port in vpnVM
Hello, How to redirect all traffic to specific socks5 port in vpnVM (not system-wide, but from connected AppVMs) ? I want to create vpnVM. It is not using openvpn as client, but other specific software with opened socks5 port. I want to redirect all incoming connections from connected appvsm to this socket port. I'm not sure, but maybe it will request to setup redsocks to work, but let's assume that I already have redsocks running with opened 1080 port and I want to redirect all traffic from connected appVMs to this vpnVM to port 1080! How to do this right? 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f9d99137-ce21-4ccd-841f-0edce6bdd14eo%40googlegroups.com.
