[qubes-users] Qubes-HCL-ASUSTeK_COMPUTER_INC_-N550JK-20180911-131707
TNT BOM BOM -- 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/0d03b782-cc5d-ecc0-bee2-c4c1a720b77b%40riseup.net. For more options, visit https://groups.google.com/d/optout. Qubes-HCL-ASUSTeK_COMPUTER_INC_-N550JK-20180911-131707.yml Description: application/yaml
[qubes-users] Re: "Introducing the Qubes U2F Proxy" by Wojtek Porczyk
Em terça-feira, 11 de setembro de 2018 13:38:09 UTC-3, Brendan Hoar escreveu: > On Tuesday, September 11, 2018 at 5:18:49 AM UTC-4, Andrew David Wong wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > Dear Qubes Community, > > > > Wojtek Porczyk has just published a new article titled "Introducing > > the Qubes U2F Proxy." The article is available on the Qubes website: > > > > https://www.qubes-os.org/news/2018/09/11/qubes-u2f-proxy/ > > *FANTASTIC*. Thanks, this is very useful. > > Brendan Good news, thank you. But sudo dnf install qubes-u2f results not found on fedora-28 repo. Please check. -- 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/b375a265-e028-4afc-91a9-7d1ef67e271a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: "Introducing the Qubes U2F Proxy" by Wojtek Porczyk
On 9/12/18 4:33 PM, Sergio Matta wrote: > Em terça-feira, 11 de setembro de 2018 13:38:09 UTC-3, Brendan Hoar escreveu: >> On Tuesday, September 11, 2018 at 5:18:49 AM UTC-4, Andrew David Wong wrote: >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA512 >>> >>> Dear Qubes Community, >>> >>> Wojtek Porczyk has just published a new article titled "Introducing >>> the Qubes U2F Proxy." The article is available on the Qubes website: >>> >>> https://www.qubes-os.org/news/2018/09/11/qubes-u2f-proxy/ >> >> *FANTASTIC*. Thanks, this is very useful. >> >> Brendan > Good news, thank you. But sudo dnf install qubes-u2f results not found on > fedora-28 repo. Please check. It is in the current-testing repo: dnf --enablerepo=qubes-vm-r4.0-current-testing install qubes-u2f (same goes for dom0 - only the current testing repo name is different) -- 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/469b5f1b-ba11-30e8-d912-b970b858ee12%40maa.bz. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: debian-9 template
On Tuesday, September 11, 2018 at 5:06:49 PM UTC-4, awokd wrote: > On Tue, September 11, 2018 2:49 pm, John Maher wrote: > > On Tuesday, September 11, 2018 at 9:02:53 AM UTC-4, awokd wrote: > > > >> On Tue, September 11, 2018 12:27 pm, John Maher wrote: > >> > >>> On Tuesday, September 11, 2018 at 8:15:50 AM UTC-4, John Maher wrote: > >>> > >>> > On Tuesday, September 11, 2018 at 6:15:43 AM UTC-4, awokd wrote: > > >> > > > > I don't get it either, especially with a fresh install. Did you > > test before running any updates? If you enable debug mode, any > > hints in the console or related VM log files? > > awokd, I did test before running updates. The template definitely > starts out appearing (or having?) no applications. > > I don't know how to enable debug mode, and I don't see anything in > the official documentation. I'm also not familiar with the console, > unless you're referring to a dom0 terminal. Any guidance would be > wonderful. Thanks. > > > > John > > > >>> > >>> I decided to see if I could install the debian-8 template with > >>> different results from the debian-9 template. Sure enough, by default > >>> terminal if displayed as an available app under debian-8, and within > >>> debian-8 Qubes Settings there are plenty of expected apps in the > >>> Applications tab. I'll > >>> now try to upgrade debian-8 to debian-9 (using a different name) and > >>> see what I get. > >> > >> Same behaviour on a fresh install of 4.0, right? Try this in dom0: > >> > > > > Yes, this all started with a fresh install of 4.0 on new hardware. > > > > > >> > >> 1) qvm-run debian-9 gnome-terminal > >> > > > > output: > > > > > > Running 'gnome-terminal' on debian-9 > > > > > > Very odd behavior. I have never gotten a terminal windows when running > > the above command, but the time I ran the command in response to your > > suggestion I actually ended up with a terminal window! Subsequent > > attempts have resulted in no terminal window. > > Have you ever been able to update that debian-9 template? Maybe it's ok on > first boot but not the rest. > > > > > > > Waiting for /dev/xvdd device... > > mount: /dev/xvdd is write-protected, mounting read-only > > [5.836088] EXT4-fs (xvdd): mounting ext3 file system using the ext4 > > subsystem [5.840428] EXT4-fs (xvdd): mounted filesystem with ordered > > data mode. Opts: (null) switch_root: failed to mount moving /dev to > > /sysroot/dev: Invalid argument > > switch_root: forcing unmount of /dev > > switch_root: failed to mount moving /proc to /sysroot/proc: Invalid > > argument switch_root: forcing unmount of /proc > > switch_root: failed to mount moving /sys to /sysroot/sys: Invalid argument > > switch_root: forcing unmount of /sys > > switch_root: failed to mount moving /run to /sysroot/run: Invalid argument > > switch_root: forcing unmount of /run > > Mine shows this too- xvdd is the kernel. > > > Starting udev Kernel Device Manager... > > [6.243442] systemd-journald[205]: Received request to flush runtime > > journal from PID 1 [6.245978] qubesdb-daemon[264]: segfault at > > 76d6ff72eff8 ip 76d6ff51bf64 sp 76d6ff72f000 error 6 in > > ld-2.24.so[76d6ff512000+23000] [.[0;1;31mFAILED.[0m] Failed to start Qubes > > DB agent. > > See 'systemctl status qubes-db.service' for details. > > [.[0;32m OK .[0m] Started Flush Journal to Persistent Storage. > > Starting Load/Save Random Seed... > > Starting Init Qubes Services settings... > > [.[0;32m OK .[0m] Started udev Coldplug all Devices. > > [.[0;1;31mFAILED.[0m] Failed to start Load/Save Random Seed. > > See 'systemctl status systemd-random-seed.service' for details. > > > > > > . > > > > > > Starting Permit User Sessions... > > Starting /etc/rc.local Compatibility... > > Starting Qubes misc post-boot actions... > > [.[0;32m OK .[0m] Started Permit User Sessions. > > [.[0;32m OK .[0m] Started /etc/rc.local Compatibility. > > [9.738613] qrexec-agent[537]: segfault at 7a9f3456bff8 ip > > 7a9f34368355 sp 7a9f3456c000 error 6 in > > ld-2.24.so[7a9f34352000+23000] [.[0;32m OK .[0m] Started Serial Getty on > > hvc0. [.[0;32m OK .[0m] Started Getty on tty1. > > [.[0;32m OK .[0m] Reached target Login Prompts. > > [.[0;32m OK .[0m] Started Qubes misc post-boot actions. > > [.[0;32m OK .[0m] Reached target Multi-User System. > > Starting Update UTMP about System Runlevel Changes... > > [.[0;32m OK .[0m] Started Update UTMP about System Runlevel Changes. > > [9.928387] qrexec-agent[572]: segfault at 7a9f3456bff8 ip > > 7a9f34368355 sp 7a9f3456c000 error 6 in > > ld-2.24.so[7a9f34352000+23000] > > > > Debian GNU/Linux 9 localhost hvc0 > > > > > > localhost login: [ 14.777457] qrexec-fork-ser[703]: segfault at > > 71772c9d3ff8 ip 71772c7cd355 sp 71772c9d4000 error 6 in > > ld-2.24.so[71772c7b7000+23000] > > All those segfaults are probably causing your problems, b
Re: [qubes-users] Re: 0.1 BTC bugfix bounty
On 09/11/2018 03:52 PM, Thomas Papenkort wrote: > I have run into the same problem for backups when switching to qubes 4.0 and > found this workaround: > > # a file cannot be attached if it is in directory /var/lib/qubes/appvms, > so create a link first > ln /var/lib/qubes/appvms/$1/private.img /home/user/private.img > LOOPDEV=`sudo losetup -f` > sudo losetup $LOOPDEV /home/user/private.img > qvm-block attach -o frontend-dev=xvds -o read-only=true backupvm > dom0:$(basename "$LOOPDEV") > > [backup happens here] > > qvm-block detach backupvm dom0:$(basename "$LOOPDEV") > sudo losetup -d $LOOPDEV > rm /home/user/private.img Thank you a lot for your help! I got it to work finally. In fact, it's a combination of the two details: - get the .img file to another path. It can't stay in "appvms/VMNAME/private.img". Get a hardlink elsewhere, or rename "appvms" (and "vm-templates"), both are fine. - you still have to delete the .qubes-exclude-block-devices file, if you renamed "appvms" or the path to your hardlink contains this file. I'm happy to finally have it figured out, so I don't need to compromise security for backups (regular Linux, or network in DOM0, or booting something else for backups etc). Thomas, please drop me a Bitcoin address. Cheers, Stickstoff -- 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/7c5edf88-544f-a42d-0466-5ca0fc26fddc%40posteo.de. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Re: 0.1 BTC bugfix bounty
On 09/12/2018 04:51 PM, Stickstoff wrote:
On 09/11/2018 03:52 PM, Thomas Papenkort wrote:
I have run into the same problem for backups when switching to qubes 4.0 and
found this workaround:
# a file cannot be attached if it is in directory /var/lib/qubes/appvms,
so create a link first
ln /var/lib/qubes/appvms/$1/private.img /home/user/private.img
LOOPDEV=`sudo losetup -f`
sudo losetup $LOOPDEV /home/user/private.img
qvm-block attach -o frontend-dev=xvds -o read-only=true backupvm dom0:$(basename
"$LOOPDEV")
[backup happens here]
qvm-block detach backupvm dom0:$(basename "$LOOPDEV")
sudo losetup -d $LOOPDEV
rm /home/user/private.img
Thank you a lot for your help!
I got it to work finally. In fact, it's a combination of the two details:
- get the .img file to another path. It can't stay in
"appvms/VMNAME/private.img". Get a hardlink elsewhere, or rename
"appvms" (and "vm-templates"), both are fine.
- you still have to delete the .qubes-exclude-block-devices file, if you
renamed "appvms" or the path to your hardlink contains this file.
Below in bash what I use since at least 4.0rc1.
Anyway what you're describing is considered a feature, not a bug (I
recall when it was introduced as part of a bug report I had made in the
beginning of 4.0rc1 about qvm-block not supporting files at all). I
think it was a udev rule one-liner checking the path back then.
I'd suggest creating a feature request for a force flag bypassing it and
maybe mention that you'd be willing to donate for that.
I'm not sure whether it's meant to be officially supported though as
they might go away from sparse files with the recent introduction of
qvm-pool etc. (wild guess).
KR
David
--
#createDomZeroLoopDeviceIfNecessary [dom0 path]
#returns: created loop device or previously used one (incl. /dev/); sets
a non-zero exit code, if no device could be created
#create a loop device from the given file path in dom0, if necessary (no
old one does exist)
function createDomZeroLoopDeviceIfNecessary {
local domZeroPath="$1"
#do we have a previously used device?
local oldDev="$(losetup -j "$domZeroPath" | grep -Eo '^/dev/loop[0-9]+')"
if [ -n "$oldDev" ] ; then
echo "$oldDev"
else
#no old device --> create a new one
#we use the exit code as ours
sudo losetup -f --show "$domZeroPath"
fi
}
#getVMDeviceNameForAttached [device in dom0] [VM]
#get the name for the device created in the given VM during execution of
the qvmBlockAttachFromDomZeroTo function
#returns: name of the attached device in the given VM (without the /dev/
prefix) or an empty String, if no such device exists (not attached anymore)
function getVMDeviceNameForAttached {
local dev="$1"
local vm="$2"
local regex="^dom0:$dev\s+.*\s+${vm}\s+\(.*frontend-dev=([a-z0-9]+).*\).*$"
#run the regex against qvm-block & return the result
qvm-block l | sed -r -n "s/$regex/\\1/p"
}
#qvmBlockAttachFromDomZeroTo [result] [source path in dom0 (must be a
file)] [target VM to attach the source path to] [optional: ro flag]
#[ro flag]: optional flag, that - if set to 1 - makes sure the file is
attached as read-only to the target VM
#returns: device created in the VM as the result variable or an empty
result variable in the case of errors
function qvmBlockAttachFromDomZeroTo {
local result="$1"
local path="$2"
local targetVM="$3"
local empty=""
local dev=""
local rwOption=""
[ $4 -eq 1 ] && rwOption="-o read-only=yes"
#default = error
eval $result="'$empty'"
#we need to create a pseudo file as Qubes 4.0rc1 will attempt to prevent
qvm-block usage for its private.img files
#hard links work to bypass that, but need to be on the same drive (/tmp
doesn't work)
local pfile="$DOM0_TEMP_DEV_PATH/$(echo "$path" | md5sum | cut -d " " -f1)"
ln "$file" "$pfile"
#unfortunately qvm-block l has issues for files, so we create a loop
device first and use that one
#also see: R3.0: qvm-block doesn't work well on files
(https://groups.google.com/forum/#!msg/qubes-users/IotETu-gsm4/FO2GOu5pBwAJ)
#for 4.0rc1 I'm not even sure whether it supports files...
dev="$(createDomZeroLoopDeviceIfNecessary "$pfile")"
[ $? -ne 0 ] && return
dev="${dev/\/dev\//}"
#run qvm-block
qvm-block a $rwOption "$targetVM" "dom0:${dev}"
[ $? -ne 0 ] && return
#get the return value and update the return var
lastAttached="$(getVMDeviceNameForAttached "$dev" "$targetVM")"
eval $result="'$lastAttached'"
}
--
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/7a79d289-656c-21fc-2c06-c1a91f7d6c97%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME
[qubes-users] wifi password storage
Dear All, Have been settling into my new qubes laptop and found that sys-net keeps my wifi password in plaintext in a file in a single directory (/rw/config/NM-system-connections) that survives reboot. Presumably as I add wifi networks such files will accumulate. This surprised me, since sys-net by design is untrusted and isolation is the whole point of qubes. If I understand right, when RandomMotelWifi corrupts my sys-net, the corruptors can then get onto almost any other wifi I've ever logged into. Is the idea that I should run different sys-net's to separate wifi's from each other, according to some scheme that I need to keep track of? Maybe, home on one, work on another and everything else on a third? Or is there a mechanism for storing certain wifi passwords in a vault VM? Perhaps I should sometimes use a disposable VM in place of sys-net? Or perhaps something else that I am missing? Maybe I just haven't internalized the qubes way. Thank you for any thoughts and recommendations, Daniel PS: VERY impressed with qubes---everything works out of the box. (thinkpad carbon X1 5th gen. Many thanks to the qubes team for ironing out the few difficulties that marmarek encountered back in Dec 2017 !) -- 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/CF1433E8-0C38-47ED-8F71-84EA21303896%40allcock.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] wifi password storage
On 9/12/18 6:53 PM, Daniel Allcock wrote: > Dear All, > > Have been settling into my new qubes laptop and found that sys-net keeps my > wifi password in plaintext in a file in a single directory > (/rw/config/NM-system-connections) that survives reboot. Presumably as I > add wifi networks such files will accumulate. This surprised me, since > sys-net by design is untrusted and isolation is the whole point of qubes. > If I understand right, when RandomMotelWifi corrupts my sys-net, > the corruptors can then get onto almost any other wifi I've ever logged into. Your reasoning is right, but defending contents of sys-net is *not* in the main scope of the Qubes project. It's even "written on the tin", as in "the default color for sys-net is red" and in all the documentation it is described as a sacrificial Qube, to protect -by isolation- the other Qubes. Still, the issue that you raise is true and sensible: an isolated WiFi password management could be a nice addition of functionality for Qubes. Moving the debate to an upper level, it could be argued that if you are so paranoid about security you should not connect to insecure WiFi networks altogether... But that would not be answering to your question ;) > Is the idea that I should run different sys-net's to separate wifi's from each > other, according to some scheme that I need to keep track of? Maybe, home > on one, work on another and everything else on a third? It can be done; please be aware that this would mean disconnecting and reconnecting the PCI device once you want to start a connection to another network, and this could easily become hard to manage. Furthermore, network connections are usually "architecturally orthogonal" to your Qubes (home, work, banking, etc.), in that you typically connect to the internet from all qubes at the same time, on any network that is available at the moment. You only typically isolate TOR traffic from the non-torified one. I'll throw in another option: what about using the PCI WiFi adapter only for "safe" networks, and using a separate external USB one (with a separate sys-net-unsecure Qube) for any unsecure connection, that you periodically purge of any WiFi settings? This way you could usb-proxy the adapter to the unsecure sys-net - I don't even know if it can be done, I only use Qubes on desktop workstations, but it may be easier to manage with existing tools than invent a full-blown NetworkManager secrets management system... > Thank you for any thoughts and recommendations, > Daniel Thank you for your contribution; bye -- Alex -- 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/91e378b1-5b58-ff5c-9a6e-692d0f965dfb%40gmx.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] wifi password storage
Thank you for your advice and quick reply, Alex. My question isn't just abstract security paranoia. Most wifi passwords don't really matter. But my university in its wisdom uses a one-per-user username/password combo for *everything*. So someone who gets my work wifi password can also change student grades and redirect my paycheck. (There is 2FA for some things, but still.) And I can't do anything about this policy. So I'd rather not have that particular password stored in a VM which qubes expects to be subverted. I don't think this is paranoia, just part of the data-flow thinking that qubes users are expected to do. I like your suggestion for a separate usb wifi device. Then when I want to connect at work I would just change the networking VM for sys-firewall from sys-net to sys-net-work. Would appreciate any pointers to docs helpful for actually doing this. (Haven't delved into the usb system yet.) And still open for suggestions from all, to my original broader question as well as the current how-to-protect-a-single-wifi-password question. Best, Daniel -- 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/1c9b03d0-662b-4c1e-95e2-118652e8ae4c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Starting a browser (brave, or chrome) in qubes as a different user (ease of management thing)
Hi! Long story short, I want to put browser into a separate user account inside qubes. I realize it is not exactly the "intended typical qubes arrangement" but it will make a certain workflow much easier for me, and hopefully would at least not degrade security (why should it, lol) So far what works: starting Chrome or Brave and getting them to bring up / display window su - browsuser brave What does not work: Audio and video playback (I need them) Audio and video works "as normal" when starting those browsers from normal user However, nothing good happens when I try it from alt user I have recognized it may be a pulse audio authentication issue, so I tried copying Pulse cookie from main "user" user to "browuser" user, to no avail. I'd rather not do a pulseaudio TCP socket, as suggested in some online tutorials, and not enable anonymous access to the unix socket (another suggestion "from the internets") Has anyone tried doing anything like that? Any suggestions on how to get sound "going" for a browser launched from an additional user in a Qubes VM? -- 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/22ca7722-93cf-4ddf-8d76-44b82a4bfa9f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] wifi password storage
I would do this without a separate network device. Create a clone of a clean (no saved passwords) sys-net. First set sys-net and sys-firewall to NOT autostart. Starting an appVM which uses them will start them first anyway. Create a shutdown script which... stop all appVMs stop sys-firewall update sys-firewall to use the insecure, general sys-net complete shut down Use this shutdown script for all shut downs. Then when you turn your machine on "not at work", it will be using the insecure sys-net by default...you won't accidentally expose your work wifi credentials. Startup at work will require running a script from dom0 to... stop all appVMs if any are running stop sys-firewall stop sys-net update sys-firewall to use work-sys-net start work-sys-net start sys-firewall start usual work appVMs All done without an additional network device Clear out any saved work wifi credentials in sys-net This is how I would approach this issue. On Wed, 12 Sep 2018 11:26:57 -0700 (PDT) daniel wrote: >Thank you for your advice and quick reply, Alex. > >My question isn't just abstract security paranoia. Most wifi passwords don't >really matter. >But my university in its wisdom uses a one-per-user username/password combo >for *everything*. >So someone who gets my work wifi password can also change student grades and >redirect >my paycheck. (There is 2FA for some things, but still.) And I can't do >anything about this policy. > >So I'd rather not have that particular password stored in a VM which qubes >expects to be subverted. >I don't think this is paranoia, just part of the data-flow thinking that qubes >users are expected to do. > >I like your suggestion for a separate usb wifi device. Then when I want to >connect at work I would >just change the networking VM for sys-firewall from sys-net to sys-net-work. >Would appreciate any >pointers to docs helpful for actually doing this. (Haven't delved into the >usb system yet.) > >And still open for suggestions from all, to my original broader question as >well as the current how-to-protect-a-single-wifi-password question. > >Best, >Daniel > -- 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/20180912144406.2bba3184%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] wifi password storage
Thank you very much Stuart. This feels like it is clearly the solution for now. So marking as complete even though I haven't actually implemented it yet. Impressed not only by qubes itself but also the help two strangers have offered. Though it may be just a noob opinion, it seems like a reasonable idea to have sys-net be disposable, so that every time you start it you know you are getting something clean. Inter-VM communication then needed to store credentials. Of course it is easy to say such things.! :) Daniel -- 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/b7e13bac-7a16-453e-b1b4-f4913aa3d215%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] wifi password storage
On 09/12/2018 03:44 PM, Stuart Perkins wrote: I would do this without a separate network device. Create a clone of a clean (no saved passwords) sys-net. First set sys-net and sys-firewall to NOT autostart. Starting an appVM which uses them will start them first anyway. Create a shutdown script which... stop all appVMs stop sys-firewall update sys-firewall to use the insecure, general sys-net complete shut down Use this shutdown script for all shut downs. Then when you turn your machine on "not at work", it will be using the insecure sys-net by default...you won't accidentally expose your work wifi credentials. Startup at work will require running a script from dom0 to... stop all appVMs if any are running stop sys-firewall stop sys-net update sys-firewall to use work-sys-net start work-sys-net start sys-firewall start usual work appVMs All done without an additional network device Clear out any saved work wifi credentials in sys-net This is how I would approach this issue. Its a decent suggestion. You could have versions of sys-net for home, work and public. However on R4.0 it isn't so complicated: you can keep all your dependent VMs running if you use 'qvm-run -u root sys-net "halt"'. Then when you start the other sys-net* and set sys-firewall's 'netvm' property to use it, the connection should be usable. Another alternative would be to configure a single sys-net with either dispVM or Qubes-VM-hardening so that neither passwords nor malware would be retained when sys-net is restarted. Then you could control wifi connections from a dom0 script. This would be like having a separate sys-net for each wifi connection, if you restart sys-net whenever the wifi connection was changed. -- 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/c62bcd60-7d83-124a-85ca-4b9c4930cc84%40posteo.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes SIEM Using SOF-ELK
I do not currently have hardware that supports Qubes, but I was wondering if anyone that does would consider checking out Sof-ELK? This is a really cool SIEM that would be useful to track all network traffic coming and going between your VMs. SOF-ELK® is a “big data analytics” platform focused on the typical needs of computer forensic investigators/analysts and information security operations personnel. The platform is a customized build of the open source ELK stack, consisting of the Elasticsearch storage and search engine, Logstash ingest and enrichment system, and the Kibana dashboard frontend. With a significant amount of customization and ongoing development, SOF-ELK® users can avoid the typically long and involved setup process the ELK stack requires. Instead, they can simply download the pre-built and ready-to-use SOF-ELK® virtual appliance that consumes various source data types (numerous log types as well as NetFlow), parsing out the most critical data and visualizing it on several stock dashboards. Advanced users can build visualizations the suit their own investigative or operational requirements, optionally contributing those back to the primary code repository. But if you send the Qubes logs via one of the supported pathways (syslog, RELP, Beats, at-rest files loaded to the filesystem), you could write (and PR!) parsers for those log formats to take advantage of this system. https://github.com/philhagen/sof-elk -- 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/8c052605-9fb0-43eb-ac88-6d813c94b241%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] wifi password storage
On Wed, September 12, 2018 8:39 pm, Chris Laprise wrote: > Another alternative would be to configure a single sys-net with either > dispVM or Qubes-VM-hardening so that neither passwords nor malware would be > retained when sys-net is restarted. Was going to suggest a dispVM as well, per https://www.qubes-os.org/doc/dispvm-customization/#using-static-disposable-vms-for-sys- . > Then you could control wifi > connections from a dom0 script. How would you do that? qvm-run some nmcli command(s), passing along the wifi credentials? -- 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/f5f003cb9eac7cb3e5d9b1cb2eae0cd2.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Touchpad problem
I have qubes 3.2 (R3.2) on a Panasonic Toughbook CF-31. My touchpad goes crazy some time after using the computer. Would this be a good idea (i8042.nomux=1 i8042.noloop=1) https://ubuntuforums.org/showthread.php?t=844968 If so, how can I do it on qubes? 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/5B99F5AB.3060506%40neomailbox.ch. For more options, visit https://groups.google.com/d/optout.
[qubes-users] application icons not displayed in panel in xenial
I created a template for Xenial. Things work well w/ the AppVM based on this, but there's one hitch: most of the icons for applications do not display in the panel. The odd thing is that the icons show just fine in the Applications launcher and in Whiskers. But on the desktop panel, they just show as a lock. It gets quite difficult to find windows after a bunch have been opened without icons to clue me in. Not sure what's causing this problem because evidently the .desktop files work fine for the launcher and Whiskers. Guy -- 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/a1e001f0-28d7-44ee-a2a9-0834a6c30906%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
