Re: [qubes-users] Secure Handling of Encrypted Drives
On Sun, Apr 16, 2017 at 7:59 PM, Andrew David Wong wrote:
> On 2017-04-12 13:05, Sam Hentschel wrote:
>> 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
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. >> writing some documentation hopefully on 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 your other vm, {decrypt, manipulate, re-encrypt}
them there, send back new ciphertext (again via
qvm-copy-to-vm) to sys-usb, and put them back on the flash
drive from there.
This isolates your document processing from potential vulns in
your filesystem manipulation code (such as fuse-exfat which
appears to be the de-facto standard flash drive filesystem
these days for maximum interoperability).
>>>
>>> This is confusing a fairly simple issue.
>>>
>>> What Sam is looking for is to use 'qvm-block -a' (or the attach
>>> menu in Qubes Manager) which indeed has nothing to do with PCI
>>> passthrough.
>>>
This approach likely
[qubes-users] Re: HOWTO: Compiling Kernels for dom0
On 04/16/2017 07:16 PM, Andrew David Wong wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 2017-04-16 18:10, Marek Marczykowski-Górecki wrote: >> On Fri, Apr 14, 2017 at 12:21:14PM -0600, Reg Tiangha wrote: >>> Here's my contribution to the project. >> Thanks! >> >> Andrew, maybe it would be good idea to at least link to this >> thread somewhere in "Building" section of docs? Or copy this >> instruction there (the part about actual building and customizing), >> including adjustments here and in subsequent messages? >> Thanks for the comments you two; I'm new to the Git stuff but I'm trying to learn fast. Actually, now that Foppe de Haan found some extra packages to install to make everything work, I wouldn't mind having a chance to re-write it and submit it. What's the best way to do that? Fork some kind of repo, create a new file, and then submit a pull request? If so, which repo? If not, what's the best/easiest way to submit a re-written guide to you guys? -- 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/od15aa%24o3b%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: remote code execution via UDP packets (CVE-2016-10229) in the context of Qubes // and kernel update recommendations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2017-04-14 06:54, Unman wrote: > I think everyone should calm down. :-) > > If you look at the source for 4.4.38 used to build the kernel used > in Qubes, you will see that it already contains the patch. That's > linux-4.4.38 from 10-Dec-2016 > > Qubes kernel version 4.4.38-11 was built 12-Dec-2016, and > incorporates that patch, so if you keep your system updated you > are already covered. > Marek has also confirmed that 4.4.38 contains the fix. - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJY9BfqAAoJENtN07w5UDAwKfgQAKppdoaL7U1Cggjxl6ZkOMkk DlG5Rb6BCnjzwSXJ8Iad0Y2rxoVa6JVvlCcEN9Ml44FLCKkN5F+ROxomOUuPHkoT TaY71yC6SO8T+xwM+SExynfpV3maTDXDFmPaZB/ydVRgIlLDk70vU2L1W9WnPT9d FOWti4RCM7eFaUMORGnClzKtU3d0ayKL6HiQMiT63CDXMteqR2ZJx1kHPooZ+ZLs zndcu345S2iM6q0UMJGo74NIkwreFmjswHATF2MiBsdzyxr62sOevtdJSmK1hHGn K/A+/VsrW0GS7/Nnc5gFy3uZcbv3HaygAJUxxhCG9Ad8fFkwY9CUkcOj8W5RnT4v eM8m/dqEsP+a7zfUPcbZnZAC57zqn+SIq6I1wN90d76WwEMbKxIJMiSwX1TsQ3NE HCFZj3060zQuW+rHxS4CUNbJQ5mZxp0cYcjsb6YB8/TASWNUJ2y8vIpCp9s72lk0 eV+n30FJK7yRMiXhUpdX+Kl/IJp+pi3RSIvkYqN1TFM61k9H/IoatBk08Ejcd+Gh ge+ccIhEDM6VytZ6NswAjjUfrQ6jPk1lNEFRhsBx1BmsWgSdNf8o2kZ8E5jCtYUY 8xZRuPj3+Y3vAMqmtsRurPUVuVS4r153/m9V+APB8h+Zmn1K88G4tRpFDxGI5Flk RFGRENsnulmB8mC6ipCd =aOPi -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/9ce549e8-9b66-8cf1-ef44-e511f2e755c2%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] HOWTO: Compiling Kernels for dom0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2017-04-16 18:10, Marek Marczykowski-Górecki wrote: > On Fri, Apr 14, 2017 at 12:21:14PM -0600, Reg Tiangha wrote: >> Here's my contribution to the project. > > Thanks! > > Andrew, maybe it would be good idea to at least link to this > thread somewhere in "Building" section of docs? Or copy this > instruction there (the part about actual building and customizing), > including adjustments here and in subsequent messages? > Good idea. I've just linked to thread for now, in case more useful replies are added in the near future. Maybe someday someone can submit a nice Markdown version to replace it. :) - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJY9BddAAoJENtN07w5UDAwnuUP/i2TtLmmDZk6J+Ll86rumDYw qK4cDtzozWxG5figs6zd4WiguyFs/SfuEU1DxJ7e/4+G730t2Purfy3ZUp1fWEhc SLurA+NpJCM/6dfkGXswmNNTYv/ncKtfX/7L7ntr7F8D8PSaE/I2+zpwGFRWmnol rr0vHmp6pqtYZFaV+ByYCIYmNHESOYtbuO4+SAOfbwzijWDckZXtkAoNpJdD3ypJ go72WZAZeDjiCw2dFi8mThcWylxQ7WRd21mRUJIf2lEkHfXVTBP6OMJa02pjfolp /J0j+6G9OG2yk7iJ05bLf2b7Y5MjhRgsJdFWBBxgH1AlxgBChLO3EYqzxDyHUq88 rZo7ePGMY38nEZofIA4pIIgYV/87Vg6BVddUm0MEVHwNjMsxh05pGTv7OzkM+Hc6 N2uH7E0vmYZERWwX34ASgiMG1RZZIswat2HSm/GEBEb1vpieOMDNAKdj7/tqNzK/ Nx82FOYWnHwkDI1sxDh4hWGsd/WeKKyk3A3kMvzsGS8JAPoQeRA3bes4+UtOBCDw mygAbvHzxmz+Kx1JptrNBFRfs9ULJ6T3+E8adqNxd31R6mzHTo3g4JDJ0hOGINRq MdZ8tZyUFCrAGRDNVN8vhdNMtq3WIJezWUhm6RaVSRb/8Ep9lcx/xQcTjpMVj9+O KlAmJ+Y+CAmxyEnpwXdK =OBeX -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/356d870a-4549-c105-9750-19c1c8b6dd25%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] HOWTO: Compiling Kernels for dom0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Apr 14, 2017 at 12:21:14PM -0600, Reg Tiangha wrote: > Here's my contribution to the project. Thanks! Andrew, maybe it would be good idea to at least link to this thread somewhere in "Building" section of docs? Or copy this instruction there (the part about actual building and customizing), including adjustments here and in subsequent messages? > On my GitHub account, I've now got branches tracking kernels from 4.4 > all the way to 4.10. I assume you've also seen devel-* branches on my github account. > My intent is to keep them up-to-date with upstream > as much as possible, but all I can really test is to see is if they > still compile and/or install/boot. If there are any issues with new > versions, let me know, but I make no guarantees that I can actually > *fix* any regressions that may be introduced by upstream. That said, if > some people want to compile the latest kernel in a supported branch > themselves on their own schedules optimized for their specific hardware > setups, I hope this makes things a little easier you. > > https://github.com/rtiangha/qubes-linux-kernel/ > > > HOWTO: > > - You'll need at least 4GB of free space in /home for each kernel you > hope to compile. > > - In a Fedora TemplateVM matching the version running in your dom0, > install git and the qubes-kernel-vm-support package: > > sudo dnf install git qubes-kernel-vm-support > > I believe that should pull in everything you need to compile a kernel. > At the moment, if you want to build a kernel higher than 4.8, you'll > need to temporarily enable the current-testing repository since the > version that's in stable right now is too old to work with kernels 4.9 > and above. That'll probably change eventually. > > - Download sources: > > git clone https://github.com/rtiangha/qubes-linux-kernel.git > > - Enter directory: > > cd qubes-linux-kernel > > - Switch to the branch that you'd like to compile. For example, to > switch to the 4.4 branch: > > git checkout stable-4.4 Some signature verification of downloaded code would be useful here. I see you sign your commits, so it should be easy (look for "Good signature" at the top, also check if the key is what you expect): git show --show-signature Or in machine readable format: git show -s --format=%G? (should output "G" for good signature made with trusted key, see `git show --help` for details) Of course you need to have appropriate public key in your keyring first. > You can also choose from devel-4.8, stable-4.9, and devel-4.10. > > - Compile rpms: > > make rpms > > - The rpms will be stored in the rpms/x86_64 directory. Copy those to > dom0 using these instructions: > > https://www.qubes-os.org/doc/copy-from-dom0/ > > - Install rpms. In dom0, run: > > dnf install kernel-.rpm kernel-qubes-vm-.rpm Some, probably obvious warning: this will also execute some pre/post-installation scripts in the package. It means that if the building VM is compromised, it can include some code in the rpm package, that will compromise dom0 when you install it. > - Reboot and see if it works > > > TIPS: > > By default, the kernel configuration is set up for a very generic build > to work with a variety of hardware. If you're going to go through the > hassle of compiling your own kernels, you might as well optimize for > your particular hardware configuration. For example, if all you have > are AMD machines and no Intel machines, rather than compiling a kernel > for a generic x86_64 CPU, you can set the kernel to optimize for AMD > CPUs specifically and you may net some performance improvements as a result. > > - To do this, first download the kernel sources (make rpms automatically > does this for you): > > make get-sources Don't forget about 'make verify-sources' (check signature on downloaded tarball). It's better to call: make get-sources verify-sources > - Then extract the source files: > > tar Jxf linux-.tar.xz > > - Move into the directory: > > cd linux-.tar.xz cd linux- > - Copy the default Qubes kernel configuration into the directory: > > cp ../config .config > > - Now, sometimes new drivers or kernel options will be introduced > in-between kernel versions. It is always useful to check for that and to > merge in anything new that you may find desirable. To do so, first run: > > make oldconfig > > What that will do is check the current kernel configuration file against > what's available in the new kernel version. If there's nothing new, then > it will exit gracefully. If there are some new things, it'll prompt you > on whether or not you want to include them. If you have no idea what to > do, you can probably just accept the default choices or just say No and > still be safe if the current kernel configuration works for you. > > - Customize your kernel: > > make menuconfig > > - You'll be presented with a menu with a whole lot of options. The > easiest ones to play with if
[qubes-users] Re: Network Manager icons-Fedora 23
On Saturday, 15 April 2017 01:52:33 UTC+10, pete...@hushmail.com wrote: > Hi > I don't know when and why but sometimes my Fedora 23 network manager icons > that are in the right down corner of my desktop, suddenly go in the top left > corner. What GUI are you using? I use XFCE and I have no issue with it any more since I changed to XFCE. KDE often had that issue though. -- 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/094dd666-2047-429e-907c-84457f6e4aae%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] qubes manager add start terminal
On Mon, Apr 17, 2017 at 02:29:05AM +0300, Eva Star wrote: > I'm get tired that Qubes Manager till now do NOT have "Start Terminal" at > right click menu of each vm, but only "Run command in VM". > > I want to patch it to add "Run terminal". I found that need to duplicate > "Run command" entry, name it "Run Terminal" and predefined "gnome-terminal" > on the input field. > > I need to modify action. On the repository I see actions at mainwindow.ui > file. But I can not find it on the disk to add new action! > > > > > :/run-command.png:/run-command.png > > > Where is mainwindow.ui with actions??? > > If I will found it I will add new function to process this action by > duplicating action_run_command_in_vm_triggered(self) and predefined > "gnome-terminal" into it. > > I've done some manager hacking myself - some of it now incorporated in release. If you dont want to build a package then you can simply start hacking in /usr/lib64/python2.7/site-packages/qubesmanager. (Back this up first, of course.) Beside the ui elements in ui_mainwindow the slots are in main.py. If you're going to hack these remember to remove the compiled files. I'd recommend using xterm, as it's in all the templates afaik. unman -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20170417001102.GA9735%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Secure Handling of Encrypted Drives
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2017-04-12 13:05, Sam Hentschel wrote:
> 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
>>> 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. > writing some documentation hopefully on 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 your other vm, {decrypt, manipulate, re-encrypt}
>>> them there, send back new ciphertext (again via
>>> qvm-copy-to-vm) to sys-usb, and put them back on the flash
>>> drive from there.
>>>
>>> This isolates your document processing from potential vulns in
>>> your filesystem manipulation code (such as fuse-exfat which
>>> appears to be the de-facto standard flash drive filesystem
>>> these days for maximum interoperability).
>>
>> This is confusing a fairly simple issue.
>>
>> What Sam is looking for is to use 'qvm-block -a' (or the attach
>> menu in Qubes Manager) which indeed has nothing to do with PCI
>> passthrough.
>>
>>>
>>> This approach likely has a higher chance of protecting your
>>> document-proc
[qubes-users] Re: qubes manager add start terminal
On 04/16/2017 05:29 PM, Eva Star wrote: > I'm get tired that Qubes Manager till now do NOT have "Start Terminal" > at right click menu of each vm, but only "Run command in VM". > > I want to patch it to add "Run terminal". I found that need to > duplicate "Run command" entry, name it "Run Terminal" and predefined > "gnome-terminal" on the input field. > > I need to modify action. On the repository I see actions at > mainwindow.ui file. But I can not find it on the disk to add new action! > > > > > :/run-command.png:/run-command.png > > > Where is mainwindow.ui with actions??? > > If I will found it I will add new function to process this action by > duplicating action_run_command_in_vm_triggered(self) and predefined > "gnome-terminal" into it. > > I don't know the answer to your question, but the problem with that is that not every TemplateVM has gnome-terminal installed (for example, the Fedora or Debian minimal templates). If you wanted to make something more generic, you'd probably be safer with 'xterm' even though it isn't as convenient to use. That's what gets called whenever you click on 'Update VM' (except in Whonix, where it's Konsole). But if you're just doing it for yourself, you can launch whatever you want. That said, being able to right-click in Qubes Manager and quickly launch any kind of terminal program would be a super useful feature to have. -- 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/od0vk7%24pmn%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Protect AppVM init startup scripts:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2017-04-10 08:43, Chris Laprise wrote: > Here is a small script for Linux templates that protects files > executed on startup by... > > bash sh Gnome KDE Xfce X11 > > Together with enabling sudo authentication, this is a simple way to > make template-based VMs less hospitable to malware. > > LINK: https://github.com/tasket/Qubes-VM-hardening > Looks great, thanks! Issue: https://github.com/QubesOS/qubes-issues/issues/2748 CDFT: https://www.qubes-os.org/qubes-issues/#qubes-vm-hardening - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJY9AGeAAoJENtN07w5UDAw7C8P/1Spas/Knt0MxGk7cD0Ld90k SSrgcd25AZhBgvmkxVZo5RqoczFzGMp+wVkrGSoLRUjQ26xikzvNrIB4+DSUOK44 f/pWjeyUWj3rqXHK/2rfNWJBYuFN5RetQD6zNK+6+QrARZi9MWnP/ii38WG2A57v fAMYmGLDE9e1OClYRKLrymLdbgFn/O5ioULKX0qFtd/iln+qPIhBZxzaUsm2COgb i46oqX3WvAQkcqL9MJ/0hWKvoShr5r9DG3/BScCsZxByVg76YB7iigCrCkJtC1gI jdV3Dy/7oiKHsJsV1A8TL/7y7OCGtrIDQk8P3gIbCbCkf6bq0FFbcq/IZxiVpf7Y Lx6xDXtZfJcGxbCIorft4f8aQjSgwbzP7gKUi13mxQjGGCZWusR5CHeUqxlqvtII G0ojdH+GAUjH9GP86NFs25zv6kHy7rkW7FPYqyn+T9UNolpgUokFvJ85Cb/xQe42 SRGSrGNP5udwQ/MqdW3qdgzkZiezLNHZdlFLtM39ni5I0Okk9ga3OEYhp8dd3rOs i+Gg557mW5D+Vtliir1QvJKijEWZk3bVWuwSfUSS2PUXFKwvxKvBbt1fuhmxxt95 u3ryfSAbx/4iRIcFs8PYEVMO1nDkS616a9qbGXW38vsU+6M8/JWX9KfUgPAC+Vrn 5kWgLvAqb9KXBDtenikt =Z3KN -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/171f47af-3d63-31d3-2112-139ff783de42%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] qubes manager add start terminal
I'm get tired that Qubes Manager till now do NOT have "Start Terminal" at right click menu of each vm, but only "Run command in VM". I want to patch it to add "Run terminal". I found that need to duplicate "Run command" entry, name it "Run Terminal" and predefined "gnome-terminal" on the input field. I need to modify action. On the repository I see actions at mainwindow.ui file. But I can not find it on the disk to add new action! :/run-command.png:/run-command.png Where is mainwindow.ui with actions??? If I will found it I will add new function to process this action by duplicating action_run_command_in_vm_triggered(self) and predefined "gnome-terminal" into it. -- Regards -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f8d6b2c5-09c4-8d4a-e7fd-730f1ca74c19%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Status of dvm support
On Sunday, April 16, 2017 at 7:25:51 PM UTC-4, cooloutac wrote: > On Saturday, April 15, 2017 at 12:27:18 AM UTC-4, cooloutac wrote: > > On Saturday, April 15, 2017 at 12:25:43 AM UTC-4, cooloutac wrote: > > > On Friday, April 14, 2017 at 5:51:47 PM UTC-4, Unman wrote: > > > > On Thu, Apr 13, 2017 at 10:06:11AM -0700, justusranv...@gmail.com wrote: > > > > > I've experienced problems with DVMs on every Qubes install I've ever > > > > > done. I currently have no devices running Qubes on which dvms work. > > > > > > > > > > Based on several threads from last year I found on this issue, and > > > > > this issue: > > > > > > > > > > https://github.com/QubesOS/qubes-issues/issues/2182 > > > > > > > > > > Is it correct that once this bug with the dvm savefile is triggered, > > > > > then dvms will never work on your system again unless you manually > > > > > patch xen and recompile? > > > > > > > > > > Are there instructions anywhere for doing this? > > > > > > > > > > > > > > > > > There are instructions at www.qubes-os.org/doc/ under the Build > > > > heading. > > > > > > > > Basically you set up the Build environment and Qubes Builder as > > > > detailed on > > > > those links, and then you will need to patch the Xen source tree before > > > > running 'make vmm-xen'. > > > > > > > > What interests me most about this is that I have never had problems with > > > > disposableVMs on any install I've done, and that's coming up to 60 > > > > installs now, on a wide variety of machines. > > > > I would be completely lost without disposableVMs - I use them a lot. > > > > > > > > So what is it that triggers this bug for some users, and not others? I > > > > don't recall any systematic effort to track down what's happening at > > > > root > > > > cause. > > > > > > > > unman > > > > > > to me it happens where I get the bug that a dispvm won't start. You > > > click it from start menu and nothing happens. I just delete the internal > > > dvm template file and create a new one. I think some people might have > > > the issue of trying to create them without deleting old one first. > > > > > > But one time I even noticed I must of went to some bad webpage or that > > > the firefox couldn't handle it and it crashed out. I mean closed and > > > disappeared. after that dispvms wouldn't start. could of been a porn > > > page, or a news site I can't remember. Not sure how to trace anything > > > with that. > > > > has only happened no more then a handful of times the few years I've used > > Qubes. > > I forgot on one of my machines for over a week now, every time I start a > dispvm it has a yellow triangle for not allrequested memory being returned. > I shut down the vm and triangle goes away, start it and it comes back. > Deleting the dvm and recreating it is not fixing this, nor is rebooting. Even > if its the only vm I load. Only recent anomaly. no idea what log to look > at, makes me uncomfortable using it on that machine. also the vm on this machine is running terribly slow even with more cpu cores enabled. I thought it was slow internet just now and realized its osmething wrong with this dvm. -- 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/abe5e1c2-503d-443f-b8b8-942b10f8bef4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Status of dvm support
On Saturday, April 15, 2017 at 12:27:18 AM UTC-4, cooloutac wrote: > On Saturday, April 15, 2017 at 12:25:43 AM UTC-4, cooloutac wrote: > > On Friday, April 14, 2017 at 5:51:47 PM UTC-4, Unman wrote: > > > On Thu, Apr 13, 2017 at 10:06:11AM -0700, justusranv...@gmail.com wrote: > > > > I've experienced problems with DVMs on every Qubes install I've ever > > > > done. I currently have no devices running Qubes on which dvms work. > > > > > > > > Based on several threads from last year I found on this issue, and this > > > > issue: > > > > > > > > https://github.com/QubesOS/qubes-issues/issues/2182 > > > > > > > > Is it correct that once this bug with the dvm savefile is triggered, > > > > then dvms will never work on your system again unless you manually > > > > patch xen and recompile? > > > > > > > > Are there instructions anywhere for doing this? > > > > > > > > > > > > > There are instructions at www.qubes-os.org/doc/ under the Build > > > heading. > > > > > > Basically you set up the Build environment and Qubes Builder as detailed > > > on > > > those links, and then you will need to patch the Xen source tree before > > > running 'make vmm-xen'. > > > > > > What interests me most about this is that I have never had problems with > > > disposableVMs on any install I've done, and that's coming up to 60 > > > installs now, on a wide variety of machines. > > > I would be completely lost without disposableVMs - I use them a lot. > > > > > > So what is it that triggers this bug for some users, and not others? I > > > don't recall any systematic effort to track down what's happening at root > > > cause. > > > > > > unman > > > > to me it happens where I get the bug that a dispvm won't start. You click > > it from start menu and nothing happens. I just delete the internal dvm > > template file and create a new one. I think some people might have the > > issue of trying to create them without deleting old one first. > > > > But one time I even noticed I must of went to some bad webpage or that the > > firefox couldn't handle it and it crashed out. I mean closed and > > disappeared. after that dispvms wouldn't start. could of been a porn > > page, or a news site I can't remember. Not sure how to trace anything > > with that. > > has only happened no more then a handful of times the few years I've used > Qubes. I forgot on one of my machines for over a week now, every time I start a dispvm it has a yellow triangle for not allrequested memory being returned. I shut down the vm and triangle goes away, start it and it comes back. Deleting the dvm and recreating it is not fixing this, nor is rebooting. Even if its the only vm I load. Only recent anomaly. no idea what log to look at, makes me uncomfortable using it on that machine. -- 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/3100df3a-6f84-4731-a49f-c35600bd82df%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Anbox?
Yes, /system being read-only is a standard situation on Android. On some devices, you can perform mount -o remount,rw /system to get it RW, but there are some drawbacks on some devices: * Some devices come with NAND lock. This was (is?) usually the case of HTC devices and it is likely also the case of Anbox – since snaps contain RO images, it seems to be the natural way to implement it. * Some devices use dm-verity to reject booting of tampered system. This is the case of BlackBerry, but more vendors are likely to go this way, because this isn't specific for BlackBerry. But I doubt Anbox goes this way. * Even if you manage to modify /system and then to boot, you are going to have troubles with updates. You can think of /data and /system in Android as rough equivalents of /rw and / in template-based VMs in Qubes. There are some differences (different update mechanisms and no CoW snapshot in Android), but the basic principles are the same. Moreover, in Android, you usually exchange one vendor-provided /system for another vendor-provided /system image (even if you use incremental update), so, unlike template-based VMs, you cannot easily customize it this way. If you don't want to touch /system, you can go several ways: * mount --bind (and manage its content to be up-to-date) * mount -t tmpfs and copy old content (I probably have some script for that) * modify / – this is a ramdisk you can write to after performing mount -o remount,rw / and there is even some directory on $PATH. In all those cases, your modification gets lost after reboot. But you can write some script like adb wait-for-device && adb shell su -c /data/busybox/install. You will probably want to run this script as user in order not to have troubles with permissions when using adb later. Specifically for busybox, its installation consists of just two steps: 1. Copy it to some directory on $PATH. 2. Install symlinks (IIRC by the following command: busybox --install /directory/to/install) Regards, Vít Šesták 'v6ak' -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/168560fb-7d50-4403-bf0a-ba95bcd7c3ca%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Anbox?
On 04/16/2017 03:35 AM, Reg Tiangha wrote: > On 04/16/2017 01:44 AM, Vít Šesták wrote: >> Yes, other apps are working after reboot. Maybe I broke it with pm. >> >> * `pm` command in Android seems to be broken – it segfaults and it seems >> that no app can be started then (though other will continue working) >> * Calculator app works, Settings app works, E-Mail app seems to work, too.. >> Maybe the Gallery 3D just has some 3D acceleration issues, but other apps >> are OK. >> * adb lolcat and adb shell are your friends, it shows what is happening >> * adb shell might be needed before adb lolcat >> * don't worry about timeouts – app window can be shown even after timeout >> * Somewhat laggy and CPU hog – maybe related to OpenGL. >> * Not sure how to install apps. I've tried adb install FDroid.apk and it >> passed, but it does not seem to be installed. >> * The desktop files sometimes disappear. >> >> Maybe we should turn off GPU rendering in developer options. Unfortunately, >> I cannot enable developer mode in Settings app. It seems we sould have to >> disable ro.kernel.qemu.gles and qemu.gles in /system/build.prop, but I am >> not sure if this is easy. The build.prop might be a RO part of the snap. >> There is a similar file in /data, not sure what we can override there. >> >> I am not sure if Anbox utilizes OpenGL. Maybe some lowlevel approach >> bypasses the mesa library, which can decide to use llvmpipe. >> >> Regards, >> Vít Šesták 'v6ak' >> > You're right; everything in the > snap/anbox/common/app-data/applications/anbox directory disappears for > some reason. No idea what to do about that. However, you can still > launch stuff from the command line if you remember the commands from the > ..desktop files. When they reappeared again after a VM reboot, I copied > them all to another directory just so I could see the launch commands > when I needed them. > > I've installed stuff with FDroid and adb and it does work; .desktop > files do get generated in that directory. But as you said, they > disappear sometimes. > > I managed to enable Developer Mode, but clicking on it does nothing. > Clicking on it from the side menu just kicks you back to the main > Settings screen. The Anbox people say this is a slimmed down version of > Android 7.1.1; is it possible that Developer Mode wasn't compiled in? > > I installed Build.prop editor from F-Droid and tried to set > ro.kernel.qemu.gles and qemu.gles to 0 using that. I'm not sure if it > did anything, but after a reboot, Gallery 3D doesn't even start. I don't > know how to revert what I changed though to see if it really had an > effect (can't find a way to delete those entries; long pressing does > nothing and I don't know where it saves its data to) but maybe that's a > route to go if it does work. Make sure to back up the VM first, though. > > Does this Android image allow for root? If so, it might be possible to > install a text editor that works with root to try and see if editing > /system/build.prop persists across a reboot. But I too am now out of > time again at the moment. > > One last idea: The Anbox docs say it's possible to use your own Android > image file. So maybe it's possible to build one that doesn't have the gl > stuff enabled. That could be another thing to try as a last resort, > especially if build.prop is read-only. > One last thing: I tried to install Busybox from F-Droid, and while it said that /data had about 4.6GB free, /system has 0GB, which implies to me that /system is either read-only or really is just an image file that you can't modify. System: * device: Anbox * android: 7.1.1 * architecture: x86_64 Free space: * /data: 4.6G * /system: 0 Latest BusyBox: * version: v1.25.1-meefik * applets: 334 items * size: 1665860 bytes * md5: 146921ec514d4828748a226dbed2fc25 Installed BusyBox: * not installed -- 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/ocveba%24mhd%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Anbox?
On 04/16/2017 01:44 AM, Vít Šesták wrote: > Yes, other apps are working after reboot. Maybe I broke it with pm. > > * `pm` command in Android seems to be broken – it segfaults and it seems that > no app can be started then (though other will continue working) > * Calculator app works, Settings app works, E-Mail app seems to work, too. > Maybe the Gallery 3D just has some 3D acceleration issues, but other apps are > OK. > * adb lolcat and adb shell are your friends, it shows what is happening > * adb shell might be needed before adb lolcat > * don't worry about timeouts – app window can be shown even after timeout > * Somewhat laggy and CPU hog – maybe related to OpenGL. > * Not sure how to install apps. I've tried adb install FDroid.apk and it > passed, but it does not seem to be installed. > * The desktop files sometimes disappear. > > Maybe we should turn off GPU rendering in developer options. Unfortunately, I > cannot enable developer mode in Settings app. It seems we sould have to > disable ro.kernel.qemu.gles and qemu.gles in /system/build.prop, but I am not > sure if this is easy. The build.prop might be a RO part of the snap. There is > a similar file in /data, not sure what we can override there. > > I am not sure if Anbox utilizes OpenGL. Maybe some lowlevel approach bypasses > the mesa library, which can decide to use llvmpipe. > > Regards, > Vít Šesták 'v6ak' > You're right; everything in the snap/anbox/common/app-data/applications/anbox directory disappears for some reason. No idea what to do about that. However, you can still launch stuff from the command line if you remember the commands from the .desktop files. When they reappeared again after a VM reboot, I copied them all to another directory just so I could see the launch commands when I needed them. I've installed stuff with FDroid and adb and it does work; .desktop files do get generated in that directory. But as you said, they disappear sometimes. I managed to enable Developer Mode, but clicking on it does nothing. Clicking on it from the side menu just kicks you back to the main Settings screen. The Anbox people say this is a slimmed down version of Android 7.1.1; is it possible that Developer Mode wasn't compiled in? I installed Build.prop editor from F-Droid and tried to set ro.kernel.qemu.gles and qemu.gles to 0 using that. I'm not sure if it did anything, but after a reboot, Gallery 3D doesn't even start. I don't know how to revert what I changed though to see if it really had an effect (can't find a way to delete those entries; long pressing does nothing and I don't know where it saves its data to) but maybe that's a route to go if it does work. Make sure to back up the VM first, though. Does this Android image allow for root? If so, it might be possible to install a text editor that works with root to try and see if editing /system/build.prop persists across a reboot. But I too am now out of time again at the moment. One last idea: The Anbox docs say it's possible to use your own Android image file. So maybe it's possible to build one that doesn't have the gl stuff enabled. That could be another thing to try as a last resort, especially if build.prop is read-only. -- 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/ocvdsl%24bnt%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Anbox?
Theoretically, /data/local.prop allows to override system properties. But I've tried and after Ubuntu reboot, I see the same values (checked by getprop command). No time to investigate it further ATM. Regards, Vít Šesták 'v6ak' -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2ec2bea6-f796-4f65-83b2-7ea39007cc5e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Anbox?
Yes, other apps are working after reboot. Maybe I broke it with pm. * `pm` command in Android seems to be broken – it segfaults and it seems that no app can be started then (though other will continue working) * Calculator app works, Settings app works, E-Mail app seems to work, too. Maybe the Gallery 3D just has some 3D acceleration issues, but other apps are OK. * adb lolcat and adb shell are your friends, it shows what is happening * adb shell might be needed before adb lolcat * don't worry about timeouts – app window can be shown even after timeout * Somewhat laggy and CPU hog – maybe related to OpenGL. * Not sure how to install apps. I've tried adb install FDroid.apk and it passed, but it does not seem to be installed. * The desktop files sometimes disappear. Maybe we should turn off GPU rendering in developer options. Unfortunately, I cannot enable developer mode in Settings app. It seems we sould have to disable ro.kernel.qemu.gles and qemu.gles in /system/build.prop, but I am not sure if this is easy. The build.prop might be a RO part of the snap. There is a similar file in /data, not sure what we can override there. I am not sure if Anbox utilizes OpenGL. Maybe some lowlevel approach bypasses the mesa library, which can decide to use llvmpipe. Regards, Vít Šesták 'v6ak' -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/945a6597-08f8-4264-9fbc-ae9f9f182c39%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Big problem?
It just do not accept the password... but there is probably no way to get to windows back? I'm do stupid -- 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/33425111-41d6-4858-a2c3-5afb79b8b88f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
