from:"Chris"

On 08/17/2016 06:41 PM, entr0py wrote:

On 08/17/2016 03:20 PM, entr0py wrote:

Just migrated my Qubes 3.1 system to new hardware and it went surprisingly
smoothly :)

I noticed however that my KDE Window Rules did not get backed up / restored
(not sure which).

It's kind of irrelevant at this point since we're moving away from KDE but I'd
still like to know why that happened and if there are other config files that I
need to copy over manually.

Most of the files in ~/.kde/share/config/ have permissions user:user 600 so it
shouldn't be a problem to back up. Is a KDE lock on those files preventing them
from being overwritten on the restore? Any other files I should bring back
manually? (Just noticed some keybindings not working...)

Thanks.

If the KDE version stayed the same (4.x) then I'd expect the dom0
restore to include window rules and keybindings.

Did you restart the system after the restore?

Chris

Yes, more details:

1. Backed up the entire system (all up-to-date): dom0, all templates, all vms;
2. Installed fresh Qubes 3.1 with no pre-configuration (seems fedora-23 was
installed anyway)
3. Did an incremental restore as follows:
a. restored dom0 - noticed that the following did not restore: desktop
background, sound prefs,
application menu settings (application menu entries were correct)
b. reboot
c. restored service templates & service vms
d. updated dom0 - noticed window rules were not restored
e. reboot
f. restored dom0 AGAIN - thinking that dom0 update might have some effect
window rules did not restore BUT desktop background did.
g. restored all other templates & vms
h. noticed that keybindings did not restore

I think all of these KDE settings are stored in ~/.kde/share/config/.
Specifically, the window rules are located in kwinrulesrc. I guess I could
reconnect backup drive and go find out if files were backed up to begin with.
My hunch is that the problem is on the restore end. How can I tell if files are
locked? And if locked can Qubes restore overwrite them?

Doesn't dom0 restore move the current home dir into a subdir, then write
the restored files to the correct locations?

The only way I can think of that failing is if the initial move was
piecemeal and didn't catch everything.

Another explanation for the problem is that KDE might store some
settings elsewhere, such as /etc or /usr/share.

FWIW, although I prefer using KDE I have never relied on a restore
process to get my desktop settings back. I think its better to have a
written checklist of customizations that need to be done after an
installation.

Chris

--
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/dd322451-6141-d22e-fe16-7787b2fe8c8d%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Missing config files after Backup / Restore


On 08/17/2016 03:20 PM, entr0py wrote:

Just migrated my Qubes 3.1 system to new hardware and it went surprisingly 
smoothly :)

I noticed however that my KDE Window Rules did not get backed up / restored 
(not sure which).

It's kind of irrelevant at this point since we're moving away from KDE but I'd 
still like to know why that happened and if there are other config files that I 
need to copy over manually.

Most of the files in ~/.kde/share/config/ have permissions user:user 600 so it 
shouldn't be a problem to back up. Is a KDE lock on those files preventing them 
from being overwritten on the restore? Any other files I should bring back 
manually? (Just noticed some keybindings not working...)

Thanks.


If the KDE version stayed the same (4.x) then I'd expect the dom0 
restore to include window rules and keybindings.


Did you restart the system after the restore?

Chris

--
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/b9244b9e-fd43-cb07-5c1e-43f0d473cbf5%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] VPN Link Up, NetVM set to VpnVM but AppVMs still don't have net access?

On 07/26/2016 05:32 PM, gaikokujinkyofu...@gmail.com wrote:

On Monday, July 25, 2016 at 5:12:42 PM UTC-10, Chris Laprise wrote:

The shebang refers to the '#!/bin/bash' at the start of the script; that
is required for it to run.

A. Ok. Well I checked and I had forgotten to remove the origonal #!/bin/sh
but it was the same file I had used before that had worked? Anyway, I edited it
and now only one line and it is bash. But still can't access anything other
than direct ip addresses via the appvm that is using the vpnvm?

The last three lines you refered to, of the .ovpn, I believe I added as the
Qubes VPN doc instructed, anyway I just c/p'd from the .ovpn I have:

script-security 2
up 'qubes-vpn-handler.sh up'
down 'qubes-vpn-handler.sh down'

Is that what you were referring to?

Yes.

Something else you can try is to bypass the DHCP stuff and add the DNS
server manually in your .ovpn with a line like this:
setenv vpn_dns 'X.X.X.X'

Replace X's with DNS server address.

I tried this next, added both like

setenv vpn_dns 'X.X.X.X X.X.X.X'

(tried without quotes too) but still no go. I then noticed that there was a
commented line in the qubes-vpn-handler.sh script so I added that line in that
script and took it out of the ovpn file, still not able to ping non ip
addresses...

Then when you connect and list your nat table again, you should see the
DNS IP there.

Chris

and both times (restarting vpnvm/appvm) the new DNS didn't show up when i tried
to list the nat tables?

I would have thought manually putting in the DNS would have been sufficent?

I thought I'd let you know another user was having the same symptoms (IP
access but no DNS) because Network Manager was running in the vpn vm...
https://groups.google.com/d/msgid/qubes-users/f35d90b9-2632-4f91-afff-3e1f8ac26302%40googlegroups.com

If you had enabled Network Manager in that vm you should disable it.
Other possible workarounds are putting a 7sec delay in handler script,
or renaming the qubes-setup-dnat-to-ns file before openvpn is run (see
linked thread for details).

Chris

--
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/30344390-4f39-eb08-a62b-274f41bdc0e2%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: installing Signal on Qubes mini-HOWTO

On 08/17/2016 11:35 AM, johnyju...@sigaint.org wrote:

On the Signal matter, just some personal paranoia Re: Signal and Google
Play Services:

I've been the subject of some rather intense and ongoing hacking (iPhone,
iPad, Android phone/tablet, PC, MacBook, cable modem connection, you name
it).

On the Android phone, I wiped it several times, and switched to Cyanogen,
but the "weirdness" kept coming back. (Seeing stuff being recorded,
logged, queued to upload etc., when scrutinizing the filesystem with adb.)
The issues often seemed to dance around Google Play Services.

The problem kept coming back, until last time, when I wiped the phone yet
again, but didn't install Google Play Store (and thus no Google Play
Services). Things *appear* to be stable and secure now, with no
logging/recording/uploading weirdness showing up on the filesystem.

I'd like to install and use Signal for obvious reasons, but I honestly
don't trust Google Store/Services enough to take the risk.

(I have a psycho ex with some crooked cop buddies, so I half suspect some
law enforcement/government hook might be present in Google Play Services.
Speculation of course. But I'll personally stay clear for now. I'm not
doing anything illegal, but with crooked cops it really doesn't matter
much. :) )

I did get a copy of Signal from apkmirror, but I expect it might not work
without Play Services, and I'm not sure it'd be smart to implicitly trust
apkmirror, either. So I'll keep my SmartPhone as a DumbPhone for now.

I was kind of excited to hear about Signal for Chromium, but disappointed
to find it relied upon you also having it installed on your smartphone.

Aand then there's this:
http://arstechnica.com/security/2015/06/not-ok-google-chromium-voice-extension-pulled-after-spying-concerns/

Not cool, Google.

Cheers. :)

I have to say I don't understand the logic of tying an app like Signal
to Google, meaning the user is attached to Google at the hip. Especially
when an app like Ring.cx operates without a browser or even a server,
which seems far less risky.

Chris

--
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/1d8e9316-1a77-9f6a-952a-880b847ae52f%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] No DNS with ProxyVM + OpenVPN

2016-08-16 Thread Chris Laprise

On 08/16/2016 06:56 AM, kotot...@gmail.com wrote:

To test this theory, you could put a 7sec delay in qubes-vpn-handler.sh
right before the line 'iptables -t nat -F PR-QBS'. Then the right IPs
should appear in PR-QBS.

It did work. Thank you again!

I wonder what is changing the NAT rules. I only see one 'up' directive in the
openvpn configuration, the one calling the qubes script. Maybe something from
Qubes itself? It's correct that the ProxyVM should be connected to sys-firewall
right?

That was going to be my next question: Is there anything in the vpn
config that triggers it, such as any other references to scripts.
Ideally, there should only be up and down.

If you're comfortable posting the configuration maybe I or someone else
could see the cause. Also the parts of the log output near the end that
deal with PUSH data, since that is a source of configuration directives.

I also wonder if your template might have an openvpn service configured
to autostart... creating a second openvpn process? You can check that
with ps, systemctl, etc.

Also, Network Manager should not be running in that vm.

Finally, you could disable the /usr/lib/qubes/qubes-setup-dnat-to-ns
script by renaming it right before openvpn starts (but it does have to
run once on vm start). That should prevent it from steamrolling over the
vpn-specific IPs.

Chris

--
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/1c702a72-f94b-f897-ee05-38b779a57b69%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 3.2-rc2 very high hard disk activity

2016-08-16 Thread Chris Laprise


On 08/16/2016 01:39 PM, donoban wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 08/16/2016 06:17 PM, Andrew David Wong wrote:

On 2016-08-16 03:58, donoban wrote:

I also have experienced a lot of process killed because I run out
of memory. This never happened with 3.1.


Is it possible that the high HDD activity is excessive swap usage
due to low memory?



I don't use swap at this moment and with 3.1 I didn't too. I should
add it probably, but if I "fix" the "hard disk problem".



Each vm has its own swap. If you misconfigure the vm with too little 
memory (this can easily happen if you inadvertently turn off memory 
balancing) then it can exhibit the symptoms you describe.


Chris

--
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/f3f605f4-9a6e-3357-f201-bddfa6113953%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] No DNS with ProxyVM + OpenVPN

On 08/15/2016 01:05 PM, kotot...@gmail.com wrote:

Thank you very much for your help. The DNS are transmitted but the rules in the
firewall seems to be missing:

Chain PR-QBS (1 references)
pkts bytes target prot opt in out source destination
0 0 DNAT udp -- anyany anywhere 10.137.5.1
udp dpt:domain to:10.137.2.1
0 0 DNAT tcp -- anyany anywhere 10.137.5.1
tcp dpt:domain to:10.137.2.1
0 0 DNAT udp -- anyany anywhere
10.137.5.254 udp dpt:domain to:10.137.2.254
0 0 DNAT tcp -- anyany anywhere
10.137.5.254 tcp dpt:domain to:10.137.2.254

The qubes script is nonetheless correctly started because I see the notification
"VPN is up".

Something else may be running a dnat script when you connect, because
that is the only thing that would be re-populating PR-QBS with the Qubes
internal IPs.

To test this theory, you could put a 7sec delay in qubes-vpn-handler.sh
right before the line 'iptables -t nat -F PR-QBS'. Then the right IPs
should appear in PR-QBS.

Alternative theory is that somehow openvpn is passing the internal IPs
to the script, but I think that's unlikely.

Chris

--
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/a1010675-628e-206e-979a-3cf2d49f7671%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] qubes-manager not showing on KDE


On 08/15/2016 11:22 AM, angelo "angico" costa wrote:

Hi, guys!

Still slowly progressing through Qubes.

I changed from XFCE to KDE and qubes-manager simply disappeared! I invoke it 
through the menu link as well as through CLI, but it just doesn't show up. It 
shows normally on XFCE, though. Also, 'ps aux | grep qubes-manager' lists it as 
running:

/usr/bin/python2 /usr/bin/qubes-manager -session ...

What am I possibly doing wrong? Any hint?

Thanks in advance,

angico.


Hi,

What version of Qubes is it?

Did you try rebooting to switch to KDE, instead of logout/login?

Chris

--
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/e6260346-116c-b934-595d-543e3118983d%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] No DNS with ProxyVM + OpenVPN

On 08/15/2016 03:33 AM, kotot...@gmail.com wrote:

Hi,

I set up a proxyVM with openvpn following the instructions from
https://www.qubes-os.org/doc/vpn/.

I cannot do DNS query over the VPN, for example this command executed from a
VM connected to the Proxy:

[user@fedora-23-dvm ~]$ dig www.google.com

; <<>> DiG 9.10.3-P4-RedHat-9.10.3-13.P4.fc23 <<>> www.google.com
;; global options: +cmd
;; connection timed out; no servers could be reached

Executing 'dig @8.8.8.8 www.google.com' works well.

What am I doing wrong?

Hi,

Its possible that your vpn service isn't supplying dns server info upon
connection.

You can check what openvpn is getting from your service by upping the
verbosity to 3 while running openvpn manually like this:

$ sudo groupadd -rf qvpn
$ sudo sg qvpn -c 'openvpn --cd /rw/config/openvpn/ --config
openvpn-client.ovpn --verb 3'

You should see a message like this from openvpn, though the dns numbers
will probably be different:
PUSH: Received control message: PUSH_REPLY,dhcp-option DNS
1.2.3.4,dhcp-option DNS 1.2.3.5

...etc. This indicates that openvpn has received dns server info from
the vpn provider.

Another thing to check is whether those dns numbers got into the firewall:
$ sudo iptables -v -L -t nat

The chain PR-QBS should have two entries per dns address.

OTOH, if you want to bypass dhcp and use hard-coded dns numbers instead,
add them to your openvpn config file like this:

setenv vpn_dns '1.2.3.4 1.2.3.5'

Chris

--
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/6c455e5c-50a2-a5dd-770a-96a7ed681e7e%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] VPN ProxyVM rc.local

On 08/15/2016 10:49 AM, Paf LeGeek wrote:

I use the Debian 8 Template so the rc.local file is in the /etc/ folder not in
the /rw/ folder. As I said, the script works find if i launch it manually in my
ProxyVM terminal.

This is the content of my rc.local

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

groupadd -rf qvpn ; sleep 2s
sg qvpn -c 'openvpn --cd /etc/openvpn/ --config myopenvpnfile.ovpn \
--daemon --writepid /var/run/openvpn/openvpn-client.pid'

exit 0

The vpn doc was written for both Fedora and Debian templates. The
/rw/config/rc.local script is a Qubes feature that works on both. The
doc uses that location so users do not have to dedicate a whole template
to their vpn... /rw/config was designed for per-vm customizations such
as this.

Chris

--
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/55e32991-6f09-702c-b048-08360a2b6de2%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] VPN ProxyVM rc.local

2016-08-14 Thread Chris Laprise


On 08/14/2016 04:52 PM, Paf LeGeek wrote:

Hello !

I am trying to follow the steps in the link below to make a ProxyVpn with VPN 
autostart :
https://www.qubes-os.org/doc/vpn/

But my rc.local does not start on my ProxyVM.

I did the commands below on my Debian 8 Template VM :

sudo chmod +x /etc/rc.local
systemctl disable openvpn.service

The rc.local service is enable.

This is the result of ls -l :
user@debian-8-vpn:~$ ls -l /etc/rc.local
-rwxr-xr-x 1 root root 472 Aug 14 22:30 /etc/rc.local


If I start the rc.local with sudo sh /etc/rc.local using the terminal on my 
ProxyVM, it's working.

So, why my rc.local does not start automatically on my ProxyVM ?

Thanks for your help.


Hi,

The vpn doc indicates /rw/config/rc.local (in the proxy vm) not 
/etc/rc.local.


Chris

--
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/696aac79-0882-38a9-0f95-9da6e8747b77%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] howto add untrusted repository to appVM (without using seperate template)

2016-08-07 Thread Chris Laprise

On 08/07/2016 07:22 AM, Marek Marczykowski-Górecki wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, Aug 06, 2016 at 06:36:10PM -0700, Andrew David Wong wrote:

On 2016-08-06 18:05, emilcronja...@gmail.com wrote:

Hi there,

How do I add an outside/untrusted repository to an app-vm based on the
standard template, *without* changing the whole template? And/or how do I,
after succeding, install a program from the outside source in the appVM
and make the program survive reboot?

I guess this is a general question, although my problem is concerned with
the VoIP-program Jtisi: they are not included in neither Fedora or Debian
repos, and I would not like to add their "untrusted" repo only to the appVM
wich would actually run the program. (I know I could create a standalone
VM, but I prefer not to use 3 GB of space to run just one program :)).

SO: How to solve this? (Without jepoardizing my template-VM)

Best regards, E

PS: Why oh why is there no voip-client with zrtp-support in the
fedora/debian repos?!

You could do this by installing the program to some place in the AppVM that
survives reboot (e.g., the AppVM's home/ directory). Besides that, I can't
think of any way to satisfy all of your desiderata simultaneously. (You could
clone the TemplateVM, but you said you didn't want to create a StandaloneVM
because it would take up too much disk space, and a cloned TemplateVM would
take up roughly the same amount.)

I have similar problem with spotify - I don't want to include it in any
of my standard template, but on the other hand, I don't want to waste
disk space just for one VM. So I ended up with installing it at each VM
startup. Using this script:

#!/bin/sh

# 1. Add the Spotify repository signing key to be able to verify
# downloaded packages
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys
BBEBDCB318AD50EC6865090613B00F1FD2C19886

# 2. Add the Spotify repository
echo deb http://repository.spotify.com stable non-free | sudo tee
/etc/apt/sources.list.d/spotify.list

# 3. Update list of available packages
sudo apt-get update

# 4. Install Spotify
sudo apt-get -y install spotify-client xdg-utils libxss1 zenity

Since I don't restart this VM that often, I call this script manually,
just before starting spotify client itself (shell command history is
useful ;) ). But is should be enough to put it into /rw/config/rc.local.

Downsides:
- it downloads the packages each time; not a big problem for me, but
can be for others
- there is no spotify entry in the menu (needs to be started from
terminal)

First issue could be fixed by downloading deb files (apt-get -d) and
then installing them from a local directory (dpkg -i /rw/debs/*.deb).
But it will not automatically download new version.

The second issue can be fixed by creating the entry manually.

- --

I just wanted to point out a qualitative difference between Jitsi and
Spotify:

The former is used as a trusted component to protect the users' privacy
and probably security. Although that depends on how you're going to use
Jitsi, the question is posed in a way that suggests the app would be
used to maintain privacy.

So the relevant questions are: 1) Is the Jitsi repo signed, and if so...
2) How much do you trust the developers? If you trust them to keep your
communications private, you might also trust them enough to add their
repo to one or more templates.

You could also look for a "portable" version of the app; Such versions
don't require standard installation procedures and usually run from
whatever folder you place them in. Although Tor Browser is a portable
app from the start, for example, there are many examples of apps that
have been converted to portable, including Jitsi (for Windows):

https://sourceforge.net/projects/jitsiportable/

I wish Ring.cx had a portable version, too, as that app shows a lot of
promise... https://ring.cx

BTW, you can also just create a standalone appvm and add the Jitsi repo
to that.

PS: Why oh why is there no voip-client with zrtp-support in the fedora/debian
repos?!

I have wondered the same thing, myself. The best answer I can come up with is
that there is a wide gulf between the wave of privacy-minded users and the
curators of those distros. There are a growing number of privacy-enhancing apps
that are being ignored by the old guard.

Chris

--
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/49930d91-2a73-d318-ddd3-2184ccca60c5%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Yellow dot / guid crash in appvms

2016-07-31 Thread Chris Laprise


On 07/31/2016 04:32 PM, Marek Marczykowski-Górecki wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, Jul 31, 2016 at 04:19:50PM -0400, Chris Laprise wrote:

ErrorHandler: BadWindow (invalid Window parameter)
  Major opcode: 10 (X_UnmapWindow)
  ResourceID:   0xe7
  Failed serial number:  179
  Current serial number: 179

The above error sometimes results when I start a debian 8 appvm (I'm not
currently using fedora appvms so I don't know if the problem exists there
too). My app window will not appear until I run some other command in the vm
(at which point the vm status dot turns green).


I'll determine whether this error can be reproduced.

Looks like this issue:
https://github.com/QubesOS/qubes-issues/issues/2085

You're using KDE, aren't you? ;)

- -- 


In dom0, yes. I do also happen to have kde installed in the template 
(completely forgot about that), but I do get this error when starting 
gtk apps.


Chris

--
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/bff2411e-df41-4579-669e-e8e4c468c755%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Fedora 23 template upgrade conflict

2016-07-29 Thread Chris Laprise


On 07/29/2016 02:08 PM, 45uiay+8xfsofrot5g94 via qubes-users wrote:

Just did, still no luck. The update still presents the same error.




I had to use 'dnf clean all' before update would work.

Chris

--
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/158132a4-3174-ec27-971f-f0bfb9c09dc8%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes Security Bulletin #24 (Critical bug)

2016-07-28 Thread Chris Laprise


On 07/27/2016 04:27 PM, Andrew David Wong wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-07-26 20:01, Chris Laprise wrote:

On 07/26/2016 08:45 PM, el...@tutanota.com wrote:

What is best way to verify our system supports these things?

I think you can also check out the processor with Intel.. ark.intel.com
You can search through the different processors if you are looking to
pick up a new computer.


A guide I found at AMD:
http://support.amd.com/en-us/kb-articles/Pages/GPU120AMDRVICPUsHyperVWin8.aspx

  From Microsoft:
http://support.amd.com/en-us/kb-articles/Pages/GPU120AMDRVICPUsHyperVWin8.aspx

  Basically, anything recent that isn't too cost-reduced.

Chris


Chris, I think you may have accidentally pasted the same link twice.

- -- 


Sorry, didn't hit Ctrl-shift-V when I should ;)

Here's the MS link:
http://social.technet.microsoft.com/wiki/contents/articles/1401.hyper-v-list-of-slat-capable-cpus-for-hosts.aspx

Chris

--
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/e93fd151-1dc1-0c42-5977-d33534a3d61b%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes Security Bulletin #24 (Critical bug)

2016-07-26 Thread Chris Laprise


On 07/26/2016 08:45 PM, el...@tutanota.com wrote:

What is best way to verify our system supports these things?

I think you can also check out the processor with Intel..
ark.intel.com
You can search through the different processors if you are looking to pick up a 
new computer.



A guide I found at AMD:
http://support.amd.com/en-us/kb-articles/Pages/GPU120AMDRVICPUsHyperVWin8.aspx

From Microsoft:
http://support.amd.com/en-us/kb-articles/Pages/GPU120AMDRVICPUsHyperVWin8.aspx

Basically, anything recent that isn't too cost-reduced.

Chris

--
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/07b40854-c066-ca18-df47-715ad96505cc%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How to log all the websites accessed by a VM

2016-07-25 Thread Chris Laprise

On 07/25/2016 02:20 PM, Marek Marczykowski-Górecki wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, Jul 25, 2016 at 03:14:02PM -0300, Franz wrote:

ok now it works, it outputted a list of addresses. But I have to paste this
list on firewall rules of that VM and this is on Qubes Manager that is on
Dom0, so normal copy paste between VMs does not work.

I can only imagine of writing the addresses on a text file, then copying
the file to Dom0, using

qvm-run --pass-io 'cat /path/to/file_in_src_domain' >
/path/to/file_name_in_dom0

opening the file in Dom0 (which seems half prohibited) and finally copying
the adresses to Qubes Manager.

Otherwise I'll have to digit manually the addresses to Qubes Manager.

Which is the suggested way to do that?

Personally I do some thing like:
qvm-run --pass-io 'cat output-of-that-command'

Then copy selected lines into shell (those are ready commands to
add firewall entries).

- --

A less tedious method to get a somewhat similar effect is to install
'HTTPS Everywhere' extension in Firefox and turn on the "block all
unencrypted" feature. Then create some bookmarks for the (HTTPS) sites
you wish to use.

You can control it further by adding the 'Request Policy' extension and
use it to whitelist the 3rd party sites as you encounter them (the
extension will remember your choices).

Chris

--
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/9e5029f2-82b6-2c03-36d6-40d1bd181357%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] VPN Link Up, NetVM set to VpnVM but AppVMs still don't have net access?

2016-07-20 Thread Chris Laprise


On 07/20/2016 02:59 PM, gaikokujinkyofu...@gmail.com wrote:

On Saturday, July 16, 2016 at 5:09:48 PM UTC-4, gaikokuji...@gmail.com wrote:


I tried the 'sudo iptables -L -v -t nat' anyway and to be honest I am not sure 
I understand the output:

[user@VPN ~]$ sudo iptables -L -v -t nat
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
  pkts bytes target prot opt in out source   destination
 0 0 PR-QBS all  --  anyany anywhere anywhere
 0 0 PR-QBS-SERVICES  all  --  anyany anywhere 
anywhere

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
  pkts bytes target prot opt in out source   destination

Chain OUTPUT (policy ACCEPT 432 packets, 30668 bytes)
  pkts bytes target prot opt in out source   destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
  pkts bytes target prot opt in out source   destination
 0 0 ACCEPT all  --  anyvif+anywhere anywhere
 3   192 ACCEPT all  --  anylo  anywhere anywhere
12   812 MASQUERADE  all  --  anyany anywhere anywhere

Chain PR-QBS (1 references)
  pkts bytes target prot opt in out source   destination
 0 0 DNAT   udp  --  anyany anywhere 10.137.4.1 
  udp dpt:domain to:10.137.2.1
 0 0 DNAT   tcp  --  anyany anywhere 10.137.4.1 
  tcp dpt:domain to:10.137.2.1
 0 0 DNAT   udp  --  anyany anywhere 
10.137.4.254 udp dpt:domain to:10.137.2.254
 0 0 DNAT   tcp  --  anyany anywhere 
10.137.4.254 tcp dpt:domain to:10.137.2.254

Chain PR-QBS-SERVICES (1 references)
  pkts bytes target prot opt in out source   destination

Hi, I don't think I am using Network Manager to connect, that is I went only by 
the Qubes VPN wiki but while trying to diag the problem I read about 
/etc/resolv.conf in some other doc while searching so thought I'd try 
(obviously no luck).

As for the sudo sg qvpn -c ping whateversite, does returning one thing back and 
hanging count for anything? I am thinking not as I am not able to connect to 
the net via the VpnVM.

Any thoughts on the DNS dnat rules?


Pinging from my vpn vm is probably the same as yours, now that I've 
checked it: I get a DNS response but the pings themselves aren't permitted.


I think the real problem is shown in your PR-QBS chain above. You see 
that the 'to' addresses on the right are still pointing to a Qubes 
internal subnet '10.137.x.x'. Something about the DHCP fetching of your 
DNS servers or the way qubes-vpn-handler.sh is executing is not working. 
You can verify this by taking the IP address for 'whateversite' and 
pinging it from your appvm (connected to vpn vm)... that should work 
even though DNS doesn't.


Cause of the problem should be a misconfigured .ovpn (the 3 lines for 
scripting) or the qubes-vpn-handler.sh script itself can't execute 
because the execute flag is not set, or the shebang at the start was 
left out, etc.


Chris

--
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/94a81cf2-db21-4c66-40d1-64837a477831%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Unable to update templates

2016-07-20 Thread Chris Laprise


On 07/20/2016 01:20 PM, jkitt wrote:
My netvm is a proxyvm that I've set up. I've just found out about the 
global in which the updatevm can be changed. However, i've set this to 
my VPN VM yet nothing - it's still trying to connect to the same IP. 
IRRC that IP is a non-existent node but it's filtered by a proxy. How 
do i get that proxy running on my VPN VM?


Its typical for a VPN to block template updates. This is because the 
update proxy normally runs in sys-net, which can no longer see the 
attempt to connect to the update proxy port number (sys-net only sees 
encrypted stream from VPN).


Quick workaround is to set your connection so it looks like: Template -> 
sys-firewall -> sys-net.



Chris

--
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/91f7890d-d110-e228-f9b0-fe0bc249cafd%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Setting up OpenVPN (Can't understand documentation)

2016-07-17 Thread Chris Laprise


On 07/17/2016 04:26 AM, ajshdas7...@sigaint.org wrote:

Under "Using iptables and openvpn" @ https://www.qubes-os.org/doc/vpn/

It says to create the proxyvm, but it does not say if the following steps
should be taken in the template or in the proxyvm. Does anyone know?



That part should be clearer. However, the intent is to setup the proxyvm.

Chris

--
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/3aec5d45-5e21-56ad-1f9a-e3181a5563bc%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] AEM with Linux 4.4 causes hard reboot (cont... Trying to resolve issue)

On 07/15/2016 10:09 PM, Todd Lasman wrote:

On 07/15/2016 04:38 PM, Chris Laprise wrote:

On 07/15/2016 09:33 AM, Chris Laprise wrote:

On 07/13/2016 11:15 AM, Chris Laprise wrote:

I am able to get 4.4.* to boot now! The trick was to add
'min_ram=0x200' to the tboot options like I used to do--the AEM
README describes how.

But now I cannot get AEM to seal the secret. Nothing at all about
AEM is displayed during startup, even though rd.antievilmaid is on
the kernel options line.

Chris

For the record, AEM is now working on my system. The other thing
that was required was to update the anti-evil-maid package to
version 3.0.3.

Chris

@Andrew, Todd Lasman...

Could one/both of you try this out ...please? :D Especially the
tboot workaround; It only requires pressing 'e' at the grub prompt
and adding the parameter to the multiboot tboot line (then press
Ctrl-x to boot).

It would be good to see if this works on other machines before either
closing the issue[1] or inquiring upstream.

Thanks,
Chris

1. https://github.com/QubesOS/qubes-issues/issues/2155

Will do, Chris. Thanks for working this out. May take a few days to
get to this, though. I'll report back.
By the way, where did you get the aem 3.0.3 package? I've only got
3.0.2 available.

Todd

Cool. Try this:

sudo qubes-dom0-update anti-evil-maid --enablerepo=qubes*testing

Chris

--
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/12a46ee5-6163-3fad-edb9-9b7acc1a2a4d%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] AEM with Linux 4.4 causes hard reboot (cont... Trying to resolve issue)


On 07/15/2016 09:33 AM, Chris Laprise wrote:


On 07/13/2016 11:15 AM, Chris Laprise wrote:


I am able to get 4.4.* to boot now! The trick was to add 
'min_ram=0x200' to the tboot options like I used to do--the AEM 
README describes how.


But now I cannot get AEM to seal the secret. Nothing at all about AEM 
is displayed during startup, even though rd.antievilmaid is on the 
kernel options line.


Chris



For the record, AEM is now working on my system. The other thing that 
was required was to update the anti-evil-maid package to version 3.0.3.


Chris



@Andrew, Todd Lasman...

Could one/both of you try this out ...please? :D  Especially the tboot 
workaround; It only requires pressing 'e' at the grub prompt and adding 
the parameter to the multiboot tboot line (then press Ctrl-x to boot).


It would be good to see if this works on other machines before either 
closing the issue[1] or inquiring upstream.


Thanks,
Chris

1. https://github.com/QubesOS/qubes-issues/issues/2155

--
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/25ec3d4f-17cb-32a9-01b9-8a30c0150fe4%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Question on DMA attacks

On 07/15/2016 02:43 PM, Andrew David Wong wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-07-15 01:46, Marek Marczykowski-Górecki wrote:

On Thu, Jul 14, 2016 at 07:22:28PM -0700, neilhard...@gmail.com wrote:

From the user FAQ:
https://www.qubes-os.org/doc/user-faq/#can-i-install-
qubes-on-a-system-without-vt-d "an attacker could always use a simple DMA
attack to go from the NetVM to Dom0"
So what does this mean though..?
Can they launch this DMA attack from a compromised App VM..?
Could they simply do a browser exploit in an App VM, and then do a DMA
attack from there to go to dom0..?
Or is it a lot harder than that..?
I'm just trying to work out whether it's really worth buying a new laptop
just to get VT-D I currently have VT-X, but not VT-D.

DMA is mechanism for PCI devices to access system memory (read/write).
Without VT-d any PCI device can access all the memory, regardless to which
VM is assigned (or left in dom0). Most PCI devices allow driver to request
arbitrary DMA operation (like "put received network packets at this
address in memory", or "get this memory area and sent to the network").
So, without VT-d, it gives unlimited access to the whole system. Now, it
is only a matter of knowing where to read/write to take over the system,
instead of just crashing. But since you can read the whole memory, it
isn't that hard.

Now, how it applies to Qubes OS? The above attack requires access to PCI
device. Which means that can be performed only from NetVM / UsbVM, so
someone must first break into one of those VMs. But it isn't that hard,
because there is a lot of complex code handling network traffic. Recent
bugs includes DHCP client, DNS client etc. Most of attacks on NetVM / UsbVM
(but not all!) requires being somehow close to the target system - for
example connected to the same WiFi network, or in case of UsbVM, having
physical acccess to some USB port.

But, just exploiting a browser in an AppVM isn't enough, as normal AppVM do
not have any PCI device assigned (unless you do that manually).

Clear and lucid answer, as always. Thanks, Marek! Added to the FAQ:

https://github.com/QubesOS/qubes-doc/commit/45cffd68543447c81d9922572d52e408b7ff
5e65

IIRC, this point may be covered by Joanna's blog post re: 'What makes
Qubes different from ...?'

The main website does sort of lack a concise rundown of Qubes' main
advantages, such as:

* Simple and strong isolation mechanism, instead of complex permissions
in monolithic kernels
* Safe virtualization of software components that normally expose
regular hypervisors to exploits (i.e. graphics, copy+paste)

* Window manager that reliably reflects the security context of running apps
* Hardware virtualization of risky interfaces such as NICs and USB
* Overall philosophy of 'protect the core system and non-networked VMs';
remotely exploited VMs stay contained ('game over' situation unlikely)

Plus secondary advantages:
* Template system
* Disposable VMs
* AEM
* Trusted document 'sanitizing'
* Flexible use of anon networks (Tor, etc.)

Chris

--
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/af563412-101d-1ab2-f7e4-aa94d34712d7%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] VPN Link Up, NetVM set to VpnVM but AppVMs still don't have net access?

On 07/15/2016 01:26 PM, gaikokujinkyofu...@gmail.com wrote:

On Thursday, July 14, 2016 at 5:50:52 PM UTC-7, Chris Laprise wrote:

On 07/13/2016 12:36 PM, gaikokujinkyofu...@gmail.com wrote:

Hi, with quite a bit of help (thanks again) I was able to setup a VpnVM and
have it work perferctly as a NetVM for AppVMs with KDE as my desktop env. I
then backed up (zipped) the /rw/config dir and reinstalled 3.1 with just xfce,
recreated the VpnVM and put all the needed vpn files from the config
dir/sub-dir in thier place. I set an AppVM to use the VpnVM as a NetVM and
started up the VpnVM, it seems to start up fine, I get the little notification
that the VPN is up, but I can't connect to anything. I have also tried, instead
of using backed up config file to just recreate everything from scratch, got
the VPN notification/confirmation that its up and running, but still couldn't
access the net. I can access the net when using the firewall as the netvm
though? I am not sure how to diagnose this further, thoughts suggestions would
really be apprecaited!

I would start troubleshooting by opening a CLI in the appvm, and also in
sys-firewall: In each CLI try pinging a known server using domain name
(first) and then IP address (second). This should tell you whether the
blockage is complete or only DNS related.

Chris

ah that was a good idea. Well it seems to be DNS related in the VpnVM as I am
able to ping a site/ip address from the firewallVM and ping an IP from in the
VpnVM but not a site name. I am not sure why that would be though since as far
as I can tell everything is the same as it was in the previous setup (obviously
not I guess). It seems to netmanager is setting a DNS other than what my VPN
provider normally sets? I tried manually editing the /etc/resolv.conf file but
that didn't seem to help (automatically generated?) so am not sure where to go
from here?

Hopefully you are not using Network Manager to connect... That would
only interfere with the script-based method described in the doc.

The qubes-vpn-handler ignores resolv.conf, but you can edit the latter
to test domain names within the vpn vm. Remember, in the vpn vm you will
need to prefix your ping commands with 'sudo sg qvpn -c' to get past the
firewall.

If you do this and pinging site names works (in the vpn vm), then the
problem may be with DNS dnat rules. After connecting, you can check
those with 'sudo iptables -L -v -t nat'. You should see the appropriate
DNS server IPs there (4 rules).

Chris

--
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/3bd1af94-2560-fa66-fde8-2b236551e53b%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Is there any debugging in the Qubes 3.2-r1 installer?


On 07/15/2016 01:55 PM, Achim Patzner wrote:

Hi!


As I'm not getting the install image to boot into the installer (it is
dropping me into dracut), is there any debug version that could collect
debug information in a convenient way? Alternatively: Could the
installation process be launched from a running Qubes 3.1 installation
(e. g. as VM, getting access to the destination disk)?



Achim



Do you see any message about saving an rdsos log? I got that when the 
installer dropped me to a CLI.


In that case, the problem was an inability to continue accessing the USB 
stick containing the installer, because of a bug in a rarely used 
storage module. The workaround was to burn the installer image to DVD 
and run it from that.


Chris

--
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/7772f3d6-29b8-16c7-cd8e-01905dd2290d%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] AEM boot option causes hard reboot/partial shutdown (Lenovo T450s)

On 07/13/2016 11:15 AM, Chris Laprise wrote:

On 07/12/2016 11:15 AM, Chris Laprise wrote:

On 07/12/2016 01:48 AM, Chris Laprise wrote:

On 07/05/2016 02:21 PM, Marek Marczykowski-Górecki wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, Jul 04, 2016 at 10:26:51AM -0400, Chris Laprise wrote:
If I replace the kernel with 4.1 from R3.1, it can make it to the
AEM target
and the decrypt prompt. It chokes just after decrypting the
volumes, but
that's to be expected. The 4.4 kernel appears to introduce some
factor that

causes the crash.

Interesting, have you tried 4.2 kernel from R3.1 unstable repository?
Do you have any means of collecting kernel/xen messages? I guess
you've

already disabled "quiet" kernel option and also removed "console=none"
from xen cmdline.
If this doesn't help, try adding "noreboot" and "sync_console" to
xen cmdline.

If you have serial console (on docking station?) if would be easier to
reliably get log messages.

- --

I just tried the 4.2 kernel on the stick created by AEM under
R3.2rc1; It seems to work as well as 4.1.

I'll try 4.4 again removing those boot options.

Unfortunately, the only docking station here is the kind lacking
serial ports.

Chris

A bit more info:

Removing rd.antievilmaid from 4.4.12 options doesn't help; it still
restarts. I also tried 4.4.14 in the unstable repo but that did not
help.

It appears to be an incompatibility between kernel version 4.4 and
tboot.

Chris

I am able to get 4.4.* to boot now! The trick was to add
'min_ram=0x200' to the tboot options like I used to do--the AEM
README describes how.

But now I cannot get AEM to seal the secret. Nothing at all about AEM
is displayed during startup, even though rd.antievilmaid is on the
kernel options line.

Chris

For the record, AEM is now working on my system. The other thing that
was required was to update the anti-evil-maid package to version 3.0.3.

Chris

--
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/045a8d25-acd2-86f7-719f-b1cda382484d%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Changing swap. /etc/fstab cant be edited

2016-07-14 Thread Chris Laprise

On 07/14/2016 05:43 PM, Facundo Curti wrote:

Hi list.

I'm having troubles to start qubes. When I start it says that a
partition is being used by a process.

As I was reading:
https://forums.opensuse.org/showthread.php/503587-Slow-boot-What-is-quot-A-start-job-is-running-for-dev-disk-by-quot
https://bbs.archlinux.org/viewtopic.php?id=161814
https://bbs.archlinux.org/viewtopic.php?id=196083

It is a problem in the swap partition, a bad configuration on /etc/fstab.
Recently I resized it... So the UUID should be changed

now I'm trying to edit /etc/fstab, but for some reason, I just can do
that chrooting the system (not just mount). When I mount the disk,
/etc/fstab is almost empty.

Anyway, I do that. But I still can not boot.

Here is my /etc/fstab:

# /etc/fstab
# Created by anaconda on Fri Jul 8 23:45:42 2016
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more
info

#
/dev/mapper/luks-1d18c3c1-3456-420e-86d9-83c5aab56904
/ ext4 defaults,x-systemd.device-timeout=0 1 1
UUID=8ac79b31-fdfe-4c2d-b6da-8e91f12b0518 /boot
ext4defaults1 2

/dev/mapper/cryptedSwap swapswap
defaults,x-systemd.device-timeout=00 0

#/dev/mapper/luks-7a2436b4-6f22-46e6-b9d4-fc72b0913d17
swapswap defaults,x-systemd.device-timeout=0 0 0

And here is my /etc/crypttab
-
luks-1d18c3c1-3456-420e-86d9-83c5aab56904
UUID=1d18c3c1-3456-420e-86d9-83c5aab56904 none
cryptedSwap /dev/disk/by-partuuid/0319b6a9-5470-49b6-84ef-eac0f91546a0
/dev/urandomswap,cipher=aes-cbc-essiv:sha256,size=256

I made the swap according this guide:
https://wiki.archlinux.org/index.php/Dm-crypt/Swap_encryption#Without_suspend-to-disk_support

But the error persist :/

The system starts in emergency mode

Some ideas plz?
--

Idea: You did not refresh your initramfs or grub.conf after making the
changes in fstab/crypttab. :)

If you can drop to a CLI when the boot process fails, maybe you can
decrypt the root partition, mount and chroot into it. Next, mount boot
partition at /boot, verify fstab and crypttab are correct and then run
the tools to refresh your boot partition. IIRC, they would be 'dracut
-H' and 'grub2-mkconfig -o /boot/grub2/grub.cfg'.

Chris

--
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/8d0a0013-37a4-85ba-c453-812f0ace9ca7%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Firewall rules

2016-07-14 Thread Chris Laprise

On 07/14/2016 04:51 PM, katerim...@sigaint.org wrote:

On 07/14/2016 10:39 AM, katerim...@sigaint.org wrote:

Good day
I'm using a VPN in sys-net and would setup firewall rules to stop
internet
connection if VPN crash. In sys-net isn't possible to insert ip
addresses,
then I did it in sys-firewall. With some tests I saw that if VPN
disconnect suddenly, sys-net finds my wifi network and doesn't break the
connection, as I would. How can I solve this? (in the proxyVMs all work
well)

Thank you

Take a look at https://www.qubes-os.org/doc/vpn/

For leak protection and security it is best to set up a vpn client in a
proxy vm, between sys-net and the appvms. You can follow the
instructions from the doc "Using iptables and openvpn", or use the
firewall script as an example. The two critical commands that prevent
leaks (in the proxy vm configuration) are:

iptables -I FORWARD -o eth0 -j DROP
iptables -I FORWARD -i eth0 -j DROP

This means that no forwarding can take place involving the
upstream/clearnet interface eth0, so the only way out is through the vpn
tunnel.

Chris

Hi Chris
Thank you for the explanation, I want to know if I can use firewall tab in
sys-net (or sys-firewall) like I have done in proxyVM because I have also
a VPN in sys-net. If it isn't possible, do I change ip tables in sys-net
while in all the other proxyVMs I use firewall tab?

Regards

The firewall tab (in any vm) is not a good place to add this restriction
even if it did accept that kind of rule (which it does not). The best
way is to run the vpn client in a separate proxy vm, and set the
firewall rules with the qubes-firewall-user-script in that vm as shown
in the doc.

You can try to use qubes-firewall-user-script in the netvm, but I think
this approach is untested. Of course, by Qubes standards it is insecure.

Chris

--
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/86dd7246-b123-92ea-7430-076d4d2599ef%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Firewall rules

2016-07-14 Thread Chris Laprise

On 07/14/2016 10:39 AM, katerim...@sigaint.org wrote:

Good day
I'm using a VPN in sys-net and would setup firewall rules to stop internet
connection if VPN crash. In sys-net isn't possible to insert ip addresses,
then I did it in sys-firewall. With some tests I saw that if VPN
disconnect suddenly, sys-net finds my wifi network and doesn't break the
connection, as I would. How can I solve this? (in the proxyVMs all work
well)

Thank you

Take a look at https://www.qubes-os.org/doc/vpn/

iptables -I FORWARD -o eth0 -j DROP
iptables -I FORWARD -i eth0 -j DROP

This means that no forwarding can take place involving the
upstream/clearnet interface eth0, so the only way out is through the vpn
tunnel.

Chris

--
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/97718377-07be-93f8-4832-ec4c3baeda8a%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] AEM boot option causes hard reboot/partial shutdown (Lenovo T450s)

2016-07-13 Thread Chris Laprise

On 07/12/2016 11:15 AM, Chris Laprise wrote:

On 07/12/2016 01:48 AM, Chris Laprise wrote:

On 07/05/2016 02:21 PM, Marek Marczykowski-Górecki wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

causes the crash.

Interesting, have you tried 4.2 kernel from R3.1 unstable repository?
Do you have any means of collecting kernel/xen messages? I guess you've
already disabled "quiet" kernel option and also removed "console=none"
from xen cmdline.
If this doesn't help, try adding "noreboot" and "sync_console" to
xen cmdline.

If you have serial console (on docking station?) if would be easier to
reliably get log messages.

- --

I just tried the 4.2 kernel on the stick created by AEM under
R3.2rc1; It seems to work as well as 4.1.

I'll try 4.4 again removing those boot options.

Unfortunately, the only docking station here is the kind lacking
serial ports.

Chris

A bit more info:

Removing rd.antievilmaid from 4.4.12 options doesn't help; it still
restarts. I also tried 4.4.14 in the unstable repo but that did not help.

It appears to be an incompatibility between kernel version 4.4 and tboot.

Chris

I am able to get 4.4.* to boot now! The trick was to add
'min_ram=0x200' to the tboot options like I used to do--the AEM
README describes how.

But now I cannot get AEM to seal the secret. Nothing at all about AEM is
displayed during startup, even though rd.antievilmaid is on the kernel
options line.

Chris

--
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/94a77415-079f-fd21-78e1-766c0ab3303e%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Multi-drive computers installation

2016-07-13 Thread Chris Laprise


On 07/12/2016 08:35 PM, Drew White wrote:

Has anyone been able to install Qubes on a multi-drive PC as a multi-drive PC 
without having all drives formed into 1 yet?



Anaconda always seems to mess up when I manually setup partitions. But 
both LVM and Btrfs will let you expand volumes into other partitions 
after installation. The trick is to luks encrypt the partitions first, 
preferably using the same passphrase as your initial volume. Then you 
adjust your crypttab and update grub.conf with the new additions. The 
downside is your kernel options line can get very very long.


Chris

--
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/b27e6dbb-d716-1e5c-feaa-406d32d9cd23%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Buying new laptop.. What check should I do in-store..?

2016-07-12 Thread Chris Laprise


On 07/12/2016 08:04 PM, neilhard...@gmail.com wrote:

Is it worth checking for a BIOS compatible with coreboot or libreboot, or some 
kind of open source BIOS..?

Is it true that if I have a Intel ME processor, but a motherboard that isn't 
compatible.. that at least this prevents network access to Intel ME...? For 
example, in my current laptop, there is no mention of Intel ME in the BIOS at 
all..

etc etc

So yeah, just looking for as many different compatibility checks as possible.



IMO most laptops sitting "in a store" are pretty awful. They usually 
represent the most cost-reduced models of their line, leaving out things 
like Vt-d/IOMMU and a TPM. Still, a trip with a Qubes disk could be 
educational.


I think you named the main points to look for.

You may also want to consider the Librem, which is certified as Qubes 
compatible.


Chris

--
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/c022d15a-3584-0264-c704-01eca4ca4b3c%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] AEM boot option causes hard reboot/partial shutdown (Lenovo T450s)

2016-07-12 Thread Chris Laprise

On 07/12/2016 01:48 AM, Chris Laprise wrote:

On 07/05/2016 02:21 PM, Marek Marczykowski-Górecki wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, Jul 04, 2016 at 10:26:51AM -0400, Chris Laprise wrote:
If I replace the kernel with 4.1 from R3.1, it can make it to the
AEM target
and the decrypt prompt. It chokes just after decrypting the volumes,
but
that's to be expected. The 4.4 kernel appears to introduce some
factor that

causes the crash.

If you have serial console (on docking station?) if would be easier to
reliably get log messages.

- --

I just tried the 4.2 kernel on the stick created by AEM under R3.2rc1;
It seems to work as well as 4.1.

I'll try 4.4 again removing those boot options.

Unfortunately, the only docking station here is the kind lacking
serial ports.

Chris

A bit more info:

Removing rd.antievilmaid from 4.4.12 options doesn't help; it still
restarts. I also tried 4.4.14 in the unstable repo but that did not help.

It appears to be an incompatibility between kernel version 4.4 and tboot.

Chris

--
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/85ff2024-584d-a10a-d91d-70c6a5aff820%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] AEM boot option causes hard reboot/partial shutdown (Lenovo T450s)

2016-07-11 Thread Chris Laprise

On 07/05/2016 02:21 PM, Marek Marczykowski-Górecki wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, Jul 04, 2016 at 10:26:51AM -0400, Chris Laprise wrote:

If I replace the kernel with 4.1 from R3.1, it can make it to the AEM target
and the decrypt prompt. It chokes just after decrypting the volumes, but
that's to be expected. The 4.4 kernel appears to introduce some factor that
causes the crash.

If you have serial console (on docking station?) if would be easier to
reliably get log messages.

- --

I just tried the 4.2 kernel on the stick created by AEM under R3.2rc1;
It seems to work as well as 4.1.

I'll try 4.4 again removing those boot options.

Unfortunately, the only docking station here is the kind lacking serial
ports.

Chris

--
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/7e3ad0a9-8e49-7de8-1aa9-20898f3d6bba%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes-users forum - Please, moderate this guy

2016-07-09 Thread Chris Laprise


On 07/09/2016 08:17 AM, Gorka Alonso wrote:

https://groups.google.com/d/msg/qubes-users/V8_SvMk0yx0/P4VNTpFnBQAJ

"Achim. Don't forget YOU are the homosexual, NOT ME. That's a mental disease, 
doesn't matter if for political reasons was removed or not from disease list."

Even me, being heterosexual, feel offended with this attitude.



I agree.

Chris

--
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/80af9b5a-8c3b-77ea-044a-db5546b17ee6%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Template installation not being reflected on AppVMs

2016-07-08 Thread Chris Laprise


On 07/08/2016 07:27 PM, danmichaels8...@gmail.com wrote:

I am using QUBES 3.0
Fedora-21

When I install certain programs in the template VM for fedora, they do not show 
up in the AppVMs, even after restarting each of the AppVMs.

I installed google-chrome-stable, and yet, it's not reflected in the AppVMs.

I have to re-install Chrome inside the actual AppVM every time I start it up.

What's up with that...?



Did you shutdown the template vm before re-starting the appvms?

Chris

--
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/8f83f5f6-0d9b-7ab5-723e-3a32405092cc%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes top priorities suggestions for me as an user.

2016-07-08 Thread Chris Laprise


On 07/08/2016 12:27 AM, raahe...@gmail.com wrote:

I'm also confused,  you say gpus are so insecure and that qubes is not doing 
enough to isolate them?
I don't think that's what I implied. But trying to be concise on a 
complex subject can leave some people with the wrong impression, so I 
apologize if I've left out too much.


Two issues with GPUs I'm assuming are that they represent a target for 
malware (being a large computing resource), and also that when we try to 
isolate them most do not respond well to bus commands that enable things 
like passthrough (i.e. they do not 'behave' in IOMMU isolation). 
Passthrough is also clunky, requiring at least another display output. 
GPU virtualization is another way for domU apps to access GPU functions, 
and it shouldn't require separate displays or secondary graphics chips.



Excuse me for being noob but doesn't qubes not allow most gpu functions to go 
past dom0.


AFAIK, Qubes doesn't allow any GPU functions whatsoever from domU into 
dom0. Qubes graphics are virtualized in a 2D, non-accelerated way. 
Having limited developer resources, that is a good first step to making 
the system secure and I'm glad it works that way--for now. But I also 
realize that needs to be a transitional phase and to not remain the 
status quo.


Graphics vendors are currently demonstrating GPU virtualization 
technology that would make GPU utilization safe, inviting developers to 
use it. ITL says this would take a lot of developer effort, however.



And so you would rather have them in domu domains with similar isolation as 
the netcard vm (which has no choice)  and you would feel that more secure?  I'm 
no expert so dont' know if thats true.  If not would even having the ability on 
machine make me more vulnerable even if not applying it myself?  excuse my 
noobness.


Hmmm, no. I think the choice is to either leave the GPU in a privileged 
domain such as dom0 and employ GPU virtualization to allow safe access 
from domUs, or to improve in some way the current (impractical) practice 
of isolating secondary graphics cards in domUs so that they actually 
work when they're properly isolated.



Most people also dont' have two gpus in their machine, which you imply would be 
the most secure way to use this feature?  Only people I know of that do are 
gamers.  If you do graphic designing and need to use special professional 
programs that require gpu processing I would recommend using a separate 
computer.  But it seems this might be a feature in the future on Qubes.  I 
wouldn't call it a priority though.


A lot of people have two GPUs and don't realize it. Even so, its not 
like we are talking about great expense here: Even having access to 
weaker GPUs could make a big difference in Qubes' power and usability.



I think Qubes is fine for normal everyday users doing everyday tasks for home 
and office use.  I can still edit photos, watch movies, create greeting cards, 
view almost any webpage.  Only thing I can't do is play video games.  And thats 
fine I have another machine for that, since i consider playing video games one 
of the most dangerous things you can do online anyways.


Projecting our own personal routines on the issue will probably not be 
of much help. And I think I've already made the case against framing 
this as a games issue; I'd urge the community not to look down its nose 
on graphics in this way or we will find the world of graphics can stare 
back at us more sharply. If it gets to the point where OpenBSD is 
recommended over Qubes because the latter "can't do much" and "lack of 
GPU virtualization sounds pretty insecure" then I think we'll be in real 
trouble. :)



Its nice that you have so much faith in Qubes and that it can stop all attacks, but that 
is unrealistic.  There is still always danger when doing untrusted tasks even when using 
Qubes, even with its hardware isolation.  People should realize what.  Qubes themselves 
describe it as "somewhat" secure, meaning much better then a traditional os,  
but nothing is 100%.


That is always a factor no matter what we do with Qubes. But it seems to 
me that the simple Qubes interfaces have already been used to enable 
some pretty complex functionality "securely". I don't think it follows 
that accessing GPUs through them necessarily incurs unacceptable risk; 
but even if this is a possibility, it requires further investigation. 
Since GPU manufacturers now have an incentive to not appear as an 
element that undermines security (hence, the GPU virtualization 
initiatives they're taking) there is a good chance that some reasonably 
secure accommodation can be made for primary graphics.


The alternative is to endow Qubes systems with secondary graphics that 
work nicely with passthrough. Currently, users can experiment with this 
in a piecemeal fashion and likely meet with failure.


Chris

--
You received this message because you are subscribed t

Re: [qubes-users] Qubes top priorities suggestions for me as an user.

2016-07-07 Thread Chris Laprise




On 07/07/2016 12:45 PM, Duncan Guthrie wrote:


On 7 July 2016 16:53:35 BST, Chris Laprise <tas...@openmailbox.org> wrote:

On 07/07/2016 10:40 AM, Duncan Guthrie wrote:

On 7 July 2016 03:28:48 BST, Chris Laprise <tas...@openmailbox.org>

wrote:

On 07/06/2016 09:42 PM, raahe...@gmail.com wrote:

I'm not so adamant about wanting gpu passthrough on qubes,  cause

imo,  gaming online usually means all security is out the window.

Plus

I feel as though gpu is much bigger attack surface for side channel
attacks then net card.  I could be wrong because I have no clue

about

low level stuff, but I feel it would somehow undermine purpose of

using

qubes.  Maybe I'm wrong.

I think this is wrong because many kinds of apps rely on GPUs now:
Media
decoding and creation, 3D design and printing (I would love to have
even
just SketchUp on Qubes!), and any other responsive 3D interface that
app
designers want to offer. This even includes web pages,

crypto-currency,

and many scientific apps. GPUs are now general processing engines

that

embody MOST of a typical computer's processing power.

This is not about games.


I think this is wrong. Most heavy computer users work in offices and

do word processing and spreadsheets, the 'average' casual use is
generally web browsing and light media consumption.

Qubes works fine for using Libreoffice, web applications and social

media, and programming e.g. in Python. Graphics designers can use GIMP
or InkScape, or any of the Windows programs that they commonly use.

It is true that you won't be able to use 3D applications like

SketchUp, but I do not think such tasks constitute most of the average
workload as you say. Perhaps they make up most of your workload, but I
don't think that you speak for everyone here. I have found Qubes works
for me, and people I know do similar tasks on their computers.

Furthermore, there is no getting around the fact that visual

rendering

is integral to security. The GPU can see any private info that you

can,

and if compromised can take steps to trick users into sabotaging

their

own privacy and security. Like the CPU, the GPU must be accepted as

a

core component of trust, and protected as such... at least any GPU

that

operates the admin and trusted domains.

It is fortunate that we at least have a trend of integrated GPUs (in
APUs) where the GPU is manufactured into the same package as the
(implicitly) trusted CPU. For the time being, this is a boost to

Qubes'

compatibility and security even if the GPUs are under-utilized.

For Qubes to either 1) give up on GPU support, or 2) relegate them

to

untrusted status would be an _irretrievable_ error in judgment. It
would
make the OS a 21st century terminal application, because the lions
share
of the power expected by PC users would be missing (as it is
currently).

Chris


I dispute this argument. Dropping "GPU support" (I am not sure where

you get this impression) is hardly going to make Qubes a terminal
application. You can use anything that uses 2D graphics, and can play
music and movies, and do word processing, and email, and software
development, and... The list goes on. Qubes is about security, and
allowing such high level access for the GPU is a terrible compromise.

I am not proposing that domUs have direct access to graphics systems
operating in dom0. GPU access needs to be properly virtualized, and
thankfully some groundwork by Intel (and probably others) has been laid

for it. Alternately, a specification for well-behaving discrete
graphics
could make graphics passthrough a realistic option for many people.

Marek has already stated that any domU used for primary graphics (as
unrealistic as that may be, given the state of passthrough
compatibility) will be a trusted one, and that the purpose of such an
implementation would be to facilitate the use of Linux graphics drivers

while the rest of the OS slims down and experiments with microkernel
admin and storage vms.

The current state is, of course, one of trusting the GPU. That poses a
problem for those who want both discrete graphics and anti-tampering
(AEM) but otherwise? I don't see the compromise you mention.


What are you suggesting then? You are criticising Qubes for not having good GPU 
support, but recognise that you can't have good security when GPU has access to 
hardware? I am sorry but I don't understand your point fully, and would 
appreciate it if you could elaborate further. What is your solution, do you 
want there to be virtualised domains for GPU? If I remember correctly, this is 
a feature being worked on.


Qubes doesn't have good GPU support; It is a work in progress on many 
fronts.


I mentioned that it could go in the direction of GPU virtualization or 
better passthrough support, or both. In either case, there would still 
be a protected primary graphics card that would at least render dom0 and 
other trusted domains. But with the former, the primary graphics can 
also s

Re: [qubes-users] Qubes top priorities suggestions for me as an user.

2016-07-07 Thread Chris Laprise


On 07/07/2016 10:40 AM, Duncan Guthrie wrote:


On 7 July 2016 03:28:48 BST, Chris Laprise <tas...@openmailbox.org> wrote:

On 07/06/2016 09:42 PM, raahe...@gmail.com wrote:

I'm not so adamant about wanting gpu passthrough on qubes,  cause

imo,  gaming online usually means all security is out the window.  Plus
I feel as though gpu is much bigger attack surface for side channel
attacks then net card.  I could be wrong because I have no clue about
low level stuff, but I feel it would somehow undermine purpose of using
qubes.  Maybe I'm wrong.

I think this is wrong because many kinds of apps rely on GPUs now:
Media
decoding and creation, 3D design and printing (I would love to have
even
just SketchUp on Qubes!), and any other responsive 3D interface that
app
designers want to offer. This even includes web pages, crypto-currency,

and many scientific apps. GPUs are now general processing engines that
embody MOST of a typical computer's processing power.

This is not about games.


I think this is wrong. Most heavy computer users work in offices and do word 
processing and spreadsheets, the 'average' casual use is generally web browsing 
and light media consumption.
Qubes works fine for using Libreoffice, web applications and social media, and 
programming e.g. in Python. Graphics designers can use GIMP or InkScape, or any 
of the Windows programs that they commonly use.
It is true that you won't be able to use 3D applications like SketchUp, but I 
do not think such tasks constitute most of the average workload as you say. 
Perhaps they make up most of your workload, but I don't think that you speak 
for everyone here. I have found Qubes works for me, and people I know do 
similar tasks on their computers.


Furthermore, there is no getting around the fact that visual rendering
is integral to security. The GPU can see any private info that you can,

and if compromised can take steps to trick users into sabotaging their
own privacy and security. Like the CPU, the GPU must be accepted as a
core component of trust, and protected as such... at least any GPU that

operates the admin and trusted domains.

It is fortunate that we at least have a trend of integrated GPUs (in
APUs) where the GPU is manufactured into the same package as the
(implicitly) trusted CPU. For the time being, this is a boost to Qubes'

compatibility and security even if the GPUs are under-utilized.

For Qubes to either 1) give up on GPU support, or 2) relegate them to
untrusted status would be an _irretrievable_ error in judgment. It
would
make the OS a 21st century terminal application, because the lions
share
of the power expected by PC users would be missing (as it is
currently).

Chris


I dispute this argument. Dropping "GPU support" (I am not sure where you get 
this impression) is hardly going to make Qubes a terminal application. You can use 
anything that uses 2D graphics, and can play music and movies, and do word processing, 
and email, and software development, and... The list goes on. Qubes is about security, 
and allowing such high level access for the GPU is a terrible compromise.


I am not proposing that domUs have direct access to graphics systems 
operating in dom0. GPU access needs to be properly virtualized, and 
thankfully some groundwork by Intel (and probably others) has been laid 
for it. Alternately, a specification for well-behaving discrete graphics 
could make graphics passthrough a realistic option for many people.


Marek has already stated that any domU used for primary graphics (as 
unrealistic as that may be, given the state of passthrough 
compatibility) will be a trusted one, and that the purpose of such an 
implementation would be to facilitate the use of Linux graphics drivers 
while the rest of the OS slims down and experiments with microkernel 
admin and storage vms.


The current state is, of course, one of trusting the GPU. That poses a 
problem for those who want both discrete graphics and anti-tampering 
(AEM) but otherwise? I don't see the compromise you mention.


Defining personal computing and what most people want as a list of 
traditional activities--instead of using examples of innovative apps and 
the kind of directions app developers can go--is a mistake that leads 
projects into an unbearable surfeit of unsupported corner cases. And 
seriously-- if that's what it would come to then just develop a 
convenient firmware verification and re-flashing system and run TAILS on 
the hardware; it would save considerable time and effort.


An accurate view of use cases would hardly stop at office software and 
playing music because almost everyone has make-or-break corner cases. 
Teleconferencing and 3D printing, for example, are now SMB and home user 
activities that benefit from GPUs, which become more necessary due to 
the extra CPU overhead of domain isolation.


As for suggesting server-based processing of large jobs to Qubes 
users... I'm not even sure where to start with t

Re: [qubes-users] Qubes 3.1 crashing, no warning, no error message (Lenovo X230)

2016-07-07 Thread Chris Laprise

On 07/07/2016 06:49 AM, Andreas Rasmussen wrote:

On 07/07/2016 05:32 AM, Chris Laprise wrote:

On 07/06/2016 01:28 PM, Andreas Rasmussen wrote:

Hi!

I bought a Lenovo x230 and installed Qubes 3.1 early may. It has worked
like a charm, but in the last two or three weeks the computer has been
shutting down without warning or error message. It has happened five
times with no apparent pattern. It has both happened with both many and
few VM's open.

The crash goes like this: The screen freezes for 3-5 seconds, then the
computer reboots. I get no error message. The reboot looks like a normal
boot.

I have tried to look in the logfiles, but I'm not sure I'm looking the
right places. So for starters: Can anyone tell me what files to look in?
/var/log/messages only seem to have information about the session after
the crash, same goes for boot.log.

(My computer skills are limited, so please bare with me)

best,

Andreas

Logitech mice are known to trigger this bug.

Chris
.

Where do I read more on this? Thanks for the input!

https://github.com/QubesOS/qubes-issues/issues/1689

Chris

--
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/bc8b377e-8d90-5594-27d7-94d2e9b4261e%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 3.1 crashing, no warning, no error message (Lenovo X230)

2016-07-06 Thread Chris Laprise


On 07/06/2016 01:28 PM, Andreas Rasmussen wrote:

Hi!

I bought a Lenovo x230 and installed Qubes 3.1 early may. It has worked
like a charm, but in the last two or three weeks the computer has been
shutting down without warning or error message. It has happened five
times with no apparent pattern. It has both happened with both many and
few VM's open.

The crash goes like this: The screen freezes for 3-5 seconds, then the
computer reboots. I get no error message. The reboot looks like a normal
boot.

I have tried to look in the logfiles, but I'm not sure I'm looking the
right places. So for starters: Can anyone tell me what files to look in?
/var/log/messages only seem to have information about the session after
the crash, same goes for boot.log.

(My computer skills are limited, so please bare with me)

best,

Andreas


Logitech mice are known to trigger this bug.

Chris

--
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/0cbd52e5-8f24-8d9e-3f72-7650bb7ef0dc%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Creating a VPN VM using openvpn issues? (starting with no /rw/config/openvpn ?)


On 07/05/2016 11:03 AM, gaikokujinkyofu...@gmail.com wrote:

On Tuesday, July 5, 2016 at 10:44:03 AM UTC-4, Chris Laprise wrote:

On 07/05/2016 10:17 AM, gaikokujinkyofu...@gmail.com wrote:

On Tuesday, July 5, 2016 at 5:52:08 AM UTC-4, Chris Laprise wrote:

On 07/04/2016 08:42 PM, gaikokujinkyofu...@gmail.com wrote:

No worries, honestly I should have thought of the sudo myself.

Well, running it with sudo and it went swimmingly, it connected so that is 
good, another hurdle cleared.

I am now back to one of your earlier posts in this thread, regarding the 
qubes-firewall-user-script.

I have to admit that I am not totally clear on needing to run the groupadd (it 
seems to be run in the firewall script?) but I ran it (and it shows up in 
/etc/group so I guess thats good?) but then on the next line:

sudo sg qvpn -c openvpn --cd /rw/config/openvpn/ --config openvpn-client.ovpn

I get an error saying:
Options error: In [CMD-LINE]:1: Error opening configuration 
file:openvn-client.ovpn

I don't understand groups and ids very well so am not sure where there 
breakdown is here, perhaps I need to set something regarding the 
openvpn-client.ovpn file?

Error message indicates that the filename has a typo:
'openvn-client.ovpn' should be 'openvpn-client.ovpn'.

File ids will be OK if you created them with sudo. Running groupadd
multiple times with 'f' option is fine, too.

Chris

Thanks Chris & Eva.

I rechecked what I typed (I was typing from one computer the error from another 
computer that time, logged in on the same comp so am c/p outputs now) and I 
actually had typed it correctly.

I also tried adding the full paths to the openvpn-client.ovpn files as 
suggested (though I added ca.crt and crl.pem instead of ca.key and crl.key, 
assuming thats ok?). As for my openvpn.config (openvpn-client.ovpn right?) 
being stored in the wrong place, I have it in /rw/config/openvpn/ should it be 
somewhere else?

Regardless, after doublechecking what I typed, and adding the full path in as 
suggested the below is what I got, this time a c/p :p

[user@VPN openvpn]$ sudo openvpn --cd /rw/config/openvpn/ --config 
/rw/config/openvpn/openvpn-client.ovpn
Options error: In [CMD-LINE]:1: Error opening configuration file: 
/rw/config/openvpn/openvpn-client.ovpn
Use --help for more information.
[user@VPN openvpn]$

thoughts?


I have seen SELinux restrictions cause this error. But that shouldn't be
a concern if you're using a regular fedora 23 or debian 8 template. Did
you enable SELinux or Apparmor?

http://unix.stackexchange.com/questions/94806/openvpn-options-error-in-cmd-line1-error-opening-configuration-file

Can you do 'ls -lZ /rw/config/openvpn' and paste the output here?

Chris

I am vaugely familar with SElinux and apparmour (hardening?) but I have not 
enabled it, at least not intentionally (not tinkered with anything realted to 
it either). But as for output, absoulutely! here it is:

[user@VPN openvpn]$ ls -lZ /rw/config/openvpn
total 16
-rw-r--r-- 1 root root ? 1395 Jul  4 17:56 ca.crt
-rw-r--r-- 1 root root ?  577 Jul  4 17:56 crl.pem
-rw-r--r-- 1 user user ?  375 Jul  5 09:58 openvpn-client.opvn
-rwxr-xr-x 1 root root ? 1088 Jul  3 20:45 qubes-vpn-handler.sh
[user@VPN openvpn]$


That shows the problem, I think. Change the ownership of the ovpn file 
to root...

sudo chown root:root /rw/config/openvpn/openvpn-client.opvn

Chris

--
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/805c334c-8f46-b747-0956-8c410381287f%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] AEM boot option causes hard reboot/partial shutdown (Lenovo T450s)


Is there an issue open for this yet?

Chris

--
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/82f9adc2-5510-f3f3-db1a-e6d8850a8a6f%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Creating a VPN VM using openvpn issues? (starting with no /rw/config/openvpn ?)

On 07/05/2016 10:17 AM, gaikokujinkyofu...@gmail.com wrote:

On Tuesday, July 5, 2016 at 5:52:08 AM UTC-4, Chris Laprise wrote:

On 07/04/2016 08:42 PM, gaikokujinkyofu...@gmail.com wrote:

No worries, honestly I should have thought of the sudo myself.

Well, running it with sudo and it went swimmingly, it connected so that is
good, another hurdle cleared.

I am now back to one of your earlier posts in this thread, regarding the
qubes-firewall-user-script.

I have to admit that I am not totally clear on needing to run the groupadd (it
seems to be run in the firewall script?) but I ran it (and it shows up in
/etc/group so I guess thats good?) but then on the next line:

sudo sg qvpn -c openvpn --cd /rw/config/openvpn/ --config openvpn-client.ovpn

I get an error saying:
Options error: In [CMD-LINE]:1: Error opening configuration
file:openvn-client.ovpn

I don't understand groups and ids very well so am not sure where there
breakdown is here, perhaps I need to set something regarding the
openvpn-client.ovpn file?

Error message indicates that the filename has a typo:
'openvn-client.ovpn' should be 'openvpn-client.ovpn'.

File ids will be OK if you created them with sudo. Running groupadd
multiple times with 'f' option is fine, too.

Chris

Thanks Chris & Eva.

I rechecked what I typed (I was typing from one computer the error from another
computer that time, logged in on the same comp so am c/p outputs now) and I
actually had typed it correctly.

I also tried adding the full paths to the openvpn-client.ovpn files as
suggested (though I added ca.crt and crl.pem instead of ca.key and crl.key,
assuming thats ok?). As for my openvpn.config (openvpn-client.ovpn right?)
being stored in the wrong place, I have it in /rw/config/openvpn/ should it be
somewhere else?

Regardless, after doublechecking what I typed, and adding the full path in as
suggested the below is what I got, this time a c/p :p

[user@VPN openvpn]$ sudo openvpn --cd /rw/config/openvpn/ --config
/rw/config/openvpn/openvpn-client.ovpn
Options error: In [CMD-LINE]:1: Error opening configuration file:
/rw/config/openvpn/openvpn-client.ovpn
Use --help for more information.
[user@VPN openvpn]$

thoughts?

I have seen SELinux restrictions cause this error. But that shouldn't be
a concern if you're using a regular fedora 23 or debian 8 template. Did
you enable SELinux or Apparmor?

http://unix.stackexchange.com/questions/94806/openvpn-options-error-in-cmd-line1-error-opening-configuration-file

Can you do 'ls -lZ /rw/config/openvpn' and paste the output here?

Chris

--
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/317c583a-f734-cdb1-aede-57932d57fe3f%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes top priorities suggestions for me as an user.