Re: [qubes-users] How to deal with Yubikey ?
Le samedi 3 février 2018 07:59:55 UTC+2, ThierryIT a écrit : > Le samedi 3 février 2018 07:45:16 UTC+2, ThierryIT a écrit : > > Le vendredi 2 février 2018 18:24:02 UTC+2, awokd a écrit : > > > On Fri, February 2, 2018 6:03 am, ThierryIT wrote: > > > > > > > > > > > I have installed "qubes-usb-proxy" on my StandaloneVM. > > > > -> qvm-usb l : sys-usb:4-2 Yubico_Yubikey_4_U2F+CCID > > > > > > > > > > > > -> qvm-device usb attach vm-name sys-usb:4-2 : Device attach failed: No > > > > device info received, connection failed, check backend side for details > > > > -> > > > > same things > > > > > > How did you create sys-usb? Have you installed qubes-input-proxy-sender in > > > it? > > > > I have followed the Qubes instructions for Qubes 4: > > https://www.qubes-os.org/doc/usb/ > > > > Yes, sys-usb (Debian 9 template) do have the "qubes-input-proxy-sender" > > installed. > > > > When reading the doc for Qubes 4 and when using the yellow widgets on the > > top right of the desktop, I can see that my Yubikey4 is attached to the > > right VM (eject symbol) but if using, from dom0 console "qvm-usb", I do not > > see that my key is attached to the VM ... > > > > Do I have to re-do my sys-usb with a fedora template ? > > > > Thx > > Something seems to be wrong with the widgets. > After having inserted the key, and using the widget, I can attach the key to > the VM and I am able to see the key attached to the vm because I can see the > "eject symbol" close to the vm. > > When using the dom0 console, and using "qvm-usb" I can see my key: > > sys-usb:4-1 Logitech_USB_Receiver > sys-usb:4-2 Yubico_Ybikey_4_U2F+CCID > > As you can see, I do not see any attached device ... > > The result of this command is: > > qvm-usb attach vm_name sys-usb:4.2 > qvm-usb: error: backend vm 'sys-usb' doesn't expose device '4.2' > > This start to be a problem, because I cannot fully use my laptop if this > function is not working. > > Thx anyway for your big support. > > > > And it is not possible for me to un-attached the key through this widget ... Same problem with a new sys-usb but this time done with Fedora 26 template. -- 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/66dba328-a2ad-4c0f-8996-53f50d02aa4a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] How to deal with Yubikey ?
Le samedi 3 février 2018 07:45:16 UTC+2, ThierryIT a écrit : > Le vendredi 2 février 2018 18:24:02 UTC+2, awokd a écrit : > > On Fri, February 2, 2018 6:03 am, ThierryIT wrote: > > > > > > > > I have installed "qubes-usb-proxy" on my StandaloneVM. > > > -> qvm-usb l : sys-usb:4-2 Yubico_Yubikey_4_U2F+CCID > > > > > > > > > -> qvm-device usb attach vm-name sys-usb:4-2 : Device attach failed: No > > > device info received, connection failed, check backend side for details -> > > > same things > > > > How did you create sys-usb? Have you installed qubes-input-proxy-sender in > > it? > > I have followed the Qubes instructions for Qubes 4: > https://www.qubes-os.org/doc/usb/ > > Yes, sys-usb (Debian 9 template) do have the "qubes-input-proxy-sender" > installed. > > When reading the doc for Qubes 4 and when using the yellow widgets on the top > right of the desktop, I can see that my Yubikey4 is attached to the right VM > (eject symbol) but if using, from dom0 console "qvm-usb", I do not see that > my key is attached to the VM ... > > Do I have to re-do my sys-usb with a fedora template ? > > Thx Something seems to be wrong with the widgets. After having inserted the key, and using the widget, I can attach the key to the VM and I am able to see the key attached to the vm because I can see the "eject symbol" close to the vm. When using the dom0 console, and using "qvm-usb" I can see my key: sys-usb:4-1 Logitech_USB_Receiver sys-usb:4-2 Yubico_Ybikey_4_U2F+CCID As you can see, I do not see any attached device ... The result of this command is: qvm-usb attach vm_name sys-usb:4.2 qvm-usb: error: backend vm 'sys-usb' doesn't expose device '4.2' This start to be a problem, because I cannot fully use my laptop if this function is not working. Thx anyway for your big support. And it is not possible for me to un-attached the key through this widget ... -- 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/8c016872-d5b1-494d-8ea1-b908f9f8b5e6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] How to deal with Yubikey ?
Le vendredi 2 février 2018 18:24:02 UTC+2, awokd a écrit : > On Fri, February 2, 2018 6:03 am, ThierryIT wrote: > > > > > I have installed "qubes-usb-proxy" on my StandaloneVM. > > -> qvm-usb l : sys-usb:4-2 Yubico_Yubikey_4_U2F+CCID > > > > > > -> qvm-device usb attach vm-name sys-usb:4-2 : Device attach failed: No > > device info received, connection failed, check backend side for details -> > > same things > > How did you create sys-usb? Have you installed qubes-input-proxy-sender in > it? I have followed the Qubes instructions for Qubes 4: https://www.qubes-os.org/doc/usb/ Yes, sys-usb (Debian 9 template) do have the "qubes-input-proxy-sender" installed. When reading the doc for Qubes 4 and when using the yellow widgets on the top right of the desktop, I can see that my Yubikey4 is attached to the right VM (eject symbol) but if using, from dom0 console "qvm-usb", I do not see that my key is attached to the VM ... Do I have to re-do my sys-usb with a fedora template ? Thx -- 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/2172948e-640a-43fd-88bd-37cec3da1b2a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Q4RC4
Hi I am trying to install qubes 4 on my xps 15 9560. I am getting this error where the installation stops, with error Watchdog: BUG: soft lockup - cpu stuck for 22s[xorg:1325] This goes on and on. Need help installing 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/3bef4705-333d-4340-924e-c3fa222c56c4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Ubuntu templates
On Thursday, February 1, 2018 at 12:56:29 AM UTC+1, Unman wrote: > I'm just pushing up some PRs to remove zesty and institute build support > for artful (17.10). > If you cant wait there's a ready built 3.2 template you can try at: > http://qubes.3isec.org/Templates > > unman This looks really nice unman. I do have a question though, which in the end might just be my lack of understanding. Essentially, how is the build process executed in terms of security and also reliability? I know you're one of the 13 contributors to the Qubes OS, but it'd be nice knowing if this is done securely and reliable like the official Qubes templates (like how Joanna explains the weak links in OS builds, i.e. in one of her presentations on youtube). Also how come it's not released in the secondary templates community repository? Is this due to license issues? I apologize for these questions, it's not out of lack of respect, but rather probably my lack of understanding. -- 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/5b29fb88-89f1-4dfa-a2ed-476a9a951346%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes OS 4.0-rc4 has been released!
On Saturday, February 3, 2018 at 2:06:34 AM UTC+1, John wrote: > I'm delighted the Qube Manager is back (typo? should it be Qubes Manager?). > Thanks for listening. Minor point but it doesn't always refresh > automatically. Keep up the good work! When naming it Qube Manager, the emphasis is put on specifically qube's, but not Qubes OS as a whole system. From what I've understood, while the manager is back, it won't be controlling the whole system like it was intended to do in Qubes =< 3.2, but instead just the qube's, the VM's. You can still do more or less the same as before, somewhat, but new features will not be added to it, at least not for current release. Odds are that it may quite possibly forever remain a secondary manager, at least probably until someone writes a completely new manager which goes completely in hand with the qubes-admin system and other complex changes done in Qubes 4. The current return of the Qube Manager, does not appear to have been such a major re-work, which from what I understand will take a lot of time and work to do with all the Qubes 4 improvements. In other words, it's a bit watered down version of the old manager. Also you must not forget, if the Qubes developers ever make major changes again, then re-doing a Manager all over again, seems a bit much considering how busy they are now and the little resources that are available. It might not make sense to make a new manager, at least until Qubes has stopped rapid development. From what I can see, Qubes 4.0 is just the beginning, it looks like the Qubes team is only getting started. Qubes may change and improve even further in upciming releases. Who knows though, this is just me sensing where its going, I may be entirely wrong. But tbh, while I too prefer GUI most of the time since it's generally faster, I did grow quite accustomed to not having the Qube Manager before RC-4 (starting to use Qubes 4 at RC-2). I realized I don't even open the Qube Manager now that I got it back, I simply don't need it anymore, with perhaps the exception to minitor the CPU/RAM, but I got other tools for that, like "xentop" for VM's and "top" for dom0, amongo ther tools. But I'm happy with the gesture of bringing it back, and also perhaps not everyone can get used to not having the manager, so it's still a nice change for that reason since eveyone are different and have different needs. I very much respect the Qubes developers for this gesture, even if I won't personally be using 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 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/b2726e0c-7bbb-4f30-959e-ead0869713e2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes OS 4.0-rc4 has been released!
I'm delighted the Qube Manager is back (typo? should it be Qubes Manager?). Thanks for listening. Minor point but it doesn't always refresh automatically. Keep up the good 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 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/bbcd73ae-8cc9-48c9-bb5e-ef90fca76449%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Ubuntu templates
On Wed, Jan 31, 2018 at 05:44:36PM -0800, mikihonz...@gmail.com wrote: > On Wednesday, January 31, 2018 at 11:56:29 PM UTC, Unman wrote: > > I'm just pushing up some PRs to remove zesty and institute build support > > for artful (17.10). > > If you cant wait there's a ready built 3.2 template you can try at: > > http://qubes.3isec.org/Templates > > > > unman > > What about Q4, are there downloads ready or does the build process work (and > which versions)? > Regards > Xenial build works as is - I've pushed up a prebuilt template if you want to try it. Look on http://qubes.3isec.org/ Artful for 4.0 is on its way, though there are some packaging issues to resolve. unman -- 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/20180203010433.nynkvcudoz6erfuq%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: I think I've mounted my iny internal hard drive exactly wrong...
On Tuesday, January 30, 2018 at 4:19:27 PM UTC+1, bill...@gmail.com wrote: > Thanks for you help --- again. Your widget discussion is what did it. In > KDE, I didn't see the widget for adding disks to VMs, but it's there in the > XCFe desktop. So instead of using the widget in KDE, I did everything by > hand from the command line. Since the SATA disk partitions (sda1-sda8) were > in /dev in dom0, I could manually mount them (even though I get I'm not > supposed to -- I'm playing with it, after all). However, those devices simply > were not visible in the other VMs. > > But... when I logged in using the default desktop, there is was. And all of > the SATA drives are available, and it works fine. > > So, I gotta figure out a) how to find and get the widget showing in KDE, > and/or what the qvm-whatever command is for doing this, because it's clearly > there and it clearly works, and there's no bug. > > Thanks for the pointer! > > billo Glad you got closer :) apologies for late reply too. I'm not sure about KDE, unfortunately I've only been using XFCE my self. Perhaps the --persistent flag can provide a solution here? I've only recently started using this my self, so I haven't discovered any quirks with the persistent flags yet, but so far it seems nice. What I'm pondering about is whether it will work problem-free by having persistent on multiple AppVM's, and when closing one, and starting the other, automatically switches the device to this new AppVM. The limit being the inability to having both AppVM's open simultaneously. If the hardware does require the PCI reset to swtich between VM's though, then there is a need for an extra flag. I believe I remember seeing a recent released guide for it somewhere in the official Qubes community, I haven't had a chance to go look for it again though. But it's something along the lines of --persistent, just with the something along the lines of allow-if-no-reset, or so abouts. -- 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/4d45a023-eb66-42c7-a8f9-8e8661b8ea98%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] HCL - Dell XPS 15 9560
Legacy boot needed Kernel parm modprobe.blacklist=nouveau -- 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/e487a6e1-f599-425f-88f7-1fd3d67d8ade%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. Qubes-HCL-Dell_Inc_-XPS_15_9560-20180202-173910.yml Description: Binary data
Re: [qubes-users] Re: Is a legacy BIOS preferable to UEFI for a secure system?
Yes it is, I despise the OEM's forcing UEFI on us. Although both are insecure vs a libre BIOS such as select coreboot boards (ex: KCMA-D8/KGPE-D16) and the OpenPOWER TALOS 2 (only $2.5K now for board/cpu - which is less than x86_64 server hardware with equiv performance) I highly suggest getting one ASAP, especially as the D8 and D16 are the last best owner controlled x86_64 boards and they will stop being available soon (the libre firmware has more features than the closed source firmware, there is also OpenBMC which is so much better than the exploit filled OEM BMC firmware) and are capable of playing modern games in a VM via IOMMU-GFX. Building and flashing firmware is very easy on these boards. -- 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/2e1a1d39-499a-f0b2-c3e9-2a0908567363%40gmx.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Windows Tools
On 2018-02-02 06:37, awokd wrote: > On Fri, February 2, 2018 9:24 am, yreb...@riseup.net wrote: >> so, I created an win7 HVM ; and I think installed windows tools, but when >> I read through the qubes docs, the instructions seem to be >> circular. > >> I guess the benefit of the AppVM over the HVM is Qubes integration for >> copy and paste and anything else practical? > > Qubes integration for copy/paste is one of the features provided by Qubes > Windows Tools. Others are described on > https://www.qubes-os.org/doc/windows-tools-3/. If you aren't sure what > you'd use templates for, just go with an HVM. QWT installed properly in > your Win7 HVM will allow secure copy/paste etc. Problem is: 1) I can't really tell if QWT is or is not installed. From the HVM I wasn't able to copy out to another AppVM but Frankly: I don't really follow the protocol To install the QWT, I have it from the --repos in dom0 but then I am supposed to once flag it to install while starting the HVM ? or as the docs say "it may take multiple attempts" , and the way I'm going to know besides trial copying out would be , look at the Win Registry or ? 2) I can't follow how one creates an AppVM from the HVM at all ? I do see an option in the VMManager to create something called HVM Templates, perhaps that fits the bill or is the paradigm for TemplateVM/AppVM somehow different in this win7 scenario ? -- 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/e211bba9d2d6da78b27fe15fe7e4e137%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Is a legacy BIOS preferable to UEFI for a secure system?
On Thursday, February 1, 2018 at 6:18:14 PM UTC+1, vel...@tutamail.com wrote: > Is legacy BIOs still preferred and likely compatible with 4.0 when final? You're seeing it backwards, flipping it around and you might see where the problem is. Instead ask, is UEFI reliable/secure now? In short, no, and probably not for a long time unless some big changes arrive in the mainstream market, which is unlikely to happen any time soon. As I understand it, the LegacyBIOS is so slowly updated, or not updated at all, that Xen/Kernel updates can keep up to speed with it and fix issues not fixed in the LegacyBIOS. But UEFI is another story altogether, not to forget a highly fragmented distribution of different releases, which is impaired in many ways (briefly mentioned further below). This is why UEFI under current schemes, will never catch up to high quality the way it works now, and it will never become anything "reliable" that you might want. In other words, it requires a shift in politics, business ethics, laws, or even the appearance of a strong competitor which provides open and high quality motherboard firmware which becomes distributed mainstream. And none of that is happening, hence we're locked in with poor UEFI updates. Every motherboard provider update their own motherboards, and they are all tailored for each model of motherboard released. In a sense, this is similar to how updates are distributed on Android, or upstream/downstream Linux updates, it can be a major issue, especially if not enough attention is put to it. The problem with motherboard companies though, is that they rarely do much effort to maintain their firmware, especially on the cheap motherboards, but not exclusively so. Some cheap boards can be decent too, but it's like a needle in a haystack without someone buying it and reviewing the motherboard for you first, or just trying your luck... Some motherboards will never even get properly updated, they'll just ignore the customers who bought it. And this issue won't go away, because there are little better competition to be found when all of them are doing the same careless act. Just look at the printer or router industry, they all are ignoring costs required to keep it up to date, reliable and secure. Thereby increasing their profits by reducing costs, trying to hide the fact from customers that they are doing so. If enoguh customers were aware and was annoyed by it, then a new better business taking customers needs into consideration may easier appear, but that hasn't happened yet. Not to forget, there are big muscles on the market, it isn't so easy for a new company to emerge without some serious funding. These existing companies do not want to make something needlessly more expensive to increase the quality, just to satisfy a customer, who has little or no better alternative on the market anyway. You're locked in, you can't pick much better, at least not at that price or if you go look for reviews. And even then, expensive doesn't mean it'll be good either. Combine this corruption of businessses with the security implication Marek explanation up above, and you'll quickly see why this is going nowhere anytime soon. UEFI is no quality, and is very slowly updated and maintained. Quite a few motherbord companies even discourage you to update the motherboard unless something is explicitely broken and an update may fix it. In other words, they're saying: "if it works, don't update". This is just absurd... and it isn't ard to make a double BIOS/UEFI motherboard to secure it against failed updates either. They are just trying to maximize profits, ignoring customer needs, and they're especially happy the less people know about this business model they're using, because then it's easier to maintain buggy hardware/software at little cost, and keep the profits coming in. But there is a big problem with that in terms of quality and customer needs, since this way you don't get the few security or other updates you may want. You could get other motherboard firmware's though, like https://www.coreboot.org/ https://libreboot.org/ and https://www.reddit.com/r/opensource/comments/4lu2l0/open_source_bios/ Some people here are pretty good with alternative motherboard firmware's, maybe you're lucky that some will post here to get some more detailed answers on how to go about it if you want to go down that road. If no one posts here, then try search old posts here in the qubes mail threads, or make a new thread asking if they do not answer your questions. -- 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/c740ed95-070d-4e
[qubes-users] Re: Qubes OS 4.0-rc4 has been released!
Great, thank you so much. Can you please update https://www.qubes-os.org/doc/releases/4.0/schedule/ Thanks again -- 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/1d403e22-bf5f-4c13-91e1-47438b7a4994%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Windows Tools
Il 02/02/2018 19.20, Matteo ha scritto: > >>> I guess the benefit of the AppVM over the HVM is Qubes integration for >>> copy and paste and anything else practical? > > If you make an AppVM instead of a template (or standalone) only > C:\Users\* will be preserved across reboot. > This is useful to keep the system clean from virus. > > C:\Users will become a symlink to the qubes private image disk (when you > install windows tools) > AND!!! was forgetting the most important thing!!! if you make a win7 AppVM based on a win7 Template, you can have the template connected to the internet to download windows updates and software updates, but the template has NO personal data inside! while the AppVM can be set WITHOUT a netvm so without internet access and will be full of your personal data (photos, documents, ...) this will be even more secure. (sorry for double mail) -- 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/53363c19-0061-c564-d699-2a804f419dcc%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Windows Tools
>> I guess the benefit of the AppVM over the HVM is Qubes integration for >> copy and paste and anything else practical? If you make an AppVM instead of a template (or standalone) only C:\Users\* will be preserved across reboot. This is useful to keep the system clean from virus. C:\Users will become a symlink to the qubes private image disk (when you install windows tools) -- 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/a79d839e-e756-5042-feb9-fe9351c576fb%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] How to deal with Yubikey ?
On Friday, 2 February 2018 01:03:14 UTC-5, ThierryIT wrote: > Le jeudi 1 février 2018 18:01:21 UTC+2, awokd a écrit : > > On Thu, February 1, 2018 3:46 pm, ThierryIT wrote: > > > What am I doing wrong ? > > > > > > > > > I have a Yubikey4 U2F + CCID. > > > Not detected with "qvm-block" > > > Detected as sys-usb:4-2 by dom0 (qvm-usb). > > > > > > > > > I have tried: > > > > > > > > > - qvm-device usb attach vm_name sys-usb:4-2 (device attached failed) > > > - qvm-device block attach vm_name sys-usb:4-2 (backend vm 'sys-usb' > > > doesn't expose device 4-2) > > > > Another poster said these aren't block devices, so don't try to use those > > commands on it. > > > > "qvm-device usb attach vm_name sys-usb:4-2" should work. What does > > "qvm-usb attach vm_name sys-usb:4-2" do? > > > > If it's the same error, did you install qubes-usb-proxy in your templates? > > See https://www.qubes-os.org/doc/usb/. > > I have installed "qubes-usb-proxy" on my StandaloneVM. > -> qvm-usb l : sys-usb:4-2 Yubico_Yubikey_4_U2F+CCID > > -> qvm-device usb attach vm-name sys-usb:4-2 : Device attach failed: No > device info received, connection failed, check backend side for details > -> same things You are using qvm-usb command to list... but are using "qvm-device" to attach? I don't think that is a valid command in Qubes 3.2. Do you mean qvm-pci? You should be using qvm-usb to both list, and attach/detach usb devices. Run qvm-usb -h... follow the manual. usage: qvm-usb -a [options] : -- 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/2392b43e-4964-4322-944c-9ff6771098b3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Windows Tools
On Fri, February 2, 2018 9:24 am, yreb...@riseup.net wrote: > so, I created an win7 HVM ; and I think installed windows tools, but when > I read through the qubes docs, the instructions seem to be > circular. > I guess the benefit of the AppVM over the HVM is Qubes integration for > copy and paste and anything else practical? Qubes integration for copy/paste is one of the features provided by Qubes Windows Tools. Others are described on https://www.qubes-os.org/doc/windows-tools-3/. If you aren't sure what you'd use templates for, just go with an HVM. QWT installed properly in your Win7 HVM will allow secure copy/paste etc. -- 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/c7b143f8c2f3cabfdea732684ab0afba.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] reboot sys-net
I remember some issues with reattaching in the past, but recently, the qvm-shutdown --wait --force sys-net && qvm-start sys-net seems to be working. It can fail in some cases like when you have a paused VM (a feature that seems to cause various issues in 3.2) and it does nto work id the sys-net is shut dows from the VM itself. You can do the same for both sys-net and sys-firewall at once. The qvm-shutdown command accepts multiple VM names. For qvm-start, you can just request start of sys-firewall, because the sys-net VM is started automatically in such case. Regards, Vít Šesták 'v6ak' -- 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/ef9188b0-4402-45c8-85f6-1527a7e8b972%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] How to deal with Yubikey ?
On Fri, February 2, 2018 6:03 am, ThierryIT wrote: > > I have installed "qubes-usb-proxy" on my StandaloneVM. > -> qvm-usb l : sys-usb:4-2 Yubico_Yubikey_4_U2F+CCID > > > -> qvm-device usb attach vm-name sys-usb:4-2 : Device attach failed: No > device info received, connection failed, check backend side for details -> > same things How did you create sys-usb? Have you installed qubes-input-proxy-sender in 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 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/c44ec4660c7ec36039088ec5550addec.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] reboot sys-net
On Fri, February 2, 2018 11:05 am, Bernhard wrote: > On 02/02/2018 11:58 AM, Ilpo Järvinen wrote: > >> On Fri, 2 Feb 2018, Bernhard wrote: >>> That would allow to confortably reboot sys-net For a bit more blunt force approach, you could qvm-kill sys-net then use the procedure "Reconnecting VMs after a NetVM reboot" on https://www.qubes-os.org/doc/firewall/ to reconnect it. Have not thoroughly tested. -- 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/289528855d40ca7fa0bff173a2a3d753.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes OS 4.0-rc4 has been released!
On Thursday, 1 February 2018 02:44:13 UTC, Andrew David Wong wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Dear Qubes Community, > > We're pleased to announce the fourth release candidate for Qubes 4.0! > This release contains important safeguards against the [Spectre and > Meltdown attacks][qsb-37], as well as bug fixes for many of the issues > discovered in the [previous release candidate][4.0-rc3]. A full list of > the Qubes 4.0 issues closed so far is available [here][closed-issues]. > Further details about this release, including full installation > instructions, are available in the [Qubes 4.0 release > notes][release-notes]. The new installation image is available on the > [Downloads] page. > > As always, we're immensely grateful to our community of testers for > taking the time to [discover and report bugs]. Thanks to your efforts, > we're able to fix these bugs *before* the final release of Qubes 4.0. We > encourage you to continue diligently testing this fourth release > candidate so that we can work together to improve Qubes 4.0 before the > stable release. > > Major changes in Qubes 4.0-rc4 > - -- > > The Qubes VM Manager is back by popular demand! The returning Qubes > Manager will be slightly different from the 3.2 version. Specifically, > it will not duplicate functionality that is already provided by the new > 4.0 widgets. Specific examples include attaching and detaching block > devices, attaching and detaching the microphone, and VM CPU usage. > > In addition, the default TemplateVMs have been upgraded to Fedora 26 and > Debian 9. > > The Qubes 4.0 stable release > - > > If the testing of 4.0-rc4 does not reveal any major problems, we hope to > declare it the stable 4.0 release without any further significant > changes. In this scenario, any bugs discovered during the testing > process would be fixed in subsequent updates. > > If, on the other hand, a major issue is discovered, we will continue > with the standard [release schedule], and Qubes 4.0 stable will be a > separate, later release. > > Current Qubes 4.0 Users > - --- > > Current users of Qubes 4.0-rc3 can upgrade in-place by downloading the > latest updates from the testing repositories in both > [dom0][dom0-testing] and [TemplateVMs][domU-testing]. As explained in > [QSB #37][qsb-37], Qubes 4.0-rc4 uses PVH instead of HVM for almost all > VMs without PCI devices by default as a security measure against > Meltdown, and this change will also be released as a patch for existing > Qubes 4.0 installations in the coming days. Therefore, current Qubes 4.0 > users will benefit from this change whether they upgrade in-place from a > previous release candidate or perform a clean installation of 4.0-rc4. > > If you wish to upgrade in-place and have manually changed your VM > settings, please note the following: > > 1. By default, Qubes 4.0-rc3 used kernel 4.9.x. However, PVH mode will >require kernel >= 4.11. This is fine, because we will include kernel >4.14 in the PVH update. However, if you have manually changed the >kernel setting for any of your VMs, the update will not automatically >override that setting. Those VMs will still be using an old kernel, >so they will not work in PVH mode. Therefore, you must must either >change their settings to use the new kernel or change the VM mode >back to HVM. > > 2. If you have created a Windows VM, and you rely on it running in HVM >mode, you must explicitly set its mode to HVM (since the default mode >after applying the PVH update will be PVH rather than HVM). You can >do this either through the VM Settings GUI or by using the >`qvm-prefs` command-line tool to change the `virt_mode` property. > > > [qsb-37]: https://www.qubes-os.org/news/2018/01/11/qsb-37/ > [4.0-rc3]: https://www.qubes-os.org/news/2017/11/27/qubes-40-rc3/ > [closed-issues]: > https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+milestone%3A%22Release+4.0%22+is%3Aclosed > [release-notes]: https://www.qubes-os.org/doc/releases/4.0/release-notes/ > [discover and report bugs]: https://www.qubes-os.org/doc/reporting-bugs/ > [release schedule]: > https://www.qubes-os.org/doc/version-scheme/#release-schedule > [4.0-bugs]: > https://github.com/QubesOS/qubes-issues/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+milestone%3A%22Release+4.0%22+label%3Abug > [dom0-testing]: > https://www.qubes-os.org/doc/software-update-dom0/#testing-repositories > [domU-testing]: > https://www.qubes-os.org/doc/software-update-vm/#testing-repositories > [Downloads]: https://www.qubes-os.org/downloads/ > > This announcement is also available on the Qubes website: > https://www.qubes-os.org/news/2018/01/31/qubes-40-rc4/ > > - -- > Andrew David Wong (Axon) > Community Manager, Qubes OS > https://www.qubes-os.org > > -BEGIN PGP SIGNATURE- > > iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDA
[qubes-users] Re: Please help with custom template build
On Tuesday, 23 January 2018 17:36:00 UTC, Krišjānis Gross wrote: > Hi, > > I am trying to build a custom installation .iso. I have an issue that I have > purchased a new set of hardware that does not work with the current builds of > qubes. I am trying to build the most updated version with hope that it could > work. > > I am running a Fedora linux and trying to build with these instructions: > https://www.qubes-os.org/doc/building-archlinux-template/ > > I use the ./setup to create the installation configuration. > > make install-deps goes fine. > make get-sources goes smooth as well > > but I get an error when running the mage qubes command. > Here is what I get: > > [krish@localhost qubes-builder]$ make qubes > Currently installed dependencies: > git-2.14.3-2.fc27.x86_64 > rpmdevtools-8.10-3.fc27.noarch > rpm-build-4.14.0-2.fc27.x86_64 > createrepo-0.10.3-12.fc27.noarch > debootstrap-1.0.92-1.fc27.noarch > dpkg-dev-1.18.24-3.fc27.noarch > python2-sh-1.12.14-2.fc27.noarch > dialog-1.3-10.20170509.fc27.x86_64 > dpkg-dev-1.18.24-3.fc27.noarch > debootstrap-1.0.92-1.fc27.noarch > PyYAML-3.12-5.fc27.x86_64 > make[1]: Entering directory '/home/krish/qubes-builder' > -> Preparing fc25 build environment > -> Initializing RPM database... > -> Retreiving core RPM packages... > -> Verifying signatures... > Filename: > /home/krish/qubes-builder/cache/fc25/base_rpms/acl-2.2.52-13.fc25.x86_64.rpm > is not signed. Exiting! > make[1]: *** > [/home/krish/qubes-builder/qubes-src/builder-fedora/Makefile.fedora:86: > /home/krish/qubes-builder/chroot-fc25/home/user/.prepared_base] Error 1 > make[1]: Leaving directory '/home/krish/qubes-builder' > make: *** [Makefile:224: vmm-xen-dom0] Error 1 > > > Does anyone has an idea of what I do wrong or how to resolve this? > I have attached the builder.conf file that I have. Tried to build on Fedora 25 but did not succeed. Did not get the same issue but there was something else that did not work. Kind of gave up trying because of Qubes 4 RC4 release. thank You to everyone for the help! -- 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/445fe880-2720-4cc2-8754-eb1013bc3f5c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Please help with 8th Generation Intel i5
On Wednesday, 17 January 2018 19:24:05 UTC, Krišjānis Gross wrote: > Hi, > > Was using Qubes 3.2 on 4th generation i5 processor when decided to upgrade my > hardware. > > Purchased 8th gen i5 processor and MB. Now when I start my Qubes only dom0 is > started. no other VM is started unfortunately. > > Here is the hardware details: >MB: ASRock Z370 Pro4 https://www.asrock.com/MB/Intel/Z370%20Pro4/index.asp >CPU: Intel® Core™ i5-8600K > https://ark.intel.com/products/126685/Intel-Core-i5-8600K-Processor-9M-Cache-up-to-4_30-GHz >RAM: 16 GB DDR4 > > > Qubes 3.2. boots but feels very slow. e.g. when I type the characters appear > with considerable delay. Mouse is not working. I can only do something with > PS2 keyboard. > > I tried to run Qubes installation but failed to do that. 3.2 did not start > the installation at all. > Qubes 4.0rc3 installation did get to some point and resulted in error. > I have attached some screen shots of 4.0 installation. > > Not sure what to do next. Read in some other topics that others had an issue > with new hardware. > > Please help to resolve this. I really really want to continue using Qubes. it > is such an awesome system! Thank You for the recommendation, awokd! I did not find the time to try that out. Will try everything again with the most recent release. And if there will be issues will post a new question thread. -- 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/be49321c-834f-4e89-bc35-672b0982a7d6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] reboot sys-net
On 02/02/2018 11:58 AM, Ilpo Järvinen wrote: > On Fri, 2 Feb 2018, Bernhard wrote: > >> Did by chance someone write a dom0-script that >> >> a) fetches a list of all (running) appvm's that use sys-net. >> >> b) setting their net-vm to "none" >> >> c) reboot sys-net >> >> d) undoes step (b) >> >> That would allow to confortably reboot sys-net (same ideas apply to >> sys-firewall & sys-whonix) and could help many people in many >> situations. I am not a bash hero, and before losing half a day on this >> useful script, I prefer asking if someone did it already :) > I didn't have it already but it wasn't too difficult to do so I wrote one > as it seems somewhat useful. Awesome! Thank you very much. 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 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/36c7f28f-90a7-f322-d5fc-3ff3a90af580%40web.de. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] reboot sys-net
On Fri, 2 Feb 2018, Bernhard wrote: > Did by chance someone write a dom0-script that > > a) fetches a list of all (running) appvm's that use sys-net. > > b) setting their net-vm to "none" > > c) reboot sys-net > > d) undoes step (b) > > That would allow to confortably reboot sys-net (same ideas apply to > sys-firewall & sys-whonix) and could help many people in many > situations. I am not a bash hero, and before losing half a day on this > useful script, I prefer asking if someone did it already :) I didn't have it already but it wasn't too difficult to do so I wrote one as it seems somewhat useful. -- i. -- 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/alpine.DEB.2.20.1802021230410.15025%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout. #!/bin/sh vm="sys-net" [ $# -ge 1 ] && vm="$1" echo "Restarting $vm..." explicitlist=$(qvm-ls --raw-data state netvm name-raw | \ grep -e "^Running|$vm|" | cut -d '|' -f 3) defaultlist=$(qvm-ls --raw-data state netvm name-raw | \ grep -e "^Running|[*]$vm|" | cut -d '|' -f 3) for i in $explicitlist $defaultlist; do qvm-prefs -s $i netvm none done qvm-shutdown --wait "$vm" qvm-start "$vm" for i in $explicitlist; do qvm-prefs -s $i netvm "$vm" done for i in $defaultlist; do qvm-prefs -s $i netvm default done
[qubes-users] reboot sys-net
Did by chance someone write a dom0-script that a) fetches a list of all (running) appvm's that use sys-net. b) setting their net-vm to "none" c) reboot sys-net d) undoes step (b) That would allow to confortably reboot sys-net (same ideas apply to sys-firewall & sys-whonix) and could help many people in many situations. I am not a bash hero, and before losing half a day on this useful script, I prefer asking if someone did it already :) Thank you, 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 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/dc35b472-0c8c-df87-a0d7-3705f9a2d1ce%40web.de. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Windows Tools
so, I created an win7 HVM ; and I think installed windows tools, but when I read through the qubes docs, the instructions seem to be circular. eg, I don't have any idea how I would run an AppVM based on ?the Win7 HVM ?? or should I try to make a win7 "Template HVM" instead , or, how does one run an AppVM based on an HVM , doesn't make sense with the normal Template/AppVM scheme for other templates, though I'm sure I'm missing Something ... I guess the benefit of the AppVM over the HVM is Qubes integration for copy and paste and anything else practical? -- 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/f495819684c9f8ff93172188c507d2b4%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Slow network speed outside netvm
Ilpo Järvinen: > > Great find Ilpo! Did you have to do some iptables-trickery for this > > testing? I have ping working between proxy and appvm, but iperf and nc > > both tell me no route to host? > > Yes, I did (it replies with ICMP by default). You'll need to fill in the > vif IP-address to this command: > > sudo iptables -I INPUT 1 -i vif+ -p tcp -d ***proxyvmIPhere*** -j ACCEPT WOW! I can easily push 19Gbit/s from appvm to proxyvm (after turning on SG on appvm), but from proxyvm to netvm I can only push 3-4Gbit/s. There HAS to be room for some improvement here? -- 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/6cab20f3-c327-4149-a7c0-f5f31067b19f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Slow network speed outside netvm
On Fri, 2 Feb 2018, Jarle Thorsen wrote: > Ilpo Järvinen: > > Can you try if you get better throughput between a proxy vm and an appvm > > using this kind of topology? > > > > sys-net <-> iperf-srv (proxyvm) <-> iperf-cli (appvm) > > > > I could push ~10Gbps with one flow and slightly more with more parallel > > flows between them. > > Great find Ilpo! Did you have to do some iptables-trickery for this > testing? I have ping working between proxy and appvm, but iperf and nc > both tell me no route to host? Yes, I did (it replies with ICMP by default). You'll need to fill in the vif IP-address to this command: sudo iptables -I INPUT 1 -i vif+ -p tcp -d ***proxyvmIPhere*** -j ACCEPT -- i. -- 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/alpine.DEB.2.20.1802021026390.13281%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Slow network speed outside netvm
Ilpo Järvinen: > Can you try if you get better throughput between a proxy vm and an appvm > using this kind of topology? > > sys-net <-> iperf-srv (proxyvm) <-> iperf-cli (appvm) > > I could push ~10Gbps with one flow and slightly more with more parallel > flows between them. Great find Ilpo! Did you have to do some iptables-trickery for this testing? I have ping working between proxy and appvm, but iperf and nc both tell me no route to host? PROXY-VM: $ ifconfig eth0: flags=4163 mtu 1500 inet 10.137.4.34 netmask 255.255.255.255 broadcast 10.255.255.255 inet6 fe80::216:3eff:fe5e:6c20 prefixlen 64 scopeid 0x20 ether 00:16:3e:5e:6c:20 txqueuelen 1000 (Ethernet) RX packets 86 bytes 6193 (6.0 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 162 bytes 14313 (13.9 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 loop txqueuelen 1 (Local Loopback) RX packets 36 bytes 2016 (1.9 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 36 bytes 2016 (1.9 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 vif37.0: flags=4163 mtu 1500 inet 10.137.6.1 netmask 255.255.255.255 broadcast 0.0.0.0 inet6 fe80::fcff::feff: prefixlen 64 scopeid 0x20 ether fe:ff:ff:ff:ff:ff txqueuelen 32 (Ethernet) RX packets 91 bytes 6489 (6.3 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 86 bytes 7993 (7.8 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 $ sudo iptables -L Chain INPUT (policy DROP) target prot opt source destination DROP udp -- anywhere anywhere udp dpt:bootpc ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ACCEPT icmp -- anywhere anywhere ACCEPT all -- anywhere anywhere REJECT all -- anywhere anywhere reject-with icmp-host-prohibited Chain FORWARD (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere DROP all -- anywhere anywhere ACCEPT udp -- 10.137.6.35 gateway udp dpt:domain ACCEPT udp -- 10.137.6.35 10.137.4.254 udp dpt:domain ACCEPT tcp -- 10.137.6.35 gateway tcp dpt:domain ACCEPT tcp -- 10.137.6.35 10.137.4.254 tcp dpt:domain ACCEPT icmp -- 10.137.6.35 anywhere DROP tcp -- 10.137.6.35 10.137.255.254 tcp dpt:us-cli ACCEPT all -- 10.137.6.35 anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 10.137.4.1 0.0.0.0 UG0 00 eth0 10.137.4.1 0.0.0.0 255.255.255.255 UH0 00 eth0 10.137.6.35 0.0.0.0 255.255.255.255 UH32715 00 vif37.0 APP-VM: $ ifconfig eth0: flags=4163 mtu 1500 inet 10.137.6.35 netmask 255.255.255.255 broadcast 10.255.255.255 inet6 fe80::216:3eff:fe5e:6c21 prefixlen 64 scopeid 0x20 ether 00:16:3e:5e:6c:21 txqueuelen 1000 (Ethernet) RX packets 86 bytes 6789 (6.6 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 91 bytes 7763 (7.5 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 loop txqueuelen 1 (Local Loopback) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 $ sudo iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination DROP udp -- anywhere anywhere udp dpt:bootpc ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ACCEPT icmp -- anywhere anywhere ACCEPT all -- anywhere anywhere REJECT all -- anywhere anywhere reject-with icmp-host-prohibited DROP all -- anywhere anywhere Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere ctstate R
