[qubes-users] Sub-menus using xfce4
I am trying to make a VM that is going to have a lot of applications. I would like to be able to put these applications into groups (sub-menus) in the main qubes menu using xfce4. I've looked at the xfce wiki[1] on working with their menus, tried everything they recommended and could not get it to work. If it is not possible in Qubes 3.2, would it be plausible in Qubes 4.0? [1] https://wiki.xfce.org/howto/customize-menu -- Respectfully, Sam Hentschel FD6A 2998 5301 B440 D26B 7040 69D1 CE58 6FA5 BB5A -- 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/20171025235332.GA993%40Personal-Email. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
[qubes-users] Making Your Own Sys-VMs
Hey all! I've been looking at changing all my VM templates to fedora minimal. I've gotten all my AppVMs moved over to templates based on fedora minimal. However, I'm still having some trouble making fedora minimal templates that will work for my NetVM, FirewallVM, and USBVM. For the NetVM specifically, I installed the driver and software that was stated on the Fedora Minimal page but it still doesn't register my wireless card. Anybody have what I need to get these templates ready for those system VMs? -- Respectfully, Sam Hentschel FD6A 2998 5301 B440 D26B 7040 69D1 CE58 6FA5 BB5A -- 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/20171011231049.GA961%40Personal-Email. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
Re: [qubes-users] Windows 7 HVM Install
On Mon, May 22, 2017 at 11:28:03PM -0400, Jean-Philippe Ouellet wrote: > On Mon, May 15, 2017 at 5:24 PM, Sam Hentschel <hentsche...@gmail.com> wrote: > > Hey all! > > > > Decided to try out making a windows 7 install just in case I needed it > > for school. > > > > I downloaded a 64-bit windows 7 enterprise iso and proceeded with the > > installation doing: > > > > $ qvm-create win7 --hvm --label green #as in the qubes-docs > > $ cp /var/lib/qubes/appvms/win7/win7.conf ~/ # to change xen to > > cirrus for graphics > > $ qvm-start --cdrom:dispXX:/home/user/Downloads/win7_sp1_64.iso > > --custom-config=win7.conf > > > > The first install went fine, I got it to boot up the first time and > > tried to load the windows tools: > > > > $ sudo qubes-dom0-update qubes-windows-tools > > $ qvm-start --custom-config=win7.conf --install-windows-tools > > > > However, something messed up and it wouldn't get passed the start up > > screen after that (I don't think it actually installed the windows tools > > as I didn't see the disk show up). I tried using all the combinations > > of commands I had for qvm-start before I gave up. I deleted it using > > qvm-remove and retried to make the windows 7 hvm. > > > > I followed the same steps above; however, when I got to the first > > qvm-start I get the following: > > > > --> Loading the VM (type = HVM)... > > Traceback (most recent call last): > > File "/usr/bin/qvm-start", line 136, in > > main() > > File "/usr/bin/qvm-start", line 120, in main > > xid = vm.start(verbose=options.verbose, > > preparing_dvm=options.preparing_dvm, start_guid=not options.noguid, > > notify_function=tray_notify_generic if options.tray else None) > > File > > "/usr/lib64/python2.7/site-packages/qubes/modules/01QubesHVm.py", line 335, > > in start > > return super(QubesHVm, self).start(*args, **kwargs) > > File > > "/usr/lib64/python2.7/site-packages/qubes/modules/000QubesVm.py", line > > 1952, in start > > self._update_libvirt_domain() > > File > > "/usr/lib64/python2.7/site-packages/qubes/modules/000QubesVm.py", line 764, > > in _update_libvirt_domain > > raise e > > libvirt.libvirtError: operation failed: domain 'win7' already > > exists with uuid 27a11689-a44e-4442-b11a-112b2728c511 > > > > If I run the command without the --custom-config option it starts, and > > hangs at startup as usual; so I'm guessing its a problem with my config? > > I've seen this happen when qubes-manager / libvirt / xen get out of > sync. "Simplest" fix is to reboot. > > Otherwise, I'd do in dom0: > $ killall qubes-manager # or right-click the tray icon -> Exit > $ xl list # check for win7 vm > $ ls /var/lib/qubes/appvms # check for win7 dir > $ grep win7 /var/lib/qubes/qubes.xml # should produce no results > $ sudo systemctl restart libvirtd # this is what really matters > and re-launch qubes-manager from the Q menu > > It's a bug, but I haven't found time to look into it. If you know how > to reproduce reliably, definitely open an issue. > > Cheers, > Jean-Philippe I tried your advice of restarting, and the alternative steps and I still get the same error. I've been looking around for answers, and looking through logs and have come up wiht nothing. -- Respectfully, Sam Hentschel FD6A 2998 5301 B440 D26B 7040 69D1 CE58 6FA5 BB5A -- 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/20170524061228.GA958%40Personal-Email. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
[hentsche...@gmail.com: Re: [qubes-users] Trusted PDF]
On Tue, May 16, 2017 at 10:21:37AM -0400, Chris Laprise wrote: > On 05/16/2017 10:06 AM, Chris Laprise wrote: > > On 05/15/2017 06:46 PM, Sam Hentschel wrote: > > > Hey All, > > > > > > Another question, why is it that the qvm-convert-pdf function returns a > > > file that is slgihtly fuzzy? > > > > > > I keep lots of copies of important documents that I want to convert to > > > secure pdfs since they don't need to have anything other than an image. > > > However, I need them to be as clear as possible so I can print them back > > > out as if they were the original. > > > > > > Using qvm-convert-pdf currently makes a really fuzzy copy. How can I > > > fix this (if at all)? > > > > > > > > > The line that does the rendering in qpdf-convert-server looks like this: > > > > pdftocairo $INPUT_FILE -png -f $PAGE -l $PAGE -singlefile $(basename > > $TEMP_PNG_FILE .png) > > > > No resolution is specified and the pdftocairo man page says the default > > res is 150 PPI. You could add the -r parameter for more resolution, > > though you may also have to adjust MAX_IMG_WIDTH and HEIGHT in > > qpdf-convert-client. > > > > I created a Qubes issue for this: > > https://github.com/QubesOS/qubes-issues/issues/2812 > > -- > > Chris Laprise, tas...@openmailbox.org > https://twitter.com/ttaskett > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 Thanks, I was wondering if it was issue worthy or not. I didn't know if it was something that could be fixed. I may go ahead and try to patch qvm-convert-pdf then (if I have a free day or two) seems like it should be relatively easy (with the information you gave me). I feel I would just add the option to specify the resolution via a -r flag (or as part of the arguments), and still allow just the pdf for backwards compatability. -- Respectfully, Sam Hentschel FD6A 2998 5301 B440 D26B 7040 69D1 CE58 6FA5 BB5A -- 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/20170516170258.GB1011%40Personal-Email. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
Re: [qubes-users] Secure Handling of Encrypted Drives
On Wednesday, April 12, 2017 at 3:20:30 PM UTC-4, Chris Laprise wrote:
> On 04/12/2017 02:37 PM, Jean-Philippe Ouellet wrote:
> > On Wed, Apr 12, 2017 at 2:07 PM, Sam Hentschel <hentsche...@gmail.com>
> > wrote:
> >> On Wednesday, April 12, 2017 at 4:15:08 AM UTC-4, Unman wrote:
> >>> On Tue, Apr 11, 2017 at 11:12:50PM -0400, Sam Hentschel wrote:
> >>>> I am trying to figure out a way to securely handle my encrypted drives
> >>>> without two things: connecting the USB directly to the Vault (as this is
> >>>> obviously a bad idea for security), and decrypting the USB in sys-usb
> >>>> (also obviously a bad idea).
> >>>>
> >>>> As an example, I have some USB that I keep encrypted backups of my
> >>>> important documents that I keep with me in case an emergency happens
> >>>> (which now that I am using Qubes will probably also be in the Vault). I
> >>>> have files on there that I need to move to Vault, and I need to be able
> >>>> to continue to put files onto it (whether from Vault or from a scan I
> >>>> have done. >>>> what I did giving DispVMs the sole ability to print and scan.> Which I
> >>>> know is a whole different problem; so I want to focus on just the
> >>>> encrypted storage.
> >>>>
> >>>> Another example is my backup drives which are all encrypted, and that I
> >>>> would like to have access to for the standard reasons. I have been
> >>>> pointed to [1] a couple days ago by JPO and I believe this is part of
> >>>> the soution, but not the whole thing.
> >>>>
> >>>> My two solutions that I have thought through are: doing PCI patthrough
> >>>> directly to the Vault (which is the least favorite of my ideas), and
> >>>> creating a separate VM for encryption that only houses software for
> >>>> encrypting and decrypting (dm-crypt or veracrypt). This way the USB
> >>>> will be passed through to this VM and will never directly touch the
> >>>> Vault (except through qvm-move-to-vm).
> >>>>
> >>>> I had a third solution of adding this functionality to DispVMs, but I
> >>>> can't PCI pass the USB to the DispVMs when they are running. So that
> >>>> one is out.
> >>>>
> >>>> Thanks in advance for the help; can't wait to see what I missed!
> >>>>
> >>>> [1] https://github.com/rustybird/qubes-split-dm-crypt
> >>>>
> >>>
> >>> Hi Sam,
> >>>
> >>> I'm obviously missing something here.
> >>>
> >>> One of your two solutions fits completely within the current Qubes model
> >>> and matches exactly the specification you set; that is, qvm-block
> >>> attach the encrypted drive to a qube and decrypt it there.
> >>> Can I ask what more you are looking for?
> >>>
> >>> There's no need to do this in a separate decryptionVM - you can use a
> >>> disposableVM for the purpose.
> >>>
> >>> If you don't want to have the decryption software in a standard
> >>> template, then put it in a separate template, build a distinct
> >>> disposableVM from that template and use my hack to fire up that
> >>> disposableVM when you want to use a decrypted drive.
> >>>
> >>> unman
> >>
> >> Unman,
> >>
> >> I was just making sure I wasn't missing something or there wasn't a better
> >> way. Anyways, I can't set this up in a DispVM because you cannot PCI
> >> passthrough to a VM while it is running(?)
> >
> > Your understanding is incorrect on the following details:
> >
> > 1) you *can* do pci passthrough to a vm while it's running. Depending
> > on if the device supports function-level-reset or not, you may need to
> > set pci_strictreset="False" for the VM in /var/lib/qubes/qubes.xml
> >
> > 2) qvm-block is distinct from and not implemented with pci
> > passthrough, it uses xen blk{front,back}. This is an entirely
> > different and believed to be less dangerous interface to expose than
> > PCI to your actual devices.
> >
> >
> > That said, you might prefer to use a normal unencrypted filesystem,
> > only interface with the filesystem in sys-usb, and use encrypted files
> > instead.
> >
> > You could then use qvm-copy-to-vm to move the ciphertext from sys-usb
> > into yo
[qubes-users] Secure Handling of Encrypted Drives
I am trying to figure out a way to securely handle my encrypted drives without two things: connecting the USB directly to the Vault (as this is obviously a bad idea for security), and decrypting the USB in sys-usb (also obviously a bad idea). As an example, I have some USB that I keep encrypted backups of my important documents that I keep with me in case an emergency happens (which now that I am using Qubes will probably also be in the Vault). I have files on there that I need to move to Vault, and I need to be able to continue to put files onto it (whether from Vault or from a scan I have done.Which I know is a whole different problem; so I want to focus on just the encrypted storage. Another example is my backup drives which are all encrypted, and that I would like to have access to for the standard reasons. I have been pointed to [1] a couple days ago by JPO and I believe this is part of the soution, but not the whole thing. My two solutions that I have thought through are: doing PCI patthrough directly to the Vault (which is the least favorite of my ideas), and creating a separate VM for encryption that only houses software for encrypting and decrypting (dm-crypt or veracrypt). This way the USB will be passed through to this VM and will never directly touch the Vault (except through qvm-move-to-vm). I had a third solution of adding this functionality to DispVMs, but I can't PCI pass the USB to the DispVMs when they are running. So that one is out. Thanks in advance for the help; can't wait to see what I missed! [1] https://github.com/rustybird/qubes-split-dm-crypt -- Respectfully, Sam Hentschel FD6A 2998 5301 B440 D26B 7040 69D1 CE58 6FA5 BB5A -- 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/20170412031247.GA989%40Personal-Email. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
[qubes-users] HCL - Lenovo Thinkpad X1 Carbon Gen3
Here's my HCL before I update my kernel or anything else. -- Respectfully, Sam Hentschel -- 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/20170406160827.GA2200%40Personal-Email. For more options, visit https://groups.google.com/d/optout. --- layout: 'hcl' type: 'notebook' hvm: 'yes' iommu: 'yes' slat: 'yes' tpm: '' brand: | LENOVO model: | 20BTS1V900 bios: | N14ET32W (1.10 ) cpu: | Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz cpu-short: | FIXME chipset: | Intel Corporation Broadwell-U Host Bridge -OPI [8086:1604] (rev 09) chipset-short: | FIXME gpu: | Intel Corporation HD Graphics 5500 [8086:1616] (rev 09) (prog-if 00 [VGA controller]) gpu-short: | FIXME network: | Intel Corporation Ethernet Connection (3) I218-LM (rev 03) Intel Corporation Wireless 7265 (rev 99) memory: | 16059 scsi: | SAMSUNG MZNLN256 Rev: 2L6Q versions: - works: 'FIXME:yes|no|partial' qubes: | R3.2 xen: | 4.6.4 kernel: | 4.4.38-11 remark: | FIXME credit: | FIXAUTHOR link: | FIXLINK ---
Re: [qubes-users] DispVM Configuration
On Thu, Apr 06, 2017 at 02:03:14PM +0100, Unman wrote: > On Thu, Apr 06, 2017 at 02:17:53AM -0400, Jean-Philippe Ouellet wrote: > > On Wed, Apr 5, 2017 at 11:59 PM, Sam Hentschel <hentsche...@gmail.com> > > wrote: > > > Hey all! > > > > > > So far so good with QubesOS on my end. Have almost everything up and > > > running to have this as my daily carry. It's amazing how little RAM all > > > these VMs actually require; and the CPU! None! > > > > > > Anyways, I am having some trouble configuring my DispVMs to allow me to > > > use them for printing and scanning. The protocols and software for > > > printing and scanning are both, as I recall, highly insecure. In > > > addition, the devices that use them (i.e. printer, scanners) should be > > > considered to be backdoored or owned already. > > > > > > I wanted to make it so that when I want to print something, I open up > > > the file in a DispVM and print it from there. I then thought that I > > > could approximately do the same thing with scanning. Open up a DispVM > > > that is running simple-scan, scan the file into the DispVM and then copy > > > it over to the VM that I want. > > > > > > By doing it this way I should be able to move out all the vulnerable > > > printer and scanner code, and my AppVMs will never directly touch those > > > devices or protocols. Instead they will be hidden behind the realtive > > > safety of the Qubes file copy mechanism. > > > > An interesting goal. In practice I'm not sure what real benefit you'd > > get from using a DispVM vs. just a regular stateful AppVM (assuming > > you just use one printer/scanner). Presumably what you care about in > > this context is confidentiality of your documents. Your > > printer/scanner is by its very nature in a perfect position to steal > > your documents, and likely also has a means to store or transmit them. > > This seems true regardless of whether or not your printer/scanner can > > compromise or persistently compromise a VM (which only deals with > > printer drivers and documents the printer will know anyway). > > > > If you use multiple printers, then I can see an argument for wanting > > separate AppVMs per printer, and if you constantly use different > > printers then sure I guess DispVMs make sense. Is this the case? > > > > In other words, I'm curious what threat you're actually trying to > > mitigate by doing this. > > > > > I tried to follow the documentation page: > > > - show internal VMs > > > - run gnome-terminal in fedora-23-dvm > > > - install and configure the necessary applications and hardware devices > > > - touch the /home/user/.qubes-dispvm-customized > > > - shutdown the VM > > > - regenerate the DispVM template using: qvm-create-default-dvm > > > --default-template > > > > > > When I opened up a DispVM the software was nowhere to be found (opened > > > up Firefox, right clicked on the DispVM in the VM Manager and ran > > > gnome-terminal). When I reopen fedora-23-dvm the software is nowhere to > > > be found. So I believe either I am doing something stupid, or the > > > documentation has it wrong. I did notice that the DispVMs start with a > > > ttemplate of fedora-23. So then do they not actually use the > > > fedora-23-dvm template like it says? > > > > If you want to make additional software available, then do so in the > > template of the dispvm (in your case fedora-23 (but you should really > > update to fedora-24!)). > > > > You can think of the process of customizing a DispVM like creating a > > new AppVM. Software that should be available on every run belongs in > > its template. Local state (/home, etc.) happens in the AppVM. > > Customizing the DispVM template is like customizing an AppVM that you > > then take a snapshot of and duplicate each time you want a new DispVM. > > In practice this is similar to how it's actually implemented. > > > > Hi Sam, > > I understand your goal, because I use dispVMs for scanning myself, > rather than a stateful appVM. (I think Jean-Philippe missed your comment > about the protocols and software being highly insecure.) > > I think your problem arises because of the way in which a disposableVM is > generated, which hasn't been made clear enough to you. > What you need to do is clone an existing template to (say) fed24-print. > Then install the software drivers and printing/scanning tools on THAT > template, and use it to g
Re: [qubes-users] DispVM Configuration
On Thu, Apr 06, 2017 at 02:17:53AM -0400, Jean-Philippe Ouellet wrote: > On Wed, Apr 5, 2017 at 11:59 PM, Sam Hentschel <hentsche...@gmail.com> wrote: > An interesting goal. In practice I'm not sure what real benefit you'd > get from using a DispVM vs. just a regular stateful AppVM (assuming > you just use one printer/scanner). Presumably what you care about in > this context is confidentiality of your documents. Your > printer/scanner is by its very nature in a perfect position to steal > your documents, and likely also has a means to store or transmit them. > This seems true regardless of whether or not your printer/scanner can > compromise or persistently compromise a VM (which only deals with > printer drivers and documents the printer will know anyway). > > If you use multiple printers, then I can see an argument for wanting > separate AppVMs per printer, and if you constantly use different > printers then sure I guess DispVMs make sense. Is this the case? > > In other words, I'm curious what threat you're actually trying to > mitigate by doing this. On a daily basis I interact with about three printers: one at home, one at work, and one at school. My goals were as follows: - Keep one printer from getting what another printer has handled - Stop the spread of pritner malware from one printer to another (if that makes sense?) - Stop the printers (which may be and probably are compromised) from compromising one of my security domains. - Kind of the same reasons as moving out the networking software and drivers to the NetVM and the USBs to a USBVM? An example scenario: an employer or future employer requires me to print out some forms from an email, fill them out, scan them, and email them back. In this case, it would be nice to be able to print the forms via a DispVM (which I open anyway when interacting with email attachments), fill them out, scan them in the same or a different DispVM and send it back. This way the PDF or word document is never opened in my Email Qube. I can thus takeout extra software in that VM, and minimize it to just working with email. > If you want to make additional software available, then do so in the > template of the dispvm (in your case fedora-23 (but you should really > update to fedora-24!)). Ok, if thats the case I may clone the fedora template and make one specifically for the DispVMs. Some of the software I want on DispVMs, I don't want on my AppVMs and vice versa. Since its the case that the DispVM uses the fedora-23 template, shouldn't the document say to edit that instead of the fedora-23-dvm AppVM? If you agree, maybe I'll go pull down the documentation and rewrite some of it. -- Respectfully, Sam Hentschel -- 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/20170406125158.GA999%40Personal-Email. For more options, visit https://groups.google.com/d/optout.
[qubes-users] DispVM Configuration
Hey all! So far so good with QubesOS on my end. Have almost everything up and running to have this as my daily carry. It's amazing how little RAM all these VMs actually require; and the CPU! None! Anyways, I am having some trouble configuring my DispVMs to allow me to use them for printing and scanning. The protocols and software for printing and scanning are both, as I recall, highly insecure. In addition, the devices that use them (i.e. printer, scanners) should be considered to be backdoored or owned already. I wanted to make it so that when I want to print something, I open up the file in a DispVM and print it from there. I then thought that I could approximately do the same thing with scanning. Open up a DispVM that is running simple-scan, scan the file into the DispVM and then copy it over to the VM that I want. By doing it this way I should be able to move out all the vulnerable printer and scanner code, and my AppVMs will never directly touch those devices or protocols. Instead they will be hidden behind the realtive safety of the Qubes file copy mechanism. I tried to follow the documentation page: - show internal VMs - run gnome-terminal in fedora-23-dvm - install and configure the necessary applications and hardware devices - touch the /home/user/.qubes-dispvm-customized - shutdown the VM - regenerate the DispVM template using: qvm-create-default-dvm --default-template When I opened up a DispVM the software was nowhere to be found (opened up Firefox, right clicked on the DispVM in the VM Manager and ran gnome-terminal). When I reopen fedora-23-dvm the software is nowhere to be found. So I believe either I am doing something stupid, or the documentation has it wrong. I did notice that the DispVMs start with a ttemplate of fedora-23. So then do they not actually use the fedora-23-dvm template like it says? Thanks in advance for your help! -- Respectfully, Sam Hentschel -- 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/20170406035927.GA952%40Personal-Email. For more options, visit https://groups.google.com/d/optout.
