[qubes-users] Could use some help with my iptables configuration
Hello, I want to achieve the following: sys-net should only be accessible by sys-firewall and sys-firewall should only be accessible by sys-whonix. No AppVM should be able to connect to the internet if I set sys-net or sys-firewall as NetVM. Internet access should only be possible via sys-whonix. What I tried so far is: I flushed the INPUT chain on sys-net and applied these 2 commands sudo iptables -I INPUT -i vif5.0 -s 10.137.0.6 -j ACCEPT (10.137.0.6) is the IP of sys-firewall sudo iptables -I INPUT -i vif5.0 -j DROP This configuration already kind of works. If I create a new AppVM and connect it to sys-net then I can not even ping sys-net anymore. But then I noticed that another vif interface on sys-net came up as soon as I connected the new AppVM. This is confusing me as I'm afraid that that could lead to potential leaks in the future. I am unsure how I should proceed with the configuration of this setup. I don't know much about networking and especially because it is on Qubes it's a bit more difficult to be sure of how things work. I presume that I probably should make a specific NAT rule but I really have no clue. What I also don't understand is: - Are the IPs that are assigned to the VMs static or do they change over time? If they change, can I make them static? - Will the flushing of a chain in a fresh VM interfere with the functionality of the VM? I saw QBS-Forwarding rules and so on. I guess it's not a good idea to delete those. -- 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/d744e58ff78ad2d9232b97dcdaa36c3a%40firemail.cc.
Re: [qubes-users] Could use some help with my iptables configuration
On 11/23/19 9:33 AM, swisspal...@firemail.cc wrote: Hello, I want to achieve the following: sys-net should only be accessible by sys-firewall and sys-firewall should only be accessible by sys-whonix. No AppVM should be able to connect to the internet if I set sys-net or sys-firewall as NetVM. Internet access should only be possible via sys-whonix. What I tried so far is: I flushed the INPUT chain on sys-net and applied these 2 commands sudo iptables -I INPUT -i vif5.0 -s 10.137.0.6 -j ACCEPT (10.137.0.6) is the IP of sys-firewall sudo iptables -I INPUT -i vif5.0 -j DROP This configuration already kind of works. If I create a new AppVM and connect it to sys-net then I can not even ping sys-net anymore. But then I noticed that another vif interface on sys-net came up as soon as I connected the new AppVM. This is confusing me as I'm afraid that that could lead to potential leaks in the future. I am unsure how I should proceed with the configuration of this setup. I don't know much about networking and especially because it is on Qubes it's a bit more difficult to be sure of how things work. I presume that I probably should make a specific NAT rule but I really have no clue. What I also don't understand is: - Are the IPs that are assigned to the VMs static or do they change over time? If they change, can I make them static? IIRC they're dynamic. - Will the flushing of a chain in a fresh VM interfere with the functionality of the VM? I saw QBS-Forwarding rules and so on. I guess it's not a good idea to delete those. QBS-Forwarding will stomp over what you try to add there. Its managed by Qubes. However, it exists in order to allow FORWARD to be user-managed. One way to do it might be to allow only one downstream vif in sys-firewall: Add a general eth0 block on top of the FORWARD chain. Then, have a script that waits for the first vif to appear; when it does, add FORWARD rule to allow it, then exit the script. -- 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/767b2063-be96-3883-d9db-912690f059fc%40posteo.net.
Re: [qubes-users] How do I hide sys-net and sys-firewall from the list of available NetVMs?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2019-11-22 22:07, swisspal...@firemail.cc wrote: > Hi, > > I would like to hide both sys-net and sys-firewall from the list > of available NetVMs when I create a new qube or when I modify a > qube. > > The reason for this is that I sometimes create and delete many > qubes If you are using Qubes Manager you could modify 'create_new_vm.py' and 'settings.py' on '/usr/lib/python3.5/site-packages/qubesmanager' -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEznLCgPSfWTT+LPrmFBMQ2OPtCKUFAl3ZfjgACgkQFBMQ2OPt CKUirg//QJIiMmHdA3+9KvSE+YmxecDIpoIfN7fER7PuZakziFNrXeo/z1sY7YOQ wa3Rqszv0n8xOYm71PI5pbLD5q1f0NuV+YJPYKj9XPATl6Nky/qAht0g+I5/m3+f VD6/LMXxx5GpUizPYMOZtLv6AK0I+K4p+2joaOg4a8Ct9AFaJ20Lcn6/gBm9Opv6 GyGhYA2BC54TH1LbcoYje08opofK01U243Q6l+/YMiuhASKY5WZnqzjRqG6EkePx n5rqvPde7NBpi/88QYy5kkSVWyz3gVZUD4DSyrPwz2kgWIw+dAiEEOxYfMcj4vtV Bdj1PU2xfDoRtDHqTdnFzI3pP+F96Hj/cRSvjMhKgOjx6iXvzyrGa+pTa/Kr7bup G3xt7R9B+/cl1THQo8097ZDXc/N2wi+3cPO4yXD8URbi9rnGpKN9A19kEMdTpN3p cLpXft37qT/1bBRQUvS0kW4v5imBFjNbWsXk6QDtZD8Dl7fvvCIp1id1NJM5dEf6 10BtWSfdAIsa52PWc+w/t5/LbCgYAFLaj5M4FZIH+o8NWCJY/BF7la6NlOMoLRoL 23CANU4KyWE/hDCxbtiIm0bLTMNYSW0pOJlzuZupwMXW4j2DNPuFe7YUP24fIdNz pjf56JMuaYFPf8qddCl6fOFnHXg2uLfFfRs/tHiZ2AS5oDxzHrU= =Cna0 -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/0b041f15-a580-c517-8e42-72a9179f6349%40riseup.net.
[qubes-users] Keyboard Shortcuts to Start / Shutdown any AppVM
Hi, Could anyone know is it possible to use shortcuts / hot keys in Dom0? For example I want to Shutdown about 10 AppVM's which already turned on. And it would be easier if I could Stop them using Hot Keys from keyboard. -- 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/c5e42120-5ced-4fc2-9d08-e334022d7e7f%40googlegroups.com.
Re: [qubes-users] Keyboard Shortcuts to Start / Shutdown any AppVM
Am 23.11.19 um 19:52 schrieb Daniil Travnikov: > Could anyone know is it possible to use shortcuts / hot keys in Dom0? If you use xfce, you could create a custom shortcut. It should point to a script, you wrote, which toggles the vm-state. deppend on it's state it run's qvm-start or qvm-shutdown for instance. beppo. -- 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/b7204d44-63dd-2d3f-2010-4a85b7bb84e1%40posteo.de.
[qubes-users] Excessive swapping & non-optimal qmemman heuristics
Hey all, Am I the only one who seems to have noticed chrome reaching max mem & swapping way more often than used to happen in the past? Some of my workflows result in having a bunch of tabs (not even _that_ many, maybe 20-30+) open in DispVMs. Unfortunately, this reaches the 4gb max pretty quickly, and causes swapping, which results in the whole VM becoming pretty unusable (can't even interact with it enough to close tabs - often end up doing qrexec calls to pill the highest-mem chrome renderer process - essentially me being a manual OOM killer). I've also noticed some VMs getting more memory than it makes sense, for example minimal VMs that just have a text editor, some notes, and a few terminals open often end up with 1200mb+ pre-allocated when they have no reason to need that much, which results in not having enough unallocated mem to be able to start new domains unless you shutdown VMs (that have accumulated large allocations while still having a small user-meaningful working set). Qubes has always been memory-hungry, and I've always considered it a worthwhile tradeoff, but now I feel like I need to upgrade to a 32gb machine just to run a couple browsers - this is getting ridiculous. I'm going to look into this more systematically (first try tweaking the qmemman algo, then maybe experiment with tmem), but I figured I'd just rant here first in case anyone happens to have looked into this already (beyond the usual "limit dom0 & sys-* maxmem" which seems to always get parroted whenever this subject comes up). Cheers, Jean-Philippe P.S.: Here's a script to tail qmemman's logs while translating from xen domain IDs to VM names (because qmemman is purposefully simple for reliability, avoiding taking a dependency on qubesd nor making extra xc calls to get the name, so doesn't do this translation itself). Has been helpful in seeing what's going on when things aren't behaving as expected: #!/bin/sh journalctl -f -n 100 -u qubes-qmemman \ | sed -u -r 's/\.[0-9]+//g' \ | $( qvm-ls --raw-data --fields xid,name \ | grep -v '^-' \ | sed -u \ -e 's/^/-e s\/([^0-9:])/' \ -e 's/|/([^0-9])\/1/' \ -e 's/$/2\/g/' \ | xargs echo sed -u -r ) \ | sed -u -r \ -e 's/([^[p])([0-9])[0-9]{3}([^0-9]|$)/\1\2k\3/g' \ -e 's/([0-9])[0-9]{3}k/\1m/g' \ -e 's/([0-9])([0-9])[0-9]{2}m/\1.\2g/g' -- 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/CABQWM_Dwpvxgghf4F2N7cLgbCgZGW9%3Dr2fM1jeDQxQRGhkwN0w%40mail.gmail.com.
[qubes-users] Re: xkb compose confusion
On Fri, 2019-11-22 at 06:50 +0100, Ben Mulvihill wrote: > I use the "US international with dead keys" keyboard > layout as a convenient way of getting accented characters. > > The keyboard is defined in: > /usr/share/X11/xkb/symbols/us > and the dead key combinations themselve are in: > /usr/share/X11/locale/en_US.UTF-8/Compose > > I am currently customising the dead key combinations. > This can be done by copying > /usr/share/X11/locale/en_US.UTF-8/Compose to ~/.XCompose > and making modifications there. But I have noticed a > discrepancy between Fedora and Debian VMs. > > The default settings in Debian and Fedora are identical. > In particular they both contain the line: > : "ć" > This implies that if I type a single quote followed > by the "c" key I should get the character "ć" (unicode > character U0107 or hex c487). > In Debian VMs, this is indeed what happens. But in Fedora > VMs, I get "ç" (unicode character U00E7 or hex c387). > > [If by way of experiment (in Fedora), I modify another > line, setting, for example: > : "ć" > then I can get the "ć" character by typing a single quote > followed by the "v" key. > I can also modify the line to obtain > something completely different. For example: > : "Y" > does indeed give me the character "Y" when I type a > single quote followed by "c".] > > It seems as though in Fedora (but not in Debian) > there is some other mechanism which is overriding > some, but not all, of the xkb compose settings. Does > anybody know what is going on? > > Thanks in advance. To answer to own question, the guilty party was ibus. Fedora enables this input method in gtk by default for all languages, not just Chinese, Japanese and Korean as I thought. -- 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/1574579951.1865.8.camel%40gmail.com.