from:"Manuel Amador $Rudd\-O$"

Re: [qubes-users] 4.2 issue with pam_sss.so

2024-02-25 Thread Manuel Amador (Rudd-O)

Install sssd_client package and it goes away.

On January 20, 2024 1:26:00 AM GMT+01:00, Ulrich Windl  
wrote:
>Hi!
>
>
>I just noticed these messages (in my upgraded Qubes OS):
>
>Jan 20 01:22:39 dom0 sudo[25013]: PAM unable to 
>dlopen(/usr/lib64/security/pam_sss.so): /usr/lib64/security/pam_sss.so: cannot 
>open shared object file: No such file or directory
>Jan 20 01:22:39 dom0 sudo[25013]: PAM adding faulty module: 
>/usr/lib64/security/pam_sss.so
>
>Am I the only one to see them?
>
>Regards,
>
>Ulrich
>
>
>-- 
>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/c0dcefc4-dba7-4a3c-9085-262408f33872%40gmail.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/0206D65D-4C02-414C-A7C4-FD9D9A98653E%40rudd-o.com.

Re: [qubes-users] issue with URL handler in Thunderbird: started VM receives truncated URL

2024-02-25 Thread Manuel Amador (Rudd-O)

I have this you can use:

https://github.com/Rudd-O/qvm-open-in-another-vm

After building the package and installing it in the template, you can
shut off the template, restart the qube where you want to configure link
clicks to launch in another qube, and follow these instructions:

https://github.com/Rudd-O/qvm-open-in-another-vm?tab=readme-ov-file#how-set-urls-to-open-in-a-separate-vm

With that, any link you click on a non-browser app will prompt you to
open the link in any qube of you choice.

On 23/02/2024 20.57, 'Skyler Ferris' via qubes-users wrote:

[quote="Ulrich_Windl1, post:8, topic:24602"]
I kind of disagree: When passing the URL as "$1", it is passed as one
single parameter. The user cannot be expected to know to how much more
levels of shell script the parameter will be passed to, so any deeper
layers have to keep the single parameter. That is: Every layer of shell
script may not remove one level of quotes. Anything else is just an
unreliable mess IMHO.
[/quote]

I want to make sure we're on the same page about exactly why the quotes
are removed, because it sounds like you're attributing this to
`qvm-run-vm`, when in fact it is the bash invocation in the script itself.

When bash (as in, the instance of bash spawned by the `#!/bin/bash` at
the top of the `run-vm-firefox` script) reads the line `qvm-run-vm
'$dispvm' /bin/firefox "$1"`, it interprets the quotes to mean "this is
one single argument and the quotations are not a part of that argument".
So the script does not send the quotation marks to `qvm-run-vm`. It
could quote all arguments automatically and there are good
justifications for doing so but it would not be a strict improvement.
For example, even with double quotes globbing is disabled and some
callers might want to use this feature.

[quote="Demi, post:7, topic:24602"]
I suggest escaping single quotes in the $1 and adding a "--" before it.
This prevents command injection attacks via a malicious URL.

So the result might be

```bash
#!/bin/bash --
exec qvm-run-vm @dispvm /bin/firefox -- "'${1//\'/\'\\\'\'}'"
```
[/quote]

I believe this is a script improvement. The URL is not trusted data and
these safeguards do not have an impact on valid inputs.

--
Rudd-O
https://rudd-o.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/dd2497e1-b86c-4d88-b782-90dacdb1fcaf%40rudd-o.com.

OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] xentop's disk I/O

2023-02-27 Thread Manuel Amador (Rudd-O)

I maintain a Xen Prometheus exporter.  Here is what I know:

You will not see device writes or reads in the dm stubs because no process in 
them is reading or writing from disks.

The Prometheus exporter is awesome, BTW.  You can get system statistics and 
ingest them into Prometheus for system profiling and tuning.  I don't know how 
I lived using xentop before I began maintaining the exporter.  Watching Grafana 
is a far more satisfying way to explore data.

On November 6, 2022 1:28:50 AM GMT+01:00, Ulrich Windl 
 wrote:
>Hi!
>
>Watching xentop, I have a question:
>I know that the network operations aren't accounted in xentop when running 
>Qubes OS, but I'm wondering:
>For domain-0 all of the disk I/O (VBD_RD, VBD_WR, VBD_RSECT, VBD_WSECT) also 
>seem to be zero, and for sys-net-dm all the writes seem to be zero.
>Is it because sys-net is a "HVM"?
>
>Regards,
>Ulrich Windl
>
>-- 
>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/2ac2c5f7-cff2-968d-9456-59dcbb45515f%40rz.uni-regensburg.de.

-- 
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/15180866-4F02-452F-AF21-A07E7526922F%40rudd-o.com.

[qubes-users] ANN: qubes-shared-folders 0.1.0, now with folder share manager

2021-12-15 Thread Manuel Amador (Rudd-O)


Hello, folks.

A new version of Qubes shared folders has been released.

https://github.com/Rudd-O/qubes-shared-folders

The main highlight of this version is a revamped security model that 
allows the user to securely delegate folder access permissions to 
specific pairs of qubes, either as a one-time basis, or permanently.  
The UI aims to be clear and easy to use. The included folder share 
manager allows the user to revoke or revise permanent share decisions 
any time after the fact.


Secondary highlights include a complete implementation of type checking, 
to prevent security issues and other common bugs that Python programs 
often carry.


Enjoy, and don't forget to open bugs if you find any.

--
Rudd-O
https://rudd-o.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/fd5dd640-e416-0824-1aff-0691e3e5b3f9%40rudd-o.com.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] Re: ANN: qubes-shared-folders

2021-12-12 Thread Manuel Amador (Rudd-O)


On 11/12/2021 22.50, Manuel Amador (Rudd-O) wrote:


https://github.com/Rudd-O/qubes-shared-folders/ is ready for testing.  
The description is below.




Release 0.0.3 fixes the client and server processes lingering after unmount.

--
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/940bc7a3-093b-60d6-71b3-cc4e1937c20b%40rudd-o.com.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] ANN: qubes-shared-folders

2021-12-11 Thread Manuel Amador (Rudd-O)

https://github.com/Rudd-O/qubes-shared-folders/ is ready for testing.  
The description is below.



Things I would love to get addressed (of course, other suggestions and 
improvements welcome):


 * Permission system to allow certain folders to certain VMs (the
   argument in qrexec is sanitized, rendering it useless for that)
 * Persistent notification on tray that indicates a specific folder is
   exported to a certain VM
 * Performance improvements (large mounts from network shares can be
   very slow)
 * Security hardening (make check was disabled in the specfile because
   there are some issues I don't know how to fix, sadly)
 * UI for mount clients to configure certain mounts to be mounted upon
   start / list existing configured mountpoints and statuses and open
   file managers to these mountpoints


README and usage instructions follow.

--

# Inter-VM shared folders for Qubes OS

This package aims to solve the problem of inter-VM file sharing
(rather than manual copying) by allowing a VM to mount folders
from any other VM's file system (or mounted network shares).

This package contains:

* a Qubes OS `qrexec` service to serve folders from a qube
* a program to mount folders in a qube served from other qubes
* policy (for dom0) to permit or deny the process


## Usage

The following instructions assume that the qube which contains the
files you want to share is named `server` and the qube where you
want to access the files is named `client`.  They also assume you
successfully finished the one-time installation instructions below.

To mount `/home/user` from the `server` VM onto `/home/user/mnt`,
run the following on a terminal of `client`:

```
cd /home/user
mkdir mnt
qvm-mount-folder server /home/user mnt
```

At this point you will see an authorization message from dom0 asking
you if you really want to give `client` access to `server`'s files.
Note that the access is blanket read/write, and once given.

Authorize the access by confirming the name of the qube (`server` on
the dialog and continuing.

**Presto.**  You should be able to use a file manager, a terminal, or
any of your favorite applications to use files in `/home/user/mnt`
-- these files are all stored in `server` on folder `/home/user`.

To finish using it, run `sudo umount /home/user/mnt`.  Note that
currently, the connection remains open between `client` and `server`
even after unmounting, so the only way to sever the connection is
to power off one of the two qubes.


## Security considerations

* There is currently no way to control *which* folders of the server
  qube can be requested by client qubes.  In principle this should
  be doable because `diod` can export only a subtree of any file
  system hierarchy, but the next point needs to be addressed first.
* The connection remains open after unmounting.  This means that the
  client VM can in principle continue to access resources from the
  file system exported by `diod` before the unmount happened.

## Installation

First, build a [`diod`](https://github.com/Rudd-O/diod) RPM package:

```
git clone https://github.com/Rudd-O/diod
cd diod
./autogen.sh && ./configure --prefix=/usr && make dist && rpmbuild -ts 
*tar.gz

```

Then, install this package on the template of the qube you plan to
*share your files from*.

Now build RPM packages for this software:

```
git clone https://github.com/Rudd-O/qubes-shared-folders
cd qubes-shared-folders
make rpm
```

Two RPMs will result:

1. `qubes-shared-folders-...noarch.rpm`
2. `qubes-shared-folders-dom0-...noarch.rpm`

Install the first one in the template of the qube you plan to
*share your files from*, as well as the template of the qube
you plan to *access your files in*.

Install the second one in dom0.  This package contains policy
(default `ask`) for the service.

Now shut down all involved qubes, to ensure the installation takes.
You don't need to shut down your computer or dom0.

--
Rudd-O
https://rudd-o.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/b70e5bdb-d94e-1ce4-008b-6a2ec734a7e7%40rudd-o.com.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] ANN: ansible-qubes (bombshell-client and qubes-network-server now compatible with Qubes 4.1

2021-10-28 Thread Manuel Amador (Rudd-O)


Hello, kind folks!

I am done making changes and testing the new releases of ansible-qubes 
(which includes bombshell-client to run shell commands across VMs) and 
Qubes network server.  The master branches of both projects are now 
compatible with Qubes 4.1 and work correctly as expected.


 * https://github.com/Rudd-O/ansible-qubes
   Lets you automate actions between VMs using the qubes.VMShell service.
 * https://github.com/Rudd-O/qubes-network-server
   Lets you expose AppVMs and StandaloneVMs to other equipment on your LAN.

You should be able to build packages for both projects and deploy these 
packages to your Qubes 4.1 setup.  In the future I'll explore building 
and publishing packages so that people can deploy directly from a 
repository.  If there is interest, we could continue shepherding these 
projects directly into the Qubes OS organizational umbrella.


Enjoy!

--
Rudd-O
https://rudd-o.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/657d5501-877d-1eb0-3b7b-0343cc4df757%40rudd-o.com.


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-users] Management of salt configs: Syncing from dom0 to a git-repository harboring vm?

2021-05-02 Thread Manuel Amador (Rudd-O)


On 03/04/2021 18.42, balin wrote:

Hi,
I urgently need to backup (and version control) my by now relative 
elaborate salt config.



You could try this: https://github.com/Rudd-O/git-remote-qubes 



--

Rudd-O
https://rudd-o.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/cb8870e8-4c9d-68b0-f5ba-7b9351f5ccf0%40rudd-o.com.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] Re: Introducing: Qubes Video Companion v1.0

2021-05-02 Thread Manuel Amador (Rudd-O)


On 21/04/2021 07.41, 'Elliot Killick' via qubes-users wrote:

Hello, everyone!

Starting this past early September, I've been working on and off to 
create a new tool for secure webcam integration in Qubes OS out of 
/absolute necessity/ for remote work at both my (new) job and school 
at the university I'm newly attending. The tool is called Qubes Video 
Companion and I'm proud to announce that it's evolved far past that 
basic requirement and at version 1.0.4 is now publicly available for 
testing!



This is truly amazing!  Thank you!

--
Rudd-O
https://rudd-o.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/d33dff25-56a7-b786-d7ac-3aadf4c9f55a%40rudd-o.com.


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-users] Custom LAN Network with dhcpd

2021-03-28 Thread Manuel Amador (Rudd-O)


On 28/03/2021 00.24, Ulrich Windl wrote:

On 3/16/21 4:59 PM, Manuel Amador (Rudd-O) wrote:

I have the treat for you!

https://github.com/Rudd-O/qubes-arbitrary-network-topology


Sounds nice, but maybe the README should contain shot instructions how 
to undo "attach-network-to".


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/eb6dc255-ee30-7d0b-5552-a51f98492839%40rudd-o.com.


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-users] A start job is running for Start Qubes VM sys-net. FOREVER.

2021-03-16 Thread Manuel Amador (Rudd-O)


You can mask the unit in the GRUB kernel command line with the parameter:

systemd.mask=qubes-vm@sys-net.service

And then you will be able to log in and fix the kernel issue (without 
networking, of course).


You can also choose the older kernel in the GRUB menu.

On 16/03/2021 16.49, Fabrizio Romano Genovese wrote:
As the title says. I've upgraded to the latest kernel (5.11) on qubes 
4.0 and now boot is stuck. How do I get out of this? :)


Fab
--
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/7ba1ae0f-4037-4a47-9bf4-aa9eae652a7dn%40googlegroups.com 
.



--
Rudd-O
https://rudd-o.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/bbc147a8-4fa0-2f74-9227-23f24b1a19ce%40rudd-o.com.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] ANN: Qubes arbitrary network topology

2021-03-16 Thread Manuel Amador (Rudd-O)

Hello, folks! I'm here to share this:

https://github.com/Rudd-O/qubes-arbitrary-network-topology

This software lets you turn your Qubes OS 4.0 machine into an arbitrary
network topology host. It is ideal to create networks of interconnected
VMs with arbitrary pathways between them, and minimal effort compared to
manually setting everything up using xl attach in your dom0 as root.

How to use

Suppose you have two VMs, which you want to be interconnected via
(virtualized) Ethernet. VM F (for frontend) will be attached to VM B
(for backend).

With this software, all you have to do is attach a feature
attach-network-to onto B, like so:

# Run me on dom0 as your regular Qubes login user. qvm-features B
attach-network-to F # You can add multiple VMs to attach to, by
separating them with newlines like so: # [user@dom0]$ qvm-features B
attach-network-to 'F # G # H'

And that's it. As soon as both B and F are running, network interfaces
will appear on each one; if you set the feature while the VMs were
running, the interfaces will appear instantly. The network interface in
F will generally be named eth0 (or eth1 or other name increasing in
value). The network interface in B will be named after F. IP networking
on none of the network interfaces will be configured by the system.

From this point on, all you have to do is configure the network
interfaces — e.g. using NetworkManager — on those two VMs, then adjust
the firewall rules on both VMs to permit input from one VM to the other,
or even forwarding through them. You could build a bridge, or set IP
configuration to your liking.

Here is a sample IP configuration file for NetworkManager (to follow our
example, stored in B under /rw/config/NM-system-connections/F.nmconnection):

[connection]
id=B
uuid=bb88cc30-1bcd-40bf-97f2-013626692bd1
type=ethernet
autoconnect-priority=-999
interface-name=F
permissions=

[ethernet]
mac-address-blacklist=

[ipv4]
address1=10.250.9.26/30
dns=10.250.7.2
dns-search=
method=manual
route1=10.250.0.0/20,127.0.0.1,1000
route2=10.250.8.0/24,10.250.9.25,1
route3=0.0.0.0/0,10.250.9.25,101

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=disabled

[proxy]

Judicious use of the qvm-features command will allow you to have
arbitrarily connected VMs on your system, directly testing a panoply of
network topologies.

How it works

A small Qubes extension running under qubesd in dom0 monitors VMs as
they start and stop. If a VM starts and it has the attach-network-to
feature, all VMs named in the feature will get Xen Ethernet frontends
attached, with the backends attached to the VM that just started. The
converse is also true — if a VM starts, and it is mentioned in the
attach-network-to feature of another VM, the frontend is attached to the
VM that just started, and the backend is attached to the VM with the
feature.

It's very simple, no magic involved.

How to install

Build the two necessary RPM packages and then install them to the
respective VMs:

1. The qubes-arbitrary-network-topology RPM: use the command make rpm
on a VM with the same Fedora version as your TemplateVM. Then
install the RPM in the TemplateVM, and power off the Template VM, as
well as any other VMs you plan to attach networking to.
2. The qubes-core-admin-addon-arbitrary-network-topology RPM: use the
command make rpm on a VM or a chroot with the same Fedora version as
your dom0 (that's Fedora 25 for Qubes 4.0). Then copy the RPM into
your dom0, and install the RPM.

You should now be good to go.

Licensing

This software is shared under the GNU GPL v2. You can find the text of
the GNU GPL in the COPYING file distributed with the source.

--
Rudd-O
https://rudd-o.com/

OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-users] Custom LAN Network with dhcpd

2021-03-16 Thread Manuel Amador (Rudd-O)

I have the treat for you!

https://github.com/Rudd-O/qubes-arbitrary-network-topology

I'm updating the readme in the next few minutes. More info there.

On 15/03/2021 12.40, 'Nyx' via qubes-users wrote:

Hello,

I am trying to implement an internal Qubes LAN with HVMs that receive
dhcp from a netvm using dhcpd. A classical network layout sort of
speak. Reading Xen Networking makes it look possible but Qubes auto
configuring the VM networking is being a bit troublesome for what I am
trying to setup. Note that the entire network will be on Qubes only
with no internet access.

The reason I am trying to set this up is I have some HVMs that are not
getting an ip through dhcp and I cannot access them to set ip manually
(they are vulnhub vms). I was thinking of just running an hvm with
virtualbox but the limits of emulation only wont work. I read that
qubes can be recompiled to enable nested virtualization to get that
working but if there is a way to create a custom network that would be
preferred.

Is there a way to allow a set of HVMs to get ip from a netvm running
dhcp and communicate like a classic 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/IUbiSSRQZ-eNLCIZh5y-81UZrPRnit3Onx2J81ZIoyhYIs0tFpNLfCPuarHsrZ2WYDKBPYpQlKCXm_-xZ5-rXJfC36oAzaMUB3Sa24YLkyk%3D%40protonmail.com
.

--
Rudd-O
https://rudd-o.com/

OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-users] Any Advantage to using OpenHAB on qubes?

2020-10-05 Thread Manuel Amador (Rudd-O)

On 30/09/2020 15.35, Stumpy wrote:
>
> I want OpenHAB to stay up to date but do not want it to be accessible
> via the internet so i was thinking if I have a template with OpenHAB
> installed that would install OpenHAB and hopefully plugins?
> The thing is I am hoping to have wifi cameras, or at least PoE cameras
> connected so it was less clear to me if i would be able to have an
> OpenHAB appvm that was not connected to the internet, or blocked from
> the network, but able to communicate with these various wireless devices?
>
Qubes can support restrictions on outbound traffic of your OpenHAB
instance by using the firewall rules built into the qube settings screen.

If you want to support inbound traffic you can use
https://github.com/rudd-o/qubes-network-server but you will then have to
manage your firewall rules on your own directly in the OpenHAB 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/e83e72eb-9bdb-06ef-0c4e-2e739de87319%40rudd-o.com.

Re: [qubes-users] Firewall issue

2020-10-05 Thread Manuel Amador (Rudd-O)

On 22/09/2020 07.05, '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. 

To support inbound connections you will need
https://github.com/rudd-o/qubes-network-server and after installing it
as per the instructions you will have to adjust nftables / iptables
rules in the target VM.

-- 
Rudd-O
http://rudd-o.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/a67d8ab0-b363-2f9d-5a71-6751594e6fe5%40rudd-o.com.

Re: [qubes-users] Qubes 4.1 audio latency after latest update today

2020-07-08 Thread Manuel Amador (Rudd-O)

On 14/06/2020 17.56, 'TQ1' via qubes-users wrote:
> I've been running Qubes 4.1 since the upgrade to fedora 32 in dom0.
> Everything has been fine up until updating dom0 with current-testing
> earlier today (14/6/2020).
> This has introduced audio latency while watching any video in any vm
> whether straming or from a file.
> I was using kernel-5.6.16-1 (kernel-latest) in dom0 before the problem
> started & now I have tried booting with kernel-5.4.44-1 & the same
> problem occurs. I have also tried running various appvms with those 2
> corresponding qubes-vm-kernels & the lag persists.

Might have to enable low audio latency in /etc/qubes/guid.conf on dom0,
then restart the box.


-- 
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/6a713840-3cf1-3a6b-7c45-517a588d09d9%40rudd-o.com.

Re: [qubes-users] Getting to the bottom of screenshots in Qubes OS

2020-07-07 Thread Manuel Amador (Rudd-O)

On 20/06/2020 10.29, Logan wrote:
> Hi Everyone,
>
> Speaking with a colleague earlier today, I heard "Qubes is great, but
> the no screenshots problem makes it a 'hard' no for me".
>
> As a Qubes user and advocate, this stung.

Yeah, it's hard.

Honestly, in my humble opinion, the secure copy and paste keyboard
shortcuts should work with image data as well, not just text data.  That
way the screenshot problem is solved -- I can screenshot in one VM, copy
directly from that app (usually Firefox), and paste in another VM at will.

-- 
Rudd-O
http://rudd-o.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/5982d535-1466-c687-1891-109f20c146a1%40rudd-o.com.

Re: [qubes-users] Speed up a VM

2020-07-07 Thread Manuel Amador (Rudd-O)

On 19/06/2020 01.42, Franz wrote:
> Hello,
> I need to do some video editing and my multimedia VM is too slow,
> video-audio is broken.
>
> Is there some easy way to speed this up?
> Perhaps does it make sense to assign 4 CPUs rather than default 2? 
> Or closing other VMs?
> Or may it be related to little memory (4GB)
> Any experience?
> Best
> Franz
> -- 
> 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/CAPzH-qCmshHBtPtbE8SGbzzAE32Qm6b-BV-j%3D6oNFuO_vCSQ%2BA%40mail.gmail.com
> .

You probably will have to enable low-latency audio in dom0's
/etc/qubes/guid.conf for the VM where you're doing audio editing.  If
you don't, there will be a desynchronization of audio and video (this is
deliberate).

-- 
Rudd-O
http://rudd-o.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/30ad0ea7-1548-43b1-da50-e81218108418%40rudd-o.com.

Re: [qubes-users] salt - dependencies in scripts

2020-05-28 Thread Manuel Amador (Rudd-O)

You can't use a `require` statement in the top file.  They only work in
SLS files.

On 23/05/2020 01.19, lik...@gmx.de wrote:
> Hi!
>
> As salt is the recommended way to manage the Appms and templates, I'm
> trying to do so.
>
> I successfully managed to create a top-script:
>
> base:
>  dom0:
>   - match: nodegroup
>   - create-template
>   - create-appvm-for-template
>
>  'created-template':
>    - install-pkgs
>    - modify_config
>    - require: dom0
>
> Unfortunately, the script fails on the first run, because step 2.
> requires step 1. done. "Require" seems not to work here. After the
> second run, everything is fine.
>
> Any hints highly appreciated. :)
>
> Best, P
>

-- 
Rudd-O
http://rudd-o.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/1df190a5-333d-61f1-4a5c-914f1d8932e3%40rudd-o.com.

Re: [qubes-users] How to use pass with split gpg ?

2020-05-24 Thread Manuel Amador (Rudd-O)

Have you tried https://github.com/Rudd-O/qubes-pass ?

On 23/05/2020 17.09, Christophe wrote:
> Hi all, 
>
> Does anyone know how to use pass with split gpg ? 
>
> I found this, but I could not get it working.
> https://github.com/kulinacs/pass-qubes/blob/master/qubes.bash
>
> I also tried to replace gpg by qubes-gpg-client-wrapper in /usr/bin/pass
> but without success, I get an error 
>
> gpg: decrypt_message failed: Unknown system error
>

-- 
Rudd-O
http://rudd-o.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/7b43a6c8-49ac-3ebe-8790-68192f9cba6f%40rudd-o.com.

Re: [qubes-users] Salt worm

2020-05-08 Thread Manuel Amador (Rudd-O)

On 06/05/2020 12.02, haaber wrote:
>> did any of you actually bother to look at the problem?
>> because i am 99% sure this doesnt apply to qubes. at all.
>> (also you are several days late on this...)
>>
>> this seems to be the original source and contains a fairly
>> good writeup:
>>
>> https://labs.f-secure.com/advisories/saltstack-authorization-bypass
>
> Thanks for the source. How do you infer that this "doesn't apply" (and
> maybe "did never apply") to qubes? Recall my question:  where does salt
> appear "under the hood" in qubes? This question seems relevant, since at
> least I (almost) never invoke salt by hand. Is that not a reasonable
> question? Explain.
>
No Salt master in Qubes -> no remoting exploit.

-- 
Rudd-O
http://rudd-o.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/5a58f9ab-de85-c992-6e9b-207cfc524211%40rudd-o.com.

Re: [qubes-users] Salt worm

2020-05-08 Thread Manuel Amador (Rudd-O)

On 06/05/2020 10.41, haaber wrote:
>> Qubes uses Salt, and there's something nasty going around:
>> https://saltexploit.com/
>
>    Risk = (probability of an event)  x   (consequences of the event).
>
> At which levels is salt used in qubes? I remember my last "active" use
> >1 year ago to get hopefully clean templates after the apt-"crisis".
> But maybe is is "under the hood" at each qubes-dom0-update? If it were
> to be used "by hand only" we could enforce risk = 0 by the above formula
> and keeping fingers off salt for a while.   Thanks!
>
>
Salt in Qubes OS does not use the Salt master.  It is therefore
unaffected by this issue.

I have now become accustomed to receiving notifications from Qubes OS
saying "XSA-xxx does not affect Qubes security".  There should be a
similar one for the Salt CVE.

-- 
Rudd-O
http://rudd-o.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/084a45d8-58c2-0834-35e6-03bed6110b55%40rudd-o.com.

Re: [qubes-users] Qubes with limited user authority

2020-05-05 Thread Manuel Amador (Rudd-O)

On 27/04/2020 20.50, mark.russ...@net-c.com wrote:
> I'm trying to get my head around possible use of Qubes in small/medium
> enterprise environments, where the system is maintained by an admin
> and the user freedom is limited by the company policies. I understand
> that the current Qubes design does not account for any threat coming
> for dom0's user,

By design, a user already has root in the machine where Qubes is installed.

If you want to grant users, say, locked remote access to certain AppVMs,
you will have to do so remotely by installing something like Qubes
network server, and making some of those AppVMs available through
encrypted VNC.  Then, by default, they will not be able to copy things
between qubes on the same machine.

-- 
Rudd-O
http://rudd-o.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/6e9bc173-37c6-8f91-eb6d-7f38479985d0%40rudd-o.com.

Re: [qubes-users] external CD writer

2020-05-05 Thread Manuel Amador (Rudd-O)

On 02/05/2020 01.23, Olaf Klinke wrote:
> (Apologies for pestering this list with another newbie question.)
>
> So I have this external DVD-RW drive (Asus SDRW-08U7M-U to be
> specific). On my Debian stretch laptop, plugging in the USB drive
> creates /dev/sr0 as well as several symlinks to it, e.g. /dev/cdrw,
> /dev/dvd etc.
>
> Plugging the drive into my Qubes desktop, I get notified of the
> availability of this drive and can attach /dev/sr0 to a Debian buster
> AppVM qube as /dev/xvdi. I can mount /dev/xvdi and read data from a CD
> allright. 
>
> However, in contrast to my Debian laptop, brasero does not recognize
> the drive as a writer, not even when I create the same /dev/cdrw
> symlink. In addition to that, both commands 
> dvd+rw-mediainfo /dev/xvdi
> cd-info -C /dev/xvdi
> exit with an error (details below). Thus it seems that some crucial bit
> did not get forwarded to/is not installed in the AppVM. Probably I'm
> just lacking the knowledge how different writing to a CD is from
> reading from CD, on the hardware level. Is there more to burning a CD
> than a single block special device?
>  
> Any hints welcome.
> Olaf

You must attach your drive via USB to the target VM, rather than as a
block device.  When attached as a block device, the Xen block device
driver does /not/ make your drive visible /as a DVD/RW drive/.

-- 
Rudd-O
http://rudd-o.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/2ceff03b-d4b4-2cb8-f305-fbd612fc1d22%40rudd-o.com.

Re: [qubes-users] Pulseaudio update error - fedora-31

2020-04-23 Thread Manuel Amador (Rudd-O)

On 22/04/2020 21.54, 'Max Andersen' via qubes-users wrote:
>
> Hi everyone,
>
> I remember some time ago we had issues with pulseaudio on earlier
> templates, and I believe a reinstall of pakages fixed the issue. I
> can't  seem to get myself out of trouble with this one on fedora-31.
>
> When doing update I get:
>
> user@fedora-31 ~]$ sudo dnf update
> Last metadata expiration check: 0:50:13 ago on Wed Apr 22 20:44:57 2020.
> Dependencies resolved.
>
>  Problem 1: package pulseaudio-qubes-4.0.27-1.fc31.x86_64 requires
> pulseaudio = 13.0, but none of the providers can be installed
>   - cannot install both pulseaudio-13.99.1-3.fc31.x86_64 and
> pulseaudio-13.0-1.fc31.x86_64
>   - cannot install both pulseaudio-13.0-1.fc31.x86_64 and
> pulseaudio-13.99.1-3.fc31.x86_64
>
...

This happens probably because we don't have automatic builds of
pulseaudio-qubes packages when upstream releases new packages.

-- 
Rudd-O
http://rudd-o.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/46ee7908-f053-7e17-feac-4180866bea09%40rudd-o.com.

Re: [qubes-users] Qubes 4.0-rc3

2020-04-16 Thread Manuel Amador (Rudd-O)

On 13/01/2018 03.34, Andrew David Wong wrote:
> On 2018-01-12 08:00, 'awokd' via qubes-users wrote:
> > On Fri, January 12, 2018 1:09 pm, Holger Levsen wrote:
>
> >> I'm not so sure, why not use git branches?
>
>
> One reason that comes to mind:
>
> Segregating the documentation into two different branches would mean
> that contributions that apply to both Qubes versions would only end up
> in one branch, unless someone remembers to manually submit the same
> thing to the other branch and actually makes the effort to do so. Most
> of the time, this won't happen. When it does, it means a second pull
> request that has to be reviewed. Over time, the different branches
> will diverge in non-version-specific content. Good general content
> that was submitted only to the 3.2 branch will effectively disappear
> once 3.2 is deprecated. (Even if it's still on the website, no one
> will look at it, since it'll explicitly be in the subdirectory of a
> deprecated version. And there will be a motivation to remove it from
> the website so that search results aren't populated with out-of-date
> information.)

That ought to be part of the review process, don't you think?  ("Have
you opened PRs for these other branches?")


-- 

    Rudd-O
    http://rudd-o.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/ae6779fd-2cfb-bcbb-273e-2c8536cf0fb0%40rudd-o.com.

Re: [qubes-users] Qubes 4.0-rc3

2020-04-16 Thread Manuel Amador (Rudd-O)

On 12/01/2018 14.09, Holger Levsen wrote:
> On Fri, Jan 12, 2018 at 01:04:23PM +, 'Tom Zander' via qubes-users wrote:
>> On Friday, 12 January 2018 11:18:19 GMT 'awokd' via qubes-users wrote:
>>> Would it be of value if I went through the published Docs and added these
>>> version headers? Should newer versions be added at the top (so 4.0 before
>>> 3.2 content)? 4.0 might just be "TBD".
>> I think that would be wonderful,
> I'm not so sure, why not use git branches?

This ought to be the chosen solution.  Mount the release 4.0 branch on
doc/ and the older releases on doc/, then provide links at the
top (Doc for  / <3.2>).

-- 
Rudd-O
http://rudd-o.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/4e04b5cb-6366-e1de-4c27-2218f522e02a%40rudd-o.com.

[qubes-users] ANN: Qubes network server available for Qubes OS release 4.0.x

2020-04-14 Thread Manuel Amador (Rudd-O)

Hello, folks!

After a long hiatus because of reasons, I'm happy to announce Qubes
network server -- an add-on to Qubes OS that allows you to expose
selected AppVMs to other VMs and to other machines in your LAN as well. 
The latest tagged release is compatible with Qubes 4.0.

The URL to check is: https://github.com/Rudd-O/qubes-network-server

An excerpt from the README.md file follows here.  I hope this helps you
understand what possibilities Qubes network server opens up for you.

I'm happy to report that, with a minor readjustment (attaching my
networked AppVMs to NetVMs instead of ProxyVMs), this functions as an
adequate replacement for Qubes network server from release 3.2.

--


  QUBES NETWORK SERVER

This software lets you turn your [Qubes OS
4.0](https://www.qubes-os.org/) machine into
a network server, enjoying all the benefits of Qubes OS (isolation, secure
inter-VM process communication, ease of use) with none of the drawbacks
of setting up your own Xen server.


WHY?

Qubes OS is a magnificent operating system, but there are so many use
cases that its networking model cannot crack:

  * As an automated integration testing system.  Qubes OS would be
phenomenal for this, and its automation tools would make it
extremely easy to bring up and tear down entire environments.
  * If only those environments could network with each other securely!*
Remote management of Qubes OS instances.  Vanilla Qubes OS cannot
easily be managed remotely.  A better networking model would allow
for orchestration tools such as [Ansible
Qubes](https://github.com/Rudd-O/ansible-qubes)  to manage entire
Qubes OS deployments, all of their VMs, and even minutiae within
each VM.
  * Anything that involves a secure server, serving data to people or
machines, simply cannot be done under vanilla Qubes OS.


ENHANCED NETWORKING MODEL

The traditional Qubes OS networking model contemplates a client-only use
case.  User VMs (AppVMs or StandaloneVMs) are attached to ProxyVMs,
which give the user control over outbound connections taking place from
user VMs.  ProxyVMs in turn attach to NetVMs, which provide outbound
connectivity for ProxyVMs and other user VMs alike.

No provision is made for running a server in a virtualized environment,
such that the server's ports are accessible by (a) other VMs (b)
machines beyond the perimeter of the NetVM.  To the extent that such a
thing is possible, it is only possible by painstakingly maintaining
firewall rules for multiple VMs, which need to carefully override the
existing firewall rules, and require careful thought not to open the
system to unexpected attack vectors.  The Qubes OS user interface
provides no help either.

Qubes network server changes all that.

With the Qubes network server software, it becomes possible to make
network servers in user VMs available to other machines, be them peer
VMs in the same Qubes OS system or machines connected to a physical link
shared by a NetVM.  Those network server VMs also obey the Qubes OS
outbound firewall rules controls, letting you run services with outbound
connections restricted.

This is all, of course, opt-in, so the standard Qubes OS network
security model remains in effect until you decide to enable the feature
on any particular VM.

The only drawback of this method is that it requires you to attach VMs
meant to be exposed to the network directly to a NetVM, rather than
through a ProxyVM.  VMs exposed through a ProxyVM will not be visible to
machines on the same network as the NetVM.


HOW TO USE THIS SOFTWARE

Once installed (see the full README.md at the URL posted above), usage
of the software is straightforward.

These sample instructions assume you already have an AppVM VM set up,
named /testvm/, and that your /sys-net/ VM is attached to a LAN with
subnet 192.168.16.0/24.

First, attach the VM you want to expose to the network to a NetVM that
has an active network connection:

qvm-prefs -s testvm netvm sys-net

Then, set an IP address on the VM:

qvm-prefs -s testvm ip 192.168.16.25

(The step above requires you restart the /testvm/ VM if it was running.)

Then, to enable the network server feature for your /testvm/ VM, all you
have to do in your AdminVM (/dom0/) is run the following command:

qvm-features testvm routing-method forward

Now testvm is exposed to the network with address 192.168.16.25, as well
as to other VMs attached to its /sys-net/ NetVM.

Do note that /testvm/ will have the standard Qubes OS firewall rules
stopping inbound traffic.  To solve that issue, you can [use the
standard rc.local Qubes OS mechanism to alter the firewall
rules](https://www.qubes-os.org/doc/firewall/#where-to-put-firewall-rules)
in your /testvm/ AppVM.

-- 
Rudd-O
http://rudd-o.com/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop

Re: [qubes-users] Upgrading directly from Fedora 23 to 26 ?

2019-06-26 Thread Manuel Amador (Rudd-O)

Qubes 3 runs Fedora 23 as the dom0.  For this reason I assume you are
trying to upgrade from Qubes 3 to Qubes 4.

This configuration of upgrades is not supported.  You must reinstall
Qubes using the Qubes 4 installer, then restore your VMs from a backup
of your Qubes 3 install.



On 20/06/2019 09.14, polish farmer wrote:
> im still running fedora 23... is that bad?  haha im such a noob. what sort of 
> attack vectors do i open myself up to by doing this ?
>

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a5ddde85-6cd7-b292-0d7d-f3701bc5144e%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: automatic start dropbox in VM

2019-01-30 Thread Manuel Amador (Rudd-O)

On 30/01/2019 15.53, John Goold wrote:
>
> I simply put a symbolic link to dropbox.desktop in ~/.config/autostart
>
> Works perfectly. I also have links to slack.desktop and thunderbird.desktop.
>
> The .desktop files are located in /usr/share/applications/

This is the cleaner solution and I highly recommend it.  It's the best
way to get apps autostarted with the *right* environment variables for
your desktop environments, something that `sudo` in the context of
`rc.local` will *not* give you.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/321bfc4a-b130-cee7-4c12-a6896aca467f%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] session managers for VMs?

2018-10-04 Thread Manuel Amador (Rudd-O)

On 2018-09-22 07:13, Daniel Allcock wrote:
> Sometimes I need to shut down a qube I'm working in for some reason
> (changing out sys-net for a specialized sys-net, or closing sensitive
> material before working in a public place).  It would be nice to be
> able to come back to the same window setup I left, when restarting the
> qube.
>
> dom0 has this kind of session management via xfce.  Is it possible to
> run a session manager in another qube?  How would I do this? I know
> how to start a window manager using exec, but I haven't figured out
> the X startup files in the VMs yet.  Perhaps each vm already has a
> window manager running?  But if so then I still need to enable that
> wm's session manager.
>
> Even better would be to "hibernate" a qube by suspending it to disk,
> but I know the qubes team has other priorities. I'm hoping per-vm
> session management is something I could do right now.
>
> Thank you very much,
> Daniel
>
>
X11 session management is dead (as much as it pains me to say that), and
so is multiple sessions by a single user (thank systemd session
management and dconf for that).

Best bet would be to implement actual hibernate/thaw for VMs.  That's a
tall order though.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/58c468c1-f59b-3064-f3ac-9d7f44284f73%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] questions - InterVM directory bind

2018-05-05 Thread Manuel Amador (Rudd-O)

On 2018-04-22 12:26, trueriver wrote:
> The page https://www.qubes-os.org/doc/qfilecopy/ decribes how to copy a file 
> or directory to another domain. In the case of a directory the files can 
> later be copied back, in which case they end up in a different directory than 
> the original.
>
> This has the advantage that both copies are available in the original host 
> domain.
>
Someone was working on a FUSE driver that would work through qrexec /
Qubes services.  You might want to look into the mailing list archives
for that.  It seems very practical (if a bit insecure?) to share VM A's
folder /x/y/z with VM B so that it appears as a mounted drive in VM B.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1c7620f3-69c8-5c47-4f2c-6403e8fc20dd%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] offlineimap with Split-GPG : get new email via cron doesn't work

2018-05-05 Thread Manuel Amador (Rudd-O)

On 2018-04-25 14:19, 799 wrote:
> Hello,
>
> I am using neomutt with offlineimap to get my corporate mail into an
> Email-AppVM.
> The current workflow is:
>
> 1) get email running offlineimap -o
> 2) start neomutt
>
> I'd like to have offlineimap check the mails in the background using cron.
> Thereof I have written a small script:
>
> /user/check-mail.sh
> #!/usr/bin/bash
> # Script will be run by cron
> #su user -c "/usr/bin/offlineimap -u quiet -f INBOX,INBOX.Inbox_CC"
> /usr/bin/offlineimap -u quiet -f INBOX,INBOX.Inbox_CC
> echo Cronjob run at: `date`>> /tmp/cron.log
>
> The last line is only for troubleshooting in order to see, if the
> cronjob has been run.
>
> The scripts is working when launched manually. It will open up the
> SplitGPG window to grant access to my GPG-key in my vault-VM.
> I need to enter the password once and if the next request is within a
> 300sec window access will be granted to th eGPG without further user
> interaction.
>
> I have installed cron and setup a cronjob which should run every 3 min
> in order to be below the 300sec time window when Spli-GPG is asking
> for a password. I have encrypted the password in my offlineimap-config
> and it can only be decrypted using my
>
> [user@my-mail]$ crontab -l
> # min  hr   day-of-month month day-of-week
> # 0-59 0-23 0-31 1-12  0-7
> # Check important mail folders every 3min
> */3 * * * * /home/user/bin/check-mail.sh
>
> unfortunately it seems that this script doesn't work via cron, do you
> have any idea what is wrong?
> If I look into the logfile the script is writing (/tmp/cron.log) I see
> that th ecronjob runs the script but no mails are downloaded.
> As mentioned running the script manually will work.
> Is cron running the job as "user" or as "root"?
>
> To all offlineimap / mutt users how are you auto-fetching new emails?
>
> [799]
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to qubes-users+unsubscr...@googlegroups.com
> .
> To post to this group, send email to qubes-users@googlegroups.com
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/CAJ3yz2tXWNz6Mst3PeUHtcPUj2EzAhH6vs7OUTg0tf8m_8LrAA%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
Cron runs under a very different environment from your desktop session
-- the variables needed for GPG agent are not set in that environment. 
I wrote a program run-in-gui / run-in-env-of a while ago, that, while
needing root, starts your program in the same environment as your
desktop session.    Check my Github for them.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ab00ceeb-a7af-a567-b42b-1b13799d93ce%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Remote Control Question

2018-05-05 Thread Manuel Amador (Rudd-O)

On 2018-04-29 00:50, Stuart Perkins wrote:
> Hi list.
>
> I'm considering setting up Qubes capable server at my home.  What I need, 
> however, is to be able to remotely control it. Updates...reboot/stop/start 
> system and app vm's etc.  Is this even possible with Qubes?  I currently run 
> a Ubuntu powered old laptop as a "server" and have it hosting a couple of 
> VM's with virtualbox.  I can ssh into it and even have an sshuttle setup for 
> VPN over SSH functionality for when I need to do something "gui" remotely.  
> One of my VM's is an old XP system which monitors my solar electric. One is a 
> ubuntu install hosting a Drupal website.  One is also installed which is a 
> full blow VPN server for when I need to do more than just simple things...I 
> rarely use this one.
>
Search for ansible-qubes on Github or Google.  Then search for
qubes-network-server on Github or Google.

I have your setup.  It ain't remote console, but it lets you do
everything you want (low-level) from another machine.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/cce3753c-4d50-7d91-4cd1-f6bcbe415986%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Move Firefox Bookmarks between AppVMs - Help with Script

2018-05-05 Thread Manuel Amador (Rudd-O)

On 2018-05-05 20:44, [799] wrote:
> Hello,
>
> following a recent discussion in the qubes-community github repository, Ivan 
> has written an interesting script for handling links and disposable VMs.
> This has inspired me to look how to move firefox bookmarks to other AppVMs.
> While disposable VMs are great, sometimes it is handy to have bookmarks 
> available in an AppVM.
>
> I was able to import bookmarks into other Appvms by transfering the 
> places.sqlite file which holds the bookmarks.
>
> In the target AppVM which has the bookmarks:
> qvm-copy-to-vm  
> /home/user/.mozilla/firefox/*.default/places.sqlite
>
> then in the destination VM you only need to move the file from QubesIncoming 
> to the profile path.
> While this works, I like to add some error checking and I would also like to 
> kill a running firefox in the destination AppVM.
>
> I was able to kill firefox running:
>
>kill `ps -A | grep firefox | gawk '{ print $1 }'`
>
> no I tried to run further command based on the fact if firefox is running or 
> not.
> I thereof tried to do something like this:
>
> if [`ps -A | grep firefox | gawk '{ print $1 }'` \> 0]; then
>echo "Run this when PID is > 0 and thereof Firefox is running"
> else
>echo "Run this when firefox is not running"
> fi
>
> Unfortunately this doesn't work. Can somone point me into the right direction?
> What is the right approach to run certain commands based on the fact that a 
> program is running or not?
>
> Sorry for this off-topic question but playing with Qubes gives so much 
> options for building own scripts and I am still a beginner here.
>
> [799]
>
You are probably better off writing something that will sync two
different .sqlite files by using SQL operations on both.  SQLite files
are safe to be accessed by two different programs at the same time, and
therefore you may not need to kill Firefox.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/31c51383-57c4-86f9-c0db-91b0dc8ccbf0%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Small Templates

2018-04-20 Thread Manuel Amador (Rudd-O)

On 2018-04-19 00:50, Drew White wrote:
> I don't want an insecure system that crashes every 5 seconds, so I
> want one hat has no SystemD. Until then, smaller template. 

It pisses me off whenever you post because you always post destructive /
nonconstructive nonsense such as this one post above this line (among
many).  You're using Fedora / Debian templates.  They use systemd (learn
to spell it, it isn't SystemD, that means a completely different thing
related to an economic population in Southeast Asia).  Deal with reality
or use something else.  And, quite frankly, I don't know what the fuck
is wrong with your computer -- I haven't had a system crash in months
while using Qubes OS, and I haven't had a systemd-related crash in Y E A
R S.  Literally YEARS since a systemd bug caused a kernel panic (because
that's how a systemd crash looks like, it's an init-related panic).

You, Drew, specifically you, always have complaints, but almost never
ever do you have solutions.  Most of your blame-assigning is entirely
fabricated and political.

So how about you start coding something that will replace the work
others have done, and then post it as a pull request?  Maybe if you
don't want to code, then you can plonk a good amount of cash for people
to code what you want.  But I, sure as iron, do not want you to continue
polluting and poisoning the environment with your useless complaints and
non-suggestions.  Every time I open the mailing list, you're there,
making useless comments or destructive quips.  I'm so, so turned off by
your destructive participation.

Thank you in advance for your courtesy in either stopping your posting
or contributing working code that (1) will be useful to others (2) will
be accepted either in Qubes OS or upstream (3) will be less whiny and
more constructive.

Enough!

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a9ecfd21-8725-1da9-b880-ba41844294f8%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] minimum size for a qube image

2018-04-20 Thread Manuel Amador (Rudd-O)

On 2018-04-16 20:50, Jan Hustak wrote:
> Hello,
> I'm also open to discussing the basic concept: is it worth trying to
> keep, for example, Firefox and GIMP in separate qubes, or should I
> just relax and use one fat TemplateVM with the union of all packages I
> need?
>

Fat template with everything you got there, *so long as your fat
template does not have anything installed that installs systemd system
or user units that will start on boot or login*.  If you have a template
that runs some sort of package on boot or login, you can nuke it using a
systemd unit override ( in the right directory) so it
won't start.  Fedora is really good about not starting units by default
(except for SSHD, which is in fact disabled by default in Qubes templates).

Aaand then perhaps a thin template for things that could be your
service VMs.  (I'm really rooting for the MirageOS templates).

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/4cd3cd9c-23a4-9505-4c87-0852237afc13%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: ANN: Qubes network server

2018-01-17 Thread Manuel Amador (Rudd-O)

On 10/09/2017 04:49 PM, Thierry Laurion wrote:
>
> Considering Qubes 4.x has switched to HVM, what needs to be done to support 
> this mode of operation? 
> Opened a ticket to track this issue: 
> https://github.com/Rudd-O/qubes-network-server/issues/4
>

Thank you for opening the ticket.  It may be difficult for me to adapt
to 4.0, so I kindly request anyone with the required skillset to send a
pull request adapting it to 4.0.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ae3a61fa-809e-d388-1358-25727847974a%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Fedora minimal template users, watch out for updates

2017-07-26 Thread Manuel Amador (Rudd-O)

I had to restore my Fedora minimal template (now at release 25) from
backups after I performed a DNF update that updated the following packages:



  ↺ updates  update yum packages for non-qubes dom0s (task @
/home/user/Devops/ansible/external/roles/updates/tasks/main.yml:20):
fedora-service-tpl:
- 'Installed: perl-IO-1.36-387.fc25.x86_64'
- 'Installed: gnome-keyring-3.20.1-1.fc25.x86_64'
- 'Installed: xen-qubes-vm-2001:4.6.5-28.fc25.x86_64'
- 'Installed: poppler-glib-0.45.0-5.fc25.x86_64'
- 'Installed: json-c-0.12.1-2.fc25.x86_64'
- 'Installed: storaged-2.6.2-6.fc25.x86_64'
- 'Installed: libgcrypt-1.7.8-1.fc25.x86_64'
- 'Installed: hostname-3.15-8.fc25.x86_64'
- 'Installed: audit-2.7.7-1.fc25.x86_64'
- 'Installed: libproxy-0.4.15-2.fc25.x86_64'
- 'Installed: audit-libs-2.7.7-1.fc25.x86_64'
- 'Installed: dbus-1:1.11.14-1.fc25.x86_64'
- 'Installed: openvpn-2.4.3-1.fc25.x86_64'
- 'Installed: strace-4.18-1.fc25.x86_64'
- 'Installed: dbus-libs-1:1.11.14-1.fc25.x86_64'
- 'Installed: dbus-x11-1:1.11.14-1.fc25.x86_64'
- 'Installed: pcre-8.41-1.fc25.x86_64'
- 'Installed: libsndfile-1.0.28-3.fc25.x86_64'
- 'Installed: gsm-1.0.17-1.fc25.x86_64'
- 'Installed: python3-dnf-plugins-qubes-hooks-3.2.18-1.fc25.x86_64'
- 'Installed: libsolv-0.6.28-2.fc25.x86_64'
- 'Installed: dhcp-client-12:4.3.5-3.fc25.x86_64'
- 'Installed: acl-2.2.52-13.fc25.x86_64'
- 'Installed: libsoup-2.56.0-3.fc25.x86_64'
- 'Installed: poppler-0.45.0-5.fc25.x86_64'
- 'Installed: dhcp-libs-12:4.3.5-3.fc25.x86_64'
- 'Installed: mate-notification-daemon-1.18.0-1.fc25.x86_64'
- 'Installed: glibc-2.24-9.fc25.x86_64'
- 'Installed: glibc-all-langpacks-2.24-9.fc25.x86_64'
- 'Installed: qubes-core-vm-systemd-3.2.18-1.fc25.x86_64'
- 'Installed: glibc-common-2.24-9.fc25.x86_64'
- 'Installed: rsync-3.1.2-4.fc25.x86_64'
- 'Installed: libcrypt-nss-2.24-9.fc25.x86_64'
- 'Installed: libcurl-7.51.0-8.fc25.x86_64'
- 'Installed: qubes-db-3.2.4-1.fc25.x86_64'
- 'Installed: gnutls-3.5.14-1.fc25.x86_64'
- 'Installed: qubes-db-libs-3.2.4-1.fc25.x86_64'
- 'Installed: qubes-db-vm-3.2.4-1.fc25.x86_64'
- 'Installed: gstreamer1-1.10.5-1.fc25.x86_64'
- 'Installed: perl-Scalar-List-Utils-3:1.48-1.fc25.x86_64'
- 'Installed: libstoraged-2.6.2-6.fc25.x86_64'
- 'Installed: gstreamer1-plugins-base-1.10.5-1.fc25.x86_64'
- 'Installed: gdk-pixbuf2-2.36.7-1.fc25.x86_64'
- 'Installed: libdb-utils-5.3.28-24.fc25.x86_64'
- 'Installed: gdk-pixbuf2-modules-2.36.7-1.fc25.x86_64'
- 'Installed: openldap-2.4.44-11.fc25.x86_64'
- 'Installed: librsvg2-2.40.18-1.fc25.x86_64'
- 'Installed: python3-bind-32:9.10.5-2.P2.fc25.noarch'
- 'Installed: bind-libs-32:9.10.5-2.P2.fc25.x86_64'
- 'Installed: libdb-5.3.28-24.fc25.x86_64'
- 'Installed: bind-license-32:9.10.5-2.P2.fc25.noarch'
- 'Installed: hwdata-0.302-1.fc25.noarch'
- 'Installed: wpa_supplicant-1:2.6-3.fc25.x86_64'
- 'Installed: pango-1.40.7-1.fc25.x86_64'
- 'Installed: gtk-update-icon-cache-3.22.17-2.fc25.x86_64'
- 'Installed: bind-utils-32:9.10.5-2.P2.fc25.x86_64'
- 'Installed: libacl-2.2.52-13.fc25.x86_64'
- 'Installed: bind99-libs-9.9.10-2.P3.fc25.x86_64'
- 'Installed: bind99-license-9.9.10-2.P3.fc25.noarch'
- 'Installed: gtk3-3.22.17-2.fc25.x86_64'
- 'Installed: dhcp-common-12:4.3.5-3.fc25.noarch'
- 'Installed: libdrm-2.4.82-1.fc25.x86_64'
- 'Installed: expat-2.2.1-1.fc25.x86_64'
- 'Installed: tracker-1.10.5-2.fc25.x86_64'
- 'Installed: perl-libs-4:5.24.2-387.fc25.x86_64'
- 'Installed: perl-macros-4:5.24.2-387.fc25.x86_64'
- 'Installed: krb5-libs-1.14.4-8.fc25.x86_64'
- 'Installed: systemd-udev-231-17.fc25.x86_64'
- 'Installed: xen-libs-2001:4.6.5-28.fc25.x86_64'
- 'Installed: pciutils-3.5.5-1.fc25.x86_64'
- 'Installed: xen-licenses-2001:4.6.5-28.fc25.x86_64'
- 'Installed: pciutils-libs-3.5.5-1.fc25.x86_64'
- 'Installed: systemd-container-231-17.fc25.x86_64'
- 'Installed: qubes-core-vm-3.2.18-1.fc25.x86_64'
- 'Installed: vim-minimal-2:8.0.728-1.fc25.x86_64'
- 'Installed: systemd-libs-231-17.fc25.x86_64'
- 'Installed: systemd-pam-231-17.fc25.x86_64'
- 'Installed: graphite2-1.3.10-1.fc25.x86_64'
- 'Installed: bind-libs-lite-32:9.10.5-2.P2.fc25.x86_64'
- 'Installed: sqlite-3.14.2-2.fc25.x86_64'
- 'Installed: perl-Errno-1.25-387.fc25.x86_64'
- 'Installed: sqlite-libs-3.14.2-2.fc25.x86_64'
- 'Installed: systemd-231-17.fc25.x86_64'
- 'Installed: curl-7.51.0-8.fc25.x86_64'
- 'Installed: perl-4:5.24.2-387.fc25.x86_64'
- 'Installed: librsvg2-tools-2.40.18-1.fc25.x86_64'
- 'Installed: tar-2:1.29-4.fc25.x86_64'
- 'Installed: d-feet-0.3.11-3.fc25.noarch'
- 'Removed: qubes-core-vm-3.2.17-1.fc25.x86_64'
- 'Removed: qubes-core-vm-systemd-3.2.17-1.fc25.x86_64'
- 'Removed:

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

2017-05-13 Thread Manuel Amador (Rudd-O)

On 05/12/2017 03:02 PM, Tom Hutchinson wrote:
> Thanks for the contribution Manuel. I'll check it out.

My pleasure :-)

Agreed about the passwords thing!

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b2aed9aa-0147-d008-ce2a-64e0d087afe2%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] OpenWhisper Systems Signal not quite right in Qubes 3.2/Fedora23/Chromium

2017-05-08 Thread Manuel Amador (Rudd-O)

On 05/08/2017 02:05 AM, Neal Rauhauser wrote:
>
> I installed Qubes 3.2 on a Dell Precision M4600 (slick) and I've been trying 
> to migrate a portion of my day to day work to it.
>
>
> I have many contacts who use Open Whisper Systems Signal App for 
> communication. I've used the Google Chrome extension on both OSX and Linux 
> without any troubles.
>
> Using a Fedora 23 VM I found Chrome installs to be clumsy, while yum install 
> chromium just works. The Signal Chrome App installs and runs, but the 
> directory function is broke. Existing conversations are fine, but they are 
> with phone numbers rather than names, and I can't look up any other contacts 
> to initiate conversations, I have to wait for them to come to me.
>
> Has anyone else already resolved this problem? This is a "beachhead issue" 
> for me - if I can get Signal going, I can switch a good sized chunk of what I 
> do to Qubes.
>
Have you tried running an Android x86 distro as a VM?

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/d528f7e4-9577-fe80-3002-cebf82b839fc%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Intel ME exploitable

2017-05-08 Thread Manuel Amador (Rudd-O)

On 05/08/2017 05:16 AM, Vít Šesták wrote:
> While I sometimes use the arguments “in such case e, attacker gains nothing, 
> because it assumes you are already compromised”, one has to be careful with 
> this, because compromise doesn't imply a total compromise.

True, yet see below.

>
> A simple example (unrelated to ME) of this catch: One might think that giving 
> user full permissions for all the files does not decrease the security if the 
> user can simply sudo anything. While this is not mostly true when considering 
> RCE vulnerabilities (or running a trojan), it doesn't apply to 
> path-traversal-like vulnerability – attacker is not automatically in the 
> position where she can simply call sudo.

True, yet nowhere near the gravity of access to ME.  ME is running an OS
that has effectively the security properties of MS-DOS.  Get some code
running in there, you're root.  Except you're root on the entire
machine.  Even if you don't get code running there, commandeering it is
enough to do remote screen and remote reprovision.

>
> I don't know ME well, but maybe this catch also applies to ME. Note that 
> whole ME includes not only some persistently running chip and its firmware, 
> it also includes some (optional) software for the OS, which is BTW actually 
> recommended to be removed by the Intel's security advisory. I don't know what 
> is it exactly capable of, it can probably give the admin access to OS shell, 
> and maybe something more. (And BTW, you can see it in dom0 by lsmod.) This 
> just illustrates that ME is actually a complex beast and it's hard to 
> properly reason about it.
>
The removal of the software just makes it harder for attackers (now they
have to have system privileges to talk to the I/O ports or PCI, so
exploit chaining would be needed).  It is sound security advice to
reduce the attack surface in this way, as it isn't a given that
exploiting Microsoft Internet Exploder (or whatever they're calling it
these days) will yield system access.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/59740614-3744-1ef3-bc1f-ee89f5d45c16%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Youtube/Video Problem

2017-05-07 Thread Manuel Amador (Rudd-O)

On 05/07/2017 07:07 PM, cooloutac wrote:
> there is also vlc plugin for firefox browser. vlc uses its own codecs
> don't think it installs anything for systemwide. You have to install
> gstreamer packages for that. Although you shouldn't need to to for
> youtube, but i had to install gstreamer1-libav to play mp4 streams,
> maybe installing some codecs would help you also even though you
> shouldn't have to.
> This happens in all vms? 

This has to be an unrelated-to-codecs problem, because YouTube knows to
serve HTML video + WebM to YouTube.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a29f2d35-88f3-24b3-2f9b-f00f8f4acbe1%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Intel ME exploitable

2017-05-07 Thread Manuel Amador (Rudd-O)

On 05/02/2017 05:25 AM, Vít Šesták wrote:
> * There seems to be some MEI PCI device (see lspci | grep -i mei) in dom0 and 
> /dev/mei0. I am not sure how all the parts (network stack, MEI PCI device, 
> MEI software for OS and management while offline) are connected together. I 
> am also unsure if having it in dom0 is good (i.e., it prevents passing 
> malicious inputs to it) or bad (i.e., it adds attack surface). The safest 
> approach seems to be attaching it to /dev/null with IOMMU (VT-d) isolation. 
> Just crerating an autostarted (and maybe also autoshutdown) 
> network-disconnected dummy VM with all ME-related PCI devices should do the 
> trick. The VM would be trusted not to pass any malicious input to MEI, but it 
> would not be trusted for anything else (so that it could absorb attack from 
> MEI). I am unsure if this adds some actual protection or if it is totally 
> hopeless.

I remember a few days ago reading that you can talk to ME via SMBus, and
that is in fact the way ME talks to other components when the system is
off and therefore can't talk over PCI.  PCI is obviously another way to
talk to ME.

Keeping them in dom0 won't hurt anything.  The fact that ME cannot be
exploited locally from a VM (assuming the Qubes OS security model holds)
is enough to protect you from local exploits.  In case of successful
exploitation. the ME has full access to RAM in any case, so moving them
to another VM won't give you any extra security.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/21446e90-3336-4d91-2249-9c60123a2b04%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Intel ME exploitable

2017-05-07 Thread Manuel Amador (Rudd-O)

On 05/02/2017 05:25 AM, Vít Šesták wrote:
> Some notes:
>
>
> * I wonder what is the technical distinction between home and SMB/Enterprise. 
> Is it vPro?

I deduced this in the affirmative a few years ago by comparing the SKUs
for various Intel products, and whether they had vPro.


-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/163291d6-af6e-50b4-6781-95c6c1e331b2%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Intel ME exploitable

2017-05-07 Thread Manuel Amador (Rudd-O)

On 05/01/2017 05:26 PM, Vít Šesták wrote:
> AFAIU, if https://ark.intel.com/ shows “Intel® vPro™ Technology: no”, then 
> the particular CPU is safe. But I am not 100% confident in vPro and related 
> technologies, so I might be wrong. Can someone confirm/deny this claim?

That has been my experience as well.

The typical test is to see if DHCP requests come out of your machine's
network port after it has been "powered off" (it is well known that the
CPU running the ME is separate and doesn't power off).

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2d52e0e2-2c62-c029-d56f-b30ba0bb9612%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Intel ME exploitable

2017-05-07 Thread Manuel Amador (Rudd-O)

On 05/01/2017 05:14 PM, Reg Tiangha wrote:
> On 05/01/2017 10:38 AM, Jean-Philippe Ouellet wrote:
>> *Sigh*... Yep. We were right to be concerned (of course). And now we
>> have something other than our tin foil hats to point at too:
>>
>> https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/
>>
>> I want my RISC-V laptop already!
>>
> I don't know if it helps things, but I recently disabled the
> CONFIG_INTEL_MEI, CONFIG_INTEL_MEI_ME, and CONFIG_INTEL_MEI_TXE kernel
> options in my kernel branches as soon as I was made aware of their
> existence. My hope is that the ME hardware can't be exploited using
> those methods if they don't exist in the kernel in the first place; that
> someone would have to find another way. But again, I have no idea if
> that's useful or not. For what it's worth, my systems still boot and run
> properly, but the newest machine I have access to is of the Sandy Bridge
> era; I have no idea if newer machines actually need those options baked
> into the kernel in order to run. Can anyone advise?

Local exploit can talk to the ME via PCI and SMBus.  Only from dom0.

Remote exploit only good against machines with vPro (check your CPU SKU
at the Intel database — I explicitly bought systems without that shit)
because vPro is the prerequisite technology for AMT.  If your machine
does not have AMT / vPro, it cannot be exploited remotely because it is
not listening over network cards.

A quick test: connect your machine physically to a router, start
tcpdumping on the router, then power it off.  Do you see DHCP requests
being emitted on the port of the router where your machine is
connected?  If so, then you're screwed.

>
> https://github.com/rtiangha/qubes-linux-kernel
>
> Also, if anyone has any other ideas on kernel options to disable for
> various security concerns (ME related or not), let me know. For the
> moment, I've implemented almost all of the KSPP's recommended settings
> that are applicable to a certain kernel branch, except for the ones
> about loadable modules since I don't know how it affect u2mfn or any
> other user-compiled kernel modules a Qubes user may want to install. I
> haven't encountered any issues on my machines (or at least, any that
> I've noticed), but those could use more testing as well:
>
> https://github.com/rtiangha/qubes-linux-kernel
>
KSPP is good, but it will not protect you from the attack, because the
attack runs *on a different CPU within your machine, which is always on,
even when the machine is off*.

Yes, it's THAT bad.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0361826c-468c-74a5-bd75-0701cd022ab1%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] ANN: qubes-pass for Ansible — an Ansible lookup plugin for Qubes pass integration

2017-05-07 Thread Manuel Amador (Rudd-O)

Building on https://github.com/Rudd-O/qubes-pass, the new Ansible Qubes
Pass lookup plugin allows you to create Ansible playbooks and roles that
integrate seamlessly with your Qubes OS pass store.

Check it out at
https://github.com/Rudd-O/ansible-qubes/tree/master/lookup_plugins

Enjoy!

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8a000fc5-01fa-3762-381e-7cb16334ff79%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

2017-05-07 Thread Manuel Amador (Rudd-O)

On 05/07/2017 05:23 PM, Andrew David Wong wrote:
>
> I prefer the security of qvm-backup[-restore], since it allows me to
> keep the vault and its contents permanently offline. The entire VM is
> BZIP compressed, AES-256 encrypted, and HMAC-SHA512 authenticated. The
> integrity verification, authentication, and decryption all happen at
> the dom0 level. The backup is tiny, so the storage overhead is
> inconsequential, and there's no need to worry about file-level
> metadata leakage or the backup file itself being used as an attack
> vector. KeePassX has sufficient built-in versioning for me, and it's
> easy enough to sync Qubes backups across machines with simple scripts.

Git push takes 5 seconds.

qvm-backup requires anywhere between minutes and many hours. 
Additionally, it requires the target VM be off.

Weekly backups are served okay by qvm-backup (I say "okay" because I
have a borg backup setup on my Qubes OS system, and it's far more usable
and performant than qvm-backup).  Git push is much better suited to,
say, syncing your keyring to other systems.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6da3112a-4873-bc02-4cac-34bf329c4a63%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

2017-05-07 Thread Manuel Amador (Rudd-O)

On 05/07/2017 03:23 PM, Andrew David Wong wrote:
> On 2017-05-07 10:10, nickl...@kulinacs.com wrote:
> > What benefit does this have over simply ysing
> > qubes-split-gpg-client-wrapper, like done here:
> > https://github.com/kulinacs/pass-qubes It seems like a lot of
> > overhead for not a lot of gain.
>
> > On May 7, 2017 9:50:26 AM CDT, "Manuel Amador (Rudd-O)"
> > <rud...@rudd-o.com> wrote:
> >> Building on the excellent pass (https://passwordstore.org), it
> >> gives me great pleasure to announce the initial release of
> >> qubes-pass — an inter-VM password manager and store for Qubes
> >> OS.
> >>
> >> Check it out here!
> >>
> >> https://github.com/Rudd-O/qubes-pass
> >>
>
> What are the advantages of either of these over the traditional Qubes
> model of having a normal password manager in a vault VM and using the
> inter-VM clipboard to copy/paste passwords out of it?
>

These programs do not require user interaction as long as the policies
are properly configured.  Thus, they are extremely useful for batch
processes or system orchestration purposes.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e8f22638-8944-b0c4-57f6-e962350fdb8b%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

2017-05-07 Thread Manuel Amador (Rudd-O)

On 05/07/2017 03:10 PM, nickl...@kulinacs.com wrote:
> What benefit does this have over simply ysing
> qubes-split-gpg-client-wrapper, like done here:
> https://github.com/kulinacs/pass-qubes
> It seems like a lot of overhead for not a lot of gain.

 1. The actual store is stored in a separate VM.  It is never decrypted
in the VM you manage the passwords from.
 2. You do not need to set up your own GPG key, as `qvm-pass init` does
it for you.
 3. There are two different services — one for read-only access and one
for read-write.
 4. There is a get-or-generate feature which is useful for stuff like
https://github.com/Rudd-O/ansible-qubes/tree/master/lookup_plugins


>
> On May 7, 2017 9:50:26 AM CDT, "Manuel Amador (Rudd-O)"
> <rud...@rudd-o.com> wrote:
>
> Building on the excellent pass (https://passwordstore.org), it gives me
> great pleasure to announce the initial release of qubes-pass — an
> inter-VM password manager and store for Qubes OS.
>
> Check it out here!
>
> https://github.com/Rudd-O/qubes-pass
>
>
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity. --
> 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
> <mailto:qubes-users+unsubscr...@googlegroups.com>.
> To post to this group, send email to qubes-users@googlegroups.com
> <mailto:qubes-users@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/0A765A21-F411-4015-B9C2-790508B1A0C1%40kulinacs.com
> <https://groups.google.com/d/msgid/qubes-users/0A765A21-F411-4015-B9C2-790508B1A0C1%40kulinacs.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout.


-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c8fc3adc-5fce-46de-05e5-d0aa2946ed6b%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Changed resolution, now screen doesn't work?

2017-05-07 Thread Manuel Amador (Rudd-O)

On 05/01/2017 05:42 PM, almir.aljic1...@gmail.com wrote:
> On Monday, May 1, 2017 at 6:51:51 PM UTC+2, almir.a...@gmail.com wrote:
>> I changed the resolution of my Qubes from 1920x1080 to 1600x1200 (by 
>> accident) and now my screen doesn't show anything when I choose HDMI2 (my 
>> desktop PC is attached to the screen with an HDMI cable). Setting the 
>> resolution to 1280x1024 worked fine, but as soon as I set it to 1600x1200 
>> and clicked "apply" my screen turned black and now all it does is say "no 
>> signal" and I can't see anything on the screen to set it back to 1920x1080. 
>> How do I go about solving this?
>>
>> Thanks.
> I know of a potential solution but then I need help from someone on here.
>
> What you can do is shut down all your windows and left-click the Qubes icon 
> (at the bottom left/top left) then solely use your keyboard to navigate to 
> the Display settings and change resolution. Then send me the exact keyboard 
> strokes you pushed (for example down arrow 2x, right arrow 1x, down arrow 8x, 
> tab 4x etc.) so that I can mimic them and ultimately change my resolution 
> back to 1920x1080.
>
> Thanks in advance!
>
Isn't it easier to launch a terminal using the xfce minicli key combo,
then using xrandr to set the right resolution?

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/75e1a8ce-4b51-9107-ec3e-c5f503a85c3d%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

2017-05-07 Thread Manuel Amador (Rudd-O)

Building on the excellent pass (https://passwordstore.org), it gives me
great pleasure to announce the initial release of qubes-pass — an
inter-VM password manager and store for Qubes OS.

Check it out here!

https://github.com/Rudd-O/qubes-pass

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/24c27d7a-e72e-14fc-e388-2f5718d95660%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Cannot execute commands in terminal - not root?

2017-04-27 Thread Manuel Amador (Rudd-O)

On 04/27/2017 01:52 PM, jimmycarter wrote:
> I am following this guide to create a ProxyVM: 
> https://www.mullvad.net/guides/qubes-os-and-mullvad-vpn/
>
> However, when I try to execute the commands in step 2 I am not able to 
> execute the sudo bash command with the error message "permission denied". The 
> sudo apt-get update && install command doesn't work either, with the error 
> message "Are you root?"-kind of thing.
>
> I selected the "do not create root user" or something in the installation, is 
> this what's wrong? How do I get this to work? I also tried going into 
> /etc/default/openvpn according to step 5 and tried editing the openvpn file 
> but it gave me read-only access and not write access.
>
> When I use the sudo command it never prompts me to type in my root user 
> password in the terminal. By the way, I am typing those commands into a 
> terminal on the ProxyVM.
>
> Help is highly appreciated.
>

They should update their guide to use
https://github.com/Rudd-O/qubes-vpn — it works almost out of the box
with Mullvad, and I would be happy to accept contributions or
suggestions of UI and interaction to specifically configure their VPN
with qubes-vpn.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b7b61224-a945-7cd6-bebd-bd3f177c8fd8%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Boot Problem

2017-04-19 Thread Manuel Amador (Rudd-O)

On 04/19/2017 08:35 PM, craig.g.jes...@gmail.com wrote:
> I am having at boot problem with my Qubes OS 3.2.  When I boot up I enter the 
> disk password and the boot process continues until it gets to the line...
>
> A start job is running for Qubes NetVM startup (32s / no limit)
>

You must boot in rescue mode (add boot kernel command line option
systemd.unit=rescue.target) and then disable qubes-netvm.service, then
reboot.

Alternatively boot with kernel command line option
systemd.mask=qubes-netvm.service .

Both of these options will mask the NetVM startup, which will then let
you diagnose the problem more accurately.

These options can be added in the GRUB2 command line editor (hit e) when
the GRUB menu appears after the BIOS screen.  If no menu appears, press
ESC multiple times right after the BIOS screen.  You'll see the menu then.

If your machine boots from UEFI, I do not know how to do this procedure,
sorry.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/42034820-17fb-afe8-ecd8-7a2590949872%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] qubes manager add start terminal

2017-04-19 Thread Manuel Amador (Rudd-O)

On 04/16/2017 11:29 PM, Eva Star wrote:
> I'm get tired that Qubes Manager till now do NOT have "Start Terminal"
> at right click menu of each vm, but only "Run command in VM".
>
> I want to patch it to add "Run terminal". I found that need to
> duplicate "Run command" entry, name it "Run Terminal" and predefined
> "gnome-terminal" on the input field.
>
> I need to modify action. On the repository I see actions at
> mainwindow.ui file. But I can not find it on the disk to add new action!
>
> 
>
> 
>  :/run-command.png:/run-command.png
> 
>
> Where is mainwindow.ui with actions???
>
> If I will found it I will add new function to process this action by
> duplicating action_run_command_in_vm_triggered(self) and predefined
> "gnome-terminal" into it.
>
>

Predefine "gnome-terminal || konsole || xterm" for more compatibility.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/4624e592-9cb2-fbf7-c4fe-06a7fb486fe1%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Feedback request: Incremental file-based backup PoC

2017-02-27 Thread Manuel Amador (Rudd-O)

On 02/27/2017 01:53 PM, Manuel Amador (Rudd-O) wrote:
>
> I am terrified that Qubes 4.0 will force me to use LVM, because LVM is
> frankly a disaster for data recovery and for data integrity as well.  I
> would be willing to write an adapter to use ZFS zvols instead.  That
> would be the right thing to do.
>
Honestly, ZFS on Linux should be integrated into the Qubes OS installer,
and the system should ship and be installed with it.  But if that's too
much work, then btrfs should be the default.

Inferior volume management systems with no data integrity protection
should not be used these days.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e2c0d505-334a-cda2-a6a3-7ce628c45063%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Feedback request: Incremental file-based backup PoC

2017-02-27 Thread Manuel Amador (Rudd-O)

On 02/26/2017 10:07 PM, Vít Šesták wrote:
> Q: Can I backup VM that is running?
> A: If you have LVM-based private.img, you can. (See README for details.) If 
> you have standard file-based private.img, you cannot. I don't plan to 
> implement this feature for file-based private.img, because Qubes 4.0 will use 
> LVM, so they don't seem to have a long future.

I am terrified that Qubes 4.0 will force me to use LVM, because LVM is
frankly a disaster for data recovery and for data integrity as well.  I
would be willing to write an adapter to use ZFS zvols instead.  That
would be the right thing to do.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ad1961d4-8e9c-308b-221c-2842f664e13d%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Feedback request: Incremental file-based backup PoC

2017-02-27 Thread Manuel Amador (Rudd-O)

On 02/27/2017 12:51 PM, Chris Laprise wrote:
>
> In some backup systems, each backup appears complete to the system,
> even though it was created with incremental deltas. A benefit of this
> is you can delete any backup in the set to reclaim space, without
> affecting any of the remaining backups---a single backup set can be
> updated in rotation forever. Its akin to block-level deduplication.
> Another benefit is that all backups except for the first will transmit
> only deltas; data that never changes never gets re-transmitted.
>
> Chris
>

Duplicati does this.  It's really well-designed and does exactly what
you want.  It also does encryption as well.

If this PoC is sound (it appears to be) then Duplicati can be repurposed
to substitute for Duplicity altogether.

File-based backup really does sound like the right thing to do, for so
many reasons.  It's really dumb to back up big, big files, even if they
could be done incrementally (as I do with my own Duplicity-based
solution for dom0).

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6b1b528c-e9c1-7034-fd77-c81f59b18163%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] qubes partitioning questsion

2017-02-18 Thread Manuel Amador (Rudd-O)

Separate /usr is not supported.

There is no point in sub mount points under /var/lib/qubes.  /var/lib/Qubes is 
enough as a single mountpoint.

There is no point in /var/lib/* sub mount points.  Or /var/log for that matter. 

You don't have to have /home under a mountpoint.  Dom0 /home should be empty if 
you are using Qubes right.

Use btrfs instead of LVM.  That way you can do subvolumes.

On February 18, 2017 8:21:10 AM PST, Oleg Artemiev  wrote:
>Hello,
>
>I'm about to upgrade from Qubes 3.0 to Qubes 3.2 now.
>
>I've two terabites (1 ssd and 1 hdd) in my laptop and 16Gigs of
>memory. Is separation to different mount points as proposed below
>is a good idea? Please note if you think that something could also be
>moved to ssd. My criteria for ssd stuff is "oftenly read, very rare
>write".
>
>
>As everything is encrypted , thus no need in gpt - dos partition table.
>
>ssd:
>/   - 400Мb
>/usr - 5G0b
>/boot - 300Mb
>/var/lib/qubes/vm-templates - 350Gb
>/var/lib/qubes/vm-kernels   - 3.5Gb
>/var/lib/rpm- 100Mb
>/var/lib/yum- 50Mb
>
>individual catalogues under /home// - up to 100 mount points ,
>unsure which ones are rewritten rarely an thus worth moving to ssd,
>thus will move after upgrade.
>
>hdd:
>/a_copy_of_/boot - 300Mb
>/tmp - 32Gb - looks like it has to be not less
>then biggest VM size
>swap - 32Gb
>/home - 100Мб
>/var/log - 300Mb
>/var/log/
>
>BTW: Looks like LVM thin provisioning gives at least two times slower
>writes, so I'm about to use usual LVM.
>
>
>-- 
>Bye.Olli.
>gpg --search-keys grey_olli , use key w/ fingerprint below:
>Key fingerprint = 9901 6808 768C 8B89 544C  9BE0 49F9 5A46 2B98 147E
>Blog keys (the blog is mostly in Russian):
>http://grey-olli.livejournal.com/tag/
>
>-- 
>You received this message because you are subscribed to the Google
>Groups "qubes-users" group.
>To unsubscribe from this group and stop receiving emails from it, send
>an email to qubes-users+unsubscr...@googlegroups.com.
>To post to this group, send email to qubes-users@googlegroups.com.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/qubes-users/CABunX6MReuC_Q9B2NYjHjKnvRLc%2BJeaWaywxF%3DLV8rYpiT32DQ%40mail.gmail.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/E7D8002A-6C9C-46DE-A29B-CC354E62C469%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Resize dom0

2017-02-18 Thread Manuel Amador (Rudd-O)

It is the standard procedure to enlarge any root partition on any Linux — 
enlarge encrypted volume, enlarge LVM physical volume, enlarge enlarge LVM 
logical volume, enlarge root file system.  You will have to do this from a 
rescue initramfs or another Linux system you booted from.

On February 18, 2017 2:23:29 AM PST, "Zbigniew Łukasiak"  
wrote:
>There are instructions how to resize a VM at
>https://www.qubes-os.org/doc/resize-root-disk-image/ - but this cannot
>apply to dom0 - because it requires stopping the VM and then running
>commands in dom0. What would be the procedure for resizing dom0 root
>partition?
>
>-- 
>Zbigniew Lukasiak
>http://brudnopis.blogspot.com/
>http://perlalchemy.blogspot.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 post to this group, send email to qubes-users@googlegroups.com.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/qubes-users/CAGL_UUvH1mT_LP57dS6DO5ksNDEf%3DZWA0XiruH7rzM455GHkdg%40mail.gmail.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/395BD576-E36E-442E-AEEF-152205714914%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] MP3 support but SMB issues on DebVM or SMB support with MP3 issues on FedVM?

2017-02-18 Thread Manuel Amador (Rudd-O)

Create a mount unit in your template of the Deb VM, which does the mount.  Have 
it WantedBy=multi-user.target.  Enable it.

Add a ConditionPathExists=/var/run/qubes-service/mediamount to the unit.

Power off the template and the Deb VM.

Thru Qubes Manager, add a Qubes service to the DebVM, naming it mediamount.

Power on the template.

Bam, now that thing mounts only in the Deb VM.

I have an Ansible play for this.  Will publish it soon.

On February 18, 2017 9:05:57 AM PST, "'.' via qubes-users" 
 wrote:
>I have been trying to get a "proper" music setup working on my Qubes
>(3.2) machine and am having issues. On a Fed24VM I can't seem to get
>mp3 support (tried installing gstreamer no go) and on Deb9 I can
>connect to my file server via the filemanager but can't find where it
>is mounting (where as I can just type "mount" in Fed and the last entry
>is usuall the mount point).
>
>I love VLC for videos, but despise it for music (compared to what I
>want in a music player). I was able to run foobar2k with wine before
>(which apparently took care of MP3 support issue in Fed) but that is an
>unweildy option and I think Quod Libet player will suffice (which I
>have installed on both Deb/Fed VMs no prob).
>
>I would prefer to use a debVM for my music but could use some
>suggestions on how to include a line to mount it to a point i can find.
>I have tried mount -t smb //fileserver/directory
>/media/testmountdirectory and a few variations (like CIFS) but nothing.
>I don't have a password on set on the server at the moment and when I
>mount via the file manager I just put in smb://fileserver/directory it
>prompts me to connect and I'm in.
>
>How can I set a Deb "AudioVM" to automatically mount the
>music_directory so it can be accessible to something like Quod Libet?
>
>-- 
>You received this message because you are subscribed to the Google
>Groups "qubes-users" group.
>To unsubscribe from this group and stop receiving emails from it, send
>an email to qubes-users+unsubscr...@googlegroups.com.
>To post to this group, send email to qubes-users@googlegroups.com.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/qubes-users/vS162_w02q8XeVvlJYqXCAPP0iOD1oRX3Pr8Bw_YVyTlMqv60sDcBeRbDle1W0m02n_GT2k7oyLC1cL9GBOQZMbG7qaHPgQOqv6odmYrEUw%3D%40protonmail.ch.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/55D5F7FA-B2FC-4403-99B1-535C7BD4DE9E%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] NetVM without firewall, no PING from outside?

2017-02-17 Thread Manuel Amador (Rudd-O)

Qubes-network-server takes care of this for you.

On February 14, 2017 2:02:18 AM PST, Jarle Thorsen  
wrote:
>> Unman:
>> > I suggest you read the docs:
>> > www.qubes-os.org/doc/firewall  has a section on allowing traffic in
>to
>> > qubes.
>> 
>> Thank you for the link. It provided a good foundation.
>> 
>> > But this may not be what you want. It reads as if you want to have
>> > sys-net operating as a router. You can do this quite simply by
>changing
>> > the iptables configuration and using proxy arp to make sure that
>the
>> > external network sees the qubes behind the router.
>> > Alternatively you could use the netvm as a gateway to the network
>of
>> > qubes, and make sure that THAT route is propagated on your internal
>> > network.
>> 
>> Thank you, it seems like using proxy arp is the way to go for me.
>That way I can still use a dynamic address for my NetVM.
>
>I'm getting back to this thread, still haven't got everything working:
>
>My NetVM is connected to a local network 10.0.0.0/16, and gets a
>dynamic IP via DHCP.
>
>AppVMs connect directly to the NetVM, without any firewall, and all
>firewall rules has been removed from NetVM.
>
>All networking is now working fine, both between AppVMs and from AppVMs
>and into the 10.0.0.0/16 network.
>
>Now I need to have the AppVMs available from the 10.0.0.0/16 network...
>
>Where do I need to enable arp_proxy to make this happen? Only on the
>NetVM interface connected to the 10.0.0.0/16 network, or also on the
>vif interfaces on the NetVM, or in the AppVMs also??
>
>-- 
>You received this message because you are subscribed to the Google
>Groups "qubes-users" group.
>To unsubscribe from this group and stop receiving emails from it, send
>an email to qubes-users+unsubscr...@googlegroups.com.
>To post to this group, send email to qubes-users@googlegroups.com.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/qubes-users/382450c2-11c6-40dc-9bea-03840335c104%40googlegroups.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/FD0BEFAB-47FA-45D7-9CB6-7207675511A4%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Minimal VM requirements for Salt configuration are not documented

2017-01-22 Thread Manuel Amador (Rudd-O)

On 01/20/2017 08:58 AM, qu...@posteo.de wrote:
> Hi,
>
> I am trying to setup all VMs with Salt since the switch to Fedora 24.
>
> I usually took the minimal template and create the others on base of
> this with more packages.
>
> The problem is that the Qubes salt documentation does not document
> what the minimal requirements on packages are for deploying salt and
> receiving.
>
> For example if I install in the minimal fedora 24 template
> qubes-mgmt-salt-vm-connector I still can not install any packages with
> Salt from the outside. If I use this minimal template as the default I
> can not deploy Salt anymore to templates which can be updated with
> Salt because they have all the necessary packages. 

You're going to need at the very minimum python-dnf.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a6913e0b-4211-2f4f-d2a2-42fce10e2c35%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Fedora Desktop in Qubes

2017-01-07 Thread Manuel Amador (Rudd-O)

On 12/24/2016 05:58 PM, Andrew David Wong wrote:
>
> This is not true. Dropbox doesn't even start automatically, much less
> communicate automatically. If you install Dropbox in a Fedora
> TemplateVM according to the above instructions, the Dropbox daemon
> will *not* start automatically in any AppVM based on that template.
> You have to start it manually. (After starting it manually, you can
> configure it to start whenever the VM starts up, if you wish.)
>

I believe the RPM installs a desktop file in the autostart directory so,
yes, it does start automatically.

You can mask it, though.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/24b5a466-8ad9-b91a-6f9f-44ac7c51185e%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Fedora Desktop in Qubes

2017-01-07 Thread Manuel Amador (Rudd-O)

On 12/21/2016 11:13 AM, Patrick Bouldin wrote:
> Hi, I saw some threads on this but am not clear at a high level.
>
> I thought I would install dropbox client on one of my Fedora VMs so that 
> working with files is much smoother than from a browser. So, is installing a 
> Fedora Desktop the best plan to do that? Don't assume I know enough of native 
> Qubes ability please - maybe I'm missing a key point!
>
> Thanks,
> Patrick
>

Run this Ansible recipe on the AppVM where you will be installing your
Dropbox client:


---

---
# It is assumed that the template will have wget.  I could probably use
get_url if it didn't demand a checksum...
- hosts: localhost
  tasks:
  - name: deploy Dropbox
command: creates='{{ ansible_env.PWD }}/.dropbox-dist' chdir={{
ansible_env.PWD }} wget -O -
"https://www.dropbox.com/download?plat=lnx.x86_64; | tar xzf -
  - name: deploy real Dropbox autostart file
copy:
  content: |
  [Desktop Entry]
  Name=Dropbox
  Comment=Run the Dropbox service
  Exec={{ ansible_env.PWD }}/.dropbox-dist/dropboxd
  Terminal=false
  OnlyShowIn=QUBES
  Type=Application
  NoDisplay=true
  dest: '{{ ansible_env.PWD }}/.config/autostart/dropbox.desktop'
  owner: user
  group: user
  mode: 0644

---


Restart the AppVM.  The Dropbox icon should appear on the taskbar now.


-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/74438f01-da56-0bfa-d747-7c188142dd0d%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How to rollback Dom0 updates?

2016-12-12 Thread Manuel Amador (Rudd-O)

On 12/10/2016 09:51 AM, Simon wrote:
> Hello everybody,
>
> Is there a way to rollback updates which corrupted a Qubes-OS system?
>
> I checked DNF history, but it seems to have been disabled / bypassed
> for all events following the OS installation back in September:
>
> - 8< --
>
> [user@dom0 ~]$ sudo dnf history
> ID | Command line | Date and time| Action(s) 
> | Altered
> ---
>
>  5 | --exclude=qubes-template | 2016-09-19 21:10 | Install   
> |1  <
>  4 | remove cairo-dock-plug-i | 2016-09-07 18:19 | Erase 
> |   19 >
>  3 | --exclude=qubes-template | 2016-09-07 14:34 | Install   
> |   14  <
>  2 | --exclude=qubes-template | 2016-09-07 14:24 | Install   
> |5 ><
>  1 |  | 2016-09-04 17:57 | Install   
> |  937 >E
>
> - 8< --
>
> Is there any equivalent feature allowing update rollback in Qubes-OS
> for the Dom0 domain?
>

The reliable way to do rollbacks is to:

1. Install Qubes OS on a btrfs file system.
2. Install the dnf / yum plugin that will snapshot your system right
before upgrades.

Slightly less convenient:

1. Migrate your Qubes OS to ZFS.
2. Manually ZFS snapshot your Qubes OS before dom0 / template upgrades.


-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/142947de-d3bb-7ff3-38ff-aee3edb7e4a0%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How to backup an iPhone under Qubes

2016-12-08 Thread Manuel Amador (Rudd-O)

On 10/05/2016 08:23 PM, qu...@posteo.de wrote:
> Hi,
>
> how can I back up my iPhone without a separate Os?
>
> I have installed Windows 10 in an HVM and tried to add both USB
> controller devices but then the VM does not start.
>
> Backing up via Wifi does not work because the HVM is behind a NAT.
>
> I have not tried WIndows 7 because I have not access to it.
>
> So is there any solution which does not require another os or another
> computer?
>
> Thx in advance
>

Qubes network server may be able to add the ability for Windows to join
your LAN with its own IP address, thereby making it visible to your phone.

https://github.com/Rudd-O/qubes-network-server

but, frankly, I have never tested it with Windows.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2fdcc24e-486e-c6c5-f3e7-b0a17a7aaf77%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Shortcuts of PlayonLinux

2016-12-05 Thread Manuel Amador (Rudd-O)

On 12/05/2016 09:46 AM, peter tseng wrote:
> I installed window applications by PlayonLinux and the shortcuts generated in 
> /home/user/desktop. then I copy those shortcuts to /usr/share/applications 
> but I can't see any of them in Add more shortcuts setting. I surely run 
> qvm-sync-appmenus XXXVM. Any solution?

The destination directory — was it on the templatevm?

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/eebf6758-6a19-e538-bf7f-327ac44ded56%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Issue with hdmi

2016-12-04 Thread Manuel Amador (Rudd-O)

On 12/05/2016 04:27 AM, Patrick Bouldin wrote:
>
> ** 2nd update ** while the above update is true, unfortunately when the 
> machine hibernates the only thing that brings the display back is a cold boot.
>
> So it seems to be associated with losing the hdmi somehow - causing the 
> machine not to be responsive to keyboard wake-up.
>
> Any clues?

You may have to enable serial port kernel console terminal for
debugging.  That's usually very difficult on a laptop.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3e17ddd9-2c38-104a-53c6-5b5e1861ff80%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Any plans for a CCC meeting?

2016-12-01 Thread Manuel Amador (Rudd-O)

I have a couple friends who are huge fans of Qubes OS and they are going
to CCC.  Since they are not subbed to this list, I'd love to know if
there's a meeting of Qubes OS devs and users planned for CCC, so I can
tell them and they can go.

Any plans?

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/aab6c8c9-fe6d-4ee7-c298-ca6901ad8a0a%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Bluetooth locking (was Re: [qubes-users] safer typing in public places)

2016-11-30 Thread Manuel Amador (Rudd-O)

On 11/30/2016 04:18 AM, pixel fairy wrote:
> has anyone here experimented with bluetooth locks? it seems like a lot of 
> extra scary code to run in dom0, but i like the idea of auto shutdown if 
> device loses range. or maybe after a timeout period of some trigger?thats 
> another discussion. 

On your Bluetooth VM (usually a USBVM), run Blueproximity, and have
Blueproximity invoke a custom /etc/qubes-rpc/pixelfairy.Lock service on
dom0 which you will need to write yourself.  It's a one-liner service:

loginctl lock-sessions

To invoke it from the Bluetooth VM, you need to ask Blueproximity to run
the command:

/usr/lib/qubes/qrexec-client-vm "$bluetoothvm" pixelfairy.Lock

Once you have given the Bluetooth VM permission ("yes to all") to invoke
the locker, it should work automatically every time you walk away.

The reverse is also possible — you could have a similar service that
unlocks the screen by running loginctl unlock-sessions.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/cd707267-d4c1-2a3c-a155-1d2cb89e850e%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] desktop sharing, capturing and screenshoting

2016-11-19 Thread Manuel Amador (Rudd-O)

On 11/19/2016 09:30 AM, Ray Brainer wrote:
> I am having hard time to make desktop sharing in Qubes.
> Within VM I see white screen.

X server in VM does not allow screengrabs at all.  Security measure.

> Installing software on dom0 and using it in broadcast is denied.
> What should I do?
>

dom0 does not allow networking.

You may be able to hook some sort of bridge using qvm-run --pass-io and
socat, but it sounds like a bad idea.

Qubes OS is intended to be a highly-secure OS.  Sharing the screen of
dom0 with other machines defeats that purpose entirely.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/faf934d9-1d53-0f2f-14da-c89db68d2c79%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How to rotate VPNs?

2016-11-17 Thread Manuel Amador (Rudd-O)

On 10/29/2016 03:09 AM, Gaiko Kyofusho wrote:
> Is it possible to set up a VpnVM to automatically/randomly switch
> between vpn servers? At the moment I have to manually replace
> openvpn-client.opvn file with another file (with other server info)
> every time I want to change, would be great if I could at least have a
> menu that would give me the choice of which server I use or randomly
> cycle through servers.
> -- 
> You received this message because you are subscribed to the Google
> Groups "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to qubes-users+unsubscr...@googlegroups.com
> .
> To post to this group, send email to qubes-users@googlegroups.com
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/CAGpWZxNH-2%3DWUuk0YXy9dxn1wBNTyow3MrWU62h6pxTt4snfdQ%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.

Can you file a ticket for a feature request on
https://github.com/Rudd-O/qubes-vpn ?  Thanks.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/39a88389-4aa6-c4b7-9ec5-91f3aa595d7b%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: ANN: Qubes network server

2016-11-17 Thread Manuel Amador (Rudd-O)

On 11/07/2016 02:29 PM, Max wrote:
>
> This worked first time!
>
> I pinged from the Debian AppVM to a new Fedora AppVM. I checked that the 
> pinging did not work first and then went through the steps to change the 
> Fedora AppVM to connect to the proxy server NetVM, assign a static IP, 
> restart, set the firewall rules and then ping.
>
> In the meantime, could I ask if it is possible to do what I am trying to 
> achieve  by adjusting the iptables? I reported my troubles attempting to do 
> this here: 
> https://groups.google.com/d/msg/qubes-users/Dan7LNLv048/pkT_O2tDAAAJ

It's not clear to me what you are trying to achieve.  Can you describe
it in English with examples?


-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ab23a251-6ecd-cc49-1ed4-e9bf5a786dba%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: Leakproof Qubes VPN

2016-11-17 Thread Manuel Amador (Rudd-O)

On 11/09/2016 01:38 PM, SEC Tester wrote:
> Hey Rudd-O,
>
> Thanks for your effort and great contribution to the Qubes community. Not 
> sure why Chris was critical, especially without specifically showing evidence 
> of any problems. Maybe just a troll?
>
> I  haven't tried your program out yet, Im keeping it as my backup option, as 
> im still hoping to find a way to get my AirVPN GUI to work. I would prefer a 
> GUI over a CLI, especially when i might want to switch servers quickly or 
> look at my stats.
>
> As you seem like such an expert on this, i was hoping you could have a look 
> at my post, and see if you could workout whats going wrong?
>
> https://groups.google.com/forum/#!topic/qubes-users/T0wbCuIgISg
>
> If you have the time that would be Awesome! Cheers.

I don't really know how that VPN software works, honestly.


-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f1e99ec5-280d-b131-0d0e-2d5d263fc5ab%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Thoughts on Qubes OS Security... Could be improved.

2016-11-17 Thread Manuel Amador (Rudd-O)

On 11/12/2016 08:58 PM, Chris Laprise wrote:
>
> That was my first reaction, too. But years later, I am so, s glad
> ITL de-emphasized kernel-based security.
>
> If they had kept it as a supported security layer, the
> "security-in-depth" mindset would have dominated most of our
> discussions and attention... essentially eaten our brains like it does
> to everyone else. Seriously, this stuff can be perniciously
> misleading, and the moment that "authoritative" voices in the
> community start looking down their noses at "dinky little 1MB
> hypervisor" compared with their heavy bookshelves full of standard
> admin guides and certifications... that's when the security zombies
> start encroaching.
>
> Therefore, I think it is up to the community to promote the Linux
> extra security measures as a kind of add-on. Enabling it could be a
> good thing IF and only if we can do it with minimal effort and
> distraction. But keep it far away from pre-installed or supported status.

Actually, enabling things like GRSECURITY / PaX / SELinux by default
adds security, so it is better than not enabling it.  The only question
is what sort of usability problems it can carry.  But something that
will prevent, say, Firefox from doing arbitrary shit when owned, that
would be absolutely great.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/dccafd8b-b4c9-a848-b1f3-41e3b21ae8c9%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Does the Standard Firewall-VM Actaully do anything?

2016-11-17 Thread Manuel Amador (Rudd-O)

On 11/17/2016 04:20 AM, Sec Tester wrote:
> It also raises the question,
>
> Is there any benefit running a VPN-Proxy-VM through sys-firewall?
>
> Or maybe save the overhead and just connect VPN-Proxy-VM directly to sys-Net?
>

Either works.  With the firewall in between, you can limit the outbound
traffic from the VPN VM to strictly VPN traffic and nothing more.

I have explanatory drawings here: https://github.com/Rudd-O/qubes-vpn

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/92dde6e3-df91-ccfa-27d2-8a91bb8d0535%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Thoughts on Qubes OS Security... Could be improved.

2016-11-13 Thread Manuel Amador (Rudd-O)

On 11/12/2016 03:21 AM, Sec Tester wrote:
> SELinux or AppArmor.

SELinux would be absofuckinglutely great.  Confined apps like Firefox
would run much more securely.

I got one DispVM owned by an attacker at Defcon in 2014.  Isolation was
nice to have because the machine didn't get owned, but the VM would have
never been owned if SELinux had been active.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c6aa365c-7c11-1ff1-6cac-482f1db0d329%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: ANN: Qubes network server

2016-11-06 Thread Manuel Amador (Rudd-O)

On 11/05/2016 03:54 PM, Max wrote:
>
> Thanks for the response!
>
> I ran this and also ran 'sudo dnf install go' when I came across the 
> following error: 'go is needed by qubes-network-server-0.0.4-1.fc23.noarch'.

A commit is now out which eliminates this dependency.

> I then did the cd into the cloned folder and the 'make rpm' function has 
> appeared to have worked.
>
> I followed the steps to get this to Dom0 and then installed the RPM. It may 
> be better to add to the documentation 'sudo rpm -ivh qns.rpm' as I wasn't 
> initially sure that I actually had to name the file. It helps the noobs! 
>
> The purpose for me for installing the network server was to be able to ping 
> my Debian VM from my Windows VM.
>
> These are the configuration steps I took subsequent to install:
>
> 1) Created a ProxyVM named server-proxy.
> 2) Changed the NetVM on both work-apps (my Debian 8 VM) and windows-7 (HVM) 
> to the new ProxyVM

Sorry, I should have clarified that HVMs are not supported at all.  I am
very, very sorry.  I need to do more work to get HVMs to work properly
("more" is an euphemism for I have totally forgotten so far to support
that use case).  It is totally my fault that I did not explain this in
the documentation.  My bad.  I have updated the documentation to reflect
that.

If you could help me, do report what happens when you ping between a
Fedora and a Debian AppVM, or two Debian AppVMs.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2d0b8050-8aa1-6b4b-c952-2c054f147930%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Your Battery is syping on you...

2016-11-04 Thread Manuel Amador (Rudd-O)

On 11/04/2016 08:32 PM, 198730178489710317470139 wrote:
> Hello,
>
> good to know that Firefox and other mainstream-browser's spy-features don't 
> work inside the Q-VMs.
>
> But here are many ways to find out, who is sitting in front of the screen, 
> without get logged in, e.g. also keyboard-typing-patterns and mouse 
> movements...
>
> So for ebanking and free of digital dicriminating shopping I should use 
> Whonix?

For ebanking you want to use a normal AppVM that does not have the
Whonix stuff.  They will fingerprint you.

For shopping you want to use a separate normal AppVM that does not have
the Whonix stuff.  They will fingerprint you.

BUT

Those fingerprints will be different and so sites you visit on your
shopping VM will not know about your banking habits in any way, and vice
versa.

For regular browsing you want to have a separate VM that has hardened
settings and uses stuff like User Agent Spoofer with all the Firefox
fingerprinting settings disabled (battery, gamepad, audio, WebGL, et
cetera), as well as uMatrix to disable HTTP requests that you have not
authorized.  This VM can totally be a Whonix browser + Tor combo.  I
think I will post a guide for that soon enough.

Just remember: Don't bank where you surf, don't shop where you bank,
don't surf where you shop.

-- 

Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/639a26e7-f6a1-5b07-2fa7-9f97f24068bb%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Display Calibration and Audio Equalizer for Dom0 ?

2016-11-04 Thread Manuel Amador (Rudd-O)

On 11/02/2016 06:28 PM, Marek Marczykowski-Górecki wrote:
>
> > @Marek:
> > Do you have any idea what to look for in order to be able to calibrate
> > my screen under Qubes?
>
> I have no idea how such software works... Especially at which stage
> calibration is applied. Is it something that application does
> "internally", or adjust display driver options?

I believe it tweaks the gamma of the X server?

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/cc1c4576-004e-195c-5ddf-a5534b659053%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Your Battery is syping on you...

2016-11-04 Thread Manuel Amador (Rudd-O)

On 11/02/2016 09:49 PM, '109384'019834'09128'340932189 wrote:
> Hello,
>
> in Q the Firefox battery fingerprinting is enabled.
>
> https://blog.lukaszolejnik.com/battery-status-readout-as-a-privacy-risk/
>
> Manual you might disable it:
>
> 1. start Firefox
> 2. open the URL about:config 
> 3. scroll down to dom.battery.enabled and disable this feature
>
> It would be nice if the DispVM has running a Firefox, which don't support the 
> fingerprinting (or even better, a real secure-browser...)

Battery access to the system battery is disallowed because the DispVM /
AppVM does not have access to the hardware.


-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/dddc3ce5-3b7b-c038-23ad-ba9e34fbeb4d%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: ANN: Qubes network server

2016-11-03 Thread Manuel Amador (Rudd-O)

On 11/02/2016 07:03 AM, Max wrote:
> On Thursday, 13 October 2016 01:31:01 UTC+8, Manuel Amador (Rudd-O)  wrote:
>> Update:
>>
>> I have dramatically enhanced the documentation of the project:
>>
>> * https://github.com/Rudd-O/qubes-network-server
>> *
>> https://github.com/Rudd-O/qubes-network-server/blob/master/doc/Setting%20up%20your%20first%20server.md
>> *
>> https://github.com/Rudd-O/qubes-network-server/blob/master/doc/Setting%20up%20an%20SSH%20server.md
>>
>> This project is now ready and documented enough to be useful to users of
>> Ansible Qubes who want to remotely manage clusters of Qubes OS machines:
>>
>> *
>> https://github.com/Rudd-O/ansible-qubes/blob/master/doc/Remote%20management%20of%20Qubes%20OS%20servers.md
>> *
>> https://github.com/Rudd-O/ansible-qubes/blob/master/doc/Enhance%20your%20Ansible%20with%20Ansible%20Qubes.md
>>
>> I strongly welcome anyone who tries this and shares their experiences. 
>> It is my goal to get this to be a key part of the Qubes OS strategy.
>>
>> -- 
>>
>> Rudd-O
>> http://rudd-o.com/
> For the "make rpm" command you refer to the local directory of your clone, is 
> there a tutorial you recommend I should follow for doing this?

That *is* the tutorial.  cd into your clone, then type "make rpm"
(without the quotes).

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/94c88b53-223c-fbd6-e438-6be8ab0d0171%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 3 MacOSX

2016-10-30 Thread Manuel Amador (Rudd-O)

On 06/17/2016 04:11 AM, Drew White wrote:
>
>
> On Sunday, 15 May 2016 14:05:50 UTC+10, Jeremy Rand wrote:
>
> FWIW, I think a legal argument could be made that such license
> agreements are anti-competitive and therefore unenforceable.
>  However,
> I am unaware of any specific precedent for this argument, so it would
> indeed probably be unwise for ITL to violate the license agreement
> unless their goal is to win the inevitable lawsuit and thus achieve a
> beneficial precedent.  (And while that would be laudable, I would
> definitely not blame ITL if they decided that such activities are not
> worth their effort or budget.)
>
> (And of course, I'm not a lawyer.)
>
>
> Well, in the end, I own a mac, It's not breaking any agreement or
> anything for me wanting to run it.

Yeah you are.  Check the licensing terms for the Mac OS X software that
came with it.

Not that it matters, as it's a bullshit "agreement" that transforms a
purchase into somewhat of a feudal renting system of objects.


-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/87694b7c-33f9-8a1c-fd26-14d1f361e02e%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: How to view Youtube in Fullscreen ? (for dummies)

2016-10-28 Thread Manuel Amador (Rudd-O)

On 10/27/2016 01:31 AM, raahe...@gmail.com wrote:
> On Wednesday, October 26, 2016 at 5:15:53 PM UTC-4, jamie wrote:
>> does not matter if I use fedora, debian or whonix ... whenever I press 
>> fullscreen on any youtube video the brower freezes..
>>
>> it also does not matter which browser I use firefox, chromium,...
>> all of them freeze.

I can confirm this issue.  It's not that they freeze, they continue to
run and you can see window updates when you resize the window, but it's
simply that they stop updating after hitting that damn fullscreen
button.  This is a new bug and I recommend you file a ticket in
https://github.com/QubesOS/qubes-issues/new .

>>
>>
>> how to watch youtube videos 'for dummies' in fullscreen ? 
>> how to enable fullscreen mode 'for dummies' in my fedora appVM ?
> hmm I've only had the issue on firefox, maybe related?  
> https://github.com/QubesOS/qubes-issues/issues/1502
>


-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3e47b747-25e4-8254-f06a-f06abb947cac%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Crashplan?

2016-10-28 Thread Manuel Amador (Rudd-O)

On 06/26/2016 03:40 PM, Andrew David Wong wrote:
> On 2016-06-26 04:27, Niels Kobschaetzki wrote:
> > Hi,
>
> > does anyone have experiences with running Crashplan in Qubes? If
> > yes, how did you install it?
>
> > Niels
>
>
> I installed it in a StandaloneVM with the installer's default options.
>
> (As I'm guessing you've discovered, attempting to install it in an
> AppVM with the default options doesn't allow it to persist across
> reboots since it tries to install parts of itself to the read-only
> root filesystem.)
>

There is a persist dirs option.  Look for bind-dirs.sh in the
qubes-core-agent-linux package.  This should let certain directories
persist for good in any AppVM (but, of course you don't want to do that
for system dirs like /usr/bin and such).


-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/d2c28aca-8ac4-7954-07d2-6626ca344010%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Internal networking: How are IPs chosen, why class C subnet.

2016-10-28 Thread Manuel Amador (Rudd-O)

On 10/28/2016 08:51 AM, Robert Mittendorf wrote:
> Hey,
>
> yesterday I noticed that even if VMs share a class C network, all
> trafic is routed through the gateway and by default the gateway does
> not allow a connection to other VMs in the same subnet.
> This makes a lot of sense from a security perspective, but the shown
> information is missleading.

qubes-network-server does the right thing if you have a number of VMs
with assigned static IPs.  Traffic gets routed to the right VM.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f2af19a4-7839-1a34-41e6-f57bf19b2cad%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request for test: Re: [qubes-users] Fedora 24?

2016-10-28 Thread Manuel Amador (Rudd-O)

On 10/28/2016 09:40 AM, Marek Marczykowski-Górecki wrote:
>
> Actually yes, we may hook qubes-gui-agent.service into graphical.target
> and call it "display manager", preventing others from running. This is
> good idea, but something I'd like to avoid as a stable update - so, for
> Qubes 4.0.

Yes, this would be a good start.

>
>> I believe the correct thing to do is to create the necessary
>> configuration for the default display manager to start qubes-guid with
>> autologin.  This will also give us a complete desktop session inside the
>> VM, 
> This is exactly what we want to avoid. We don't want another window
> manager there (which would be fighting with the one in dom0), as well as
> a ton of other useless things like panels, clock icons etc. Excluding
> this crap makes Qubes VMs lightweight enough to run 20+ of them at the
> same machine.

I was not suggesting you run a window manager.  Just a qubes-guid
session.  No window manager whatsoever.  Certainly not clocks, or
panels, or any of that shit.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/68bd52bc-ad96-f342-0989-869fbc97fb6c%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: ANN: git-remote-qubes: Inter-VM Git for Qubes OS

2016-10-28 Thread Manuel Amador (Rudd-O)

On 10/28/2016 10:51 AM, cyrinux wrote:
> Le jeudi 27 octobre 2016 13:47:14 UTC+2, Manuel Amador (Rudd-O) a écrit :
>> It gives me great pleasure to announce the inter-VM Git bridge for Qubes
>> OS, which allows you to git push and git pull from VMs stored in other
>> repos, with no networking involved whatsoever, and observing full
>> compliance with Qubes OS qrexec policy.
>>
>> This should usher in a new era of software development that allows
>> people to segregate their secure Git repos from insecure build VMs and
>> other engineering constructs I can't even think of (after doing
>> low-level socket programming for a week, which has left my brain utterly
>> fried).
>>
>> Find the software at https://github.com/Rudd-O/git-remote-qubes
>>
>> ---
>>
>> # Inter-VM Git for Qubes OS
>>
>> This is a very simple Git protocol bridge between Qubes OS VMs.  With it,
>> you can `git pull` and `git push` between VMs without having to grant
>> any of the VMs any special policy privileges other than access to Git.
>>
>> ## Using the software
>>
>> These instructions assume you have installed the software.  See the
>> *Installing the software* heading below for more information.
>>
>> ### Creating a repository
>>
>> We'll assume for illustration purposes that you want to access a repository
>> stored in `/home/user/xyz` on your VM `servervm`.
>>
>> Run the following commands on `servervm`:
>>
>> ```
>> cd /home/user
>> mkdir -p xyz
>> cd xyz
>> git --bare init
>> ```
>>
>> That's it.  Your new and empty repository is ready to use.
>>
>> ### Adding a remote to a local repository
>>
>> For illustration purposes, you'll be pushing and pulling `servervm`'s `xyz`
>> repo on your vm `clientvm`.  Run the following commands on `clientvm`:
>>
>> ```
>> cd /home/user
>> git clone qubes://clientvm/home/user/xyz
>> ```
>>
>> You will get a permission dialog from dom0 asking for `ruddo.Git` access.
>> Accept it.  Note that accepting the permission dialog implicitly gives
>> Git access to all Git repos stored in `servervm`, but only for that one
>> execution (unless you say *Yes to all*, in which case the permission
>> is remembered within the policy file that you installed earlier with the
>> `dom0` package).
>>
>> This should have cloned `xyz` from `servervm` into your `/home/user/xyz`
>> directory in `clientvm`.
>>
>> From this point on, you can push and pull in `clientvm` from
>> `servervm:/home/user/xyz` to your heart's content.
>>
>> If, instead of cloning, you have an existing repo, you can add a new remote
>> just as easily:
>>
>> ```
>> cd /home/user/existingxyz
>> git remote add qubesremotevm qubes://servervm/home/user/xyz
>> ```
>>
>> That addition will enable to push and pull from the remote `qubesremotevm`
>> which represents the repo `/home/user/xyz` in the remote VM `servervm`.
>>
>> ## Installing the software
>>
>> There are two components for this software:
>>
>> * Component 1 is the VM side of things, which implements the Git protocol
>>   across VMs.
>> * Component 2 is the dom0 side of things, which is a simple text file
>> declaring
>>   the initial Git access policy for your VMs.
>>
>> First, build the software,  After cloning this repository on a suitable VM,
>> run the command:
>>
>> ```
>> make rpm
>> ```
>>
>> This will generate two installable packages on the local directory:
>>
>> * `git-remote-qubes-.noarch.rpm`, which contains the Git
>>   protocol implementation.
>> * `git-remote-qubes-dom0-.noarch.rpm`, which contains the
>>   default policy.
>>
>> Copy the `git-remote-qubes-.noarch.rpm` file to the template VM
>> or standalone VM where you plan to pull or push to / from a Git repo
>> stored in another Qubes VM.  Install the RPM with
>> `dnf install `.  At this point, this VM, as well as
>> any VMs using this as a template, have gained the ability to push and pull
>> from Git repos stored in other VMs, as well as the ability to listen on
>> push / pull requests from different VMs in the same system.
>>
>> Now copy the `git-remote-qubes-dom0-.noarch.rpm` file to
>> your dom0.  At this point, the default policy (`deny`) is active on
>> your Qubes OS system, and you can begin pushing and pulling.
>>
>> Those clever among you will have discovered that there is a `Makefile`
>> included, and

Re: [qubes-users] Re: Introducing the qubes-announce read-only mailing list

2016-10-28 Thread Manuel Amador (Rudd-O)

On 10/28/2016 05:02 AM, Achim Patzner wrote:
> Am 28.10.2016 um 02:00 schrieb Drew White:
>> On Friday, 28 October 2016 10:57:03 UTC+11, Andrew David Wong  wrote:
>> We've just introduced a new mailing list: qubes-announce
>>> So it's a forum, not a mailing list >
> No, darling. It's a mailing liist. The contents are transferred to
> registered users by mail and only those subscribed will receive it. The
> contents are distributed by SMTP. The link he sent is an explanation
> page on a web server.
>
> Don't pretend to be dumber than you are, it doesn't make you look better.
>
>
> Achim
>

Forgive me for asking this:

Anyone else beginning to get annoyed with Drew's constant participation
that contributes nothing of value, and in fact often detracts from the
value of the mailing list?

I don't want to be mean, but it's like we have our own Ken M in this
mailing list, and it is Drew.


-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7bc77a5f-d86c-249f-6153-c7083568fce4%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request for test: Re: [qubes-users] Fedora 24?

2016-10-28 Thread Manuel Amador (Rudd-O)

On 10/28/2016 01:56 AM, Marek Marczykowski-Górecki wrote:
> On Thu, Oct 27, 2016 at 03:31:46PM +0200, Marek Marczykowski-Górecki
> wrote:
> > On Thu, Oct 27, 2016 at 09:50:56AM +0200, Zrubi wrote:
> >> On 09/06/2016 01:24 AM, Marek Marczykowski-Górecki wrote:
> >>
> >>> I've just tried this and successfully upgraded Fedora 23 to Fedora 24
> >>> template.
> >>>
> >>> TL;DR version:
> >>> 1. Clone fedora-23 to fedora-24-test.
> >>> 2. Open terminal in fedora-24-test.
> >>> 3. Run "dnf upgrade --releasever=24".
> >>> 4. Shutdown the template.
> >>> 5. Switch (some of?) VMs to this template.
> >>>
> >>
> >> Just tried to upgrade my templates and got this error:
> >>
> >>
> >> Error: Transaction check error:
> >>   file /usr/lib64/libpython3.so from install of
> >> system-python-libs-3.5.1-17.fc24.x86_64 conflicts with file from
> package
> >> python3-libs-3.4.3-12.fc23.x86_64
> >>
> >>
> >> Was not able to workaround it, because(?) those libs are used by dnf
> >> itself :o
> >>
> >> The official fedora upgrade way:
> >> https://fedoraproject.org/wiki/DNF_system_upgrade
> >>  seems not compatible with Qubes
> >>
> >>
> >> any hints how to solve this?
>
> > I haven't tried recently, but it worked before. Maybe a workaround would
> > be to disable "updates" repository for the upgrade time? Just add
> > --disablerepo=updates.
>
> Or another idea: use `dnf distro-sync --releasever=24`, instead of `dnf
> upgrade`. Not sure if that helps.
>
> > I think it may be possible to use "official" upgrade method, by
> > switching to pvgrub first:
> >
> https://www.qubes-os.org/doc/managing-vm-kernel/#using-kernel-installed-in-the-vm
> > But in practice probably it will be more complex than just following
> > that instructions...  Maybe worth a try?
>
> Actually, it looks like it almost works this way, even without switching
> to pvgrub. The only problem is that we put "3" on kernel cmdline, which
> forces systemd going into multi-user.target (instead of
> system-update.target). This can be worked around by putting
> "systemd.unit=system-update.target" on the template kernel command line
> ("kernelopts" property) before starting second phase of the upgrade.

We should not be putting 3 in the kernel command line, and we should not
be modifying the default target in qubes-core-vm-systemd either.  What
we should do is do the necessary work to get the default system
configuration to work when we boot a VM into graphical.target (the
default).  That way we avoid these integration issues.

I believe the correct thing to do is to create the necessary
configuration for the default display manager to start qubes-guid with
autologin.  This will also give us a complete desktop session inside the
VM, and XDG autostart as well, as opposed to just a tiny stub that
doesn't have e.g. password manager environment or GPG agent.

This area is ripe for research, and it's time we matured in that
direction.  Also noteworthy is that, with the move to Wayland, this sort
of work is very apropos.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/822d780c-e039-f80b-3808-c6c8e740ffa7%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Networking between two vms?

2016-10-28 Thread Manuel Amador (Rudd-O)

On 04/08/2016 02:17 PM, edev.u...@gmail.com wrote:
> On Sunday, February 1, 2015 at 11:45:05 PM UTC-5, Marek Marczykowski-Górecki 
> wrote:
>
>> By default firewallvm blocks all the inter-vm traffic. But you can add a
>> rule to allow that. Take a look here:
>> https://wiki.qubes-os.org/wiki/QubesFirewall#EnablingnetworkingbetweentwoAppVMs
> The above guide requires both VMs to be connected to the same firewall vm.
>
> I have a case when one vm is a proxyvm connected to a separate NIC via a 
> dedicated netvm and I want to connect the proxyvm to the default sys-firewall 
> vm. How can I enable networking between these two vms?
>

To enable transparent networking between VMs, you can also use:

https://github.com/Rudd-O/qubes-network-server

Just give your two VMs different IP addresses and they will work.  Of
course, the firewall rules still need to be set, if the VMs are attached
to a ProxyVM.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/385f673c-f103-07e8-af90-3d70428d3645%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Windows HVM doesn't get updates

2016-10-28 Thread Manuel Amador (Rudd-O)

On 04/10/2016 11:34 PM, Salmiakki wrote:
> Well, maybe. I haven't looked at traffic yet. Is there a simple way to
> do that with qubes?

sudo tcpdump -i eth0 -nn in the ProxyVM that your Windows VM is attached to.


-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ef0825ab-29be-31a1-f382-538ac61a8d5a%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: ANN: git-remote-qubes: Inter-VM Git for Qubes OS

2016-10-27 Thread Manuel Amador (Rudd-O)

On 10/27/2016 11:37 PM, Drew White wrote:
> On Thursday, 27 October 2016 22:47:14 UTC+11, Manuel Amador (Rudd-O)  wrote:
>> It gives me great pleasure to announce the inter-VM Git bridge for Qubes
>> OS, which allows you to git push and git pull from VMs stored in other
>> repos, with no networking involved whatsoever, and observing full
>> compliance with Qubes OS qrexec policy.
> You can either do that and use something that will absorb RAM, OR you can 
> just add the iptables rules, they work easier and faster than adding ANOTHER 
> layer.
>
> Just look for the post I put up months ago regarding the rules for it.
>

Actually, it's the other way around — your solution requires some sort
of daemon continuously running on the machine serving the repos, such as
git daemon or sshd.  That costs RAM.

And your solution requires networking too, which makes it impossible to
apply your solution to serve repos stored in non-networked VMs.

But thanks for pointing this out so I can update the README with these
advantages.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5d7da42c-f427-4b6a-a074-2ac17e191a9e%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request for test: Re: [qubes-users] Fedora 24?

2016-10-27 Thread Manuel Amador (Rudd-O)

On 09/06/2016 11:10 AM, Achim Patzner wrote:
> Some key bindings might have changed; ctrl-"+" in a terminal window
> increases the font size but the terminal window does not grow with it
> anymore.

Finally!  The GNOME people finally unfucked Ctrl++!

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0192cadb-f62e-3955-96c1-5770609ec274%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: Leakproof Qubes VPN

2016-10-27 Thread Manuel Amador (Rudd-O)

On 10/27/2016 12:03 PM, Robert Mittendorf wrote:
> Just saw the Qubes VPN project right now.
>
> Quick-reading the tutorial I have to questions:
>
> 1) why does the VPN-VM need to be allowed to do DNS,

The VPN VM does not need to be allowed to do DNS.  You can set an IP in
its configuration and then no DNS is needed.

I will expand the instructions to indicate that.

> if DNS requests are routed through the VPN. Is it just in case the VPN
> server it wants to connect to is defined by hostname instead of IP?

No.  The DNS requests of the chained AppVMs are routed to the DNS
servers declared by the VPN server.  The DNS requests of the VPN VM
itself are routed to the DNS servers of the NetVM that is upstream of
the VPN VM.

> 2) why is the recommendation to allow all hosts for the VPN server
> (and not only the VPN servers IP)?

No reason.  I will clarify that there's no need to do that.

>
> thank you
>

Thank you for helping me clarify the documentation.

-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1324039e-5a32-e200-b60b-533a9ad56ceb%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: Leakproof Qubes VPN

2016-10-27 Thread Manuel Amador (Rudd-O)

On 10/27/2016 09:15 AM, cyrinux wrote:
>
> Hi Rudd-o, just for say I use Qubes VPN since 2 weeks, with mullad, and no 
> problem, this seems perfect ;)

Thank you very, very much.  You are very kind for taking the time to
give public appreciation for my work :-)


This is the stuff I live for.


-- 
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e9c69164-c780-7755-8c1f-fb258676900b%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] ANN: git-remote-qubes: Inter-VM Git for Qubes OS

2016-10-27 Thread Manuel Amador (Rudd-O)

It gives me great pleasure to announce the inter-VM Git bridge for Qubes
OS, which allows you to git push and git pull from VMs stored in other
repos, with no networking involved whatsoever, and observing full
compliance with Qubes OS qrexec policy.

This should usher in a new era of software development that allows
people to segregate their secure Git repos from insecure build VMs and
other engineering constructs I can't even think of (after doing
low-level socket programming for a week, which has left my brain utterly
fried).

Find the software at https://github.com/Rudd-O/git-remote-qubes

---

# Inter-VM Git for Qubes OS

This is a very simple Git protocol bridge between Qubes OS VMs. With it,
you can `git pull` and `git push` between VMs without having to grant
any of the VMs any special policy privileges other than access to Git.

## Using the software

These instructions assume you have installed the software. See the
*Installing the software* heading below for more information.

### Creating a repository

We'll assume for illustration purposes that you want to access a repository
stored in `/home/user/xyz` on your VM `servervm`.

Run the following commands on `servervm`:

```
cd /home/user
mkdir -p xyz
cd xyz
git --bare init
```

That's it. Your new and empty repository is ready to use.

### Adding a remote to a local repository

For illustration purposes, you'll be pushing and pulling `servervm`'s `xyz`
repo on your vm `clientvm`. Run the following commands on `clientvm`:

```
cd /home/user
git clone qubes://clientvm/home/user/xyz
```

You will get a permission dialog from dom0 asking for `ruddo.Git` access.
Accept it. Note that accepting the permission dialog implicitly gives
Git access to all Git repos stored in `servervm`, but only for that one
execution (unless you say *Yes to all*, in which case the permission
is remembered within the policy file that you installed earlier with the
`dom0` package).

This should have cloned `xyz` from `servervm` into your `/home/user/xyz`
directory in `clientvm`.

>From this point on, you can push and pull in `clientvm` from
`servervm:/home/user/xyz` to your heart's content.

If, instead of cloning, you have an existing repo, you can add a new remote
just as easily:

```
cd /home/user/existingxyz
git remote add qubesremotevm qubes://servervm/home/user/xyz
```

That addition will enable to push and pull from the remote `qubesremotevm`
which represents the repo `/home/user/xyz` in the remote VM `servervm`.

## Installing the software

There are two components for this software:

* Component 1 is the VM side of things, which implements the Git protocol
across VMs.
* Component 2 is the dom0 side of things, which is a simple text file
declaring
the initial Git access policy for your VMs.

First, build the software, After cloning this repository on a suitable VM,
run the command:

```
make rpm
```

This will generate two installable packages on the local directory:

* `git-remote-qubes-.noarch.rpm`, which contains the Git
protocol implementation.
* `git-remote-qubes-dom0-.noarch.rpm`, which contains the
default policy.

Copy the `git-remote-qubes-.noarch.rpm` file to the template VM
or standalone VM where you plan to pull or push to / from a Git repo
stored in another Qubes VM. Install the RPM with
`dnf install `. At this point, this VM, as well as
any VMs using this as a template, have gained the ability to push and pull
from Git repos stored in other VMs, as well as the ability to listen on
push / pull requests from different VMs in the same system.

Now copy the `git-remote-qubes-dom0-.noarch.rpm` file to
your dom0. At this point, the default policy (`deny`) is active on
your Qubes OS system, and you can begin pushing and pulling.

Those clever among you will have discovered that there is a `Makefile`
included, and that you can use the `Makefile` to install the software on
other non-RPM templates. I welcome pull requests to add support for
other distro packages and Qubes OS templates.

## Troubleshooting and debugging

If you are experiencing problems communicating with a Git repo in a VM,
export the variable `QUBES_DEBUG` on the side of your client (where your
local Git repo is), and look at the debugging output that appears.

As always, you can file new issues on the repo of this project for help
with fixing bugs that the programs may have. Pull requests also welcome.

--
Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/1f1dc56f-4d34-c9e1-6d15-f497fc7e5822%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: Leakproof Qubes VPN

2016-10-26 Thread Manuel Amador (Rudd-O)

Apologies for the reply to self, but I have received great news.

The first piece of great news is that a user of Qubes VPN found a bug
that made it impossible for Qubes VPN to work with tun-style VPN
providers.  We have fixed that bug thanks to his cooperation, and you
can see the result of our bug report and conversation here:

https://www.reddit.com/r/Qubes/comments/57acz8/add_a_leakproof_vpn_to_your_qubes_os_with_this/

The second piece of great news is that, based on what he reported there,
ABSOLUTELY NO TRAFFIC ever leaked from his VPN-protected AppVM to any
sort of network device, as the VPN VM still prevented the traffic from
going anywhere else except over the VPN.

That means: even under an environment where a critical bug rendered VPN
operation impossible, Qubes VPN still managed to prevent leaks 100%.

I am quite happy to see that the engineering gone into this thing
actually paid off big time.

Have you tried Qubes VPN yet?

-- 

Rudd-O
http://rudd-o.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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/667e45a5-0278-ca7a-0cd4-3bc0101ff045%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

1 2 >

1 - 100 of 158 matches

Mail list logo