Re: [qubes-users] qubes-mirage-firewall 0.4
On Sunday, 24 December 2017 16:24:37 UTC+2, donoban wrote: > On 12/24/2017 12:57 PM, Roy Bernat wrote: > > > > Hi > > > > Not seems to work for me . > > > > Ideas ? > > > > R > > > > Could you paste your 'qvm-prefs mirage-firewall' output? autostart D False backup_timestamp D debug - False default_dispvmD fedora-25-dvm default_user D user gateway D gateway6 D include_in_backupsD True installed_by_rpm D False ipD 10.137.0.33 ip6 D kernel- mirage-firewall kerneloptsD nopat klass D AppVM label - green mac D maxmem- 320 memory- 32 name - mirage-firewall netvm - sys-net provides_network - False qid - 33 qrexec_timeoutD 60 stubdom_mem U stubdom_xid D -1 template - fedora-26-minimal template_for_dispvms D False updateableD False uuid - 378b816e-b7bf-4ec3-a22a-03218cc433bd vcpus - 1 virt_mode - pv visible_gateway D 10.137.0.5 visible_gateway6 D visible_ipD 10.137.0.33 visible_ip6 D visible_netmask D 255.255.255.255 xid D -1 -- 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/bb396586-68e8-4853-a21b-7e189a0fc6a0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Appvm - memory
What I did is to add meminfo-writer that helps R -- 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/1288dcb0-d40a-43de-97ad-2b24dbb94adb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: VM Logins? Qubes 4.0rc3
If anyone else happens across this post: it appears the issue resolved itself (annoying when that happens, but oh well). It has presented in isolated pockets here-and-there since, the solution seems to be simply to power down the VM and try again. I also tweaked the settings so that only my sys-net and sys-USB VMs power up at first, I think that helps. The system doesn't get overloaded powering up a ton of VMs at once and seems to avoid the login issue. -- 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/004f5c64-294b-42ad-ac4f-d2f6f80d1d6b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Which 3.2 VMs to backup and for eventual 4.0 migration?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2017-12-24 19:08, yreb...@riseup.net wrote: > On 2017-12-23 11:11, Andrew David Wong wrote: >> On 2017-12-22 21:30, yreb...@riseup.net wrote: >>> On 2017-12-22 09:50, awokd wrote: On Fri, December 22, 2017 10:29 am, 'Tom Zander' via qubes-users wrote: > On Friday, 22 December 2017 02:42:57 CET yreb...@riseup.net > wrote: > >> assuming 4.0 is going to come out of the box with like >> Debian 9 and Fed 26? If you have room for it, back up everything! You can restore selectively later. >>> >>> thanks for the two replies, *However, neither gets to the gist >>> of my inquiry. Namely, which VMs am I supposed to be backing >>> up, >> >> You should back up every VM that contains data that you don't >> want to lose and can't replace. For most people, this means >> backing up every VM that contains things like documents, emails, >> photos, and videos. If you're short on space, it's not necessary >> to make backups of things that you know you'll be able to >> download easily again later (e.g., an unmodified TemplateVM). >> >>> Dom0 (which for some reason is over *500GB!) , hence I can't >>> backup "everything" even with a 2GB internal HD that I'm >>> trying to use >>> >> >> For most users, the main reason to back up dom0 is because that's >> where your dom0 user settings are stored. Normally, dom0 should >> not be that large, since you're only backing up the home >> directory. (You're using qvm-backup, right?) It sounds like you >> didn't expect it to be that large, so if there's not enough data >> in your home directory to account for it, check /var/tmp to see >> if you have a lot of partial restores taking up space. >> >>> I was thinking of skipping the 1 large offline AppVM where I >>> keep old photos, and did, so why did the Templates and Dom0 >>> come out to such a *Huge filesize, what would be typical ??? >>> From what your saying can I skip the Debian 8 Template, I have 2 AppVMs >>> and the Whonix stuff based on it I guess >>> > > > What is the default backup location from the GUI VM Manager It looks like the default is dom0. (Not sure, since I usually use the CLI, but I just tried going through the first few prompts in the GUI, and the default target was dom0.) > : I'm wondering now where I backed up my 300GB VM with old photos > back in May 2017 maybe that has something to do with the size > problem I'm encountering .. I probably wanna know where is it > anyway. I don't think I thought to change it from the default > setting, as I was new, and still am to what behaviour to expect > from Qubes systems ...and just let it back up where-ever the > default would be. > Yeah, it sound like you probably have ~500GB worth of backups in your dom0 home directory. You'll probably want to move those to another location before backing up dom0 (if you don't want to include those backups in your backup). > PS: keeping in mind, my perhaps, *only reason to be attempting a > backup would be to migrate it to 4.0 , I recommend making frequent backups (so that you don't lose data in an unexpected hardware or software malfunction), not just for migration. > so I *still want to back up Templates and Dom0?? That really depends on you. The answer will be different for different people. The main consideration is whether you have any data in dom0's home or in your TemplateVMs that you don't want to lose. Personally, I would back everything up just in case. You may not end up using it all in the migration process, but the problem is that you may not be entirely certain, before that process is complete, which data you will want to have migrated. In hindsight, you may wish you had migrated more. You can always exclude data you have, but you can't include data you no longer have. > Most of my AppVMs are just for browsing the web and the 15 > different times, I've reset up firefox with perhaps a few > downloads . considering that would there be some reason to > backup AppVMs . > > > Maybe the only VM that matters *is the 300GB AppVM with photos in > it , that stays offline ? > Again, it really just depends on what data you want to keep. Given your uncertainty, I highly recommend backing up *everything* so that you don't regret losing something later. It sounds like you're talking about less than a terabyte in total, which is a pretty small amount of data relative to hard drive capacities these days. Better safe than sorry! > > re: /var/tmp is dom0 I am unable to cut and paste from dom0 > what I see is /dev/mapper/qubes_dom0-root 952848292 > 780151168(used) 123272164(available) 87% / and various others > smaller directories ; I don't know what a "partial restore" > would look like ; I never touch dom0 :0 > It would be some large directories in /var/tmp that start with `restore_`. But it sounds like that's not your problem. Pretty sure
Re: [qubes-users] Which 3.2 VMs to backup and for eventual 4.0 migration?
On 2017-12-23 11:11, Andrew David Wong wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 2017-12-22 21:30, yreb...@riseup.net wrote: >> On 2017-12-22 09:50, awokd wrote: >>> On Fri, December 22, 2017 10:29 am, 'Tom Zander' via qubes-users >>> wrote: On Friday, 22 December 2017 02:42:57 CET yreb...@riseup.net wrote: > assuming 4.0 is going to come out of the box with like Debian > 9 and Fed 26? >>> >>> If you have room for it, back up everything! You can restore >>> selectively later. >> >> thanks for the two replies, *However, neither gets to the gist of >> my inquiry. Namely, which VMs am I supposed to be backing up, > > You should back up every VM that contains data that you don't want to > lose and can't replace. For most people, this means backing up every > VM that contains things like documents, emails, photos, and videos. If > you're short on space, it's not necessary to make backups of things > that you know you'll be able to download easily again later (e.g., an > unmodified TemplateVM). > >> Dom0 (which for some reason is over *500GB!) , hence I can't >> backup "everything" even with a 2GB internal HD that I'm trying to >> use >> > > For most users, the main reason to back up dom0 is because that's > where your dom0 user settings are stored. Normally, dom0 should not be > that large, since you're only backing up the home directory. (You're > using qvm-backup, right?) It sounds like you didn't expect it to be > that large, so if there's not enough data in your home directory to > account for it, check /var/tmp to see if you have a lot of partial > restores taking up space. > >> I was thinking of skipping the 1 large offline AppVM where I keep >> old photos, and did, so why did the Templates and Dom0 come out >> to such a *Huge filesize, what would be typical ??? >> >>> From what your saying can I skip the Debian 8 Template, I have 2 >>> AppVMs >> and the Whonix stuff based on it I guess >> > > - -- > Andrew David Wong (Axon) What is the default backup location from the GUI VM Manager : I'm wondering now where I backed up my 300GB VM with old photos back in May 2017 maybe that has something to do with the size problem I'm encountering .. I probably wanna know where is it anyway. I don't think I thought to change it from the default setting, as I was new, and still am to what behaviour to expect from Qubes systems ...and just let it back up where-ever the default would be. PS: keeping in mind, my perhaps, *only reason to be attempting a backup would be to migrate it to 4.0 , so I *still want to back up Templates and Dom0?? Most of my AppVMs are just for browsing the web and the 15 different times, I've reset up firefox with perhaps a few downloads . considering that would there be some reason to backup AppVMs . Maybe the only VM that matters *is the 300GB AppVM with photos in it , that stays offline ? re: /var/tmp is dom0 I am unable to cut and paste from dom0 what I see is /dev/mapper/qubes_dom0-root 952848292 780151168(used) 123272164(available) 87% / and various others smaller directories ; I don't know what a "partial restore" would look like ; I never touch dom0 :0 -- cc: the user group -- -- 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/04a90bcb398de37dce6a3d3ba4d83320%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Password security/disposable vm security
Okay so I read all of that lol, and I understood it all but what if there was an e-mail client that used the browser method? You get logged in to all your emails without retrieving anything then switch to cookie authentication and forget the password, that way when the zero-day happens you only lose your cookie which is probably not as powerful as the actual password(ie I dont think you can change your password with just the cookie) plus the zero day can't "permanently" compromise thunderbird cause you opened it in a disposable , just only after this odd login method over and over again =p. Maybe that's overdoing it butI don't want to change my passwords ever so laziness commands me to want such a thing XD. -- 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/08bc87f4-c999-47d0-ac60-5c1f6aa450b0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] pools, how to use
On Sunday, 24 December 2017 02:09:54 CET Marek Marczykowski-Górecki wrote: > > sudo lvcreate -L 390.5g -n data Slow > > You need yo create those as thin pools, not standard volumes. For > example this way: > lvcreate -L 37g --thinpool systems qubes_dom0 Thanks, that fixed it :-) It took some more puzzling and I now have some VMs on LVM pools instead of everything as huge files in my dom0 filesystem. Great success. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel -- 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/2149218.s4zhisSmft%40strawberry. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part.
Re: [qubes-users] Appvm - memory
On 12/24/2017 06:56 AM, Roy Bernat wrote: Hi All , using qubes 4rc3 ( 16GB i7 7500 ) . the appvm is based on fedora26. i saw something weird, i put min memory 800, max mem 8000 , 4 cpu . and for some reason the memory is stuck on 3742 always. This cause everything to be very very slow when i add more apps . Any ideas ? R This sounds like Issue #3265. Workaround from dom0 is: sudo systemctl restart qubes-qmemman.service Repeat every so often as needed... -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To 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/5e9ed73d-114f-5ab5-3c13-4a55f24c441d%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Anyway to boot into only dom0 (4.0rc3)/sys-firewall stuck at boot
On 12/24/2017 04:04 AM, Kushal Das wrote: Hi, My sys-firwall is stuck at the boot time (with no limit) 4.0rc3 (updated). Is there anyway to boot into dom0 without starting any other vm? Then I can remove and create the sys-firewall vm again (or if there is any easy way to recreate the vm). My primary Qubes laptop is not usable state thanks to this issue. Any tips to solve this will be a big help. Kushal What worked for me is simply disable "Start on boot" for sys-net and sys-firewall. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To 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/87988906-150e-9279-d783-e0083d1aa9f0%40posteo.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes 4.0 rc3 Windows ISO issues
I have used Qubes 3.2 in the past with Windows HVM without any problems.
I setup my Windows Standalone but having issues getting the system to boot with
the iso. It is not even getting to the boot screen.
When I start with the iso I get the error msg:
Got empty response from qubesd. See journalctl in dom0 for details.
Any advice how to troubleshoot this? I copied part of the log file below and
hope this can help. I am just not savy enough to understand the details.
Dec 24 16:35:19 dom0 qubesd[13425]: File
"/usr/lib/python3.5/site-packages/jinja2/environment.py", line 989, in render
Dec 24 16:35:19 dom0 qubesd[13425]: return
self.environment.handle_exception(exc_info, True)
Dec 24 16:35:19 dom0 qubesd[13425]: File
"/usr/lib/python3.5/site-packages/jinja2/environment.py", line 754, in
handle_exception
Dec 24 16:35:19 dom0 qubesd[13425]: reraise(exc_type, exc_value, tb)
Dec 24 16:35:19 dom0 qubesd[13425]: File
"/usr/lib/python3.5/site-packages/jinja2/_compat.py", line 37, in reraise
Dec 24 16:35:19 dom0 qubesd[13425]: raise value.with_traceback(tb)
Dec 24 16:35:19 dom0 qubesd[13425]: File
"/usr/share/qubes/templates/libvirt/xen.xml", line 93, in top-level template
code
Dec 24 16:35:19 dom0 qubesd[13425]: {% block devices %}
Dec 24 16:35:19 dom0 qubesd[13425]: File
"/usr/share/qubes/templates/libvirt/xen.xml", line 135, in block "devices"
Dec 24 16:35:19 dom0 qubesd[13425]: {% include 'libvirt/devices/block.xml'
%}
Dec 24 16:35:19 dom0 qubesd[13425]: File
"/usr/share/qubes/templates/libvirt/devices/block.xml", line 3, in top-level
template code
Dec 24 16:35:19 dom0 qubesd[13425]:
Dec 24 16:35:19 dom0 qubesd[13425]: jinja2.exceptions.UndefinedError:
'qubes.devices.UnknownDevice object' has no attribute 'device_node'
Dec 24 16:35:41 dom0 qmemman.daemon.algo[13453]:
balance_when_enough_memory(xen_free_memory=648227590,
total_mem_pref=2502710144.0, total_available_
Dec 24 16:35:41 dom0 qmemman.systemstate[13453]: stat: dom '0' act=6837416528
pref=1600066022.4
Dec 24 16:35:41 dom0 qmemman.systemstate[13453]: stat: dom '7' act=3977183232
pref=1145540198.4
Dec 24 16:35:41 dom0 qmemman.systemstate[13453]: stat: dom '9' act=2241183744
pref=461473792.0
Dec 24 16:35:41 dom0 qmemman.systemstate[13453]: stat: dom '3' act=1879252992
pref=441170329.6
Dec 24 16:35:41 dom0 qmemman.systemstate[13453]: stat: xenfree=700656390
memset_reqs=[('9', 2137900888), ('0', 7412734221), ('3', 2043839662)]
Dec 24 16:35:41 dom0 qmemman.systemstate[13453]: mem-set domain 9 to 2137900888
Dec 24 16:35:41 dom0 qmemman.systemstate[13453]: mem-set domain 0 to 7412734221
Dec 24 16:35:42 dom0 qmemman.systemstate[13453]: dom '9' didnt react to memory
request (holds 2241183744, requested balloon down to 2137900888)
Dec 24 16:35:42 dom0 qmemman.systemstate[13453]: mem-set domain 3 to 1952162889
--
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/d7317554-7bdd-4a08-ab82-89e26eb75f24%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Anyway to boot into only dom0 (4.0rc3)/sys-firewall stuck at boot
On Sun, Dec 24, 2017 at 3:14 PM, awokd wrote: > > It's not very elegant but this should work: > > Boot from your Qubes install media > Troubleshooting > Rescue a Qubes system > 1 > Enter > chroot /mnt/sysimage > nano /var/lib/qubes/qubes.xml > look for the line with name="sys-net", it will probably start with QubesNetVm > change name="sys-net" to name="sys-net2" > ctrl-x, y to save changes, Enter > exit > reboot > remove Qubes install media > boot into Qubes normally Did the same by just changing the sys-firewall vm name in qubes.xml to sys-firewall2, which caused qubesd failure. That helped to boot into dom0 super fast. After that had to keep trying different combinatin to get qubesd service to start again, and later removed and recreated the sys-firewall vm. Thanks a lot for the tips. I am not exactly sure why I am getting into this pain again and again :( For now, I updated dom0 with the packages from latest testing. Let us see how well those work. Kushal -- Staff, Freedom of the Press Foundation CPython Core Developer Director, Python Software Foundation https://kushaldas.in -- 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/CAAzeMbxFMq7Jck-Wi9eVW-PCOdK%2BMJQYn6--L3-kvBBMZ5ZKJw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] qubes-mirage-firewall 0.4
On 12/24/2017 12:57 PM, Roy Bernat wrote: > > Hi > > Not seems to work for me . > > Ideas ? > > R > Could you paste your 'qvm-prefs mirage-firewall' output? -- 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/1e80067c-1dba-e6ef-22a2-ba42180655b7%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: How to hide all except one USB controller?
Actually, having a malicious hardware attached at boot time is something hard to defend. Even if Xen does not attach the hardware to dom0, there is some pre-Xen phase of boot – BIOS/UEFI. Qubes cannot affect this phase of boot. If you have attached a malicious device that for example pretends to be a USB keyboard, it can control the computer. It can also try to provide another boot medium or to exploit a vulnerability (e.g., some FS parsing vulnerability in UEFI). So, I advise some Qubes-unrelated mitigations: * If possible, avoid having untrusted devices connected at boot. * Check your boot medium options in BIOS config. * Set a BIOS password. Even if it can be bypassed by anyone with physical access, your malicious device is unlikely to take a screwdriver and disassembly your computer. :) That's not to say that Qubes-related mitigations are useless. They are just not enough when you are concerned about boot time. -- 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/bb4a5f98-9605-4b15-b5c8-8cd10d574512%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] qubes-mirage-firewall 0.4
On Saturday, 23 December 2017 11:23:39 UTC+2, Reynir Björnsson wrote:
> Hi,
>
> On Friday, 22 December 2017 22:59:24 UTC+1, Roy Bernat wrote:
> > On Friday, 22 December 2017 23:51:29 UTC+2, donoban wrote:
> > > >Hi All
> > > >
> > > >i tried to install mirage-firewall followed by the Readme . and didn't
> > > >succeed
> > > >to run the mirage firewall .
> > > >
> > > >error : libxenlight failed to create new domain log
> > > >
> > > >2017-12-22 19:13:01.320+: libxl:
> > > >libxl_device.c:1235:device_hotplug_child_death_cb: script: Device
> > > >/dev/mapper/snapshot-fd01:25956374-fd01:25956356-fd01:26346316 does not
> > > >exists error
> > > >
> > > >any help ?
> > >
> > > Do you get this when you try to start your mirage vm? Could you detail
> > > how did you create it?
> >
> > Followed the Readme . put the files inside the /var/lib/qubes/vm-kernels/
> > and create app vm 32 MB _ 1cpu choose the the mirage kernel . and trying
> > to start .
> >
> > Am i doing somethng wrong ?
> >
> > i am using qubes 4 rc3
> >
> > R
>
> I have been using the following script to create mirage qubes on R4-rc3.
>
> setpref () {
> qvm-prefs --set "$vm_name" "$1" "$2"
> }
>
> qvm-create --label "$color" "$vm_name"
> setpref virt_mode pv
> setpref kernel "$kernel"
> setpref kernelopts ""
> setpref memory "$memory"
> setpref maxmem "$memory"
> setpref vcpus 1
Hi
Not seems to work for me .
Ideas ?
R
--
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/cac219ab-eead-4170-9c68-531dbe858ce7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] Appvm - memory
Hi All , using qubes 4rc3 ( 16GB i7 7500 ) . the appvm is based on fedora26. i saw something weird, i put min memory 800, max mem 8000 , 4 cpu . and for some reason the memory is stuck on 3742 always. This cause everything to be very very slow when i add more apps . Any ideas ? R -- 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/38e84b06-a92c-47b9-b83f-9ff29c92296e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] 3.2.1 / An updated 3.2 iso?
On Sun, December 24, 2017 9:47 am, Frédéric Pierret (fepitre) wrote: > Hi, I have also some free time (holidays!), as I have already prepared > updated ISO for myself, I will give you some help on it. Thanks! I'll ping you off list. -- 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/b54b7463a8ebe851f4722f7c574f1226.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] 3.2.1 / An updated 3.2 iso?
Le samedi 23 décembre 2017 23:57:25 UTC+1, awokd a écrit : > On Sat, December 23, 2017 10:14 pm, "Marek Marczykowski-Górecki" wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > > > On Sat, Dec 23, 2017 at 07:09:22AM -, awokd wrote: > > > > > Just qubes-src/installer-qubes-os/conf/comps-qubes.xml should be > > enough... Oh, I see you've changed group name. Then you need to update it > > in qubes-src/installer-qubes-os/conf/qubes-kickstart.cfg. I think the > > better solution would be to name it just "debian", to avoid this problem > > in the future. > OK. > > >> Hypervisor command line is just "placeholder"; this caused dom0 to > >> consume most of my RAM. > > > > On the installed system, or installer itself? > > On the post-installed system. > > >> Good news is dom0 and the qubes are all on Linux > >> 4.9.56-21.pvops.qubes.x86_64. Haven't done any testing past that. Will > >> try install on a UEFI Intel later. > >> > >> For future reference, is it possible to "make -j4 qubes", and/or to > >> make each component in the order given in "make help" instead of my all > >> or nothing approach? > > > > "make -j4 qubes" would not work, because of very primitive dependency > > tracking in qubes-builder. But you can execute make with list of components > > directly (copy&paste from make help). Then if something fails, retry > > starting from that failed component. > > > >> Also, should I open a qubes-issue to track this build? > >> > > > > Some tracking ticket for Qubes OS 3.2.1 related tasks would be useful. > > https://github.com/QubesOS/qubes-issues/issues/3426 > > > Something even more useful would be, if you could open pull requests > > with the changes mentioned below, referencing that ticket (add > > QubesOS/qubes-issues#... to the comment). Then we'll have nice summary > > about the state in that ticket. > > > > Thanks! > > Thank you too, will update the issue with above and some more testing notes. Hi, I have also some free time (holidays!), as I have already prepared updated ISO for myself, I will give you some help on 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/12337fef-2d0f-42ee-ac08-f12a269009bd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Anyway to boot into only dom0 (4.0rc3)/sys-firewall stuck at boot
On Sun, December 24, 2017 9:04 am, Kushal Das wrote: > Hi, > > > My sys-firwall is stuck at the boot time (with no limit) 4.0rc3 > (updated). Is there anyway to boot > into dom0 without starting any other vm? Then I can remove and create the > sys-firewall vm again (or if there is any easy way to recreate the vm). My > primary Qubes laptop is not usable state thanks to this issue. Any tips to > solve this will be a big help. It's not very elegant but this should work: Boot from your Qubes install media Troubleshooting Rescue a Qubes system 1 Enter chroot /mnt/sysimage nano /var/lib/qubes/qubes.xml look for the line with name="sys-net", it will probably start with QubesNetVm change name="sys-net" to name="sys-net2" ctrl-x, y to save changes, Enter exit reboot remove Qubes install media boot into Qubes normally start a dom0 terminal nano /var/lib/qubes/qubes.xml go through that same line again and delete the "2" off the end of "sys-net". it will have been added in multiple places automatically so make sure to review the entire line and delete the "2" anywhere it got added ctrl-x, y to save changes, Enter you should now be in dom0 with no started VMs -- 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/f2add896dedbe6521067c83c67dcf196.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Anyway to boot into only dom0 (4.0rc3)/sys-firewall stuck at boot
Hi, My sys-firwall is stuck at the boot time (with no limit) 4.0rc3 (updated). Is there anyway to boot into dom0 without starting any other vm? Then I can remove and create the sys-firewall vm again (or if there is any easy way to recreate the vm). My primary Qubes laptop is not usable state thanks to this issue. Any tips to solve this will be a big help. Kushal -- Staff, Freedom of the Press Foundation CPython Core Developer Director, Python Software Foundation https://kushaldas.in -- 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/CAAzeMbzUuJtGmS7RokDypOA3WJhU9UgqpDDgbSH6oLLH0w227g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Password security/disposable vm security
> "there is absolutely no point in not allowing e.g. Thunderbird to remember > the password – if it got compromised it would just steal it the next time I > manually enter it" Correct! > So this was written 6 years ago but it's the latest one I think. > > Can't we just create disposable thunderbirds to protect the password? > Or is disposable not true security? I mean maybe a custom thunderbird would > be needed so it never used the password again/instantaneously forgets it > after login >.> no, this is not possible. let me try to explain: This is going to be long thing, i hope anyone will read it, i was quite inspired; qubes is A-W-E-S-O-M-E-!-!-! the main reason is that you want to be able to read your mails, so you can't just drop/delete/forget every received mail on shutdown. you also can't drop/forget/don't store the password after login because the way any email work is: login->check if there are new mails->download->logout and if you keep it open like me so that it check for new mails every 10 minutes it can't work. websites with a login works in a different way: you fill the password and if it is correct they give you a cookie that your browser store and automatically give back to website every time you open. as you can see if you want to be logged in a moment of time you have to present to the remote side some kind of "secret thing" in that moment of time. is not that "you login once and the remote side automagically know that you are logged". so for the whole time you use the service you must keep in memory a secret to prove that you are logged. So where is the difference between Qubes and a normal os? how Qubes improve the security? let's think about a normal windows/linux computer: you have many programs and every program can control the whole pc. yes, there is admin vs not admin but on windows this means that a not admin process can't mess with admin processes or can't write in c:\programs or c:\windows. but this is useless! a virus can do all the damage it wants also running as not admin; it can: -delete all your files (cryptolocker) -run at boot (persistence) -spy you from mic/webcam -steal/upload all your files in internet -keylogging all what you write -steal saved passwords for me this is comparable to "full control of the pc" the problem with this model is that any single exe that you open can do pretty much what it want, and you can only hope/hava a bit of trust that it will not do it. in such security model it might be good not store passwords because when you will get a virus it will steal instantly all your saved password (bad). while if you don't save them it will only steal the one that you will write while the virus is present for example mail password because you use it often. so if we suppose that antivirus delete it after a few days you can hope that you have used only a few passwords on the compromised pc, and not all your passwords. TL;DR: any program you open/have opened in the past might have read/stealed all your mails/passwords NOW QUBES OS: On qubes your pc is splitted in more parts, every part works the way i said above (in fact they are normal windows/linux os) and is isolated. the only (important) difference is that only home in linux and c:\users in windows is preserved if you reboot; this is good because it limits the places in which a virus can hide (but still there is persistence=run at boot). suppose that you get a virus, downloaded from your browser. your mail is safe because it runs in another vm. simple, isn't? same for every other action you can do on your pc: play games, reading documents, ... because all these actions happens in a different vm, not in the mail vm. now suppose that you get a virus exactly the mail vm: the first question is how this can happen? it's not that virus pop up automagically, most of the time is the user that open them. so how can you open a virus from the email? you can open an attachment or a link, thats all you can do to open a virus from email. but on qubes this should not be possible because you should not open attachments and links in the mail vm, but in a disposable vm! (here is where the disposable thing became useful!!!) you can also automate this, so you can't forget to open a link in dispvm. if the attachment was something bad you simply don't care, close dispvm and virus is gone. but sometimes (smaller that always!) you need to store attachments, because they are work documents, photos, or something important. but again mail can't be compromised because you save photos and documents in work vm or somewhere different. the final question is: can mail vm be compromised? yes, but since the user can't be tricked to open something bad in the mail vm the only thing left is a zeroday: some bug in thunderbird that when it receive the bad email it is instantly compromised because *for example* the bad guy send 500 attachments and thunderbird can manage only up to 255 attachments, and this thing lead to code exec
Re: [qubes-users] Re: Duplicate MAC address error
On Fri, Dec 22, 2017 at 4:18 PM, Holger Levsen wrote: > On Fri, Dec 22, 2017 at 02:34:41AM -0800, Reynir Björnsson wrote: >> It may be a coincidence, but when it happened to me I got sys-net running by >> shutting down sys-whonix first. I've since disabled sys-whonix and haven't >> had the issue again, although I haven't been rebooting much since. > > I believe it's coincidence. I've had this several times, where I couldnt > restart sys-net (after it crashed) and then after shutting down some > random VMs I could start sys-net again... > On Friday sys-firewall showed the same error when I tried to restart the vm. After that I tried to restart the system, and now it gets stuck in the boot screen trying to start sys-firewall :( Any tips on how to get out of this mess? Kushal -- Staff, Freedom of the Press Foundation CPython Core Developer Director, Python Software Foundation https://kushaldas.in -- 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/CAAzeMbxhaMOMiFK3ZDcxi%3D4C9q3hfL%3DO-gN5KXvpgVQiy50ETw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Verifying Install Files: Confused About How to Verify R3 ISO file
> Thanks, Chris! I got one step further: successfully verifying the ISO > signature with the Qubes OS Release 3 Signing Key. Should I still use > the Qubes Master Signing Key to verify that my Qubes OS Release 3 > Signing Key is good? If so, how to I use gpg4win to do this? > > Kyle yes, you should check it. Qubes R3 key should be signed with the masterkey. this means that: 1-if you checked that the master key is original 2-and you see that R3 key is signed (certified) by the masterkey it means that also the R3 key is original without any other check (*because you trust the team behind qubes) to do this check using gpg4win you can: -from kleopatra: double click on the key, click certifications, and check that "qubes master key" is listed WITH THE CORRECT FINGERPRINT (the name is useless as anyone can generate a key called in that way, but noone can generate it with the correct fingerprint) -from gpa: click detailed than signatures; check that the master key is listed. the final question is how do you know that the master key is the original one? you can check these websites, all of them has a copy of the masterkey and all of them are https. here you can find the fingerprint: https://github.com/rootkovska/rootkovska.github.io/tree/master/keys https://keys.qubes-os.org/keys/ https://www.youtube.com/watch?v=S0TVw7U3MkE (near the end 46:51) https://hyperelliptic.org/PSC/slides/psc2015_qubesos.pdf (last slide) https://twitter.com/rootkovska/status/496976187491876864 all this might seem complex but in the end it means: -get masterkey and check that is original (get only once, but you can verify that fingerprint on your pc match the one on website many times in different moments) -get (only once) the r3/4 key and check that is signed (certified) by the masterkey, this means more or less: "me the masterkey, say that that this gpg key is the only real r3/4 key" -get the signature and the signed file and verify the signature: it should say "good" and should also say "signed using [fingerprint of] r3/r4 key" (the one that we trust because above points) i hope that i have not confused you more than you were before :) -- 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/31764a18-5989-8999-f7ec-1f75d2d55005%40posteo.net. For more options, visit https://groups.google.com/d/optout.
