Re: [qubes-users] Automatic updating of extra RPMs from add-on repos in Fedora template-based VMs?

2020-11-19 Thread unman
On Thu, Nov 19, 2020 at 07:33:27AM -0500, Matt McCutchen wrote:
> On Wed, 2020-11-18 at 14:34 +0000, unman wrote:
> > On Wed, Nov 18, 2020 at 08:54:23AM -0500, Matt McCutchen wrote:
> > > The problem is when I change the main TemplateVM and want to apply the
> > > change to all existing system volumes.  For example, recently I've
> > > migrated some really useful configuration settings (e.g., enabling
> > > undo-tree by default in Emacs and setting "merge.conflictstyle = diff3"
> > > in Git) from the user volume of my "main" AppVM to my TemplateVM so I
> > > would enjoy their benefits in all AppVMs.  If I had multiple
> > > TemplateVMs, I would have to somehow copy those changes to all of them.
> > >  If I changed a single file, maybe I could write a script that does a
> > > bunch of qvm-copy commands.  But if I want to make sure things do not
> > > get out of sync over time due to mistakes, it would help to have a
> > > management tool of some kind.
> > 
> > Just one word - salt.
> > Salt your templates, and you can straightforwardly clone, and configure,
> > those templates with one command.
> > Using salt also has the benefit that you can sit down at a new machine,
> > pull down the salt config and recreate your system. No more wondering if
> > you kept track of what was installed, or whether your scripts contain
> > all the nice config changes you laboured over.
> 
> I thought someone might mention Salt. :)  If you feel like it, to
> satisfy my curiosity, can you point me to documentation on how I'd use
> Salt to copy a file to all templates?  I'm still more likely to use my
> original proposed solution though.

The state file, copyit.sls, could look like this:
```
/home/user/target:
  file.managed:
- source:
  - salt://source
- user: user
- group: group
```

And the command would be:
qubesctl --skip-dom0 --templates state.apply copyit

The best source is, of course, the docs, which explain all the
different things you can do with files/directories:
https://docs.saltstack.com/en/latest/ref/states/all/salt.states.file.html

I have some introductory notes at 
https://github.com/unman/notes/tree/master/salt

> 
> In the long term, I'd indeed like to have a concise script of some kind
>  to reproduce all my templates.  It will be a significant amount of
> work to find all my customizations and get them into such a script, so
> I'm seeking a nearer-term solution for these proprietary apps.  But
> while we're on the topic: while mutating templates may be a decent
> solution for rapid iteration, how fast could I make the clean
> regeneration run?  Is there a reasonable way to generate one template
> and then generate the others from it?  Might OSTree be helpful?
> 
> Thanks for any insights!
> 
> Matt
> 

As the Irishman said, "I wouldn't start from here".
It's undoubtedly *much* easier to start by installing and customising
using salt, than to try to remember what one has done and fit that in to
salt states.

As to "how long", that depends on exactly what you're doing. Creating and
cloning templates is, I'd say, pretty much as fast as
qvm-create/qvm-clone.
Installing and configuring slower than opening console and doing it
manually, I think, although I haven't done that for some time, except for
minimal templates that cant be salted out of the box. (This is a
constant  source of frustration for me and a huge error imo)
The first thing I do is salt a caching proxy in place of tinyproxy. 
Then I clone the vanilla template, build the largest template (which
caches almost all the packages), and start on the rest.
Most of my templates don't share new packages, so I cant install, clone and
install in to the clone. If your model is different, then you'd be able to do
this quite simply, using cascading template installs.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20201119163807.GA26002%40thirdeyesecurity.org.


Re: [qubes-users] Automatic updating of extra RPMs from add-on repos in Fedora template-based VMs?

2020-11-18 Thread unman
On Wed, Nov 18, 2020 at 08:54:23AM -0500, Matt McCutchen wrote:
> I have the honor of a response from Andrew! :)
> 
> On Tue, 2020-11-17 at 20:57 -0800, Andrew David Wong wrote:
> > For me, the advantage of TemplateVMs over StandaloneVMs (even if there's 
> > only one TemplateBasedVM based on the TemplateVM) is that it's easier to 
> > update the TemplateVM and back up the TemplateBasedVM.
> 
> I assumed the update process was the same for a TemplateVM or a
> StandaloneVM (though I've never tried the latter), and for backups, I
> can select any set of VMs in the Qube Manager.  Perhaps you're pointing
> out that if the system volume of the desired AppVM is easy enough to
> recreate that it's not worth backing up, then using a TemplateVM +
> TemplateBasedVM rather than a StandaloneVM makes it possible to skip
> the backup?  Interesting point.  Though I suppose the more general
> observation underlying my original proposal was that if the process to
> generate the system volume from that of the main TemplateVM is
> automated and reasonably fast, then there's the option to run it on
> every boot of the TemplateBasedVM rather than persisting a separate
> system volume at all.
> 
> > > my bigger
> > > concern is the custom tools and configuration changes in my main
> > > template that aren't currently packaged for dnf.  I could probably
> > > package them and/or do without some of them in some proprietary-app
> > > VMs, but I think that would end up being a bigger hassle than
> > > developing and using my proposed tool.
> > 
> > No need. Just make your changes in one template, then clone that 
> > template as needed. That way, you only have to make the changes once.
> 
> The problem is when I change the main TemplateVM and want to apply the
> change to all existing system volumes.  For example, recently I've
> migrated some really useful configuration settings (e.g., enabling
> undo-tree by default in Emacs and setting "merge.conflictstyle = diff3"
> in Git) from the user volume of my "main" AppVM to my TemplateVM so I
> would enjoy their benefits in all AppVMs.  If I had multiple
> TemplateVMs, I would have to somehow copy those changes to all of them.
>  If I changed a single file, maybe I could write a script that does a
> bunch of qvm-copy commands.  But if I want to make sure things do not
> get out of sync over time due to mistakes, it would help to have a
> management tool of some kind.

Just one word - salt.
Salt your templates, and you can straightforwardly clone, and configure,
those templates with one command.
Using salt also has the benefit that you can sit down at a new machine,
pull down the salt config and recreate your system. No more wondering if
you kept track of what was installed, or whether your scripts contain
all the nice config changes you laboured over.

> 
> However, on second thought, I realize that the only VM with a
> proprietary app in which most of these customizations are valuable is
> the one with Visual Studio Code, in which I do some of my software
> development.  In the others, I pretty much run the proprietary app and
> nothing else because I want to minimize the data exposed to the
> proprietary app.  So as long as there are only two TemplateVMs in which
> the customizations are needed, it may be manageable to copy them
> manually.
> 
> > > Also, I'm low on disk space and
> > > making many templates would make it worse, though maybe it's time that
> > > I just bought a bigger disk.
> > > 
> > 
> > If you use minimal templates, even having a lot of them doesn't take up 
> > much space.
> 
> Good point.  This would likely be appropriate for my VMs that run a
> proprietary app and nothing else, although the video conferencing ones
> will need at least pavucontrol, for example.  For the Visual Studio
> Code VM, I'd need a lot more, but probably still a lot less than the
> ~13G of software in my main TemplateVM that is the union of everything
> needed for all the projects in its TemplateBasedVMs.
> 
> Matt
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/qubes-users/d14988baabf450f6b979f4c68ad4d3589f1c54f6.camel%40mattmccutchen.net.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20201118143426.GA18950%40thirdeyesecurity.org.


Re: [qubes-users] Questions regarding updating a Fedora-template to a new version integer

2020-11-13 Thread unman
On Fri, Nov 13, 2020 at 02:24:27PM +0100, Effie ML wrote:
> I am not sure, it seems so:
> https://www.qubes-os.org/doc/templates/#switching
> 
> You should see the docs on upgrading:
> https://www.qubes-os.org/doc/templates/fedora/#upgrading
> 
> On 11/13/20 2:21 PM, 'M' via qubes-users wrote:
> > "[...] you need to change all AppVMs to the new template."
> > 
> > Is this done by open the "Qube Settings" in the AppVm's and under
> > Template choose the new template, or what is needed to connect the old
> > AppVM's to the new/updated template ?
> > 

There is a nice Template manager tool - look in the System Menu for "manage
Templates for qubes"
You can select multiple qubes and switch to a new template with one
press of a button.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20201113151259.GD14749%40thirdeyesecurity.org.


Re: [qubes-users] How to install Maple in a Fedora-30 template in Qubes OS R4.0 ?

2020-11-13 Thread unman
On Fri, Nov 13, 2020 at 05:35:56AM -0800, 'M' via qubes-users wrote:
> 
> Can I then open a terminal and view the script-file in nano and try to see 
> if it installs a package or place data anywhere else to determine if it's 
> possible to only install it in a AppVM, or is it possible that it isn't 
> written in the installer script that it puts data somewhere else ?
> 

Yes - example - Matlab has an installer file that gives you the option
to choose destination. If /opt then it has to go in TemplateVM; but if
you choose somewhere in /home/user you can install in to an AppVM,
since *that* will persist across reboots.
The choice there comes as option in install process.
You quite likely *will* be able to see this in the script.

Since I'm just a bodger at heart, I would go ahead and run the script in
a Template based qube, and see what happens. If you get the option well
and good; if not you've learnt something in exchange for a few
minutes of your time.
Doing this will *also* allow you to see what packages you may
additionally need to install, so that's a bonus too.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20201113144843.GB14749%40thirdeyesecurity.org.


Re: [qubes-users] How to install Maple in a Fedora-30 template in Qubes OS R4.0 ?

2020-11-09 Thread unman
On Mon, Nov 09, 2020 at 07:21:25PM +, 'awokd' via qubes-users wrote:
> 'M' via qubes-users:
> > I have received this file from a administrator at my workplace:
> > "Maple2020.1LinuxX64Installer.run" which I have downloaded to my work
> > domain.
> > 
> > My question is then: How can I install Maple in a Fedora-30 template in
> > Qubes OS R4.0. ... ?
> > 
> Don't know Maple specifically, but if it's like most packages, you qvm-copy
> it to the template, then install it there. Be aware it will then be
> "installed" in all AppVMs based on that template.
> 

If you're looking for specific advice on how to install it, the first
thing to do is to check what *sort* of file it is. You can do this using
the `file` command.
But from the "run" suffix, I'm guessing it's an installer script. You
would need to check that it is executable by running `ls -l`, or make it
so using `chmod +x`

I don't know Maple: you may or may not be able to install it in a
template. If it is intended to be installed in the home directory, then
you should run it in /etc/skel in the template and install it there.
Then it will appear in the /home/user directory in qubes created from
that template.
Otherwise install it in the home directory in a qube. You can always
clone that to other qubes.

When you've determined the best approach, please document it here so
other users can benefit from your experience.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20201110004855.GA21723%40thirdeyesecurity.org.


Re: [qubes-users] specifying specific dspvm when opening links/files in another appvm?

2020-11-09 Thread unman
On Mon, Nov 09, 2020 at 10:12:14AM -0500, Stumpy wrote:
> I currently have a desktop file in some of my appvms to open links and files
> using the default dspvm. How can I specify an alternate, ie not default,
> dspvm like the whonix dvm, to handle links/files?
> 
> This is what I currently have:
> 
> [Desktop Entry]
> Encoding=UTF-8
> Name=BrowserVM
> Exec=qvm-open-in-dvm %u
> Terminal=false
> X-MultipleArgs=false
> Type=Application
> Categories=Network;WebBrowser;
> MimeType=x-scheme-handler/unknown;x-scheme-handler/about;text/html;text/xml;application/xhtml+xml;application/xml;application/vnd.mozilla.xul+xml;application/rss+xml;application/rdf+xml;image/gif;image/jpeg;image/png;x-scheme-handler/http;x-scheme-handler/https;
> 
> Thanks in advance!
> 

You can change the default dispvm for that qube in qvm-prefs.

If you just want to change it in this desktop file, then change the exec
line:
`Exec=qvm-open-in-vm $dispvm: %u `

You may need to edit the policy file for seamless opening without
prompts.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20201109153928.GA18858%40thirdeyesecurity.org.


Re: [qubes-users] Using an external tablet as mouse

2020-11-09 Thread unman
On Mon, Nov 09, 2020 at 12:56:10PM +0100, Magali Bardet wrote:
> thanks for your answer !
> yes, it is attached to sys-usb.
> 
> qubes.InputMouse contains
> sys-usb dom0 allow,user=root
> $anyvm $anyvm deny
> 
> and
> 
> qubes.InputTablet contains
> $anyvm $anyvm deny
> 
> How do I change qubes.inputTablet ? like qubes.InputMouse ?
> 
> 
> Magali
> 

Yes, try editing the file with the same sys-usb line:
`sys-usb dom0 allow,user=root`
You will, I think, need to do this as root

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20201109120414.GA17564%40thirdeyesecurity.org.


Re: [qubes-users] Using an external tablet as mouse

2020-11-09 Thread unman
On Mon, Nov 09, 2020 at 12:05:29PM +0100, Magali Bardet wrote:
> Hello,
> 
> I have a wacom tablet, and I would like to use it as an external mouse.
> 
> I see it in "System Tools -> Mouse and Touchpad", the device is enable,
> but it doesn't move the mouse pointer.
> 
> Any idea ?
> 
> thanks,
> Magali
> 
> PS:
> 
> - if I use a USB Mouse it works perfectly fine,
> - When I attach the tablet to a vm, I can use the pen for instance with
> xournalpp, but I cannot see where my pointer is.
> 

How is the tablet attached to the Qubes machine? Is it attached to
sys-usb?
Have you authorised the interaction in qubes-rpc policy?
Take a look at /etc/qubes-rpc/policy files, particularly
qubes.InputMouse and qubes.InputTablet

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20201109114116.GB16981%40thirdeyesecurity.org.


Re: [qubes-users] Updating a disposable qube / Can't delete unused qubes

2020-11-08 Thread unman
On Sat, Nov 07, 2020 at 08:53:19PM -0800, Andrew David Wong wrote:
> On 11/7/20 5:35 PM, unman wrote:
> > On Sat, Nov 07, 2020 at 12:50:52PM -0800, Shawn Creighton wrote:
> > > When trying to delete I go to the qube -> qube settings -> delete qube ->
> > > type name of qube -> press enter
> > > 
> > > Doesn't delete it though
> > > 
> > > On Tuesday, November 3, 2020 at 6:04:44 PM UTC-5 a...@qubes-os.org wrote:
> > > 
> > > > On 11/3/20 8:57 AM, 'src11' via qubes-users wrote:
> > > > > How do I update Firefox to the latest version in a disposable qube?
> > > > > 
> > > > 
> > > > Generally, you update it in the TemplateVM:
> > > > 
> > > > 
> > > > https://www.qubes-os.org/doc/software-update-domu/#updating-software-in-templatevms
> > > > 
> > > > > How do I create a new disposable qube?
> > > > > 
> > > > 
> > > > https://www.qubes-os.org/doc/disposablevm/
> > > > 
> > > > > Why am I not able to delete unused qubes? I tried but they're still
> > > > there.
> > > > > 
> > > > 
> > > > What exactly did you do, and what exactly was the behavior you observed?
> > > > 
> > 
> > If you open a terminal in dom0 and type `qvm-delete ` you
> 
> Minor typo: Should be `qvm-remove` rather than `qvm-delete`.
> 

Not a typo - I get used to my own aliases and scripts, which are, of course, 
mine.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20201108111012.GA10886%40thirdeyesecurity.org.


Re: [qubes-users] Updating a disposable qube / Can't delete unused qubes

2020-11-07 Thread unman
On Sat, Nov 07, 2020 at 12:50:52PM -0800, Shawn Creighton wrote:
> When trying to delete I go to the qube -> qube settings -> delete qube -> 
> type name of qube -> press enter
> 
> Doesn't delete it though
> 
> On Tuesday, November 3, 2020 at 6:04:44 PM UTC-5 a...@qubes-os.org wrote:
> 
> > On 11/3/20 8:57 AM, 'src11' via qubes-users wrote: 
> > > How do I update Firefox to the latest version in a disposable qube? 
> > > 
> >
> > Generally, you update it in the TemplateVM: 
> >
> >
> > https://www.qubes-os.org/doc/software-update-domu/#updating-software-in-templatevms
> >  
> >
> > > How do I create a new disposable qube? 
> > > 
> >
> > https://www.qubes-os.org/doc/disposablevm/ 
> >
> > > Why am I not able to delete unused qubes? I tried but they're still 
> > there. 
> > > 
> >
> > What exactly did you do, and what exactly was the behavior you observed? 
> >

If you open a terminal in dom0 and type `qvm-delete ` you
will either delete the qube or see an error message.
You may find that the qube is not unused after all.

Try it and report back.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20201108013531.GA8717%40thirdeyesecurity.org.


Re: [qubes-users] Fedora and Debian has ARM64 versions. What about Qubes?

2020-10-12 Thread unman
On Mon, Oct 12, 2020 at 05:04:01AM -0700, load...@gmail.com wrote:
> Does anyone know if the developers are planning to release a version for 
> ARM64?
> 

Not aware of any plans. There is work on a port to ppc64
https://github.com/QubesOS/qubes-issues/issues/4318

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20201012144953.GB22860%40thirdeyesecurity.org.


[qubes-users] Focal template and packages

2020-10-05 Thread unman
I've put in PRs to allow for build of focal packages and template, on
Fedora 32 build system. These should be merged soon, and will allow you
to select Focal as a target in ./setup, run make get-sources, make qubes-vm, and
make template.

As always, I recommend that you build from source yourself - it really
isn't difficult.
If you are not sure about building for yourself, or don't have time,
I've made a pre-built template available at https://qubes.3isec.org/Templates

All my templates, packages and repositories are signed with
my Qubes Signing key - you can get this from any keyserver. You
should check this against other sources - the Qubes-Users mailing list, 
[GitHub](https://github.com/unman/unman/blob/master/gpg-keys.asc), maybe another
keyserver over Tor.

You should do something like this, in a disposableVM:
Download the template from https://qubes.3isec.org/Templates

Once you have downloaded and confirmed my "Qubes OS signing key", add it to
your rpm keyring:
`sudo rpm --import `

Check the signature on the template:
`rpm -K `
If all is well you will see "digests signatures OK"

Once you are satisfied, install the Template.
To do this you will need to copy it to dom0. In dom0 run:
`qvm-run -p   'cat ' > focaltemplate`

Then install, in dom0 :
`sudo dnf install focaltemplate`



You can also add the repository to a StandAlone focal qube, and install
normal range of Qubes packages, for better integration with the system.

Cheers

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20201005140147.GA15434%40thirdeyesecurity.org.


Re: [qubes-users] How to resize bionic-desktop template

2020-10-04 Thread unman
On Sun, Oct 04, 2020 at 04:35:27PM +0200, roger paranoia wrote:
> Hello
> 
> I have another question relating this.
> That command resizes the logical volume and that's ok, but... the problem
> is that partitions inside that volume doesn't get resized.
> 
> What I've done is:
> Installing the bionic-desktop template
> Clone the template to bionic-desktop_test
> Resize the logical volume with "qvm-volume resize bionic-desktop_test:root
> 20G
> 
> Now I start the template, open a terminal on it and run:
> user@localhost:~$ lsblk
> NAMEMAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
> xvda202:01 18.6G  0 disk
> ??xvda1 202:11  200M  0 part
> ??xvda2 202:212M  0 part
> ??xvda3 202:31  9.8G  0 part /
> xvdb202:16   12G  0 disk /rw
> xvdc202:32   1   10G  0 disk
> ??xvdc1 202:33   11G  0 part [SWAP]
> ??xvdc3 202:35   19G  0 part
> xvdd202:48   1  500M  1 disk
> 
> So the volume was resized (18.6G) but the root partition is still 9.8G and
> that means... there's a limit for the software that can be installed in
> there.
> I can't resize the partition from inside the template and I can't find how
> resize specifically the xvda3 partition inside that particular logical
> volume.
> 
> Any ideas on how to do it?
> 
> Thanks in advance!
> 

The simplest route for you would be to use a tool like gparted:
`apt install gparted`

Open gparted - you will be asked if you want to make the extra
space available - say "Yes".
Then in the GUI, expand /dev/xvda3 to use the available space.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20201004155851.GA9906%40thirdeyesecurity.org.


Re: [qubes-users] Mount private appvm volumes to dom0 or access directly

2020-10-02 Thread unman
On Fri, Oct 02, 2020 at 05:03:34PM +0200, roger paranoia wrote:
> Hello
> 
> My qubes os system got stucked at "Started Accounts Service." and I want to
> backup the /home date on different qubes to an external usb medium.
> 
> I've found this link:
> https://qubes-os.discourse.group/t/for-backing-up-data-how-to-connect-a-usb-drive-directly-to-dom0/324/3
> 
> So that gives a me a clue that private volumes can be accessed and mounted.
> Where or on what directory are private volumes stored? How can I access
> them directly from a dom0 terminal? How can I mount them to a dom0
> directory?
> 
> Thank you very much
> 

You can find the private volumes under /dev/qubes_dom0.
You can mount them directly from there, (although these are actually
links to volumes under /dev/ itself. Try , e.g 
ls -l /dev/qubes_dom0/vm-work-private .

You can simply mount these like you would mount *any* volume:
sudo mount /dev/qubes_dom0/vm-work-private  /mnt 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20201002153025.GA31787%40thirdeyesecurity.org.


Re: [qubes-users] How to resize bionic-desktop template

2020-09-30 Thread unman
On Wed, Sep 30, 2020 at 11:46:45AM +0200, roger paranoia wrote:
> Hello
> 
> I have tried to resize the bionic-desktop template through the usual "Qube
> Settings" menu but it actually doesn't resize. I've tried to look for
> information about this on the internet but I couldn't get a clue on how to
> do it.
> Does anyone know how to do it?
> 
> Thanks in advance!
> 

qvm-volume resize bionic-desktop:root 

new size can be e.g 50G

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200930142929.GB19859%40thirdeyesecurity.org.


Re: [qubes-users] Can't start apps from menu/app finder but can from dom0?

2020-09-28 Thread unman
On Sun, Sep 27, 2020 at 10:54:46PM -0400, Stumpy wrote:
> On 2020-09-27 21:42, Stumpy wrote:
> > On 2020-09-27 19:59, Stumpy wrote:
> > > The subject says most of it. I can start apps from a dom0 terminal
> > > with qvm-run but cant figure why I cant do it via the xfce menu or
> > > app finder. I tried running using qvm-sync-appmenus appvm but that
> > > didnt help. Thoughts?
> > > 
> > The last two times (just tried rebooting the system) i tried to start an
> > app up from the dom0 terminal now i cant even do that... so, is it
> > possible to do something like mount an appvm so i can copy the important
> > info off of it?
> > 
> new observation, it seems to be related to the template, debian 10 in this
> case.
> I switched the template for the aapvm i wasnt able to start up and viola! it
> opened up, then i tried to make a new appvm based on the deb10 template and,
> no go, nothing would start?
> what about a template would cause an appvm not to start?
> 

What have you done to the template?
There are many things you might have done , including deleting (by
mistake) Qubes packages etc. This is why it's generally a good idea to
keep a spare vanilla template hanging about, so you can rebuild as
necessary.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200928131533.GC7642%40thirdeyesecurity.org.


Re: [qubes-users] Firewall issue

2020-09-22 Thread unman
On Tue, Sep 22, 2020 at 05:05:35AM +, 'src11' via qubes-users wrote:
> When I go into any qube settings for the firewall there is only an option to 
> create and edit rules for outgoing traffic, nothing at all for incoming 
> connections. Is that right? When I look at screenshots online it shows 
> options for creating both outgoing and incoming connection rules. Latest 
> version of Qubes.
> 
The Qubes firewall does not support changes to incoming connections. For
that you need to start manually adjusting nftables.
By default, no new inbound connections are allowed, only connected
traffic.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200922122402.GC6563%40thirdeyesecurity.org.


Re: [qubes-users] startx over ssh leads to many new Qubes windows

2020-09-19 Thread unman
On Sat, Sep 19, 2020 at 12:50:35PM +, 'qubesanon' via qubes-users wrote:
> Hello! I am trying to start X on a different machine (FreeBSD if it matters) 
> over SSH in a Qube VM (nothing fancy, just a Qube based on Fedora 32).
> 
> This works, but every window I open ends up being a new window in Qubes. It's 
> worse than that because UI components also end up as new windows in Qubes. 
> For example, the Xfce panel ends up as a new window too.
> 
> What I'd like to happen is for everything to open in a single window, so 
> there's just a single Qube window and anything that happens in that 
> environment stays in that window. Is that doable?
> 
> Sorry I couldn't find anything in the documentation for this.
> 
> Here's exactly what I do:
> $ ssh -X me@host.
> 
> $ /usr/local/bin/startxfce4 --with-ck-launch
> 
> And then chaos ensues.
> 
> Appreciate any help here, thanks!
> 

It's doing exactly what you are asking to do. The client is forwarding
everything to the Xserver you are sitting at.

What you *want* to do is to see the remote desktop in a window on the
Qubes desktop.
For that you should use a remote desktop tool like vnc, and tunnel it
over ssh. (Search for vnc over ssh and you will find many online
guides.)

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200919232804.GC24307%40thirdeyesecurity.org.


Re: [qubes-users] Adding new kernels to iso?

2020-09-19 Thread unman
On Sat, Sep 19, 2020 at 04:00:38PM +0200, Ond??ej Fiala wrote:
> I tried opening the link in question on three different occasions and it 
> required me to log in on all of them, which is why I asked for the summary.
> 
> I agree that linking to a resource that does not (even occasionally) require 
> login should be preferred. People looking to Qubes for security often do so 
> to have a secure environment for privacy-enhancing tools such as Tor, so it's 
> reasonable to expect that a lot of them don't have Google account.On Sep 19, 
> 2020 14:53, unman  wrote:
> >
> > On Fri, Sep 18, 2020 at 09:39:30PM +0200, Ond??ej Fiala wrote: 
> > > Please read more carefully next time -- "Since I don't have Google 
> > > account 
> > > which seems to be required to view the initial discussion (*as linked in 
> > > the 
> > > first post of the thread*)". The first post says "continuing from 
> > > discussion 
> > > at [link to Google groups]" without explaining anything... 
> > > 
> >
> > It really isn't true that you need a google account to read google 
> > groups. 
> > I connect over Tor, and rarely use groups- much prefer to use the mail 
> > archive ( and you could easily have done this instead of posting snitty 
> > comments). On the rare occasions that I *have to* use google groups, 
> > other than enabling jscript, I connect just fine. 
> > I realise that other users have reported a log in requirement - all I'm 
> > saying is that it isn't universally applied. 
> >
> > For the record, google groups for qubes-users is available at: 
> > https://www.mail-archive.com/qubes-users@googlegroups.com/ 
> > and this provides a searchable archive 
> >
> > It would be desirable if every one linked to the mail archive - is there 
> > **any** chance that this could become the default? 
> > (Also, the documentation should do this by default too.) 

Did you do this from the same qube at the same IP address? It's just not
my experience using variety of qubes under Tor. If I get a login, I just
fire up another qube and try again.

mail-archive.com undoubtedly helps, and I think it should be the default
reference in the docs. I believe that these lists are now echoed to the
Forum - perhaps "will be echoed" - I'm not sure of that: I mean I'm not
sure of the benefit.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200919164723.GB30010%40thirdeyesecurity.org.


Re: [qubes-users] Adding new kernels to iso?

2020-09-19 Thread unman
On Fri, Sep 18, 2020 at 09:39:30PM +0200, Ond??ej Fiala wrote:
> Please read more carefully next time -- "Since I don't have Google account
> which seems to be required to view the initial discussion (*as linked in the
> first post of the thread*)". The first post says "continuing from discussion
> at [link to Google groups]" without explaining anything...
> 

It really isn't true that you need a google account to read google
groups.
I connect over Tor, and rarely use groups- much prefer to use the mail
archive ( and you could easily have done this instead of posting snitty
comments). On the rare occasions that I *have to* use google groups,
other than enabling jscript, I connect just fine.
I realise that other users have reported a log in requirement - all I'm
saying is that it isn't universally applied.

For the record, google groups for qubes-users is available at:
 https://www.mail-archive.com/qubes-users@googlegroups.com/
and this provides a searchable archive

It would be desirable if every one linked to the mail archive - is there
**any** chance that this could become the default?
(Also, the documentation should do this by default too.)

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200919125345.GE28762%40thirdeyesecurity.org.


Re: [qubes-users] sys-firewall

2020-09-17 Thread unman
On Thu, Sep 17, 2020 at 05:46:16AM -0700, memoo mena wrote:
> can i reinstall sys-firewall and how 
> can  i cheek my qubes os it works properly
> need some videos to learn how use qubes os
> from beginning to highest
> 
> 
sys-firewall is just a netvm - create a new qube, set its netvm to
sys-net, and set the "provides-network" property.
The default has memory 500, a green label, and is set to autostart.

I'm not sure how you would check Qubes works properly except by using
it.  At a minimum you should be able to get online, open a browser and
open disposableVMs.

There is a guide at https://www.qubes-os.org/intro/ and there's a link
at the bottom of that page to "Video tours".
I'm told there is now a wide collection of videos on YouTube.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200917142421.GB18318%40thirdeyesecurity.org.


Re: [qubes-users] Split PGP threat model questions

2020-09-16 Thread unman
On Thu, Sep 17, 2020 at 12:41:56AM +, uro2204nk81jeorn wrote:
> Let's say I have created a general purpose domain for storing EVERY subkey I
> create, what kind of implications could this have? Am I leaking multiple
> identities every time I use the gpg wrapper?
> 
> Where can I read deeper into the design as well?

I'm assuming you have read:
https://www.qubes-os.org/doc/split-gpg

The "Discussions" referenced at the bottom of that page are a good
guide.

As to the risks in storing all your keys in the same qube, there *is* a
danger, in that an attacker who gained access to a client qube would be
able to see your subkeys and therefore link identities.
Since the overhead in creating multiple pgp qubes is small, I would do that.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200917011830.GA14990%40thirdeyesecurity.org.


Re: [qubes-users] Has anyone had a qube compromised?

2020-09-14 Thread unman
On Fri, Sep 11, 2020 at 11:03:15AM +, taran1s wrote:
> 
> 
> unman:
> 
> This is interesting. Can you be more specific in regards of settings you
> use? How do you set the tripwire for to run against network connected
> qubes? You also mentioned using mutt in an offline qube. Can you
> elaborate more on this too please? Is the mutt PGP friendly and more
> safer option than Thunderbird?
> 

This warrants a much more detailed answer than I have time for now.

Tripwire - install in templates, store db in offline vault - I'm looking
for changes in /rw, as well as "normal" directory structures.

Mutt - varies according to provider. I set this up when I was first
playing with Qubes.
I use 3 qubes: one disposableVM to pick up mail - either offline imap or
rsync mail dirs. That qube is minimal, connects over Tor, and is restricted
to mail provider.
If the sync is in Mbox format, you can use mb2md to convert to Maildir
format.
The mail dirs are synced in to my mutt qube which is offline. I use
qrexec for this.

Mutt is a great MUA, and has good integration with PGP. I use split-gpg,
of course. I use notmuch integrated with mutt to keep on top of email.

For sending mails I use msmtp. Actually I queue outgoing in the Mutt
qube, and rsync the queues (over qrexec) in to a sender disposableVM,
which has outgoing traffic restricted to SMTP host. Over Tor of course.

So the fetch and send are done using disposableVMs, and the message
queues synced in and out of the offline mutt queue over qrexec. The
disposableVMs use minimal templates, have restricted network access,
and use different network routes.
The mutt qube is also based on a minimal template, and has a mailcap
that effectively loads almost all attachments in offline disposableVMs.
I have keyboard shortcuts to trigger the receive and send sides - I
suppose you could do this with cron jobs, but I prefer not to use
automatic processes.

That probably raises a few more questions. If it does, ask and I'll try to
provide some specifics.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200915032523.GF1783%40thirdeyesecurity.org.


Re: [qubes-users] Re: saltstack: user specific pillars in qubes

2020-09-13 Thread unman
On Sun, Sep 13, 2020 at 10:31:31AM +0100, lik...@gmx.de wrote:
> > > 
> > 
> > Have you enabled the pillar in /srv/salt/user_pillar/top.sls?
> > 
> > Example:
> > 
> > In /srv/salt/user_pillar/top.sls I have a stanza:
> > user:
> >'target':
> >  - get
> > 
> > In /srv/salt/user_pillar/get.sls, I set the pillar:
> > host: www.qubes-os.org
> > 
> > Then I have the state and top files, get.sls and get.top:
> > get file:
> >cmd.run:
> >  - name: wget {{pillar['host'] }}
> > 
> > base:
> >target:
> >  - get
> > 
> > 
> > qubesctl --skip-dom0 --targets=target state.apply get
> > 
> 
> First of all I'd like to thank you for your answer unman.
> 
> I've tried your example (and after modifying it to be able to run it) I get 
> exact the same error as before.
> 
> Here's the setup:
> 
> > Have you enabled the pillar in /srv/salt/user_pillar/top.sls?
> As far as I know, I have only to enable state.top files. But I have a file 
> like you suggest located in /srv/salt/user_pillar/:
> 
> > In /srv/salt/user_pillar/top.sls I have a stanza:
> > user:
> >'target':
> >  - get
> 
> Ok!
> 
> > In /srv/salt/user_pillar/get.sls, I set the pillar:
> > host: www.qubes-os.org
> 
> Ok!
> 
> > /srv/salt/user_salt/get.sls
> > get file:
> >cmd.run:
> >  - name: wget {{pillar['host'] }}
> 
> Ok!
> 
> > /srv/salt/user_salt/get.top
> > base:
> >target:
> >  - user_salt.get
> 
> This one I had to modify as the get.sls is located in "/srv/salt/user_salt/". 
> Above is already the modified version (user_salt is prefixed). I also enabled 
> this top file by executing:
> sudo qubesctl top.enable user_salt.get
> 
> Now, let's run this:
> 
> > qubesctl --skip-dom0 --targets=target state.apply get
> 
> When I'm executing this, I get the error logged in 
> /var/log/qubes/mgmt-target.log:
> calling 'state.apply'...
> 2020-09-13 10:08:14,729 output: target:
> 2020-09-13 10:08:14,730 output: - Rendering SLS 'base:user_salt.get' 
> failed: Jinja variable 'salt.utils.context.NamespacedDictWrapper object' has 
> no attribute 'host'
> 
> When I'm executing this (additional parameter 
> --pillar-root=/srv/salt/user_pillar/):
> sudo qubesctl --skip-dom0 --targets=target state.apply 
> --pillar-root=/srv/salt/user_pillar/
> 
> The result is the same as I described before:
> target: ERROR (exception list index out of range)
> 
> I also tried to modify the pillar top file to meet the different location:
> > In /srv/salt/user_pillar/top.sls I have a stanza:
> > user:
> >'target':
> >  - user_pillar.get
> 
> But this haven't changed the results.
> 

OK, it might have been better if you had NOT modified my example, as you
should then have been able to verify that user pillars can be referenced
in this way.
I always find it better to take one small step at a time when
troubleshooting or trying to learn something new.

In the new case, you are using the user environment. I would try the
following:
/srv/salt/user_salt/get.top
user:
   target:
 - get

/srv/salt/user_salt/get.sls
get file:
   cmd.run:
 - name: wget {{pillar['host'] }}

qubesctl --skip-dom0 --targets=target state.apply saltenv=user get


You might like to look at:
https://docs.saltstack.com/en/latest/ref/states/top.html#environments

New environments can be defined in
`/etc/salt/minions.d/f_defaults.conf`, but I rarely do this in Qubes.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200913141831.GA25257%40thirdeyesecurity.org.


Re: [qubes-users] Multi Media update fails Qubes 4

2020-09-11 Thread unman
On Fri, Sep 11, 2020 at 04:40:08AM -0700, William Fisher wrote:
> I have the Multi Media VM installed including Chrome, Spotify, Musique, VLC 
> player, etc.  Qubes Updater keeps saying it needs updates but the updates 
> always fail. It always comes back with 1 changed 2 failed.
> 
> Error on updating t-multimedia: Command '['sudo', 'qubesctl', 
> '--skip-dom0', '--targets=t-multimedia', '-show-output', 'state.sls', 
> 'update.qubes-vm']' returned non-zero exit status 20
> 
>ID: dsa-4371-update
>  Function: cmd.script
> Result: True
> Comment: Nothing to do
>   
> 
>ID: update
>  Function: pkg.uptodate
> Result: False
> Comment: w:target Packages (main/binary-amd64/Packages) is configured 
> multiple times in /etc/apt/sources.list.d/google-chrome.list:3 
> and/etc/apt/sources.list.d/google.list:1
> 
> I have numerous other packages listed multiple times but I can't figure out 
> how to copy the text displayed in dom0 Updater to this VM.
> 
> Any ideas?  
> Is this a common problem?
> How can I get updates on multi-media, especially Chrome and VLC Media 
> Player? 
> 
I see no reason to copy the text to the VM.
I would try opening the template you are using and removing the
duplicate entries: the files to review are clear, and it shouldnt be
difficult for you to delete as necessary. (You'll need to do this as
root.)
I would then try an update in the template.
Then try the Qube Updater.

I'm not sure what you mean by "numerous other packages listed multiple
times" or why you would want to do this.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200911124821.GB12791%40thirdeyesecurity.org.


Re: [qubes-users] Tsurugi on Qubes

2020-09-09 Thread unman
On Wed, Sep 09, 2020 at 07:16:44PM +0200, Barry Du Plessis wrote:
> Hi Everyone
> Has anyone had any luck with installing Tsurugi (
> https://tsurugi-linux.org/index.php) on Qubes?
> 
> Thanks
> 
> Barry
> 

Yes, I have it as an HVM Template, so I can spin up disposable
instances at will.

Installation was quite straightforward. Standard HVM, with 40GB
allocated to system disks and 4GB RAM. Boot the live image and then
select to install to /dev/xvda.
Once installation completes, restart the HVM. I set the network details
manually, and did a standard "vesa" config for X. (This is in the docs
under linux-hvm-tips)

Since it's based on Ubuntu, you can install qubes packages to provide
some level of interaction with other qubes - qvm-copy, qvm-open etc.

I have a normal template too, which I may be able to post if you are
interested. Somewhat hampered by the fact that Tsurugi don't provide (as
yet) full build details, which is odd.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200910013052.GA3693%40thirdeyesecurity.org.


Re: [qubes-users] Has anyone had a qube compromised?

2020-09-08 Thread unman
On Tue, Sep 08, 2020 at 09:13:47PM +0200, Qubes wrote:
> On 9/7/20 2:12 AM, unman wrote:
> > On Sun, Sep 06, 2020 at 06:55:01PM +0200, Qubes wrote:
> > > On 9/6/20 5:32 PM, unman wrote:
> > > > On Sun, Sep 06, 2020 at 11:12:31AM -0400, Demi M. Obenour wrote:
> > > > > In all of my time using QubesOS, I have never had reason to believe
> > > > > that a qube was compromised.  Has anyone here had a qube compromised?
> > > > > 
> > > > > Sincerely,
> > > > > 
> > > > > Demi
> > > > > 
> > > > 
> > > > I have had occasion to set a honeypot and use Qubes as a classic
> > > > Internet-inna-box - ideal for such use, and very instructive. But I
> > > > guess that wasn't what you were interested in.
> > > > In normal use, both myself and colleagues have seen compromised qubes.
> > > > 
> > > Hi Unman
> > > 
> > > How did you know you're qube was compromised, can you give some details?
> > > 
> > 
> > snort and tripwire.
> > 
> > Other IDS are available.
> > 
> Hi Unman
> 
> What I mean is what made you suspicious to use a tripwire and snort?

I run them on most of my Qubes installs, almost out of habit.
Because I salt my qubes, its relatively easy to run tripwire against
network connected qubes
But the way in which Qubes allows one to separate out activities really
does minimise risk. Example: read email in mutt in offline qube with
minimal template - any attachments are opened in offline disposableVM.
Anything I want to keep is transferred to an offline storage qube ,
again with no significant programs installed. In this sense, it doesn't
matter if attachments have malware  because the infection risk is
minimised.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200909004740.GA5118%40thirdeyesecurity.org.


Re: [qubes-users] problems with trackpad during installation

2020-09-08 Thread unman
On Tue, Sep 08, 2020 at 05:18:21AM +, dnDG5W wrote:
> I have a standard trackpad. It works perfectly fine under debian/ubuntu.
> However, during installation, it completely stops working.
> 
> Any ideas?
> 

A bit light on detail here, but I'll see what I can do absent any
information on model or BIOS version.
Did you create a sys-usb? Is the "standard trackpad" presented as a USB
device? (It happens)
Check the output of lspci in dom0 and lsusb in dom0 and sys-usb.
`ls /sys/module/psmouse/driver/*/` may also give useful information -
look in the uevent file.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200908142150.GD2436%40thirdeyesecurity.org.


Re: [qubes-users] Has anyone had a qube compromised?

2020-09-06 Thread unman
On Sun, Sep 06, 2020 at 06:55:01PM +0200, Qubes wrote:
> On 9/6/20 5:32 PM, unman wrote:
> > On Sun, Sep 06, 2020 at 11:12:31AM -0400, Demi M. Obenour wrote:
> > > In all of my time using QubesOS, I have never had reason to believe
> > > that a qube was compromised.  Has anyone here had a qube compromised?
> > > 
> > > Sincerely,
> > > 
> > > Demi
> > > 
> > 
> > I have had occasion to set a honeypot and use Qubes as a classic
> > Internet-inna-box - ideal for such use, and very instructive. But I
> > guess that wasn't what you were interested in.
> > In normal use, both myself and colleagues have seen compromised qubes.
> > 
> Hi Unman
> 
> How did you know you're qube was compromised, can you give some details?
> 

snort and tripwire.

Other IDS are available.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200907001259.GB24691%40thirdeyesecurity.org.


Re: [qubes-users] saltstack: user specific pillars in qubes

2020-09-06 Thread unman
On Sun, Aug 30, 2020 at 11:36:12AM +0100, lik...@gmx.de wrote:
> Hi!
> 
> What's the correct way to use user specific pillars in qubes salt stack?
> 
> My pillars are located in
> /srv/salt/user_pillar/
> 
> To enable during a run them I'm running:
> sudo qubesctl --show-output state.highstate 
> --pillar-root=/srv/salt/user_pillar/
> 
> This works quite well, but when I'm running it towards a target:
> sudo qubesctl --show-output --target myTarget state.highstate 
> --pillar-root=/srv/salt/user_pillar/
> 
> I receive this error:
> ERROR (exception list index out of range)
> 
> 
> Any ideas to investigate? Should pillar files be enabled in a different way?
> 
> 
> Thanks in advance! P.
> 

Have you enabled the pillar in /srv/salt/user_pillar/top.sls?

Example:

In /srv/salt/user_pillar/top.sls I have a stanza:
user:
  'target':
- get

In /srv/salt/user_pillar/get.sls, I set the pillar:
host: www.qubes-os.org

Then I have the state and top files, get.sls and get.top:
get file:
  cmd.run:
- name: wget {{pillar['host'] }}

base:
  target:
- get


qubesctl --skip-dom0 --targets=target state.apply get

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200907000719.GA24691%40thirdeyesecurity.org.


Re: [qubes-users] Has anyone had a qube compromised?

2020-09-06 Thread unman
On Sun, Sep 06, 2020 at 11:12:31AM -0400, Demi M. Obenour wrote:
> In all of my time using QubesOS, I have never had reason to believe
> that a qube was compromised.  Has anyone here had a qube compromised?
> 
> Sincerely,
> 
> Demi
> 

I have had occasion to set a honeypot and use Qubes as a classic
Internet-inna-box - ideal for such use, and very instructive. But I
guess that wasn't what you were interested in.
In normal use, both myself and colleagues have seen compromised qubes.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200906153257.GB22327%40thirdeyesecurity.org.


Re: [qubes-users] Re: HCL DELL PRECISION M4800

2020-08-31 Thread unman
On Sun, Aug 30, 2020 at 12:17:17PM -0700, Scott Mason wrote:
> Solved:
> 
> I have found this and I think it would serve the entire Qubes community 
> when checking hardware requirements:
> 
> *How do I know if my CPU supports VT x or AMD-V?*
> 
> Method 3: Visit Intel???s product specification site. Visit Intel???s product 
> specification site (*https://ark.intel.com/* ) and 
> follow these steps:
> 
>1. 
>
>Once on the site, enter the processor information you noted above in the 
>search box located on the right-hand side of the page. 
>2. 
>
>Under ???Advanced Technologies??? on the product page for your processor, 
> *you 
>will see* whether Intel?? Virtualization Technology (VT-x) is supported 
>or not.   It will show *Yes* or *No*
>
> *If you do this before you purchase or attempt to install Qubes you will 
> have some assurance that Qubes will work.*
> 

This resource has been mentioned regularly on the mailing list, and is
on the hardware requirements page in the docs.
Unfortunately it only provides *part* of the assurance that is needed -
we do see people who have CPU capable of VT-x, but are unable to get
it working.
The thing is that you need **both** a board **and** a CPU which are VT-x
or AMD-V capable.
The usual advice is that you ask the manufacturer before purchase -
that way you have iron clad guarantee of getting money back if support
is not available.
Or select model from HCL.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200831114930.GA18243%40thirdeyesecurity.org.


Re: [qubes-users] No more Qubes available (except dom0) - How do I get them back?

2020-08-30 Thread unman
On Thu, Aug 27, 2020 at 02:32:33PM -0700, 'qubes os' via qubes-users wrote:
> I need help recovering my OS!
> 
> When I have fully started QubesOS, only *dom0 is up and ready* for use - 
> but *no Qube is booted up* whatsoever.
> 
> When I then try to start a Qube manually from the Qube Manager, i.e. 
> "sys-ubs", then I get the error message:
> 
> "*volume qubes_dom0/vm-fedora-29-root missing*"
> 
> But I did certainly not delete anything from my system, so it cannot be 
> missing. How can I get this up and running again?
> 
> (Btw, I got here because I had the following bug and ran the explained 
> procedure: https://github.com/QubesOS/qubes-issues/issues/5160)
> 
> Thank you very much for any help!
> 

This tells you that the fedora-29 template is broken.
You could copy the file from your installation media in to dom0 and
install it by hand. (If necessary this may require that you allow dom0
to access the USB devices, or that you boot from a live system.)

Do you have recent backups?

You can access the private data in each qube, as they are stored in
volumes that you can find under /dev/dm-XXX.
The familiar names are under /dev/qubes_dom0 - `ls -l` will show you the
"real" volume under /dev

You can try mounting important private disks and copying out the data,
to be on the safe side.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200830113255.GA12213%40thirdeyesecurity.org.


Re: [qubes-users] Qubes issue 953 "qvm-screenshot-tool"

2020-08-29 Thread unman
On Sat, Aug 29, 2020 at 08:19:54AM -, alm via qubes-users wrote:
> Hi. I need help in regards to issue 953.
> 
> https://github.com/QubesOS/qubes-issues/issues/953
> 
> The link in the text description:
> "The ability send dom0 screenshots directly to an AppVM/DispVM from the
> screenshot app is an oft-requested feature (see below). The ability to
> transfer saved screenshot files from dom0 to other VMs is already
> available, but it is neither obvious nor easy for most users to do this."
> 
> is:
> "already available"
> 
> and leads to:
> https://github.com/QubesOS/qubes-issues/issues/CopyToDomZero
> 
> which when opened:
> "No results matched your search. You could search all of GitHub or try an
> advanced search."
> 
> Does anybody have a working link? Thanks in advance!
> 

That's an old issue, and the link relates to old material.
The link that will help is https://www.qubes-os.org/doc/copy-from-dom0/

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200829121732.GD6519%40thirdeyesecurity.org.


Re: [qubes-users] sys-firewall based on debian-10-minimal not recognized

2020-08-22 Thread unman
On Sat, Aug 22, 2020 at 02:01:54AM -0700, 54th Parallel wrote:
> On Friday, 21 August 2020 at 16:58:48 UTC+8 54th Parallel wrote:
> 
> > I'm having the same issue with disposable firewalls built on 
> > debian-10-minimal, with the minimum amount of packages, on 
> > brand-spanking-new installations (plural) being unreliable firewalls. They 
> > sometimes function but not all the time--and this is what's scary, because 
> > there's no way of knowing without manually checking all the time. The 
> > warning prompts when editing firewall rules aren't useful indicators since 
> > they always appear regardless of whether filtering is happening.
> >
> > I ran systemctl in both and found that qubes-firewall.service is not 
> > running in either, despite having manually activated them. I'm not a 
> > technical person, but this seems like a pretty critical issue to me 
> > (unreliable firewall with no indicator)--a warning about using minimal 
> > debian as templates for firewalls should be put up somewhere highly visible.
> >
> > This unreliability has been bugging me for a while and I've been testing 
> > and testing (to the best of my abilities) before realizing that this is 
> > almost certainly not a user issue, so Sven, the OP,  probably either ran 
> > into the issue again, didn't know about his deactivated firewalls, or 
> > didn't report the issue. 
> >
> 
> After some more probing around, I think I've found the issue, and that what 
> I wrote earlier contains inaccuracies. The unreliable firewall might not be 
> a debian-10-minimal issue, though the warning prompt that appears whenever 
> editing firewall rules in a connected VM is. 
> 
> My setup has two firewalls--one behind sys-net and another behind a VPN VM. 
> Though the two firewalls are clones of one another, the sys-net firewall 
> works (responds to rules set in appVMs) and the proxyVM firewall doesn't. 
> This is what caused me to think that deb-10-min firewalls in general are 
> unreliable--some things are connected to the net-firewall (sometimes) and 
> most are connected to the VPN-firewall. This makes it look like the 
> firewalls work sometimes. 
> 
> I have two laptops running Qubes with the same setup. Of the four 
> firewalls, all with qubes-firewall explicitly enabled, only one actually 
> has the qubes-firewall.service show up after typing 'systemctl | grep 
> firewall'. Each of these firewalls were created in fresh but updated 
> installations of 4.0.3 with the absolute minimum amount of packages 
> (qubes-core-agent-passwordless-root (so I can configure sudo prompt), 
> qubes-core-agent-networking, apparmor*) and the typical settings, along 
> with qubes-vm-hardening (vm-boot-protect enabled).
> 
> Any insight into this would be greatly appreciated since this is a massive 
> headache for me.
> 

To deal with the question here, I use debian minimal templates
extensively, (NOT with qubes-vm-hardening), and have never seen this
issue - neither the unreliable firewall nor the warning prompts issue.
I've asked fellow users who also use debian-minimal and they do no not
recognise the issue.
So either it's qubes-vm-hardening, or your proxyVM setup.
Insight will follow (perhaps) if you give more information. How have you
set up the proxyVM? Since that does not work n either machine we should
be able to dig into that problem relatively easily.
What is different about the setup and laptop where the "sys-net
firewall" (please explain what this means) does NOT work compared to the
one where it DOES work?

For the sake of sanity I suggest you answer in ONE place and then
cross-post the solution, rather than pursue the issue in both the
forum and the mailing list. And please don't post it in reddit too.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200822151042.GB29426%40thirdeyesecurity.org.


Re: [qubes-users] open app in a specified workspace

2020-08-18 Thread unman
On Tue, Aug 18, 2020 at 11:34:21PM +0200, Vadim Tambovtsev wrote:
> Hello.
> 
> For example, "qvm-run untrusted google-chrome" opens Chrome browser in the
> current workspace.
> 
> How to generalise this command to control the workspace the browser opens
> in. To be able, for example, open Browser in Workspace2, open TextEditor in
> Workspace3 by a single script.
> 
> Thank you.
> 

In KDE you can leverage Activities and Desktops, to provide exactly this
functionality.
It's simple to set up such rules - right click on the title bar, and
select Window or Application Settings. You can then match windows by
class or title (useful in Qubes), and set size, position, desktop
and Activity where the window will appear.
You can colour code each Activity, to match the colours used per
security domain, or have activities for different applications, as you
suggest.
Try it.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200819011640.GA8337%40thirdeyesecurity.org.


Re: [qubes-users] Adding code/packages to an OS

2020-08-16 Thread unman
On Sun, Aug 16, 2020 at 10:34:41PM +, signupforemails via qubes-users wrote:
> I've noticed I can't add a missing command packets to an appVM. I drilled 
> down to adding the software-common package, $ sudo apt-get install -y 
> software-properties-common
> but It didn't work. So, I tried it in the respective template and it did 
> work. However, that packet is still not avalable in the appVM. I closed and 
> retarted the appVM and those commands were still abscent nor was I able to 
> install the commands as previously mentioned.
> 
> Initially, the appVM was looking in the wrong repository of a different OS 
> when the appVM asked if it could install the missing sudo command.
> 
> This is the message I noticed: Couldn't resolve host name for 
> https://mirrors.fedoraproject.org/metalink?repo=fedora-30=x86_64 [Could 
> not resolve host: mirrors.fedoraproject.org]
> 
> So, either I install the commands in the appVM or I find a way to change the 
> query destination for the missing command codes. Any suggestions?
> 
> thanks,
> 

It sounds as if you need to make sure that you install the package in
the template used by the appVM.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200817001250.GC28867%40thirdeyesecurity.org.


Re: [EXT] Re: [qubes-users] Google requiring login to access qubes-users

2020-08-16 Thread unman
On Mon, Aug 17, 2020 at 12:41:27AM +0200, Ulrich Windl wrote:
> On 8/16/20 2:29 AM, unman wrote:
> > On Sat, Aug 15, 2020 at 07:39:19PM +, tetrahedra via qubes-users wrote:
> > > WHen I try to access the Google Groups qubes-users site, sometimes (circa
> > > 50%) I'm presented with a Google login prompt and can't access the
> > > qubes-users group unless I have a Google account.
> > > 
> > > Since Qubes is privacy-focused it seems like maybe the Qubes mailing lists
> > > should migrate to a less Orwellian mailing list provider.
> > > 
> > 
> > This comes up repeatedly.
> > If you don't like Google Groups, but want a web interface, use the mail
> > archive at https://www.mail-archive.com/qubes-users@googlegroups.com/
> > If you don't want a web interface, interact with it as a mailing list.
> 
> But still your messages will be sent to Google...
> 
And so?
I don't send messages to Google - I send them to people who read the
mailing list. Since that is a public activity I don't care if Google sees
it.
The list is public, so Google will be all over it in any case.
Does this mean that I favour Google in any way? Not at all.

I never use the google web client, and it aggravates me when people link to
messages there, instead of in the mail archive. I wish they wouldn't.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200817000811.GB28867%40thirdeyesecurity.org.


Re: [qubes-users] Google requiring login to access qubes-users

2020-08-15 Thread unman
On Sat, Aug 15, 2020 at 07:39:19PM +, tetrahedra via qubes-users wrote:
> WHen I try to access the Google Groups qubes-users site, sometimes (circa
> 50%) I'm presented with a Google login prompt and can't access the
> qubes-users group unless I have a Google account.
> 
> Since Qubes is privacy-focused it seems like maybe the Qubes mailing lists
> should migrate to a less Orwellian mailing list provider.
> 

This comes up repeatedly.
If you don't like Google Groups, but want a web interface, use the mail
archive at https://www.mail-archive.com/qubes-users@googlegroups.com/
If you don't want a web interface, interact with it as a mailing list.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200816002920.GA23530%40thirdeyesecurity.org.


Re: [qubes-users] why do fedora templates always start sys-whonix on update

2020-08-15 Thread unman
On Sat, Aug 15, 2020 at 04:26:34AM -0700, 0spin...@gmail.com wrote:
> mainly because fedora updates are always so very slow (200-400kbps), while 
> debian isn't.
> 

The proxy is configured at /etc/qubes-rpc/policy/qubes.UpdatesProxy
You want a line at the top of the file that says (e.g):
fedora-32  $default  allow,target=sys-net

Templates have no networking, (by default), and you should keep it that
way to avoid mistakes.
To enable them to install software and update, there is a proxy
mechanism that listens on port 8082 and connects to a download proxy.
This is all normal.

On your system you probably opted to install updates via Tor, so the
default proxy setting is to use the Whonix system. Editing the policy
file will change that.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200815132307.GB20973%40thirdeyesecurity.org.


Re: [qubes-users] debian network manager add vpn connection

2020-08-15 Thread unman
On Sat, Aug 15, 2020 at 09:45:03AM +0200, Qubes wrote:
> I have more than one vpn connection configured using appVMs based on Fedora.
> If you open the "Qube Settings" window you can add the "network-manager"
> service on the "Services" tab. If you then boot the appVM a network manager
> icon appears in the system tray. If you click on the icon you can select
> "VPN Connections -> Add a VPN connection...".
> 
> On the new window that opens there is a dropdown menu that you can use to
> continue with the VPN configuration. Usually you would just choose to import
> a saved vpn connection.
> 
> When I choose debian as the base template for my appVM and I choose to add a
> new vpn connection from the network manager icon the dropdown on the vpn
> connection wizard is blank, there is nothing to choose. Is the configuration
> on debian different?
> 

No, the configuration is the same, but the Template is more basic.
Fortunately, if you try to select VPN, the "Choose a VPN Connection
Type" Window **tells** you that "if the type of VPN connection you wish to
create does not appear in the list, you may not have the correct VPN
plugin installed."

So you need to open the template and install (using aptitude or some
other package management tool) the VPN plugin you want - look at the
"network-manager-XXX" plugins.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200815131541.GA20973%40thirdeyesecurity.org.


Re: [qubes-users] Suggestions as a user

2020-08-14 Thread unman
On Fri, Aug 14, 2020 at 07:00:02AM -0700, acharya.sagar.sag...@gmail.com wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> But one can't trust Intel right? How can one be sure that tests and 
> warnings generating code is not malware. Open code is the 1st requirement 
> for security right?! I don't think hidden security enhancing code is really 
> enhancing security.

I dont think you understand.
If a user *does* have an Intel processor then they are stuck with known
vulnerabilities. They trust Intel already, so trust the microcode
supplied.
The tests and warnings are in the Linux kernel.
Libre kernels remove them so that users wont be tempted to use non free
microcode, although they are *already* using non free microcode. i
think this is incoherent, and haven't seen any persuasive arguments.
In my opinion users should be given all the information they need to
make an informed choice.

Open code is not the 1st requirement for security. It isn't even one of
the requirements, although it may be desirable.
There are many examples of free software where the bugs and security
flaws remain open for years.
Sometimes people talk as if they think that closed source programs dont
get any review. This simply isn't true,(although sometimes with
Microsoft in the past, one might think differently.) I've worked with
development teams where the code is crawled over in depth by professional
auditors, but the product is closed source.

> 
> Qubes is an extremely secure OS and with RISCV processors coming, Qubes 
> should go towards removing trust from hardware. Atleast it should have 
> option (another ISO, say qubes-libre.iso) for fully free software going 
> ahead. Trusting Intel would be optional going ahead due to RISC-V cores or 
> other open processors. And if not, Qubes should make their life difficult 
> as much as possible by choosing linux-libre by default. Parabola is a 
> perfectly usable OS, and so is hyperbola(it has few packages though). I use 
> it on a flash drive. Except WiFi rest of the things work.

"Except WiFi rest of the things work." Exactly. I think that makes my
point.

> 
> I strongly think there is no unreadable code for security. There is only 
> unreadable code or security. While the whole concept of qubes lies on 
> protecting against malware by trusting it less, with free hardware ahead, 
> having an option for no hidden code and actively preventing user from 
> installing hidden code in most doms is impressive.

This is just a false opposition.
To make things clear, I'm an advocate for free software, but that has
nothing to do with security. In some cases, the advocates for free
software and linux libre have no regard for the security of end users.
That's wrong.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200814153804.GA15765%40thirdeyesecurity.org.


Re: [Fwd: Re: [qubes-users] how to install virtualbox?]

2020-08-13 Thread unman
On Thu, Aug 13, 2020 at 08:57:01PM +, 'disrupt_the_flow' via qubes-users 
wrote:
> On August 13, 2020 7:41:23 PM UTC, "afdskjbkjds...@secmail.pro" 
>  wrote:
> >
> >I need the virtual box for development, there's a virtual environment
> >configured for it.
> >So if I am new to linux, I can't do it? Maybe there are some guides?
> >
> >
> >-- 
> >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 view this discussion on the web visit
> >https://groups.google.com/d/msgid/qubes-users/4c9fed44debd4b5d8cd8aec1c3905972.squirrel%40giyzk7o6dcunb2ry.onion.
> 
> I dont think it's possible tbh. If anyone has done please tell us. Anyway if 
> you really need virtualbox you could in a Debian live USB and play there.
> 

Running in a Debian standalone.
Install the virtualbox package and dependencies, as normal.
Edit the file, /usr/lib/virtualbox/vboxdrv.sh and comment out the Xen
test at lines 269-271

That's minimum to get you running. You'll be limited in what you can run
and vbox will complain if you have VT-x etc enabled, but it may do.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200814003505.GA12054%40thirdeyesecurity.org.


Re: [qubes-users] connecting to an app on an appvm from lan

2020-08-13 Thread unman
On Thu, Aug 13, 2020 at 12:34:39AM +0200, Qubes wrote:
> How does one go about connecting to an appvm from another device on your
> LAN? Is there any documentation on this?
> 
> Just to avoid confusion a device on the same network as where sys-net gets
> it's network from.
> 

https://www.qubes-os.org/doc/firewall/ covers in some detail in the
section on "Port forwarding"
If you hit problems, give some detail on what you have done, and we
should be able to help.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200813140649.GB9446%40thirdeyesecurity.org.


Re: [qubes-users] Suggestions as a user

2020-08-13 Thread unman
On Wed, Aug 12, 2020 at 07:23:27AM -0700, acharya.sagar.sag...@gmail.com wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hello guys, I would like to suggest a few changes and while you may not 
> have them in qubes by default, I ask you to give an option to the users 
> such that they be able to make it easily.
> 
> With GUI VM coming in 4.1, I request you to have linux-libre in dom0. 
> Linux-libre for every template by default would be even better and 
> certainly my choice. (atleast Freedora instead of Fedora). KDE instead of 
> XFCE would be a better default option since it provides a better UI. It 
> provides a premium feel and is a level above XFCE. Shifting focus to GNU 
> recommended OSes like Hyperbola, Parabola, Guix is also a step ahead in my 
> view.
> 
> I state this because GNU has also had an aim to make a completely free 
> software to be used on a computer. While they approach with security by 
> correctness and by actively trying to demotivate nonfree software, I feel 
> they might not get to the end. Also, they don't make it difficult for the 
> user to install a problematic software by mistake like Qubes does. If Qubes 
> combines such OSes (especially recommend Hyperbola, they are highly 
> critical of any contaminating packages) with it own security by 
> compartmentalization, it will be a step ahead.
> 
> Thanking you
> Sagar Acharya
> 
> P.S. I dream of having a stateless computer (Joanna 2015) with 
> libreboot+Qubes having HyperbolaBSD in dom0 and Parabola, Guix and 
> Hyperbola as available template VMs, with plasma as a DE. That would be 
> ideal and a nightmare for malicious crackers.
> -BEGIN PGP SIGNATURE-
> 
> iQGzBAEBCAAdFiEEeMyXyyr6L/PtWnZUnZv6jjOfaEIFAl8z+voACgkQnZv6jjOf
> aEJqFwv9Eb8RioP2sHOp91g2AtNxCRXcs88HvrJYwCBJWPuQBqAax+yWIcgB24F0
> bmYsHewPWPYzguOVZ565C1ma1PbmAjUi0UYriv4ddstEbWpKnX6I2VtfsTeCpP9s
> j3NtDBXtbQXEAY+10soubiNm/CjLNNaCYidgkubnOXaXHAIgUukIchINA/Zxp/dz
> aw8VNapGzoayCFDATiz8rJXYCI4eGe3mRngjAcsXVNwPoxPVnUlMlGAf8RzRUXle
> /dsczJvk6jgyQoYETWgntfqG+er0dZm6D3whN4rVxqtqxO+9SR1rwi5Fi5Ly4AS3
> yEeWo7fum7x6stJnp1N5CnQENN0heqev2qEcsvMniq1MRuGnKit4AmP8H2mVSwtm
> Oor2W6vZCivMB4dPkoeSBZ+zjjkPQwb5x3ljBoa3465BGeXnAGxblfW3RFM50Ml7
> yQsxN3G1FsrGOcwz5GpdSzDCm7sMF/0P77VYBqtTgBEkSvOI/gWLEIeIHWzi7oAT
> enJPiihw
> =61lG
> -END PGP SIGNATURE-
> 

Nothing like reading someone's personal preferences.
Unfortunately linux-libre is not something I could endorse - removing
the tests and warnings about known CPU vulnerabilities, on the spurious
ground that a user might just want to install microcode to enhance their
security, makes it unfit for a security focussed distro.
The same applies to libreboot, which has the added incoherence of
advocating updating EC firmware, while blocking CPU microcode.

As to the rest, I support KDE because it allows users to more easily
control the Qubes Menu - a major pain point for many - and provides
Activities, which meld perfectly with the use of Qubes security domains.
The OS you recommend are interesting, but Qubes has to be as usable as
possible with a wide reach, and I'm afraid a focus on free software
alone wont help there.
It would be simple to incorporate those OS into Qubes as templates,
(with extra work for a BSD hyperbola), but what would be the benefit for
most users, who need non-free blobs to get their machines working?
Don't let me put you off: it's a worthy aim, and will hit a small set of
users.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200813140334.GA9446%40thirdeyesecurity.org.


Re: [qubes-users] Qubes dom0-update-guard script

2020-08-08 Thread unman
On Fri, Aug 07, 2020 at 09:07:39PM -0700, fiftyfourthparal...@gmail.com wrote:
> On Saturday, 8 August 2020 06:38:38 UTC+8, Chris Laprise wrote:
> >
> > I think this is only properly done via a trusted .onion address, i2p 
> > address, etc... Unless Tor's DNS lookups have been improved since the 
> > last time I checked. 
> >
> > Just for reference here, threat model I'm thinking of here is when an 
> > attacker tries to MiTM while having the cooperation of the certificate 
> > authority. 
> >
> > -- 
> > Chris Laprise, tas...@posteo.net  
> > https://github.com/tasket 
> > https://twitter.com/ttaskett 
> > PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886 
> >
> 
> Since dom0 can be updated via tor, is there an onion address? If not, what 
> would it take to make one or convince someone to make one? Without this 
> (since i2p is a whole can of worms I don't want to touch), the whole 
> exercise is meaningless. 
> 
> -- 

Onion? Of course.
Check /etc/yum.repos.d/qubes-dom0.repo
Also, it's on mirror list at https://www.qubes-os.org/downloads, and has
been referenced on this list.
The repo is:
http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion

What you should do is grab a few of those mirror sites, and compare the
metadata downloaded through Tor. i.e don't trust *any one* site, but look at
them in the mass .
Just as you would with an iso or pgp key.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200808125121.GA14753%40thirdeyesecurity.org.


Re: [qubes-users] GPT or MBR?

2020-08-05 Thread unman
On Wed, Aug 05, 2020 at 09:04:41PM +0200, Qubes wrote:
> On 8/5/20 8:31 PM, Stumpy wrote:
> > On 2020-08-05 12:06, Stumpy wrote:
> > > I have win installed on a drive with mbr, should I be able make a
> > > vhd and convert that to a RAW and run it as a template in Qubes?
> > > 
> > > If i remember correctly gpt does not play well with qubes?
> > > 
> > 
> > I guess more to the point, "MBR is better" or "GPT is better" or "either
> > is fine" is what I am looking for.
> > Thanks!
> > 
> Coreboot is better, look into Coreboot, https://www.coreboot.org.
> 
> Otherwise I would rank UEFI above BIOS in terms of security.
> 
> 

GPT is part of the UEFI standard, but can be used with legacy BIOS.
Coreboot, UEFI, and legacy BIOS are not clearly related to partition
tables, which is what MBR and GPT are.
Both are fine in the context of Qubes.
Stock templates are built using gpt.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200806011323.GB456%40thirdeyesecurity.org.


Re: [EXT] Re: [qubes-users] Update templates in parallel

2020-08-05 Thread unman
On Wed, Aug 05, 2020 at 05:59:05PM +0200, Qubes wrote:
> On 8/5/20 1:07 AM, Ulrich Windl wrote:
> > On 8/2/20 4:42 PM, Chris Laprise wrote:
> > > On 8/2/20 8:32 AM, fiftyfourthparal...@gmail.com wrote:
> > > > I have a ton of templates and standalones (>10), so updating
> > > > them one by one serially is a pain. I found a convenient dom0
> > > > script so I thought I'd share.
> > > > 
> > > > Basically, take this and paste it into dom0 then make it
> > > > executable. There'a also a handy test function. All credit goes
> > > > to Andrea Micheloni. Anyone have similarly handy
> > > > modifications/scripts?
> > > > 
> > > > https://m7i.org/tips/qubes-update-all-templates/
> > > 
> > > IIRC there is an option somewhere in 'qubesctl' for parallel
> > > template updates.
> > 
> > Actually instead of parallel updates (assuming limited bandwidth) I'd
> > vote for a more verbose progress indicator (in the graphical update
> > app):
> > Currently the VMs start, update starts, and then ...long time
> > nothing..., then the list of packages updated.
> > 
> > Regards,
> > Ulrich
> > 
> > > 
> > > You can check out my github for some interesting stuff. The
> > > 'Qubes-scripts' project has a (serial) template updater that lets
> > > you select by certain criteria. It could be parallelized pretty
> > > easily.
> > > 
> > > Since you have a lot of templates+standalones, the 'findpref' tool
> > > might also be of interest. It can bulk search/replace VM prefs, such
> > > as changing all the VMs that are using 'sys-vpn1' to use 'sys-vpn3'
> > > instead, or change VMs to use a different template.
> > > 
> > > I also wrote 'wyng-backup', a fast LVM incremental backup tool that
> > > only scans where LVM reports new activity.
> > > 
> > > Finally, there is a VPN tool and one to enhance VM internal security.
> > > 
> > 
> I vote for the local proxy to cache updates. Is that not possible?

Yes, it is. A simple mechanism is to install apt-cacher-ng, and
configure it to listen on port 8082, while removing or masking
tinyproxy.
This acts as a simple drop in replacement with benefit of caching.
To use https in the repositories you need to rewrite them as
"http://HTTPS///;, and the caching proxy will then connect using https.
To use for Fedora you need to keep an eye on the multiplicity of Fedora
repos, and update the repo definitions.
Debian and debian based archives work out of the box.

> 
> Would it not make sense if a Fedora-32 or Fedora-32-xx template downloads
> for example the latest Firefox that it should be cached locally. When the
> next Fedora-32 template checks for updates the system can check what the
> latest version is on the repository, if it is the same as the cached version
> use the cached copy. This will dramatically reduce update bandwidth
> requirements and make updating quick and painless no matter the number of
> templateVMs.
> 
> There must be a fancy way of making this secure. When an update is
> downloaded for the first time it is verified so we must ensure the cache's
> integrity. Maybe the downloaded files can be signed by the users own key
> kept in the vault AppVM.
> 

The security isnt to be found at the proxy level, but at the package
management level. It's there that verification is (and should be) done.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200806010324.GA456%40thirdeyesecurity.org.


[qubes-users] Bullseye and Kali templates

2020-07-22 Thread unman
Hello All,

I've uploaded new builds of the bullseye and Kali templates to
https://qubes.3isec.org/Templates for any one who is interested.

These packages are signed with my Qubes Signing key - you can find this
on keyservers, in this list, and at GitHub. Verify the key, and then check
the signature on the template package.

If you are satisfied, copy the package in to dom0, and then install it
with `dnf install`.

The Kali template has all the packages of a standard Kali install,except
for amass and cherrytree which are currently broken. (Problems of using
a rolling distro based on a testing Debian - things will just break.)
Otherwise all your favourite tools are there.

As always, any one can dig in and examine the packages - comments always
welcome.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200722164935.GA20581%40thirdeyesecurity.org.


Re: [qubes-users] A way to "write configurations" to SALT?

2020-07-21 Thread unman
On Tue, Jul 21, 2020 at 07:14:19AM -0400, Stumpy wrote:
> I have been trying to figure out SALT in my spare time and every time I
> start I finish with watery eyes and a mushy brain... for me its hard to wrap
> my head around.
> 
> While I am not giving up per se it occurred to me, so i just thought id ask
> on the off chance its possible... Can one say setup an AppVM and configure
> it to ones own needs _then_  somehow write that configuration to SALT? While
> this seems unlikely I have to ask.
> 
> Thanks!
> 

I think this would depend on what configuration you had in mind - basic
preferences, of course.
Packages installed? Possible but *incredibly* long winded.
Home directory configurations? Possible but somewhat difficult to pull
out the changes.

Have you looked at my notes on using salt?
https://github.com/unman/notes/tree/master/salt

Here's a suggestion - post an example of what you would like to have in
the appVM, and we'll generate the state files. (Obviously don't send
details of an actual qube.)

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200721130221.GA14690%40thirdeyesecurity.org.


Re: [qubes-users] saltstack: dependencies during vm.create

2020-07-20 Thread unman
On Sun, Jul 19, 2020 at 04:15:17PM +0100, lik...@gmx.de wrote:
> Hi!
> 
> I'm trying to create a DVM from a TemplateVM which is also created in the 
> same file. The DVM depends on the TemplateVM and that's why the creation 
> fails. Running the script twice works.
> 
> My top files looks similar to:
> 
> base:
> ??dom0:
> ?? - match: nodegroup
> ?? - create-template-vm
> ?? - create-dvm
> 
> I've played around with the "require" or "order" key words, but it doesn't 
> work:
> 
> base:
> ??dom0:
> ?? - match: nodegroup
> ?? - create-template-vm
> ?? - create-dvm
> ?? - order: last
> 
> Error is:
> Rendering exception occurred: Jinja error: mapping values are not allowed 
> here; line 6
> 
> Any ideas to enforce an order during vm creation?
> 
> Thanks a lot in advance! P.
> 

Dont put both entries in the top file: - you can use only `create-dvm`.
`require` and `order` are connections between **states** - put them in
the state file.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200720114521.GC9057%40thirdeyesecurity.org.


Re: [qubes-users] Re: pen testing / port forwarding guide?

2020-07-20 Thread unman
On Sun, Jul 19, 2020 at 10:52:37AM -0700, ludwig jaffe wrote:
> Feature Request:
> 
> Kali template VM with qubes-os secialities like cut installed.
> 
> Cheers,
> 
> Ludwig
> 
> On Tuesday, July 14, 2020 at 3:54:43 PM UTC, jm wrote:
> >
> > hi, 
> >
> > Has anyone written a guide to setting up a Kali vm in Qubes for 
> > pen testing? 
> >
> > I'm studying for the OSCP, and the Qubes firewall port forwarding 
> > guide suggests a fragile and finicky setup that I'm reluctant to 
> > rely on. Punching holes from sys-net to sys-firewall to vpn-vm to 
> > an an appvm just to run `nc -nlvp ` seems... like a kludge, at 
> > best. 
> >
> > Issue #4028 tracks this problem. 
> >
> > The alternatives seem to be 1) create a HVM with direct access 
> > to hardware--no sys-net or firewall-vm--or 2) purchase a 
> > dedicated laptop for this use case. 
> >
> > Any suggestions? 
> >
> > thanks, 
> >
> > jmp 
> >


The convention here is not to top-post.
Please scroll to the bottom of the message before you start typing. Or
reply inline.
It only takes you seconds, makes it much easier to follow threads, and
cumulatively saves your fellow users hours.

You can already build a kali template with the qubes-builder - or I
provide a pre-built one if you are uncertain about building your own

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200720113725.GB9057%40thirdeyesecurity.org.


Re: [qubes-users] Re: Does qubes protect against all firmware viruses ?

2020-07-20 Thread unman
On Sun, Jul 19, 2020 at 07:28:02AM -0700, tomas.schutz...@gmail.com wrote:
> Yeah but, in that article: they talk about checking number, not actual 
> account number. I never heard of some checking number honestly. I have 
> recurring payments and it doesn't work that way, i have no checking number. 
> I don't even know what that means in my language...
> 
> On Thursday, July 16, 2020 at 10:10:24 PM UTC+2, awokd wrote:
> >
> > tomas.s...@gmail.com : 
> > > Wait a minute... How checking account number, can represent security 
> > risk? 
> >
> > https://www.consumer.ftc.gov/articles/0196-automatic-debit-scams 
> >

The convention here is not to top-post.
Please scroll to the bottom of the message before you start typing. Or
reply inline.
It only takes you seconds, makes it much easier to follow threads, and
cumulatively saves your fellow users hours.
Thanks.

In that article *in English* there is no reference to "checking number",
every reference is to "checking account" information or number,  so I
suspect something is lost in translation.
A checking account is a US name - we dont have them where I live, but we
have similar accounts, which allow for Direct Debits to be set up.

The point is that if someone has your account number and sort-code, they
*may* be able to set up a payment out of the account without your
knowledge or authority.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200720113408.GA9057%40thirdeyesecurity.org.


Re: [qubes-users] Re: DisposableVM Help

2020-07-19 Thread unman
On Sat, Jul 18, 2020 at 01:11:16PM -0700, Robert Spigler wrote:
> 
> 
> > Yes, it is, and from what you have said, that is what you have. (EXCEPT 
> > that the flag is `template_for_dispvms` not `template_for_dvms` - is this 
> > a 
> > typo or the root of the problem?) 
> >   
> >
> 
> I believe that was a typo, sorry.  I was just stating what the flag was 
> from your first post, but you said 'template_for_dvms' there as well. How 
> do I check the flag other than seeing if it is marked 'Yes' for 
> 'DisposableVM Template' in Qube Manager? It is marked 'Yes', if that helps

My bad.
You can check it from dom0 terminal, using `qvm-prefs`

> 
> 
> 
> > The best I can suggest is that you: 
> > `qvm-features fedora-32-dvm-template appmenus-dispvm 0` 
> > Check the menu item. 
> > Check (again) that you have `template_for_dispvms` flag set. 
> > `qvm-features fedora-32-dvm-template appmenus-dispvm 1` 
> > Check the menu item again. 
> >
> >
> 
> I tried the above, and there was no difference in menu or whether or not 
> the qube had 'Yes' marked under 'DisposableVM Template' in Qube Manager. 
> Opening an application under the menu still opened the template, and not a 
> disposableVM.
> 
> I don't know if this information helps or not, but for the debian-10-dvm 
> and whonix-15-dvm, they are labeled in the menu as 'Disposable: 
> debian-10-dvm' and 'Disposable: whonix-15-dvm' at the top.  The other is 
> listed as 'Domain: fedora-32-dvm-template' with the rest of my AppVM's, 
> before listing my ServiceVMs and TemplateVMs.  I am attempting to create 
> what I had before; another 'Disposable: fedora-32-dvm' that is it's own 
> DisposableVM Template.
> 

I tried this - it *did* create a Disposable menu item, and the entries
started disposableVMs.
Not much help to you, but it confirms that there is nothing inherently
wrong with the fedora-32 template.
I would delete the qube, make sure your system is fully
updated,(optionally reboot), and start again.
Dont get hung up on the terminology.
Create the qube based on the fedora-32 template, and mark it as
DisposableVM template, either in Qube Manager or at command line.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200719135219.GA4494%40thirdeyesecurity.org.


Re: [qubes-users] Re: DisposableVM Help

2020-07-18 Thread unman
On Fri, Jul 17, 2020 at 09:11:16PM -0700, Robert Spigler wrote:
> I appreciate your help.
> 
> 'qvm-run dispvm=fedora-32-dvm-template --service qubes.StartApp+xterm' 
> results in the error:
> 
> unrecognized arguments: qubes.StartApp+xterm.
> 
> I don't know if I am communicating this correctly, but I am trying to 
> create a fedora-32-dvm, that is also itself a DVMTemplate (has the 
> 'template_for_dvms' flag set), like I currently have for my debian-10-dvm 
> and whonix-15-dvm.  Is this not the proper way to run DVM's?

Yes, it is, and from what you have said, that is what you have. (EXCEPT
that the flag is `template_for_dispvms` not `template_for_dvms` - is this a
typo or the root of the problem?)
 
> I currently have a menu item for 'fedora-32-dvm-template', but opening any 
> application from the menu, like Firefox for example, opens the DVMTemplate, 
> not a DispVM.
> 

And this seems to be the problem - you *have* a DVMTemplate, but your
menu items continue to point to the DVMTemplate, instead of using it to
spawn a disposableVM.
In a previous post I pointed out the difference between the menu items.

The best I can suggest is that you:
`qvm-features fedora-32-dvm-template appmenus-dispvm 0`
Check the menu item.
Check (again) that you have `template_for_dispvms` flag set.
`qvm-features fedora-32-dvm-template appmenus-dispvm 1`
Check the menu item again.

If it still is not working then we can dig in to the menu items, but on
Xfce I may be struggling.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200718131842.GA32738%40thirdeyesecurity.org.


Re: [qubes-users] Re: DisposableVM Help

2020-07-17 Thread unman
On Fri, Jul 17, 2020 at 12:14:07PM -0700, Robert Spigler wrote:
> According to the documentation, I try:
> 
> 'qvm-prefs fedora-32-dvm template_for_dispvms True'
> 
> error: no such domain: 'fedora-32-dvm'
> 
> Tried 'qvm-prefs fedora-32 template_for_dispvms True'
> 
> error: no such property: 'template_for_dispvms'
> 
> 
> Following 'Creating a New DisposableVM Template' further down the page:
> 
> 'qvm-create --template fedora-32 --label red fedora-32-dvm-template'
> 'qvm-prefs fedora-32-dvm-template template_for_dispvms True'
> 'qvm-features fedora-32-dvm-template appmenus-dispvm 1'
> 
> This creates a domain titled 'fedora-32-dvm-template' like I describe in my 
> original post, with the disposable_vm_template flag set, but it is not a 
> DisposableVM itself, which is what I am attempting.
> 

Hi Robert
I'm sorry my previous post wasn't clear enough.
A DisposableVM is  based on a DisposableVM Template.
You have created a DisposableVM Template. You can use it to spawn
disposableVMs.
You can do this by hand:
qvm-run dispvm=fedora-32-dvm-template --service qubes.StartApp+xterm

Setting the qvm-features as you have done *should* create menu items
that will spawn disposableVMs that use that template.

If you wanted to create disposableVMs based on a qube that uses the
fedora-32 template, that is what you have done.
If that is *not* what you were attempting, please explain exactly what
it is you want. (If you think that your fedora-32-dvm-template should
itself be a DisposableVM , please re-read the glossary, and the page on
disposableVMs: *this* attempt is based on a misunderstanding of how
disposableVMs are created in Qubes 4.)

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200718012701.GA30460%40thirdeyesecurity.org.


Re: [qubes-users] Re: Fw: qubes arch template

2020-07-17 Thread unman
On Thu, Jul 16, 2020 at 05:16:57PM +0200, Fr??d??ric Pierret wrote:
> 
> 
> On 2020-07-16 16:51, fargubz wrote:
> > Hi Frederic,
> > 
> > Having the https://github.com/QubesOS/qubes-issues/issues/5503 issue.
> 
> Hi, please don't ask directly to any member of the Qubes OS project 
> (including me :)). Ask to the list directly for which I CC it.
>  
> > What is the step to fix this?
> 
> I'm pretty sure any person who built Archlinux could help you (which is not 
> my case).
> 
> > Best regards!
> > 
> > fargubz
> > 
> 
> Regards,
> 

I *have* built the template and do not have this problem.
Are you sure that is your issue?
If so, there's clearly something majorly wrong with your arch building
environment.
I suggest you clean it out, and start again.

1. Run ./setup and make sure that only arch is selected.
2. Run `make clean-rpms`
3. Confirm that chroot-vm-archlinux is not present.
Delete (using sudo) if it is.
4. Confirm that
qubes-src/linux-template-builder/prepared_images/archlinux.img is not
present.
Delete (using sudo) if it is.
5. `make qubes-vm` and `make template`

Alternatively I provide pre-built templates, and Arch packages at
https://qubes.3isec.org
Download an arch template, confirm the signature, copy it in to dom0 and
install it using `dnf install`

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200717140811.GA27865%40thirdeyesecurity.org.


Re: [qubes-users] Security advantages of static DVMs for sys-VMs?

2020-07-16 Thread unman
On Thu, Jul 16, 2020 at 12:26:04PM +0200, Peter Funk wrote:
> fiftyfourthparal...@gmail.com asked:
> > I read about running sys-vms as static disposable VMs on the Qubes 
> > documentation site 
> > ,
> >  
> > then on the Whonix guide to Qubes security 
> > . I have my reservations 
> > about this (but then I'm no expert) and it feels like the outcome will be 
> > unstable and hard to use. However, since this is on both the Qubes and 
> > Whonix sites, this is probably worth looking at. 
> > 
> > What do you think about using static DVMs as sys-VMs?
> 
> I'm no real expert either.  But from my knowledge so far:
> 
> The basic idea of disposable VMs is, that any bad change to
> this virtual machine is disposed (thrown away) after a restart
> by returning to an "known good state" automatically.
> 
> However: If it was possible in the first place that something
> bad happened to this "known good state" then starting over
> will not remove this possibility for future events.
> 
> Throwing everything away will also delete any evidence that
> something bad might have happened to this part of your digital
> life and will make later analysis of the events harder.
> 
> I think those disposable VMs are great if you want to enter
> new unexplored territory and want to keep the risk of your
> experiments under better control.
> 
> However if for example you use an external USB keyboard (as
> most of us must today as the old PS/2 connector is dead) and
> you have this device connected to your Qubes OS laptop using
> the ordinary USB socket then I see not much gain by bothering
> about making sys-usb a static DisposableVM.
> 
> Please correct me if I'm wrong.
> 

54th - static disposableVMS are neither unstable nor hard to use. They
are as stable as a normal sys-VM and transparent in use.

Peter - I think you are missing this point - when you set up (e.g) a
disposable sys-usb you need not start the template before creating the
disposableVM. That means that there is (almost) no prospect of the
"known good state" being compromised.
In the USB case, if someone were to access your computer with a BadUSB,
then they may be able to dump a payload which could then compromise any
other USB devices, or possibly other qubes. Using a disposable sys-usb
reduces this risk.
I routinely cycle my usb qubes after removal of any device.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200716124849.GB22089%40thirdeyesecurity.org.


Re: [qubes-users] Qubes in a corporate network behind HTTP proxy [R4.0.x]

2020-07-16 Thread unman
On Wed, Jul 15, 2020 at 11:41:57PM -0700, pr0xy wrote:
> On 2020-07-15 09:28, pr0xy wrote:
> > I have been running R3.2 for about as long as I can. Time to upgrade to
> > R4.0.x
> > 
> > Original 2017 thread where I got this working in R3.2:
> > https://groups.google.com/d/msg/qubes-users/K_etKdhnqLA/KyJ16z8JCwAJ
> > 
> > It appears that some of the R3.2 tweaks I used to get Qubes to work
> > nicely with my corporate proxy are no longer valid in 4.0.x. To
> > summarize, my company network has a very restrictive proxy that forces 
> > internet traffic through an HTTP/HTTPS proxy like:
> > 
> > proxy.example.com:8080 
> > 
> > In R4.0.x how and where would I set this proxy for the Qubes Updates
> > Proxy? sys-net? sys-firewall? TemplateVMs?
> 
> If I understand the documentation correctly...
> https://qubes-os.org/doc/software-update-domu/#updates-proxy
> we have TinyProxy running in sys-net, and this proxy is used for
> TemplateVM updates.
> 
> In the default R4.0.3 install, sys-net is based on a Fedora 30 template.
> In the fedora-30 templateVM I tried editing
> /etc/tinyproxy/tinyproxy.conf to add the IP of my company's HTTP proxy
> as the upstream proxy
> 
> Upstream http 10.0.0.1:8080
> 
> That does not seem to work.

It would be helpful if you said in what way it does not seem to work.

Check in dom0, the contents of /etc/qubes-rpc/policy/qubes.UpdatesProxy,
to make sure which qube is acting as the proxy.
Check in a template if you are using sources with http:// or https:// -
look in /etc/yum.repos.d or /etc/apt/sources.list as appropriate
Confirm that you have DNS resolving in whichever qube is acting as
proxy.

Report back.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200716123452.GA22089%40thirdeyesecurity.org.


Re: [qubes-users] Re: saltstack used to update firefox profile

2020-07-15 Thread unman
On Mon, Jul 13, 2020 at 06:22:57PM +0100, lik...@gmx.de wrote:
> On 2020-07-13 13:48, unman wrote:
> > On Sun, Jul 12, 2020 at 05:55:56PM +0100, 
> > liked2-mmb7mzph...@public.gmane.org wrote:
> > > Hi,
> > > 
> > > I'm trying to build up my AppVms with saltstack and currently stuck with 
> > > updating my firefox profile because it's located in a randomly generated 
> > > directory (where xxx are random alpha-numerics):
> > > /home/user/.mozilla/firefox/xxx.default-release/prefs.js
> > > 
> > I'm a great believer in keeping salt as simple as possible.
> > In this case:
> > ```
> > echo 'user_pref("browser.startup.homepage", "https://www.qubes-os.org; ); ' 
> > >> /home/user/.mozilla/firefox/*.default-release/prefs.js :
> >cmd.run
> > 
> > ```
> > 
> > If you *do* want complexity, your 1st try is a non-starter, as you've
> > discovered.
> > In the 2nd, I wouldn't use a variable name which is also the name of a
> > salt module. Nor would I use `ls` and `file.find` together - what's the
> > point? Otherwise that looks workable.
> > 
> 
> I agree to use salt-KISS but, with using the command line in salt renders it 
> somehow less useful from my point of view. For example I've to be careful not 
> to execute that script twice etc.

Actually, in this case you *dont* need to worry about that, because
afaik firefox will only keep the last entry and will prune the others.

> 
> You're right with the second try. I just mixed 2 solutions into 1 during 
> copying.
> This one fails basically with the same error.
 
> Any other suggestions?
> 

```
{% set filenames=salt['file.find']('/home/user/.mozilla/firefox', 
'name=prefs.js') %}
{% for value in filenames %}
{{ value }}:
  file.append:
- text: 'user_pref("browser.startup.homepage", "https://www.qubes-os.org;); 
' 
{% endfor %}
```

The problem with this is that it relies on you having started firefox
already (to generate the .mozilla entries).
You used to be able to get the same effect before opening by editing
/etc/firefox-esr/firefox-esr.js , but that doesn't seem to work. In any
case you would need to do this in the template.
I'm sure you can find the right place to edit *before* starting firefox.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200715130911.GA16571%40thirdeyesecurity.org.


Re: [qubes-users] saltstack used to update firefox profile

2020-07-13 Thread unman
On Sun, Jul 12, 2020 at 05:55:56PM +0100, lik...@gmx.de wrote:
> Hi,
> 
> I'm trying to build up my AppVms with saltstack and currently stuck with 
> updating my firefox profile because it's located in a randomly generated 
> directory (where xxx are random alpha-numerics):
> /home/user/.mozilla/firefox/xxx.default-release/prefs.js
> 
> 1st try with file.append from saltstack seems not to work with wildcards:
> 
> /home/user/.mozilla/firefox/*.default-release/prefs.js:
> ?? file.append:
> ?? - text:
> ?? - user_pref("browser.startup.homepage", "https://www.ecosia.org/;);
> 
> 2nd try with a for loop also fails:
> 
> {% for file in salt[cmd.run']('ls -l 
> /home/user/.mozilla/firefox/*.default-release/prefs.js') %}
> {{ file }}
> { file.find type=f 
> name='/home/user/.mozilla/firefox/*.default-release/prefs.js' }
> ?? file.append:
> ?? - text:
> ?? - user_pref("browser.startup.homepage", "https://www.ecosia.org/;);
> {% endfor %}
> 
> 
> Do you have a 3rd working example/suggestion?
> 
> 
> Thanks in advance! P.
> 

I'm a great believer in keeping salt as simple as possible.
In this case:
```
echo 'user_pref("browser.startup.homepage", "https://www.qubes-os.org; ); ' >> 
/home/user/.mozilla/firefox/*.default-release/prefs.js :
  cmd.run

```

If you *do* want complexity, your 1st try is a non-starter, as you've
discovered.
In the 2nd, I wouldn't use a variable name which is also the name of a
salt module. Nor would I use `ls` and `file.find` together - what's the
point? Otherwise that looks workable.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200713124825.GB4984%40thirdeyesecurity.org.


Re: [qubes-users] broken link in https://www.qubes-os.org/doc/vm-sudo/

2020-07-13 Thread unman
On Mon, Jul 13, 2020 at 11:51:15AM +0200, Peter Funk wrote:
> While reading in the official Qubes OS documentation I discovered
> a broken link in the page titled "Passwordless Root Access in VMs"
> in "Background (/etc/sudoers.d/qubes in VM)".  I was interested in
> the Background and was unable to find the mentioned 
> https://github.com/QubesOS/qubes-core-agent-linux/blob/master/misc/qubes.sudoers
> anywhere else.  Does anybody know where this was moved to?
> 
> Best regards, Peter Funk

The contents of the file are there on that page, so you have already
read it.
As to your failure to find it anywhere else in master, it has been hidden in the
confusingly named "passwordless-root" directory. ;-)

https://github.com/QubesOS/qubes-core-agent-linux/blob/master/passwordless-root/qubes.sudoers

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200713105358.GA4984%40thirdeyesecurity.org.


Re: [qubes-users] Qubes Methodology

2020-07-12 Thread unman
On Fri, Jul 10, 2020 at 01:27:04PM +, 'qubesanon' via qubes-users wrote:
> Hello! I am looking for guidance in how best to set up my Qubes. I understand 
> that it's a very personal decision but having a methodology for how to 
> navigate the tradeoffs with an individual's personal philosophy seems prudent.
> 
> I believe that it's best to start with different types of threats that Qubes 
> may help you protect against. I am not a security expert, so please forgive 
> the informality of my description here as well as gross errors/omissions. 
> Corrections are very welcome.
> 
> 1. Malicious software: A user wishes to reduce the harm/access of malicious 
> hardware.
> Solution: Execute malicious software in a VM only with access to data that 
> the user is willing to risk.
> 
> 2. Malicious install script: While install scripts are smaller and easier to 
> audit, they are typically run as root.
> Solution: Install software in standalone VM. Consider that VM compromised 
> from inception.
> 
> 3. Tracking based on cookies/ad networks: privacy is undermined because your 
> behavior is correlated across seemingly unrelated websites you visit.
> Solution: Separate VMs (and/or use disposable VMs) for different types of web 
> browsing. Use a search engine that does not track you.
> 
> 4. Tracking based on IP.
> Solution: Use Whonix/TOR or a VPN. Use a search engine that does not track 
> you.
> 
> 5. Theft of data from hardware.
> Solution: Store in VM without network access. The data may need to be 
> acquired from a VM with network access, but keeping it at rest on a 
> non-network VM is still beneficial.
> 
> Personally, I find the tracking threats (3 and 4) to be the most challenging 
> to wrap my head around. Ideally, I would want as much traffic as possible 
> going through Whonix. And that which can't may want a different VM for each 
> website visited. While that approach is extreme and onerous both on myself 
> and my machine's precious resources, I find it difficult to determine where 
> to draw the line between caution and convenience.
> 
> Some questions that might help bring clarity:
> 
> - Under what circumstances would I want to use a different VM for my email 
> and for my financial accounts?
> - Under what circumstances would I want to use a different VM for my email 
> and for my shopping?
> 
> Thanks!
> 

Brief response:

Beside considering the types of threats you should start by considering
the way you live your digital life - this is implicit in your questions,
but I would make it explicit.

Draw the line between caution and convenience wherever it works for you.
It has to work, or you will find yourself ignoring your own guidelines.

Start by sketching out the areas of your life, and then allocate
qubes/colours to those areas. This will help you to decide how many
qubes you need. I always suggest starting big - you can always merge and
cut down after. It's much better to merge than retrospectively split.
Use background colours to match the ones you choose - force windows to
specific desktops - much easier in KDE, but doable in Xfce (I think).
Use different templates for different purposes.
Use many different disposableVMTemplates, and use the disposableVMs
systematically, allocated to different areas.
Use Tor.
Use Multiple Tor gateways systematically.
Randomly change things around in sensitive online areas.
Store data in offline qubes based on mini templates. Storing data
carries a minimal risk. Always *open* that data in an offline
disposableVM.

On your specific questions:
1. Always. That way an attacker cant leverage your email to get your
financial details/logins etc.
It follows that you should probably have different email qubes for
different accounts to keep your financial emails separate from your
other emails.

2. The same answer as 1 - except that the risk of being attacked by
shopping sites is probably higher than by banking sites, so here the
risk runs both ways. Leveraging email to get access to your shopping
habits etc, and leveraging a website to get access to your emails.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200712125603.GF922%40thirdeyesecurity.org.


Re: [qubes-users] Possibility to detect suspend events in VM?

2020-07-12 Thread unman
On Fri, Jul 10, 2020 at 01:04:40PM +0200, Phil Kn??fer wrote:
> Hi,
> 
> when accessing an SMB share in a Qubes AppVM after the system has been
> suspended for some time, I experience a serious lag (up to about a
> minute or so for each share that is mounted from the same SMB server).
> This seems to be due to the fact that the server has already timed out
> the SMB session, while the client (the AppVM) is still trying to resume
> it and therefore runs in TCP timeouts.
> 
> For bare-metal Linux systems, a possible solution is to unmount all SMB
> shares before the system goes into suspend (e.g., via a script in
> /usr/lib/systemd/system-sleep or via pm-utils).
> 
> I tried this approach in Qubes but it seems that the AppVMs do not know
> about a suspend event. Is there a way to trigger scripts on suspend in
> Qubes AppVMs or do I need to coordinate the SMB unmount from dom0 (it
> should be possible to trigger a script there that interacts with VMs via
> qvm-run or similar)?
> 
> 
> Regards,
> Phil
> 
> 

I think that the dom0 route is the way to go - it's what I use myself.
If you did find a way in the qube of detecting such events, I'd be
interested.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200712123719.GE922%40thirdeyesecurity.org.


Re: [qubes-users] Security benefits of rootless template VMs

2020-07-12 Thread unman
On Fri, Jul 10, 2020 at 08:18:20AM +, Alex Lu wrote:
> I've been thinking about splitting my templateVMs into a bunch of smaller
> ones with no root access where I don't need it. Is having like 5 templateVMs
> 4 of which have no root is better than having 1 templateVM which have root
> and in charge of every appVM? Or there is no security benefits considered I
> never do anything in templateVMs, besides installing packages, all of which
> are from official repos?
> 
> Alex
> 

The purported security benefit is that if the qube is compromised it
will be more difficult for the attacker to use root commands.
The Qubes position is that this benefit is illusory, in that if an
attacker is able to compromise your qube in the first place they will be
able to get root, even if `su` is not available.
Take a look at /etc/sudoers.d/qubes.

That said, there is a clear benefit in using multiple templates, in that
you reduce the attack surface of each qube. Base your templates off
minimal templates and only install the packages you need for qubes that
will use that template.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200712123554.GD922%40thirdeyesecurity.org.


Re: [qubes-users] DisposableVM Help

2020-07-12 Thread unman
On Sat, Jul 11, 2020 at 04:40:57PM -0700, Robert Spigler wrote:
> I have a debian-10-dvm and a whonix-ws-15-dvm.  I also had a fedora-30-dvm, 
> but when upgrading to fedora-32, I followed "Creating a New DisposableVM 
> Template" here: (https://www.qubes-os.org/doc/disposablevm-customization/), 
> so no longer have the fedora-30-dvm. Instead, I have a 
> custom-disposablevm-template based on fedora-32. I would prefer to rename 
> this to fedora-32-dvm-template, but renaming fails with 'Failed to clone 
> appmenus'.
> 
> My main question/problem is that unlike the debian-10-dvm and 
> whonix-ws-15-dvm, opening an application in fedora-32-dvm-template does not 
> open a disposableVM (disp), instead it opens 
> 'custom-disposablevm-template'.  IIUC, that is because I am supposed to 
> create fedora-32-dvm from the dvm-template.  But I cannot figure out how to 
> do that.  It is set as the default disposableVM template, so opening files 
> through the GUI in a disposableVM will open them in a disposableVM based on 
> fedora-32, but I would still like to be able to open an application through 
> the GUI/start menu in a fedora-32-dvm.
> 
> What I am also having trouble understanding is what dvm-template is the 
> debian-10-dvm and whonix-ws-15-dvm based on? I know Qubes4.0 introduced 
> multiple DVMTemplates, but I don't see any other DVMTemplates listed under 
> the start menu.  In Qubes Manager, debian-10-dvm and whonix-ws-15-dvm are 
> marked as being their own DVMTemplates? But also DVM's themselves?
> 
> Thank you,
> 
> Robert
> 

Hi Robert,

As you say, Qube 4.0 allowed for the use of many DVMTemplates - any
qube can be used as the basis for disposableVMs.
So the debian-10-dvm is not based on a dvm-template - it *is* a
dvm-template, a qube using the debian-10 template which has had the
`template_for_dvms` flag set.
That's all there is to it.

In your case, I suspect that the appmenus have not been correctly set,
so that they still refer to 'custom-disposablevm-template', instead of
using that as the basis for a disposableVM.
You can try running the command
 `qvm-features custom-disposablevm-template appmenus-dispvm 1`, although
there was an open issue about this command failing in some cases.

In dom0, (and therefore the menus), the difference is between:
qvm-run custom-disposablevm-template --service qubes.StartApp+xterm
and
qvm-run dispvm=custom-disposablevm-template --service qubes.StartApp+xterm

hth

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200712122741.GC922%40thirdeyesecurity.org.


Re: [qubes-users] vCPUs count over-booking

2020-07-12 Thread unman
On Sat, Jul 11, 2020 at 11:44:34AM -0700, Claudio Chinicz wrote:
> Hi,
> 
> I noted that my sum total of vCPUs is larger than the actual number of vCPUs.
> 
> Maybe Xen works at the minimum in order to keep sum total of vCPUs within 
> limits?
> 
> One thing I tried was to disable VT-x and then HVMs (min and max vCPUs is the 
> same) would not start.
> 
> Any ideas of how Xen manages vCPUs within the limits of the processor?
> 
> Regards
> 

Interesting question, Claudio.
As I understand it Xen allows you to create arbitrary number of vCPUs,
unrelated to the actual number of pCPUs you have. As you allocate more
vCPUs the system will start scheduling calls to the pCPUs and this may
impact performance.I don't think that disabling VT-x will impact this,
and as you have discovered it means that HVMs will not function.
To work around the limit you may find it useful to reduce the number
of vCPUs in most "ordinary" qubes to 1. You can also limit the  number
that dom0 uses, with the `dom0-max-vCPUs` parameter at boot.
If you have processor intensive qubes, you can then try allocating
specific vCPUs to that qube - this is called "pinning". In Xen this can
be done with the `xl vcpu-pin` command . You can make a pin hard ,"MUST
use this CPU", or soft, "PREFERS to use this CPU"
By default Qubes makes all qubes hard/soft pin to all CPUs.
If you think that you are being impacted by the scheduler, you can try
pinning on processor intensive qubes and see if it helps. There used to
be a health warning saying that pinning caused as many problems as it
(may) solve, so try at your own risk.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200712121407.GB922%40thirdeyesecurity.org.


Re: [qubes-users] Unable to install Google Chrom in my "media VM template" (fedora-32-minimal)

2020-07-06 Thread unman
On Mon, Jul 06, 2020 at 08:55:20PM +0200, 799 wrote:
> Hello,
> 
> because I want to be able to rebuild my system from scratch and to keep
> track of my installation notes, all my templates can be rebuild from dom0
> using scripts.
> All templates are based on a fedora-xx-minimal templates.
> 
> I have one template which I use as template for a media-VM. which has
> google chrome installed.
> Strangely my script which was working before is unable to install chrome
> using a fedora-32-minimal template.
> 
> I get the following error:
> [...]
>   Verifying: google-chrome-stable-83.0.4103.116-1.x86_64
>  23/23Errors during downloading metadata for repository 'google-chrome':
>   - Curl error (6): Couldn't resolve host name for
> http://dl.google.com/linux/chrome/rpm/stable/x86_64/repodata/repomd.xml
> [Could not resolve host: dl.google.com]
> Error: Failed to download metadata for repo 'google-chrome': Cannot
> download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were
> tried
> 
> the script which I use from dom0:
> https://github.com/one7two99/my-qubes/blob/master/my-qubes-templates/50%20template-media-vms.md
> 
> -
> Template=fedora-32-minimal
> TemplateName=t-fedora-32-media
> AppVMName=my-media
> qvm-kill $TemplateName
> qvm-remove --force $TemplateName
> qvm-clone $Template $TemplateName
> qvm-run --auto --pass-io --no-gui --user root $TemplateName \
> 'dnf -y update'
> 
> 
> qvm-run --auto --pass-io --no-gui --user root $TemplateName \
>  'dnf install -y pulseaudio-qubes qubes-core-agent-networking'
> 
> # Install Google Chrome
> qvm-run --pass-io --no-gui --user root $TemplateName \
>   'dnf install -y fedora-workstation-repositories && \
>dnf config-manager --set-enabled google-chrome && \
>dnf install -y google-chrome-stable'
> 
> qvm-shutdown --wait $TemplateName
> 
> qvm-create --template=$TemplateName --label=orange $AppVMName
> -
> 
> 
> Any idea what is wrong here or what needs to be changes in fedora-32 to be
> able to install Google Chrome?
> 
> O799
> 

The problem is that the template has no net access, so the curl call
fails - " [Could not resolve host: dl.google.com]" - that's a dns
failure.
The other calls work because they use the configured proxy - you need to
make sure that curl is also using that proxy. It might be clearer what is
happening if you were a little more verbose in the error report, but you
should get the idea.
You can make curl use a proxy by editing .curlrc to include the proxy
details:
proxy = 127.0.0.1:8082
Alternatively you can set environment variables for http_proxy and
https_proxy.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200707025719.GC6920%40thirdeyesecurity.org.


Re: [qubes-users] Adding a new / an extra virtual disk to a HVM in qubes 4.x

2020-07-06 Thread unman
On Sun, Jul 05, 2020 at 02:39:34PM -0700, keld@gmail.com wrote:
> thanks but the drive does not exist as you assume - i want to make the disk 
> from the existing volumegroup/disk-pool 
> I think i first need to allocate a lvm, then encrypt it ? and assign it 
> somehow 
> to get it to be persistent i think i need to also alter the XLM file used 
> to define the virtual machine.. 
> 
> I am still googling the fragments of how to do it - it would be a nice 
> feature to have it in the GUI as a "add another disk" option.
> 
> Regards Keld.
> 
> l??rdag den 4. juli 2020 kl. 03.39.56 UTC+2 skrev unman:
> 
> > On Thu, Jul 02, 2020 at 02:29:09AM -0700, Keld Norman wrote:
> > > I am trying to figure out how to add an extra virtual disk to a HVM 
> > > 
> > > I would like to just add a disk from the existing dom0 pool just like 
> > the 
> > > two disks assigned already (system and user) 
> > > 
> > > It is not that clear on how to do it - do any one here know if there is 
> > a 
> > > guide to do that in qubes v4.0
> > > 
> > > Best regards 
> > > Keld Norman
> > > 
> >
> > 1. Identify the drive that you want, and find the actual device.
> > You'll see (from ls -l ) that qubes/vm-qube-private is a link to some
> > device under /dev ; say /dev/dm-xx
> >
> > 2. Start the HVM with the disk attached:
> > `qvm-start HVM --hddisk=iso;/dev/xx`
> >
> > 3. The disk will be attached as /dev/xvdi
> >
> 

The convention here is not to top-post.
Please scroll to the bottom of the message before you start typing. Or
reply inline.
It only takes you seconds, makes it much easier to follow threads, and
cumulatively saves your fellow users hours.
Thanks.

Indeed, I had assumed that "add a disk from the existing pool" meant an
existing disk. This is a different question.
You will need to create a disk for use - it isn't clear why you mention
encryption, but you could encrypt if you wish.
You can either use the "qvm-start" method, or create a custom settings
file for the qube. This is documented at
https://dev.qubes-os.org/projects/core-admin/en/latest/libvirt.html

Depending on how you have configured the disk, you can create a custom
config which pulls n the disk. The information you need is at 
https://libvirt.org/formatdomain.html

If you hit a problem and need help, explain how you have configured the disk 
and post your
config file here.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200707024611.GB6920%40thirdeyesecurity.org.


Re: [qubes-users] Re: safely remove yum from debian tempate?

2020-07-06 Thread unman
On Sun, Jul 05, 2020 at 02:16:01PM -0700, Rune Philosof wrote:
> Hi
> 
> s??ndag den 28. juni 2020 kl. 23.23.39 UTC+2 skrev Dave C:
> >
> > A) Is it safe to remove qubes-core-agent-dom0-updates and 
> > qubes-vm-recommended from a debian template?
> > I've noticed that installing qubes-vm-recommended brings yum and yum-utils 
> > along with it.  This leaves me wondering, is there a way to uninstall yum 
> > on a debian template?
> >
> >
> I am having a related problem in my kali vm template. `yum` is not 
> available in the debian testing (bullseye) and unstable (sid).
> So I also have a bunch of qubes packages I have to mark as manually 
> installed to not have them uninstalled.
> I wonder what qubes will do in a debian11 vm template when yum is not 
> available.
> 

Indeed, yum/dnf are not available in Debian 11. But Frederic has
packaged a version for Qubes, and it may/should be incorporated in to
Debian. So all will be well.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200707022359.GA6920%40thirdeyesecurity.org.


[qubes-users] Bionic and Arch templates/packages

2020-07-05 Thread unman
Hello All,

Getting back in the swing after an enforced absence. 
I've uploaded new builds of the bionic and Arch templates to
https://qubes.3isec.org/Templates

These packages are signed with my Qubes Signing key - you can find this
on keyservers, in this list, and at GitHub. Verify the key, and then check
the signature on the template package.

There are also repositories for Ubuntu and Arch Qubes packages. You can add
these to your templates/qubes and update. You will need to add my key
before you can use the repository.

For Arch:
qvm-copy the key in to the arch template.
Add the key:
`sudo pacman-key --add `
`sudo pacman-key --lsign unman`

Set up the repository:
`cd /etc/pacman.d`

Then either create a new conf file, or rename the existing
99-qubes-repository-4.0.conf.disabled to 99-qubes-repository-4.0.conf.
Open the conf file for editing - the contents should be:
```
[qubes-r4.0]
Server = https://qubes.3isec.org/arch/4.0
```
(Don't type the ```)

Then update:
`sudo pacman -Syuu`
 
enjoy

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200705150111.GA31113%40thirdeyesecurity.org.


Re: Maybe salt has an issue with Python 3.8? (was: Re: [qubes-users] Salt issue with fedora 32)

2020-07-03 Thread unman
On Sat, Jul 04, 2020 at 02:41:53AM +0100, unman wrote:
> On Sat, Jul 04, 2020 at 01:45:10AM +0100, unman wrote:
> > On Wed, Jul 01, 2020 at 04:59:15PM +0200, Peter Funk wrote:
> > > > > File 
> > > > > "/var/tmp/.root_62a99a_salt/pyall/salt/grains/core.py", 
> > > > > line 40, in 
> > > > >   from platform import _supported_dists
> > > > >   ImportError: cannot import name '_supported_dists' from 
> > > > > 'platform' (/usr/lib64/python3.8/platform.py)
> > > ...
> > > 
> > > I had the chance to do some more research: This particular line was 
> > > originally 
> > > added in 2012 to salt/grains/core.py: 
> > >   
> > > https://github.com/saltstack/salt/commit/1f050476dee2b27278f1c8f7772339444c153f06
> > > But the current version of this module from looks very different:
> > >   https://github.com/saltstack/salt/blob/master/salt/grains/core.py
> > > 
> > > So it seems like the version of salt in your installation of Qubes OS 
> > > is to old by now to work together with the Python 3.8 in Fedora 32.
> > > 
> > > Regards, Peter Funk
> > 
> > There's an oblique reference to this in the announcement of the Fedora 32
> > template, in the section that refers to using the Qubes Updater. That
> > change is necessary because the Updater uses Salt - so the notice could
> > have referred to *any* use of salt including the Qubes Updater.
> > 
> > unman
> > 
> 
> Although making *that* change isnt enough to get salt working, even with
> the full Fedora-32 template.
> 

Scratch that - I've been away a while and am a bit rusty. With that
change, works fine, (at least for me).

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200704024858.GA24007%40thirdeyesecurity.org.


Re: [qubes-users] HowTo implement selks

2020-07-03 Thread unman
On Fri, Jul 03, 2020 at 12:40:23PM +0200, Joo Nasss wrote:
> HowTo implement selks
> 
> I have installed selks with hvm and ISO Install..
> 
> Now the question IS HowTo Set IT between sys-net and sys-firewall
> 
> Hope anybody can Help me
> 
> Best regards
> 
> cenapatop...@gmail.com
> 

I have not yet found a way to add a second downstream interface to an HVM in 
Qubes.
I dont think you can do this.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200704014745.GF23414%40thirdeyesecurity.org.


Re: [qubes-users] Template Installation Problem

2020-07-03 Thread unman
On Fri, Jul 03, 2020 at 01:52:59PM +0200, Qubes wrote:
> On 7/3/20 1:41 PM, Qubes wrote:
> 
> > qubes-dom0-current/metalink
> >  | 2.7 kB 00:00
> > https://mirror.linux.pizza/qubes-os.org/repo/yum/r4.0/current/dom0/fc25/repodata/repomd.xml:
> > [Errno 14] HTTPS Error 404 - Not Found
> 
> > updates
> >  | 4.7 kB 00:00
> > https://ftp-stud.hs-esslingen.de/pub/Mirrors/archive.fedoraproject.org/fedora/linux/updates/25/x86_64/repodata/b94977172dc0781147253c23a829626a015d4fd1d2c5ed90f0739b752fce4556-primary.sqlite.bz2:
> > [Errno 14] curl#16 - ""
> 
> Why do both mirror links point to 25, should it not be 32?
> 


You're trying to install the 32 template in dom0, and dom0 is fedora-25.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200704014441.GE23414%40thirdeyesecurity.org.


Re: Maybe salt has an issue with Python 3.8? (was: Re: [qubes-users] Salt issue with fedora 32)

2020-07-03 Thread unman
On Sat, Jul 04, 2020 at 01:45:10AM +0100, unman wrote:
> On Wed, Jul 01, 2020 at 04:59:15PM +0200, Peter Funk wrote:
> > > > File 
> > > > "/var/tmp/.root_62a99a_salt/pyall/salt/grains/core.py", 
> > > > line 40, in 
> > > >   from platform import _supported_dists
> > > >   ImportError: cannot import name '_supported_dists' from 
> > > > 'platform' (/usr/lib64/python3.8/platform.py)
> > ...
> > 
> > I had the chance to do some more research: This particular line was 
> > originally 
> > added in 2012 to salt/grains/core.py: 
> >   
> > https://github.com/saltstack/salt/commit/1f050476dee2b27278f1c8f7772339444c153f06
> > But the current version of this module from looks very different:
> >   https://github.com/saltstack/salt/blob/master/salt/grains/core.py
> > 
> > So it seems like the version of salt in your installation of Qubes OS 
> > is to old by now to work together with the Python 3.8 in Fedora 32.
> > 
> > Regards, Peter Funk
> 
> There's an oblique reference to this in the announcement of the Fedora 32
> template, in the section that refers to using the Qubes Updater. That
> change is necessary because the Updater uses Salt - so the notice could
> have referred to *any* use of salt including the Qubes Updater.
> 
> unman
> 

Although making *that* change isnt enough to get salt working, even with
the full Fedora-32 template.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200704014153.GD23414%40thirdeyesecurity.org.


Re: [qubes-users] Adding a new / an extra virtual disk to a HVM in qubes 4.x

2020-07-03 Thread unman
On Thu, Jul 02, 2020 at 02:29:09AM -0700, Keld Norman wrote:
> I am trying to figure out how to add an extra virtual disk to a HVM 
> 
> I would like to just add a disk from the existing dom0 pool just like the 
> two disks assigned already (system and user) 
> 
> It is not that clear on how to do it - do any one here know if there is a 
> guide to do that in qubes v4.0
> 
> Best regards 
> Keld Norman
> 

1. Identify the drive that you want, and find the actual device.
You'll see (from ls -l ) that qubes/vm-qube-private is a link to some
device under /dev ; say /dev/dm-xx

2. Start the HVM with the disk attached:
`qvm-start HVM --hddisk=iso;/dev/xx`

3. The disk will be attached as /dev/xvdi

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200704013952.GC23414%40thirdeyesecurity.org.


Re: Maybe salt has an issue with Python 3.8? (was: Re: [qubes-users] Salt issue with fedora 32)

2020-07-03 Thread unman
On Wed, Jul 01, 2020 at 04:59:15PM +0200, Peter Funk wrote:
> > > File "/var/tmp/.root_62a99a_salt/pyall/salt/grains/core.py", 
> > > line 40, in 
> > >   from platform import _supported_dists
> > >   ImportError: cannot import name '_supported_dists' from 
> > > 'platform' (/usr/lib64/python3.8/platform.py)
> ...
> 
> I had the chance to do some more research: This particular line was 
> originally 
> added in 2012 to salt/grains/core.py: 
>   
> https://github.com/saltstack/salt/commit/1f050476dee2b27278f1c8f7772339444c153f06
> But the current version of this module from looks very different:
>   https://github.com/saltstack/salt/blob/master/salt/grains/core.py
> 
> So it seems like the version of salt in your installation of Qubes OS 
> is to old by now to work together with the Python 3.8 in Fedora 32.
> 
> Regards, Peter Funk

There's an oblique reference to this in the announcement of the Fedora 32
template, in the section that refers to using the Qubes Updater. That
change is necessary because the Updater uses Salt - so the notice could
have referred to *any* use of salt including the Qubes Updater.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200704004510.GB23414%40thirdeyesecurity.org.


Re: [qubes-users] fedora-32

2020-07-03 Thread unman
On Wed, Jul 01, 2020 at 09:12:34AM +0200, Qubes wrote:
> On 7/1/20 3:51 AM, anon wrote:
> > Hello, is fedora-32 minimal adequate for use as sys-firewall? or is
> > there some reason that its better to use the full F32 template?
> > 
> You can use the minimal template, but not as it is 'out-of-the-box', the
> minimal template is missing Qubes specific packages/configuration. Have a
> look at this page in the documentation,
> https://www.qubes-os.org/doc/templates/minimal/.
> 
> In my opinion the minimal template may as well contain all of the packages
> needed to use that template for any Qubes related function, instead of the
> user meticulously having to make sure the needed packages for a specific
> qube to function as sys-firewall or sys-usb for example are installed.
> 

The idea is that it's minimal, so you can use it for a specific purpose,
which need not be one of the Qubes sys-* - nor need it be online. It's
also supposed to be used by someone who has some Qubes/command line
knowledge, so installing the necessary packages should not be a problem.
It is a small template with the absolute minimal required to function
in a Qubes environment.
I have seen requests to strip it down further, so one can have a headless
qube.
Horses for courses.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200704004208.GA23414%40thirdeyesecurity.org.


Re: [qubes-users] DisposableVM Closing/Stopping Unexpectedly

2020-06-29 Thread unman
On Tue, Jun 30, 2020 at 12:10:12AM +0200, Qubes wrote:
> On 6/29/20 10:34 PM, 'awokd' via qubes-users wrote:
> > Qubes:
> > > On 6/29/20 10:03 PM, haaber wrote:
> > > > On 6/29/20 9:25 PM, Qubes wrote:
> > > > > On 6/29/20 3:42 PM, Qubes wrote:
> > > > > > If I try to open a terminal in a dvm, I have tried in both the dvm's
> > > > > > that are installed by default (Disposable: fedora-31-dvm and
> > > > > > Disposable: whonix-ws-15-dvm) and one that I created on my own by 
> > > > > > just
> > > > > > creating a qube and setting the "Disposable VM Template" flag.
> > > > > > 
> > > > > > When I open a terminal in any of these the new disposable VM gets
> > > > > > created, is started, and the terminal opens briefly, but then closes
> > > > > > immediately after and the disposable VM gets deleted.
> > > > > > 
> > > > > > Which log should I look at to troubleshoot?
> > 
> > Use xterm instead. Gnome terminal does that with dvms because of how it
> > starts.
> > 
> I am not sure I agree. Gnome is the default in Qubes. A vanilla Qubes
> install works and the default is the Gnome terminal.
> 

awokd is right - This is a long standing problem and there is an issue
relating to it - gnome terminal actually spawns gnome-terminal-server to
spawn a new window and then exits. Because the command you called has
exited the disposableVM closes, as expected.
Strange but true.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200630005435.GA29022%40thirdeyesecurity.org.


Re: [qubes-users] safely remove yum from debian tempate?

2020-06-29 Thread unman
On Mon, Jun 29, 2020 at 12:50:01PM +0200, Fr??d??ric Pierret wrote:
> 
> 
> On 2020-06-28 23:23, Dave C wrote:
> > I'd like to??
> > 
> > |
> > sudo apt remove yum
> > |
> > 
> > because the yum files in /etc/bash_completion.d/ break things for fossil 
> > (autocomplete appends a space instead of slash after directories when 
> > running fossil).
> > 
> > However, apt warns the following:
> > 
> > |
> > The following packages will be REMOVED:
> > ?? qubes-core-agent-dom0-updates qubes-vm-recommended yum yum-utils
> > 
> > |
> > 
> > A) Is it safe to remove qubes-core-agent-dom0-updates and 
> > qubes-vm-recommended from a debian template?
> > 
> > Also, apt tells me that autoremove would further remove quite a few 
> > packages, including several from qubes:
> > 
> > |
> > ?? qubes-core-agent-passwordless-root qubes-gpg-split
> > ?? qubes-img-converter qubes-input-proxy-sender qubes-mgmt-salt-vm-connector
> > ?? qubes-pdf-converter qubes-thunderbird qubes-usb-proxy
> > |
> 
> When building normal template, we add a meta-package called 
> qubes-vm-recommended which is responsible to pull above dependencies and 
> notably qubes-core-agent-dom0-updates, which itself requires yum and 
> yum-util. You can safely remove it if you don't use debian template as 
> "UpdateVM" in Qubes global preferences.

As with any meta-package, you may want to keep some of the other
packages that it pulls in. This is not peculiar to Qubes.
You should mark these as "hold" or "instal" when removing the
meta-package, so that you remove only the target package.
A decent package manager like aptitude will make this easy.

If you need help with this, just ask.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200629113150.GA25753%40thirdeyesecurity.org.


Re: [qubes-users] WARNING: Thin volume qubes_dom0/img-Tails maps 8.00 GiB while the size is only 2.00 GiB.

2020-06-19 Thread unman
On Sun, Jun 14, 2020 at 11:51:04PM +0200, Ulrich Windl wrote:
> Hi!
> 
> While experimenting with an image that didn't do what I wanted to I ended up
> with this LVM warning:
> WARNING: Thin volume qubes_dom0/img-Tails maps 8.00 GiB while the size is
> only 2.00 GiB.
> 
> How can I "heal" LVM?
> [root@dom0 master]# lvdisplay qubes_dom0/img-Tails
>   --- Logical volume ---
>   LV Path/dev/qubes_dom0/img-Tails
>   LV Nameimg-Tails
>   VG Namequbes_dom0
>   LV UUID4IwD50-xeKY-0PNs-FbB7-99aF-fGde-162Soq
>   LV Write Accessread/write
>   LV Creation host, time dom0, 2020-02-13 21:32:40 +0100
>   LV Pool name   pool00
>   WARNING: LV qubes_dom0/img-Tails maps 8.00 GiB while the size is only 2.00
> GiB.
>   LV Status  available
>   # open 0
>   LV Size2.00 GiB
>   Mapped size100.00%
>   Current LE 512
>   Segments   1
>   Allocation inherit
>   Read ahead sectors auto
>   - currently set to 256
>   Block device   253:11
> 
> Ulrich
> 

You have a consistency problem - you should be able to fix it by using
lvresize to change the size of that volume to 8.0 GiB

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200619235017.GA14741%40thirdeyesecurity.org.


Re: [qubes-users] Weird Windows Install Error

2020-06-19 Thread unman
On Fri, Jun 19, 2020 at 08:33:23PM +, 'Matt Drez' via qubes-users wrote:
> Hey guys,
> 
> I've been using Qubes for quite a while now and I'm stoked.
> 
> I just finished building a second computer for Qubes. (This times it's AMD in 
> case it matters). Everything went perfect but when I tried installing a 
> Windows 10 and a Server 2019 VM both died with BSOD. The error message was:
> "stop code: windows multiprocessor configuration not supported"
> 
> Any idea what in the world could cause this? None of the other VMs caused any 
> headache, not even the ones I installed from ISO.
> 
> Thanks for the help
> 
> Matt
> 
It's not an uncommon error.
Try the obvious - go in to the qube settings, and change VCPU to 1.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200619233635.GA14595%40thirdeyesecurity.org.


Re: [qubes-users] Re: Programmatically configuring appmenus for dispvm templates

2020-06-19 Thread unman
On Thu, Jun 18, 2020 at 07:59:48AM -0700, Emma Borhanian wrote:
> Multiple other problems:
> * do not run qvm-appmenus or qvm-sync-appmenus as root, this will create
> entries in other XDG_DATA_DIRS/XDG_DATA_HOME that cannot be deleted through
> the UI, which you have to delete manually
> * sometimes the list of available applications just keeps disappearing? I'm
> not sure what's doing this. qvm-sync-appmenus fixes it but I keep having to
> run it over and over.
> * entries in dmenu keep randomly all disappearing, being replaced by only
> Qube Settings. the whitelist files look fine, but they get deleted from the
> qubes-appmenus/applications directory
> * when I run many qvm-appmenus in parallel in my dom0 salt config, the
> stderr for some is getting output from other qvm-appmenus runs!?
> 
> Maybe there's some sort of race condition in qvm-appmenus?
> 
> Also a significant portion of the time, trying to launch an application from
> dmenu causes it to never start.
> 
> Also I'm getting System tray icons disappearing constantly, especially wifi:
> https://github.com/QubesOS/qubes-issues/issues/2242
> 
> I'm starting to regret thinking I could configure my system entirely
> idempotently with salt.
> 
> On 6/17/20 10:56 PM, Emma Borhanian wrote:
> > Nevermind, my problem was trying to run `qvm-appmenus` from sudo.
> > 
> > Still unfortunate there's no --get-default-whitelist though.
> > 
> > On 6/15/20 6:48 PM, Emma Borhanian wrote:
> > > Hi, I'm trying to programmatically configure the appmenus for a
> > > dispvm template.
> > > 
> > > `qvm-appmenus --get-whitelist / --set-whitelist /
> > > --set-default-whitelist` seems out-of-sync with what I configure in
> > > Qube Manager, and neither --set-whitelist or --set-default-whitelist
> > > work for dispvm templates. I'm also confused why there's no
> > > `--get-default-whitelist`.
> > > 
> > > I considered just manually copying over the .desktop files, but the
> > > `apps.templates` directory is empty and doesn't populate when I run
> > > `qvm-sync-appmenus`. Are they put somewhere else?
> > > 
> 
Hi Emma

The convention here is not to top-post.
Please scroll to the bottom of the message before you start typing. Or
reply inline. (Even for your own messages.)
It only takes you seconds, makes it much easier to follow threads, and
cumulatively saves your fellow users hours.

In general, it's a dreadful idea to run *any* qubes tools as root,
because (as you've discovered) permissions.

I cant help with dmenu. What WM are you using?

What do you think `--get-default-whitelist` would do? Restore the
application list to default settings? I dont believe that information is
stored anywhere.
Do you still see a discrepancy between the qvm-appmenus output and what
you have configured in Qube Manager?

On the salt front, it would be helpful if you could post a snippet of
your state file, so we can see exactly is going on.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200619131507.GA12249%40thirdeyesecurity.org.


Re: [qubes-users] Can someone pls help me troubleshoot why qvm-run --pass-io doesn't work with win7-template

2020-06-12 Thread unman
On Fri, Jun 12, 2020 at 03:57:35PM -0700, xyzo wrote:
> qubes version 4.0.
> I need to copy files from win7-template to a Linux appvm. I was suggested to 
> use (qvm-run --pass-io win7-template "type C:\n.pdf" > ./n.pdf)
> To copy files from win7-template to dom0 then move it from dom0 to any 
> destination appvm. Invoking this command in dom0 terminal, the curosr just 
> hangs and nothing happens and I exit by ^C in terminal. Running it with 
> --verbose parameter shows "Running win7-template C:\n.pdf" and it hangs. It's 
> like it's not seeing that win7-template is already running.
> 
> I discovered that the command only works when win7-template is powered off. 
> Then invoking above command will power on win7-template and successfully 
> execute.
> 
> PS: I can copy files from any Linux appvm to the win7-template QubesIncoming 
> folder by right-clicking the file I want to copy to win7-template and 
> selecting "copy to another Vm" this works fine to copy any file from Linux 
> appvm over to win7-template. But not the other way around.
> 
> So I'm not sure why the qvm-run --pass-io hangs when win7-template is already 
> running. Any help is appreciated. Thanks
> 

Why are you doing this?
In Windows, right click on the file, Select "Send to", and there are the
options to copy or move to another qube.

As to your "problem", on my windows templates with QWT installed, I do
not see the behaviour you report. Simply, it does not hang, but it does
not provide the output that you want.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200612233835.GA8841%40thirdeyesecurity.org.


Re: [qubes-users] Accessing files on a different SSD on the same laptop...

2020-06-07 Thread unman
On Sun, Jun 07, 2020 at 04:04:25AM -0700, Andrew Sullivan wrote:
> 
> 
> On Sunday, 7 June 2020 07:12:23 UTC+1, haaber wrote:
> >
> > On 6/6/20 6:33 PM, Andrew Sullivan wrote: 
> > > 
> > > If you use qvm-block in dom0 can you see the disk/partitions? 
> > > 
> > > 
> > >   Don't know, I'll give it a try and post back. 
> > > 
> > > 
> > > OK, if I click on the  Devices widget I can indeed see all the 
> > > partitions on my internal SSD, with an arrow next to each.  If I click 
> > > the arrow I get a list of qubes, which I believe allows me to attach the 
> > > selected partition to where I want.  However, when I do this I can't 
> > > find the partition in the Files application in the qube.  Think I'm 
> > > still missing something...  Also, am I correct that this attachment will 
> > > only persist until I close the qube? 
> >
> > they will be inserted in the appvm-qube as /dev/xvdi, /dev/xvdk ... 
> > [vd = virtual device, I guess]. The existence of a device does not mean 
> > mounting it. I do that by hand: in a terminal, type 
> >
> > sudo mount /dev/xvdi /media 
> >
> > will mount the attached device to /media and allow file access. If it is 
> > a luks-encrypted system, do 
> >
> > sudo crypsetup luksOpen  /dev/xvdi  MYSSDVOL 
> > sudo mount  /dev/mapper/MYSSDVOL/media 
> >
> > cheers 
> >
> 
> Many thanks for that, works exactly as described!  Seems a bit strange that 
> the partition isn't mounted at the time it was attached (not sure why you'd 
> want to attach it if you didn't plan to read or write to it?).   Anyways...

You may want to read/write *without* mounting - for example, when using
dd to write a disk image.

> 
> Is there any way the attachment and mounting can be made permanent?
> 

`man` is your friend - specifically `man qvm-block`.
You will see that there is indeed a `--persistent` option.

Mounting could be a simple (and standard) entry in /etc/fstab - nothing Qubes
specific here. Or simply a call to `mount`.
Make sure that you use a good identifier - /dev/xvdi may or may not work
- a label or UUID would be much better.
Again `man fstab` and `man mount` will help.

The Qubes specific part will be to make sure that any changes you  make
to /etc/fstab are persistent - you could do this using bind-dirs or by
an entry in /rw/config/rc.local




> Next challenge - access files on another Linux laptop on the same network!
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/qubes-users/da8f0bd7-8736-4e32-b64c-9721ab8fabaco%40googlegroups.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200607152850.GC14422%40thirdeyesecurity.org.


Re: [qubes-users] Has anyone tried pptp in qubes 4.0?

2020-06-07 Thread unman
On Sat, Jun 06, 2020 at 08:02:20PM +0200, onelovecisco via qubes-users wrote:
> And i forgot to tell you that pptp doesnt work from sys-net directly else. Do 
> you know why?
> Journalctl gives me a little info such like "Modem hangs up".So i cant?? 
> troubleshooting connection.
> >From another host it works good. Firewall doesnt block 1723 (telnet and ping 
> >to server works)
>  Nat_conntrack enabled in fedora template kernel.
> 
> 
> Jun 6, 2020, 17:51 by un...@thirdeyesecurity.org:
> 
> > On Thu, Jun 04, 2020 at 08:25:50PM +0200, 0rb via qubes-users wrote:
> >
> >> Telnet 1723 port works and i can ping server?? from 
> >> sys-net/sys-firewall/proxy-vm
> >> But connection can't be established from proxy-vm. Modem hangs if watch 
> >> journalctl | grep ppptp
> >>
> >> [user@sys-net ~]$ lsmod | grep pptp
> >> nf_nat_pptp?? 16384?? 0
> >> nf_nat_proto_gre 16384?? 1 nf_nat_pptp
> >> nf_conntrack_pptp?? 16384?? 1 nf_nat_pptp
> >> nf_conntrack_proto_gre?? 16384?? 1 nf_conntrack_pptp
> >> nf_nat 36864?? 5 
> >> nf_nat_ipv4,xt_nat,nf_nat_pptp,nf_nat_proto_gre,xt_REDIRECT
> >> nf_conntrack?? 163840?? 11 
> >> xt_conntrack,nf_nat,nft_ct,xt_state,nf_conntrack_pptp,ipt_MASQUERADE,nf_nat_ipv4,xt_nat,nf_nat_pptp,nf_conntrack_proto_gre,xt_REDIRECT
> >>
> >> Can anyone help how to use ppptp in QubesOS ?
> >>
> >> In 2016 Unman says
> >>
> >> First you need to allow INBOUND protocol 47:
> >> On sys-net:
> >> modprobe ip_conntrack_pptp
> >> modprobe ip_nat_pptp
> >> iptables -I FORWARD -p 47 -s ?? -j ACCEPT
> >>
> >> On proxyVM:
> >> iptables -I INPUT -p 47 -s  -j ACCEPT
> >>
> >> Now, zero the iptables counters, (using -Z), and try to start the vpn.
> >> You should see the counters incrementing both in sys-net and on the
> >> vpn proxy.
> >> If the connection fails look to see if any DROP rules are being
> >> triggered.
> >> By default PPTP uses tcp port 1723 so you could put in a rule to log
> >> that traffic :
> >> iptables -I FORWARD -p tcp --dport 1723 -j LOG
> >>
> >> But it doesnt solve the problem.
> >>
> >
> > 4 year old suggestions will rarely work in Qubes, but the principle is
> > good.
> > I don't use pptp myself, but have set this up for various users - a little
> > more information from your end would be useful.
> > Where are you trying to set up pptp connection from?
> > What does your Qubes netvm structure look like?
> > Have you set up firewall rules to allow INBOUND protocol 47?
> >


The convention here is not to top-post.
Please scroll to the bottom of the message before you start typing. Or
reply inline.
It only takes you seconds, makes it much easier to follow threads, and
cumulatively saves your fellow users hours.

Have you allowed inbound proto 47?
TCP port 1723 is the control connection, but the pptp tunnel is GRE -
that's PROTOCOL 47
It might be helpful if you post your firewall rules

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200607151318.GB14422%40thirdeyesecurity.org.


Re: [qubes-users] SplitGPG with Subkeys Encryption Error

2020-06-07 Thread unman
On Sat, Jun 06, 2020 at 06:22:31PM -0700, Robert Spigler wrote:
> 
> 
> > > 
> >
> > Read my last message - you dont actually type the angle brackets 
> > This is simply a bash script, you can inspect for yourself: it's at 
> > /usr/bin/qubes-gpg-client-wrapper 
> >
> > I'm not sure I understand your clarification - in any case, use the 
> > command line I cited without the angle brackets. 
> >
> 
>  I tried your suggestion:
> 
> qubes-gpg-client-wrapper -r robertspig...@protonmail.ch --trusted-key 
> C2C60E279E86F10D5697782535CE0FE6C2141823 -e 
> '/home/user/Documents/Test_Encryption.txt' -o /home/user/Documents/Final.gpg
> 
> But with the error in terminal:
> 
> gpg: C2C60E279E86F10D5697782535CE0FE6C2141823 is not a valid long keyID
> 
> However, this time the qubes-gpg-client interface did pop up, as well as 
> the file Final.gpg being created (but it was empty).  Seems like we're 
> getting closer.  That definitely is the valid keyID, so I don't know what 
> is wrong.
> 

What is wrong is that you dont seem to understand the difference between
fingerprints and keyIDs.
fingerprint C2C60E279E86F10D5697782535CE0FE6C2141823
long keyID  35CE0FE6C2141823
short keyID C2141823

I've included "short" only for reference - dont use it.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200607134715.GA14422%40thirdeyesecurity.org.


Re: [qubes-users] Accessing files on a different SSD on the same laptop...

2020-06-06 Thread unman
On Sat, Jun 06, 2020 at 07:59:14AM -0700, Andrew Sullivan wrote:
> Well, just done my first Qubes install - onto a USB 3 stick attached to a 
> Dell Latitude E5470 (only a temporary arrangement pending installing a 
> second SSD in the laptop).  I was pleasantly surprised how smoothly it went 
> (although it took a while to complete the install and updates seem to take 
> an age) and most things I need to work, do.
> 
> One thing I can't figure out...  I have data files on the internal SSD 
> which I would like to access from Qubes.  I can find reference in the 
> documentation to accessing USB sticks, but not a SSD.  I would like to have 
> the access permanent (in a "conventional" Linux installation, I think I 
> would edit fstab appropriately?).  Neither lsblk or fdisk -l seem to show 
> me anything about the internal SSD.
> 
> I think I must be missing something, any pointer would be welcome.
> 
> Thanks
> 

Do you want the SSD partitions permanently attached to one qube?
If you use qvm-block in dom0 can you see the disk/partitions?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200606151308.GE10363%40thirdeyesecurity.org.


Re: [qubes-users] IT IS Not possible to encrypt boot Filesystem in Installation process

2020-06-06 Thread unman
On Sat, Jun 06, 2020 at 08:42:59AM +0200, Joo Nasss wrote:
> If I try to select encrypted Filesystem IT Changes to unencrypted FS.
> 
> 
> I want to Install IT with grub encryption
> 
> ( https://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/ )
> 
> With grub in a write protected SD
> 

You're right - it isnt possible to do this. That's because Qubes uses
the Fedora installer, which requires unencrypted /boot.
You can install as normal, and THEN move boot on to the encrypted
drive/partition.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200606150316.GD10363%40thirdeyesecurity.org.


Re: [qubes-users] Question for google groups

2020-06-06 Thread unman
On Fri, Jun 05, 2020 at 12:09:54PM -0500, Sven Semmler wrote:
> On Fri, Jun 05, 2020 at 04:28:59AM -, lymepopsicle via qubes-users wrote:
> > Can someone help me with the commands for installing Signal in the debian
> > 10 template vm? It seems like the official documentation from the Qubes
> > website is outdated, so ideally if someone could update the documentation
> > for debian 10 rather than the current deprecated debian 9 documentation,
> > that would benefit more users beyond myself.
> 
> I just did it the other day. The one piece of information that's missing in 
> the documentation is that for curl to work the template needs to have a 
> netvm. Normally you want your templates to be offline and only use the 
> UpdateProxy to install software. Here step-by-step:
> 

Since the proxy is *just* a proxy you can (ab)use it as you will, as has
already been pointed out. Much better than giving the template a netvm.
You can use the proxy for grabbing PGP keys as well as curl.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200606145808.GC10363%40thirdeyesecurity.org.


Re: [qubes-users] Has anyone tried pptp in qubes 4.0?

2020-06-06 Thread unman
On Thu, Jun 04, 2020 at 08:25:50PM +0200, 0rb via qubes-users wrote:
> Telnet 1723 port works and i can ping server?? from 
> sys-net/sys-firewall/proxy-vm
> But connection can't be established from proxy-vm. Modem hangs if watch 
> journalctl | grep ppptp
> 
> [user@sys-net ~]$ lsmod | grep pptp
> nf_nat_pptp?? 16384?? 0
> nf_nat_proto_gre 16384?? 1 nf_nat_pptp
> nf_conntrack_pptp?? 16384?? 1 nf_nat_pptp
> nf_conntrack_proto_gre?? 16384?? 1 nf_conntrack_pptp
> nf_nat 36864?? 5 
> nf_nat_ipv4,xt_nat,nf_nat_pptp,nf_nat_proto_gre,xt_REDIRECT
> nf_conntrack?? 163840?? 11 
> xt_conntrack,nf_nat,nft_ct,xt_state,nf_conntrack_pptp,ipt_MASQUERADE,nf_nat_ipv4,xt_nat,nf_nat_pptp,nf_conntrack_proto_gre,xt_REDIRECT
> 
> Can anyone help how to use ppptp in QubesOS ?
> 
> In 2016 Unman says
> 
> First you need to allow INBOUND protocol 47:
> On sys-net:
> modprobe ip_conntrack_pptp
> modprobe ip_nat_pptp
> iptables -I FORWARD -p 47 -s ?? -j ACCEPT
> 
> On proxyVM:
> iptables -I INPUT -p 47 -s  -j ACCEPT
> 
> Now, zero the iptables counters, (using -Z), and try to start the vpn.
> You should see the counters incrementing both in sys-net and on the
> vpn proxy.
> If the connection fails look to see if any DROP rules are being
> triggered.
> By default PPTP uses tcp port 1723 so you could put in a rule to log
> that traffic :
> iptables -I FORWARD -p tcp --dport 1723 -j LOG
> 
> But it doesnt solve the problem.

4 year old suggestions will rarely work in Qubes, but the principle is
good.
I don't use pptp myself, but have set this up for various users - a little
more information from your end would be useful.
Where are you trying to set up pptp connection from?
What does your Qubes netvm structure look like?
Have you set up firewall rules to allow INBOUND protocol 47?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200606145106.GB10363%40thirdeyesecurity.org.


Re: [EXT] Re: [qubes-users] Multiple X sessions in Dom0?

2020-06-06 Thread unman
On Sat, Jun 06, 2020 at 01:09:07AM +0200, Ulrich Windl wrote:
> On 5/29/20 12:23 PM, Fr??d??ric Pierret wrote:
> > 
> > 
> > On 2020-05-29 02:34, brendan.h...@gmail.com wrote:
> > > Can Qubes support multiple X sessions in dom0?
> > 
> > I guess you want to see VMs in separate X sessions. Without speaking of 
> > user management, yes it can but currently gui-daemon is running on 
> > DISPLAY=:0 waiting for all VM start/shutdown and starting a proper server 
> > for them. In your case of having multiple DISPLAY, that would mean to adapt 
> > the automatic start of each deamon per VM.
> 
> Actually I think that the virtual desktops (four by default) can substitute
> for having multiple X servers running on private screens.
> (Did you ever try Ctrl+Alt+CursorLeft/CursorRight?)
> However what I'm missing is the feature to make some VMs (or maybe Apps)
> start on a specific virtual desktop.

Switch to KDE, and use "Activities", which are *made* for Qubes use.
Unlimited Activities, each with own virtual desktops - extremely easy to
target qubes on particular Activities, or target specific applications.
Activity backgrounds can be set to specific colours to help identify security 
domains.
Simple to modify KDE menu.
Once you've changed, you wont go back.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200606144148.GA10363%40thirdeyesecurity.org.


Re: [qubes-users] removing "system tools" and "Create Qubes VM" etc from start menu ..

2020-06-03 Thread unman
On Wed, Jun 03, 2020 at 07:22:38PM +, WillyPillow wrote:
> On Thursday, June 4, 2020 3:12 AM, Dave  wrote:
> 
> > Is it possible to remove everything from the start menu but the different 
> > domains ..?
> > So the user can only see the different vm's in the start menu and non of 
> > the stuff like "System Tools" and "Create Qubes VM"..
> 
> Related issue: .

This really isnt a Qubes issue, but relates to the DE you are using.
If you were to switch to KDE you would find it extremely easy to
customise the menu as you like. Right click on the Qube Menu icon and
select "Edit Applications".
 
XFce Menu support is somewhat harder to manage, but it can be done -
take a look at https://wiki.xfce.org/howto/customize-menu to start.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200604001607.GB29477%40thirdeyesecurity.org.


Re: [qubes-users] whats the correct syntax for qvm-backup-restore

2020-06-03 Thread unman
On Wed, Jun 03, 2020 at 11:45:10AM -0700, Dave wrote:
> when i use qmv-backup-restore -d sys-net backup_location 
> /run/media/path_to_usb/backup_file i am asked for passphrase to decrypt the 
> backup.
> Next i get an error Backup Header retrieval failed (exit code2) ... Tested 
> the backup with the GUI and the backup restored fine ..
> Any clue whats causing the error ..?
> 
> On Wednesday, 3 June 2020 18:12:59 UTC+2, unman wrote:
> >
> > On Tue, Jun 02, 2020 at 06:01:23AM -0700, Dave wrote: 
> > > Hey guys, 
> > > 
> > > Whats the syntax to restore a backup from an usbstick attached to 
> > > sys-net(used as sys-usb) .. 
> > > is it qmv-backup-restore -d sys-net backup_location 
> > > /run/media/path_to_usb/backup_file .. 
> > > or do i need to use another syntax ..? 
> > > 
> >
> > `qvm-backup-restore -d sys-net /run/media/path_to_usb/backup_file ` 
> >
> >
> 

Hi Dave

The convention here is not to top-post.
Please scroll to the bottom of the message before you start typing. Or
reply inline.
It only takes you seconds, makes it much easier to follow threads, and
cumulatively saves your fellow users hours.

Compare what you typed with what I suggested - dont include the
words "backup_location"

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200604000656.GA29477%40thirdeyesecurity.org.


Re: [qubes-users] Re: Do you use Qubes OS as your main OS on primary PC? What kind of work do you get done on it?

2020-06-03 Thread unman
On Wed, Jun 03, 2020 at 08:25:08AM -0700, Daniil Travnikov wrote:
> I know that this is kinda off topic. But what about Battery Runtime in your 
> laptops? I mean is it the same in Qubes like in any other OS?
> I am asking because my laptop working in Ubuntu about 5 hours, but in Qubes 
> only 1 hour. On any version till the last one - I started use it from 3.2.1.
> 

1 hour sounds woeful, but you dont say what laptop it is.
Yes, under Qubes all the Thinkpads I've seen run hotter with lower
battery life than a standard distro. With coreboot worse again.
This x230 with 9cell battery gives me 4-5 hours, well tuned.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200603162045.GC27681%40thirdeyesecurity.org.


Re: [qubes-users] Arch Linux Template stops working when upgrading nettle and gnutls

2020-06-03 Thread unman
On Wed, Jun 03, 2020 at 04:47:27AM -0700, dazwil...@gmail.com wrote:
> QubesOS 4.0
> 
> For me, its always such a mess updating my Arch Linux template. Make a 
> backup first if something goes wrong, and then if/when something fails, 
> locate the offending package(s).
> 
> This time it's nettle 3.6-1 and gnutls 3.6.13-2. Cant launch anything from 
> the template and appwms after installing those.
> If I hold those packages in pacman.conf many things breaks (of course).
> 
> So, what do I need to do to fix this?
> I can connect to the template via XL Console from dom0, so I tried a few 
> things like recompiling qubes-vm-gui. Did not do anything.
> 
> Help please.
> 

I know it's a pain but it's a consequence of using a rolling distro -
you get the same if using a testing Debian - things will break.
I'll dig in tomorrow and see what can be done.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200603161711.GB27681%40thirdeyesecurity.org.


Re: [qubes-users] whats the correct syntax for qvm-backup-restore

2020-06-03 Thread unman
On Tue, Jun 02, 2020 at 06:01:23AM -0700, Dave wrote:
> Hey guys,
> 
> Whats the syntax to restore a backup from an usbstick attached to 
> sys-net(used as sys-usb) ..
> is it qmv-backup-restore -d sys-net backup_location 
> /run/media/path_to_usb/backup_file ..
> or do i need to use another syntax ..?
> 

`qvm-backup-restore -d sys-net /run/media/path_to_usb/backup_file `

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200603161254.GA27681%40thirdeyesecurity.org.


Re: [qubes-users] Re: Updating sys-usb template

2020-06-01 Thread unman
On Thu, May 28, 2020 at 01:39:57PM -0700, TheGardner wrote:
> Always using for updates of sys-usb the following commands in Terminal in 
> dom0:
> 
> Just a restart:
> qvm-shutdown --wait sys-usb; qvm-start sys-usb
> 
> 
> A change of the (already installed) new template, when all other vms 
> already working with this new template:
> qvm-shutdown --wait sys-usb; qvm-prefs -s sys-usb template  -number>; qvm-start sys-usb
> 
> 
> So for an update to Fedora-32 it would work with:
> qvm-shutdown --wait sys-usb; qvm-prefs -s sys-usb template fedora-32; 
> qvm-start 
> sys-usb
> 
> 
> Sometimes it crash and the cube won't starting proper again, so I have to 
> turn the machine off and start new, but in 80% of the cases it's working 
> this way.

And *that* is exactly why I suggest testing first with an automatic roll
back to use the original template

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200601233838.GA18914%40thirdeyesecurity.org.


Re: [qubes-users] ubuntu template qubes 4.0

2020-05-31 Thread unman
On Sun, May 31, 2020 at 09:14:27AM -0700, Damien Waber wrote:
> Thanks very much ! and than you for the link to prebuilt images. You even 
> have focal :-D
> 
> 
> 
> Le dimanche 31 mai 2020 07:51:06 UTC-4, unman a ??crit :
> >
> > On Sat, May 30, 2020 at 12:06:16PM -0700, Damien Waber wrote: 
> > > Hi, 
> > > 
> > > I tried to build an ubuntu template since it is required for one of my 
> > > courses. I followed several tutorials / posts on the internet but all 
> > > failed. Could anyone help me? 
> >
> > There's a fix in the pipeline - in the meantime, go to 
> > app-linux-pdf-converter/debian and edit `rules` - 
> > On line 17, there's a typo - 
> > Change qubes.pdf-converter to qubes-pdf-converter 
> >
> > Now the build will work, albeit with warnings that I really should fix. 
> >
> > If you are short of time, you can always grab a pre-built template from 
> > https://qubes.3isec.org 
> >
> 

The PR has been merged, so a simple update on the sources will do.

I do have a focal template there - Made it for a client, but thought I'd
make it available.
It wont be available in qubes-builder until the debootstrap scripts are
updated to include focal.
If anyone's interested, I could provide a quick write-up on how to build
the focal template..

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200531235030.GA13020%40thirdeyesecurity.org.


Re: [qubes-users] ubuntu template qubes 4.0

2020-05-31 Thread unman
On Sat, May 30, 2020 at 12:06:16PM -0700, Damien Waber wrote:
> Hi,
> 
> I tried to build an ubuntu template since it is required for one of my 
> courses. I followed several tutorials / posts on the internet but all 
> failed. Could anyone help me?

There's a fix in the pipeline - in the meantime, go to
app-linux-pdf-converter/debian and edit `rules` -
On line 17, there's a typo - 
Change qubes.pdf-converter to qubes-pdf-converter

Now the build will work, albeit with warnings that I really should fix.

If you are short of time, you can always grab a pre-built template from
https://qubes.3isec.org

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200531115101.GA10314%40thirdeyesecurity.org.


  1   2   3   4   5   6   7   8   9   10   >