Re: [qubes-users] Thoughts about installed software
However I would not use the "move to VM" command like this, as I experienced those requests getting lost One time files were actually deleted, since that time I always use copy instead of move. Sounds troubling. Do you remember the last Qubes release version where you experienced this kind of data loss? [...][...] qvm-move-to-vm *should* be safe since R3.1 (unless the destination VM was debian-7 based, which had an old glibc without syncfs() support). Rusty 3.1 - but I dont remember src & dest types My thoughts are more about continuing the attack to other QubesVMs or even other systems by means of installed Software like a VNC client. But I only ever allow the ports I require to be used at that time. I do have one area that is set up as a complete, but they can only talk to each other, nothing else. So if you configure Qubes correctly, including the VMs, it will be very difficult to actually attack other VMs in the way I think you may be thinking it's easy? Good point, Drew. The problem is reduced significantly if you reduce the firewall exceptions to a minimum. -- 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/17c46299-307c-4f0e-e04a-d62e6baee4d7%40digitrace.de. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Bug or Feature? DispVM inherits settings from calling VM
Currently your easiest option is not to click on the links, but to copy-paste them to an open dispVM. Small sacrifice for a major security gain. Well, the "easiest" option is to use a net-vm directly. What is the security gain? Its a dispVM after all. -- 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/cdf8657f-cf4f-63d8-563b-15d04af59a0d%40digitrace.de. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] How to solve ProxyVM (sys-firewall) becomming non-functional at runtime
Am 10/13/2016 um 04:12 PM schrieb Manuel Amador (Rudd-O): On 10/11/2016 09:42 AM, Robert Mittendorf wrote: Hey folks, sometimes the sys-firewall (more likely a service within it) crashes and does no longer allow connected VMs to resolve DNS. The ProxyVM must be the responsible entity, because the connection will be fine again If I restart the sys-firewall. You're onto it. I think I fixed this yesterday: https://github.com/QubesOS/qubes-core-agent-linux/pull/20 Quick-reading you link I dont think that this is the issue. My obervation is that it happens after several hours/days of a flawlessly working ProxyVM, not at boot. -- 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/c1fd7dc8-e572-897c-7ef8-215cd6a04479%40digitrace.de. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: QUBES 3.2 won't install... EFI_MEMMAP is not enabled... ESRT header is not in the memory map
Am 10/16/2016 um 12:59 AM schrieb raahe...@gmail.com: On Saturday, October 15, 2016 at 6:05:39 PM UTC-4, aldenj...@gmail.com wrote: I have the same issue! see if you can select legacy boot mode in your bios and then install qubes. I had a similar issue with Qubes 3.2 but not 3.1. For me the issue was the GPU. Increasing the memory from 256 MB to 512 MB solved the issue (non-discrete GPU, of course) -- 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/6a542cdb-3c5e-82d1-a012-8fdaa724f407%40digitrace.de. For more options, visit https://groups.google.com/d/optout.
[qubes-users] AMO Mozilla Updates - Which IPs?
Hey folks, maybe someone did solve my problem before. I want to allow Thunderbird in MailVM to update extensions. That is easy for non-AMO[1] extensions, but AMO uses a lot of IPs for load-balancing, availability and performance. Any idea of how to allow AMO-based extension updates? [1]AMO is addons.mozilla.org, the official "repository" for extensions of Mozilla products The URLs are https://versioncheck.addons.mozilla.org/update/ https://versioncheck-bg.addons.mozilla.org/update/ A quick check of DNS for IPs resolves to: DNS propagation results for versioncheck.addons.mozilla.org == Expected value (discovered direct from the root servers): 52.10.239.169 Location Lookup Result Status Atlanta, USA 54.187.193.33 Falkenstein, Germany 52.24.177.214 Hong Kong, China 54.187.193.33 Johannesburg, South Africa 54.68.227.204 Las Vegas, USA 50.112.138.61 London, UK 52.24.192.1 Los Angeles, USA 50.112.138.61 Milan, Italy 54.68.227.204 Montreal, Canada 52.88.174.121 New York, USA 50.112.138.61 Rotterdam, Netherlands 54.187.193.33 Seattle, USA 50.112.138.61 Sydney, Australia 54.149.244.207 Toyko, Japan 54.187.193.33 -- 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/5a9b5495-d58c-9a83-5db2-763b63a2e3dc%40digitrace.de. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: How to send wake on lan from qubes?
Thank you all for your help. Wake on lan works from the sys-net VM and I am happy with this solution. -- 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/ce18da46-1af2-4f84-b9fe-b0ae9d821ab8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Group/Hide VMs (e.g. mark arbitrary VM as "internal")
Am 10/11/2016 um 08:05 PM schrieb Unman: qvm-prefs -s internal True Simple as that ? - thank you! I checked the config files and did not find the "internal" switch -- 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/1f7e7c1a-6dfd-61da-2ce8-2cfbd9c02dd8%40digitrace.de. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: USB over IP (Network Gateway)
Hi! I am Doris from Eltima Software. Did you try to use it on Qubes? What exact issues appeared? You may send me your logs on doriss.l...@eltima.com and our team will try to solve the appeared issue. Regards, Doris. -- 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/628f588d-a035-4b3c-9cef-56647ccef918%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Is Qubes R3.2 still in testing branch?
On 2016-10-17 08:39, Andrew David Wong wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2016-10-16 22:51, Pawel Debski wrote: On 2016-10-16 23:22, Marek Marczykowski-Górecki wrote: On Sun, Oct 16, 2016 at 08:21:17PM +0200, Pawel Debski wrote: Folks, I'm planning R3.1 -> 3.2 upgrade and need explanation: |sudo qubes-dom0-update --enablerepo=qubes*testing --releasever=3.2 qubes-release| why do I need to enable testing repo? I thought that R3.2 has already been released as stable. You're right, testing repo is no longer needed. Instruction fixed. The thing is, that I was getting errors until I enabled testing repo. With --enablerepo=qubes*testing the upg went on. What errors did you get? About packages not existing in repo. As I've already run first stage of the upg with --enablerepo=qubes*testing the exact errors are hard to recollect. My assumption (perhaps wrong) was that the packages are still in testing repo. Is there any log file I can paste the errors from? Z powazaniem / Best Regards Mit freundlichen Gruessen / Meilleures salutations Pawel Debski -- 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/c8cae1fe-a772-a5aa-544d-cc2260e1ed5d%40econsulting.pl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Maybe a provocative question
>> 1) XEN is developed by people working for a company based in >> the U.S. Some fun stats for Xen 4.6 changesets, as used by Cubes: Lines of Code: ~150,000 This is from https://wiki.xenproject.org/wiki/Xen_Project_4.6_Acknowledgements and related pages (and similar pages with 4.6 replaced by 4.x): Lines of code added/removed: Vers People Empl Added Rempved NSA-Add NSA-Rem 4.4 81 29 38048 25989 121 4.5 10239 80906 141593 67142645 4.6 96 30 124035 90299 459 193 4.7 10236 106606 37160 ? ? Now, about 4.7. Note that the page for only lists individual names, does not list any company affiliations or employers at all. An odd change/omission? So the NSA barely contributed for 4.4, contributed a significant amount for 4.5, a bit for 4.6, and then either stopped contributing, or are doing so in a non-transparent way through individuals for 4.7. :( I can't say that's confidence-inspiring. Xen's change from 4.6 to 4.7 to not listing employers almost has a slight "warrant canary" feel to it. :S The source is open, I guess, but still, smart people can sneak in subtle backdoor bugs. As we have seen. Also, out of those 100 individuals, what are the odds that the NSA could sneak in a few apparently unaffiliated "representatives" to submit some subtle changes. Now, I'm sure a good many of the people at NSA just want a stable, reliable, professional operating system to use for their work, and contribute back to Linux in turn to make it better. It'd be refreshing and inspiring to see them fixing our critical tech tools rather than hopelessly busting them. Go America. But given their history of sneaking in back doors through subtle code bugs, it does make one a bit, err, cautious. Xen is a much bigger and faster-moving target than I ever expected for a hypervisor. After discovering I was being victimized by some keylogging and some other covert surveillance hw/sw, I spend a fair bit of time about how to use a computer with confidence, assuming that you can't necessarily trust the hardware nor software. Is it possible to have a secure environment, where you don't fully trust the hardware/software? And unless you've designed the hardware and software yourself (or they're both open and heavily and transparently reviewed), and your never let either out of your sight and protection, how can you ever fully trust hardware/software? (For example, things such as a password safe on a memory key can help partially thwart even a hardware keylogger, since online/etc. passwords are never typed. Can this type of small success be achieved for a whole system? It's daunting.) Related: http://invisiblethingslab.com/resources/bh08/part2-full.pdf JJ -- 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/6fc41c35e0c90896e50fc5892626c230.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Maybe a provocative question
On Mon, Oct 17, 2016 at 02:12:52PM -, johnyju...@sigaint.org wrote: > Lines of code added/removed: interesting numbers, thanks for posting them here. > Now, about 4.7. Note that the page for only lists individual names, does > not list any company affiliations or employers at all. An odd > change/omission? could there be a simpler explaination? > Xen is a much bigger and faster-moving target than I ever expected for a > hypervisor. indeed, same here. > Is it possible to have a secure environment, where you don't fully trust > the hardware/software? no, especially assuming s#fully## ;-p > And unless you've designed the hardware and > software yourself (or they're both open and heavily and transparently > reviewed), and your never let either out of your sight and protection, how > can you ever fully trust hardware/software? you can't. and yeah, that's sad. luckily the real world is mostly not *that* black and white. long story short: I'd argue that *noone* should fully trust computers. however, this doesn't make them completly useless ;-) -- cheers, Holger (SCNR) -- 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/20161017143310.GA22301%40layer-acht.org. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [qubes-users] Re: Maybe a provocative question
>> Now, about 4.7. Note that the page for only lists individual names, >> does >> not list any company affiliations or employers at all. An odd >> change/omission? > > could there be a simpler explanation? Certainly. Maybe some intern generating the stats page was too lazy to summarize it by company. Maybe they stopped tracking company affiliation. Maybe it's just an oversight. Given the state of computer/network/software security these days and the NSA's reputation, I thought it was worth pointing out. :) >> Xen is a much bigger and faster-moving target than I ever expected for a >> hypervisor. > > indeed, same here. Wiki on Microkernels is consistent with my understanding: > In terms of the source code size, as a general rule microkernels tend to be smaller than monolithic kernels, usually sizing at under 10,000 lines of code. Xen's Wiki page states: > Xen Project is a hypervisor using a microkernel design It's a bit disingenuous to call Xen a Microkernel, at 150,000+ lines of code. I hope to dig through the sources a bit tonight, and see how much of that is truly the core kernel/security bits, and how much of that is qemu drivers and stuff. Maybe there is a lean, well-reviewed core that we can all trust, with a lot of supporting drivers and such. Although the fact that those acknowledgement pages are careful to point out "Microkernel core" vs. auxiliary stuff. >> Is it possible to have a secure environment, where you don't fully trust >> the hardware/software? > > no, especially assuming s#fully## ;-p Not with existing hardware/software/operating systems, but can we get there? Is there even a path forward? :) Sadly, there doesn't seem to be any viable Xen alternatives. (I guess one could always create alternatives from forks of Xen or the various other hypervisors/kernels out there; although securing/improving/auditing Xen is probably less work.) >> And unless you've designed the hardware and >> software yourself (or they're both open and heavily and transparently >> reviewed), and your never let either out of your sight and protection, >> how >> can you ever fully trust hardware/software? > > you can't. > > and yeah, that's sad. luckily the real world is mostly not *that* black > and white. True, security isn't an on/off binary thing, it's more of a probability to be combined with your risk profile. Qubes certainly increases your odds at having some security by a fair bit. Probably minor in comparison to all the holes, bugs, bad design choices, and vulnerabilities in PC hardware (and software bugs/backdoors), but every little bit helps. > long story short: I'd argue that *noone* should fully trust computers. > however, this doesn't make them completly useless ;-) Very good point. I've overly-trusted computers, and have been hacked so badly in the past few years that computers have basically become useless to me. But I'm also a pretty low-valued target, lol, so I'm trying to rebuild my confidence in my setup for work (and personal) sanity and dignity. It's awfully hard not to rely upon computers on a daily basis for work, personal, communications, media purposes. Stumbled across this, rather interesting: https://en.wikipedia.org/wiki/Exokernel JJ -- 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/31ab8b2a2629b9c5dfb22e8b0eaa4824.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Bug or Feature? DispVM inherits settings from calling VM
On 10/17/2016 09:42 AM, Robert Mittendorf wrote: Currently your easiest option is not to click on the links, but to copy-paste them to an open dispVM. Small sacrifice for a major security gain. Well, the "easiest" option is to use a net-vm directly. What is the security gain? Its a dispVM after all. The data copied to that VM (i.e. the pdf file or whatever you opened) must be considered leaked if the VM gets compromised via e.g. drive-by exploits. Agreed, it's limited to that data, but nevertheless an unexpected potential impact. And depending on your data it can be critical. From a usability point of view you'll also get annoyed if you cannot print in dispVMs just because your firewall rules allowing connectivity to your printer aren't inherited, but those to allowing connectivity to the internet suddenly are in place. Moreover your netVM is also inherited and firewall rules can have a different meaning depending on your netvm (just imagine the same private subnets being used for 2 different networks), i.e. it makes sense to inherit firewall rules, if you do it for netVMs. Btw inheriting netVMs makes a lot of sense if you imagine one Tor proxy VM and one directly connected one. So a dispVM from a Tor connected VM would spawn a direct internet connection in your case... Currently it fortunately does not. -- 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/1b04afd0-8e3f-087b-9db1-a381495deb64%40hackingthe.net. For more options, visit https://groups.google.com/d/optout. smime.p7s Description: S/MIME Cryptographic Signature
[qubes-users] sys-net doesn't detect wifi
Sorry, maybe it is a bug There is network manager applet but it is invisible -- 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/e8e9835a0a67cc06b2179644844eafcd.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Bug or Feature? DispVM inherits settings from calling VM
The data copied to that VM (i.e. the pdf file or whatever you opened) must be considered leaked if the VM gets compromised via e.g. drive-by exploits. Agreed, it's limited to that data, but nevertheless an unexpected potential impact. And depending on your data it can be critical. Well, that is why it is a distinct DispVM. If I open a legit PDF from my mail client in a DispVM (say dispvm1) and I open a non-legit URL in a DispVM, this will not be the same dispVM and thereby not leak the PDFs data. If the PDF itself is malicious, I most likely will not care about the leak. Only exception: A legit PDF gets infected and is then mailed to me. Usually that would allow the attacker to leak the PDF from the system it was send from in the first place. From a usability point of view you'll also get annoyed if you cannot print in dispVMs just because your firewall rules allowing connectivity to your printer aren't inherited, but those to allowing connectivity to the internet suddenly are in place. agreed, basically. Btw inheriting netVMs makes a lot of sense if you imagine one Tor proxy VM and one directly connected one. So a dispVM from a Tor connected VM would spawn a direct internet connection in your case... Currently it fortunately does not. agreed. Well, I was actually suprised that there is more than 1 DispVM. Do the child-DispVMs use the fedora-23-dvm template as well? -- 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/a8dfee0a-0107-64f1-7ed2-8ae82809b638%40digitrace.de. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Persistant routes on Qubes are not persistant?!
Hi, Does anyone knows how to achieve this on Qubes? Thanks Sent using GuerrillaMail.com Block or report abuse: https://www.guerrillamail.com/abuse/?a=UFR2AB5NVqcQmh2U93EQdRjCStifx8dDiadNcQ%3D%3D -- 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/92534927000b3a8ba33f465f37cd20faad66%40guerrillamail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Persistant routes on Qubes are not persistant?!
> Hello, > > I need to add some static routes since I'm using a network with different > GWs. For that reason I've tried to add some static routes through the > NetworkManager which maps all the configuration into a file called > qubes-uplink-eth0 . Strangely and since this file is within the private > disk image, one would expect that the changes are be preserved after a > reboot, unfortunately this has not been the case. Everytime there's a > reboot the file gets overwritten somehow. > Does anyone know if there's a way to preserve static routes on Qubes or is > this simply a limitation? That seems quite odd. Is the symlink for /etc/NetworKManager/system-connections -> /rw/config/NM-system-connections in place? Is /rw/config/NM-system-connections indeed a valid directory, writable by root, etc.? Is /rw properly mounted to /dev/xvdb? If you go into /etc/system do you see a file for each network adapter (i.e. "Wired Connection 1")? Is that file rw by root only? When you modify settings in the network-manager taskbar icon, does the network's config file change accordingly? (It's text-based, easy to view.) I use a couple of different static network configurations through NetworkManager, and they stick around just fine. What template are you using? JJ -- 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/cd66f141fc4026811b40a87101e9118d.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Inconsistent Screen Resolution for Fedora VMs
I just did a clean install of Qubes 3.2. For some reason the resolution off apps in Fedora VMs is wildly inconsistent. The borders of the windows, dom0, and the Debian VMs are correct but the apps in Fedora VMs range from consistent with the others to so low as to be almost unusable. I can't figure out what causes them to change and xrandr outputs the same thing no matter what the displayed resolution is. -- 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/7ee13d48-ff24-4f0d-95ce-c132a5eb5bb4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Anonymize MAC address
On 10/16/2016 02:02 PM, pl1...@sigaint.org wrote: On 10/15/2016 08:59 AM, pl1...@sigaint.org wrote: Anyone? Instructions for MAC anonymization have just been updated: https://www.qubes-os.org/doc/anonymizing-your-mac-address/ Chris Ok, is recommend to use debian as sys-net My question is about already used mac-spoof in sys-net, please can you try to give me an answer if it is possible? pL11 Maybe someone involved in the macchanger instructions can chime in with advice. My personal recommendation would be to use Network Manager, as the Macchanger script is prone to breakage and lists these limitations: * This does not randomize your MAC Address on sleep and wake state (only on restarting the |sys-net| VM) * The |sys-net| networking VM takes longer for device drivers to start up than usual, this delayed startup may cause the first attempt of |sys-whonix| to connect to Tor to fail I started about 2 years ago trying to get Macchanger to work consistently. None of the different approaches really did the job. It should be handled by the system's network configuration daemon, which is Network Manager. Chris -- 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/9a4b1571-5742-a5e7-d194-3bcb8b1eb369%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re:Persistant routes on Qubes are not persistant?!
Yes, the symlink is in place: ls /etc/NetworkManager/system-connections 131205 lrwxrwxrwx 1 root root 32 Oct 17 21:17 /etc/NetworkManager/system-connections -> /rw/config/NM-system-connections/ The /dev/xvdb is properly mounted on /rw : /dev/xvdb on /rw type ext4 (rw,relatime,discard,data=ordered) I don't have a /etc/system directory on my system, are you referring to the unit files? For the sys-firewall I'm using the default template - > fedora-23 When I set the routes by hand via NetworkManager they are reflected on the qubes-uplink-eth0 file: (...) [ipv4] address1=10.137.1.8/32,10.137.1.1 dns=10.137.1.1;10.137.1.254; dns-search= may-fail=false method=manual never-default=true route1=192.168.0.0/16,10.137.1.1 route2=172.16.0.0/16,10.137.1.1 #---EOF--- The file before the sys-firewall is rebooted has the following checksum and md5sum: 2551335477 425 qubes-uplink-eth0 83b37a6b68007838efb1e9e9fbc841f4 qubes-uplink-eth0 As soon as the sys-firewall is booted the file with the NW configuration is overwritten : [ipv4] method=manual may-fail=false dns=10.137.1.1;10.137.1.254 addresses1=10.137.1.8;32;10.137.1.1 #---EOF--- As you can see the configuration was not preserved. Therefore something is clearly overwritten the NM configuration, the problem is to know what and how to avoid it, preserving the NM config. So in short, I cannot tell what process have been changing the NM configuration at every boot. It would be great if someone from the Qubes support would be able to shed some light on this. Sent using GuerrillaMail.com Block or report abuse: https://www.guerrillamail.com/abuse/?a=UFR2AB5NVqcQmh2U93EQdRjCStifx8dDiadNcQ%3D%3D -- 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/87a342d6cf1e466edf3faab497ec5514ad30%40guerrillamail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Unable to uptade templates affer forced all traffic trhough VPN
On 10/16/2016 08:50 AM, 4lpt9o+3m11o9qubb38o via qubes-users wrote: You don't need to manually add the iptables rules. When enable the 'qubes-yum-proxy' on the VPNVM the rule to iptables is automatically added: Chain PR-QBS-SERVICES (1 references) pkts bytes target prot opt in out source destination 0 0 REDIRECT tcp -- vif+ * 0.0.0.0/0 10.137.255.254 tcp dpt:8082 And also the corresponding rule on the INPUT chain: Chain PR-QBS-SERVICES (1 references) pkts bytes target prot opt in out source destination 0 0 REDIRECT tcp -- vif+ * 0.0.0.0/0 10.137.255.254 tcp dpt:8082 So you don't need to do this by hand. @Manuel I agree with you, the instructions on the Qubes VPN doc. don't outline this step. And this is necessary to have the updates working while forcing all the traffic through the VPN. Can someone add some references on the VPN article (https://www.qubes-os.org/doc/vpn/) in the same manner as this page reflected in this page - https://www.qubes-os.org/doc/software-update-vm/#updates-proxy . Since anyone following the VPN article,as it is, would not have the yum/apt updates working. Although following the doc would leave the updates working (user is instructed to create a new VPN VM, not use existing sys-firewall) it would be nice to be able to update over a VPN tunnel. I'll create an issue for updating the doc. Chris -- 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/3cff8ec6-510e-34a6-9681-4ff01d223c9c%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] how to integrate 3-year old backed up VM's into new system?
Hi, I have a 3-year old backup of an old Qubes system that I cannot access on my new, up-to-date system. Two templates are standalone VM's: I can integrate them with the Qubes-backup tool, so they appear in Qubes Manager, but they wont start: "ERROR: Cannot execute qrexec-daemon!" Two VM's are based on out-dated templates (fedora-18-x64) and cannot be restored. I can restore them still, with the "ignore missing" option, but I guess this wont make them boot? Any suggestions? Best regards, Emil -- 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/db36114d-35ab-7218-13e8-0d1a3e9ca9b4%40riseup.net. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] TVM ASLR-exploit-proof?
Hello Rudd-O, here is an interessting concept, in some way they reach the RAM randomization by one central DLL (for Windows Plattforms only), but it works direct on the fly for all apps and libs!!! http://www.morphisec.com/how-it-works/ Wow, not bad! This will be much more robust. And in parallel they keep the honypot, to run the law enforcement procedures against intruders. Here are some critical view to ASLR: http://blog.morphisec.com/aslr-what-it-is-and-what-it-isnt/ But for sure, the randomization will need a good non-deterministic random generator and a fast random update sequence (in Seconds) because 4 GB are quite endless... Would it makes sense to implement a similar fast not-deterministic randomization tech into the Qubes to overcome some standard template vulnerabilities, with smart countermeasurements? Kind Regards -- 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/f27cd0f8-c6d4-40b3-b33c-90284e85dba4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] TVM ASLR-exploit-proof?
Hello, Tails is also using ASLR security tech now... https://fossbytes.com/tails-2-6-secure-linux-os-snowden-updated-tor-and-kernel/ Kind Regards -- 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/7b310ec2-0b3a-48b3-831c-7e7c2902fd1c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] how to integrate 3-year old backed up VM's into new system?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Oct 17, 2016 at 07:50:26PM +, Emil Cronjäger wrote: > Hi, > > I have a 3-year old backup of an old Qubes system that I cannot access > on my new, up-to-date system. > > Two templates are standalone VM's: I can integrate them with the > Qubes-backup tool, so they appear in Qubes Manager, but they wont start: > "ERROR: Cannot execute qrexec-daemon!" Take a look at those instructions (in order): https://www.qubes-os.org/doc/upgrade-to-r3.0/ https://www.qubes-os.org/doc/upgrade-to-r3.1/ https://www.qubes-os.org/doc/upgrade-to-r3.2/ Especially the first link have steps for recovering from your situation. > Two VM's are based on out-dated templates (fedora-18-x64) and cannot be > restored. I can restore them still, with the "ignore missing" option, > but I guess this wont make them boot? That should work - those VMs will be set to use your default template. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJYBUB3AAoJENuP0xzK19csiFkIAI/QKzWZckvhk/f77ib7wvDS 33AY5h342ZJhmIK8dGyP8yJVHxxYAr4p1UPqM59hQlgTy4hWPwcWjS4MF5SV5x6K QyYTuuVBjyz2oaA1z+r5rmFpJWnTHapk+h1Z/epmy4iNZ0UH2QKxU10C//BLpx4W dVkFixv7aaeRjuIjPDtfYYfnQ7A5H3VYZPgvMwvF27z2wnHYqEW995TevkGwDpSi 9pMOj+uGGODIM8ytz9b0MGMlcXejIAhIZ2MfG99oBRcK09BNNS+/38I4AUMQ992a XhGi9Eqji0ddH6WX3ICU7zGzRc/LnYDCy2MOuTXuNaJa2lg0JaQp2qpdmj/V1gA= =LRLN -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 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/20161017211952.GK15776%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] how to integrate 3-year old backed up VM's into new system?
Marek Marczykowski-Górecki: > On Mon, Oct 17, 2016 at 07:50:26PM +, Emil Cronjäger wrote: > Take a look at those instructions (in order): > https://www.qubes-os.org/doc/upgrade-to-r3.0/ That got me a shell in one of the two VM's - thanx! There were some problems with the ip-commands though, but I managed to get the data out, and put it into a fresh VM. The other VM (also standalone), however, wont help me with a shell: connected to domain [domain-name] error: operation failed: PTY device is not yet assigned I am not sure or how to determine it, but it *might* be a debian-based VM, if that is to any help. It is not crucial for me to get the VM up and running, but I need to get data out of it somehow. > That should work - those VMs will be set to use your default template. > > Yup, it worked. -- 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/da6f51de-4ca4-c6f9-c915-a646b2861311%40riseup.net. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] how to integrate 3-year old backed up VM's into new system?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Oct 17, 2016 at 11:08:35PM +, Emil Cronjäger wrote: > > > Marek Marczykowski-Górecki: > > On Mon, Oct 17, 2016 at 07:50:26PM +, Emil Cronjäger wrote: > > Take a look at those instructions (in order): > > https://www.qubes-os.org/doc/upgrade-to-r3.0/ > > That got me a shell in one of the two VM's - thanx! There were some > problems with the ip-commands though, but I managed to get the data out, > and put it into a fresh VM. > > The other VM (also standalone), however, wont help me with a shell: > > connected to domain [domain-name] > error: operation failed: PTY device is not yet assigned > > I am not sure or how to determine it, but it *might* be a debian-based > VM, if that is to any help. Standalone (PV) VM, right? Or maybe some HVM? > It is not crucial for me to get the VM up and running, but I need to get > data out of it somehow. If you just want the data, create new VM, start it, and then attach the old VM private.img and/or root.img to the new one as additional device: qvm-block --attach-file new-vm /var/lib/qubes/appvms/old-vm/private.img - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJYBV54AAoJENuP0xzK19csi8UIAJtW6Yj8/xFst44BqegUSxDZ j0WzxGSPXFWMesqSeB6rvsZFftK0oSdyWK2QxYuo8FhmI2pD8PPMB6C/9WKpSM5D cSkBFubZRAr4eolrArTF1spOtJTit/QvIqlWQhbKpR2Lquf+f8x5n5oEG81Ar0si VJvgEhdXE1Y/uJX97YBBpqCSo5SvWbADJ2fN09yNFMbuADKBdqvwr8zv9WnGkJvl 1LK0BM9yvwGPAyA1h8uze5KqpoFUK/Tw61GD2LkAHtpL2AoAY3ch+N4B/CsKcwki nFRRIWUO/RjDhAmseXAY0IjASeEh5/XbPmkq8S6AUJMyRTEUheWXJjsoq5FGSbI= =4mtR -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 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/20161017232754.GM15776%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] sys-net doesn't detect wifi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2016-10-17 08:24, katerim...@sigaint.org wrote: > Sorry, maybe it is a bug > There is network manager applet but it is invisible > Yes, this is a known issue: https://github.com/QubesOS/qubes-issues/issues/2242 - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJYBWt/AAoJENtN07w5UDAwqNMQALPL2wjGIEUVuDygVn494HRJ nnsXOGqj9xbsa/bDQp5zkhNIqmvP5ieWpe7BjsLzYG02Nl89glApQqDAThuS4/sf h+Trexc2YfZyeuV469l2h5PoKSx4lXErmtD0lQIJUOsfnKLR4/jRRHdRwio8Pp42 BiZ77mrdiGx0/y/CdQh3y9BF5oMMGB4iakDpsgBCf3NNCsEvybtyfzbQ8zqiDBOX 9LXCZaCYc5zH+zRx3g2umm9IHg10r2hi8YtKRsiV3cKrgLXgM13+p6KLfeCIDfwF KYB8k7SEOOpXRrdj7Dy4/aMrxZgMW1QVDC47IA/4q59MpZP2nkNDseDWRTq0Qq1Y XjLjjREdoy76O4OZYslI8H2+UHerbtX5cMDj9RJvtKF/PFGgRjkfK2nLAqfK2b4Y vldziMb1aAFhG4P1WQiX/VRznoUWUCKVC8UkyG2H3ccl+VVCArQ/XmMfbe/qfkCg +1lik3IBA9QptHuBzXywnHrKu4nvEhNl06cq1c/dAYpQYKr9fGrQM12nJcV5cYO0 FYEIH7oLlX/5FD3VYkxx1r4bs/MOjMqbSMa79Wr+9S1ZFlq/JPsCx98nzcafpTVc CwV0jQng/6wsMHyY/0ZN5u/rSWOVF/m+TKt34FSRKuYGZOhDx0e0qAnGXt1l1by5 NPI52w74Dpt3Ok+q/Nd4 =MUyS -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 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/96c3a404-b050-d6aa-59d3-0d1feaf9d91b%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
