[qubes-users] Re: FYI: Experimental Qubes coldkernel support now available

2016-12-11 Thread Reg Tiangha
On 12/11/2016 06:01 PM, raahe...@gmail.com
wrote:

> 
> Thanks for all your info.
> 

A few last observations:

- If you run coldkernel on a NetVM or ProxyVM, *nothing* will be able to
connect behind it (which kind of sucks).
- Dropbox no longer launches and it keeps trying to download the daemon
every time you start it up. Ironically, there are no issues with
SpiderOAK or NextCloud, but those programs don't force you to download a
daemon after installation.
- coldkernel works in a usbVM with USB input proxy, however, it does
*not* work with mass storage device pass-through (which also sucks) and
it has the added effect of locking up Qubes VM Manager once you try as well.

Note that all of my sysVMs are running Fedora minimal templates; not
sure if using a Debian template would make a difference, but I would
suspect not. In the meantime, I've reverted all of my service VMs to use
normal kernels and am only running coldkernel on AppVMs.

I wonder if properly setting RBAC rules may help with some of the
issues? It'd be nice to be able to figure out how to get gradm working
in an AppVM. Does anyone know what the /dev/grsec device is or how to
create it?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To 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/o2lfbh%24ms8%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Debian 9 updates to x11 makes template unusable

2016-12-11 Thread Chris Laprise
New updates to x11 in Debian 9 have made otherwise well-running template 
unable to boot properly. The status dot stays yellow and sys-net NM icon 
doesn't appear, so this appears to affect the GUI daemon. I had to 
revert it to get stuff done, so I'll post details later.


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/b8a4c823-8d9e-d9fc-e356-36421f0028fe%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Kali VM no longer responding

2016-12-11 Thread Marek Marczykowski-Górecki
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, Dec 12, 2016 at 12:17:16AM +, a.mcwh...@yandex.com wrote:
> That means not only me has the same issue with debian-9 template. I've 
> started reinstalling template.
> 
> On December 12, 2016 11:01:00 AM AEDT, qubenix  wrote:
> >Lucas Arnström:
> >> Hi, I have been using a debian template converted into kali for quite
> >> some time. But recently, neither the kali template nor any appvms
> >based
> >> on it are responding. I can start the vms just fine, but cant do much
> >> other than that. It seems to be some recent change that induced this
> >> problem, considering i have been able to use the very same vms for
> >quite
> >> some time. But after my last update they all stopped working.
> >> 
> >> I have attempted to do a complete rebuild of my kali template. I got
> >> everything set up, but as soon as I restarted the template I got the
> >> same issue again.
> >> 
> >> I'm attaching the logs.
> >> 
> >> // Lucas
> >> 
> >
> >I've had this same experience after a dist-upgrade on my debian-9
> >template (d9) about 12 hours ago. I had made a clone of this template
> >about two weeks ago and added the kali repos and some packages.
> >Strangely, my kali template (and AppVM based on it) work normal even
> >though it was also upgraded at the same time.
> >
> >```
> >user@dom0:~$ qvm-run -p d9 gnome-terminal
> >Unable to init server: Could not connect: Connection refused
> >Failed to parse arguments: Cannot open display:
> >```

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

Rebuilt package just uploaded to testing repository
(qubes-gui-agent_3.2.10-2+deb9u1).

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJYThG0AAoJENuP0xzK19csldEH/jrTxcryYPNjC/umInRN2BG4
Lgc3EaAdtlF+wVnW+EKD0aq/8Xiyxq0VetCiGHRMH5ia4o9StnUnFQUTIE77gWuJ
ocy7XfP+n8rhpBfE/cCpVVeUZiFTJMP4CgRAmnw5o4od1Qx0Kf6t15ORc92GjXRt
aW1MZBkRfWSoXDWHaux8flw2UvNo5tSI3ugyo3eRSRJxCmKDvgBRoSW/OXZPdhUV
VHgt2mGouf1UALO/OSSqvewlsD93AEyh8hjio3qjtCziFzTEsHT9N7jzFdpB8R53
LN/XFF9IxjXiIMB/UEVDRe+ypWhg6TNfUku/ZE5TCTLeMBKgj132738bb7UYsZA=
=MQId
-END PGP SIGNATURE-

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


Re: [qubes-users] Kali VM no longer responding

2016-12-11 Thread a . mcwheel
That means not only me has the same issue with debian-9 template. I've started 
reinstalling template.

On December 12, 2016 11:01:00 AM AEDT, qubenix  wrote:
>Lucas Arnström:
>> Hi, I have been using a debian template converted into kali for quite
>> some time. But recently, neither the kali template nor any appvms
>based
>> on it are responding. I can start the vms just fine, but cant do much
>> other than that. It seems to be some recent change that induced this
>> problem, considering i have been able to use the very same vms for
>quite
>> some time. But after my last update they all stopped working.
>> 
>> I have attempted to do a complete rebuild of my kali template. I got
>> everything set up, but as soon as I restarted the template I got the
>> same issue again.
>> 
>> I'm attaching the logs.
>> 
>> // Lucas
>> 
>
>I've had this same experience after a dist-upgrade on my debian-9
>template (d9) about 12 hours ago. I had made a clone of this template
>about two weeks ago and added the kali repos and some packages.
>Strangely, my kali template (and AppVM based on it) work normal even
>though it was also upgraded at the same time.
>
>```
>user@dom0:~$ qvm-run -p d9 gnome-terminal
>Unable to init server: Could not connect: Connection refused
>Failed to parse arguments: Cannot open display:
>```
>
>-- 
>qubenix
>GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500
>
>-- 
>You received this message because you are subscribed to the Google
>Groups "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/7851f332-b97d-e5cb-3bb6-02d09be245da%40riseup.net.
>For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"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/11C7A11E-265A-4FDC-BAF0-6224A905D455%40yandex.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Allow reverse shell to AppVM

2016-12-11 Thread putnam
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

putnam:
> I wonder if anyone can help me to create a reverse shell on
> one AppVM (which is connected to sys-firwall) from an external
> ip address.
>
> First, I'm using a VPN and netcat to test the connection like
> this:
>
> Qubes Debian-9 AppVM:
>
> `nc -nlvp 443`
>
> On remote machine:
>
> `nc -nv 10.11.0.100 443` # 10.11.0.100 is my ip on tap0.
>
> I've tried:
>
> - Using `sys-net` as NetVM.
>
> - Using `sys-net` as NetVM and flushing iptables in both
> sys-net and Debian-9 AppVM.
>
> - In qubes-manager firewall: "Allow network access except...",
> "Allow ICMP traffic", and "Allow DNS queries" all checked. No
> exceptions listed.
>
> I just can't seem to get this reverse shell to work no matter
> what combination of the above I do. I've tried both with
> `netcat` and with `ncat` explicitly allowing the remote
> machine.
>

Well I figured it out by looking here:
https://www.qubes-os.org/doc/firewall/

In AppVM run:

`sudo iptables -I INPUT -s  -j
ACCEPT`

Now netcat can connect from remote machine to listening port on
AppVM.

- -- 
putnam | 0xE910A14357F33056
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJYTf3/XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQyOEFEMjgzMUIyQjU4MzdFN0I5Q0NGMzdF
OTEwQTE0MzU3RjMzMDU2AAoJEOkQoUNX8zBW7wQP/i3f0CTN4LGdGgUrQZjEj3h6
A67hSa/FK7RPi0iO9fVgOtOi0fTbTi+gyKf3MG67dLmBw0BNo+HiqUj0yKgLxFyX
Rdb04t8Dabq7xMWYg/DwN5huR02gyy7pKA/mnPoerpZr+bQRQ45z2omud/FAt9xN
DWnJH/9M9mjMitudc3SQX0vLuT9TucXJfA3Dzm5sdarBnbhKCclqHVOKQynw0eHl
6Fhl2+7t42FkxGuRtFcYcgi9fGXVE17MUzDh3PCjMVRi1HXxAyx4ukZOHmqzvzN0
tDWExDL9XBXvxhacciNacFZUHATC8DhtDYuYqrOtn7CPYyy4B51HxFkjj77kupVq
4ohe9y4EDUaNszEXzcxQOWvhBiz9ZlQM5V0/8+CQu9+BiS0vKwBDjL0z1W8NXog7
v7FSQOat6pXV+qxJGY0/jdtByxpgxQshm4rXac81HGV7vKp9PI8DoeQ6y/PS/iV7
o01cBEdbQvkNteqRu1oc98MYxwWPX6b6BdQ0k0w6K/qv7lEnl4VXhuVGu+gjnqBd
VIYuq2oHM0FA1z6q5WeRR+xUeqOyjIl/xk+6slLu0Uxf12oENAldw/5PS7hsY1u4
0GpJMcmG5SEnHxye7xJyOZTMOp+YGZLrFD1qt4xUpwOsw6RZY6dFW3r4qxfwICWf
QzUdEARpKAkEAnp+i6/2
=hQQS
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e1c2764d-adfa-d056-ed35-300e8db79ab5%40sigaint.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: HP PRINTER PROBLEM

2016-12-11 Thread raahelps
On Sunday, December 11, 2016 at 5:19:48 PM UTC-5, JPL wrote:
> "Good luck" is the best I can offer. I tried a while ago with an HP printer 
> and gave up. Would be good if someone who has succeeded could provide a 
> walkthrough.

I use a couple networked hp printers on a couple qubes machines  Its no 
different then installing on linux really.  Not sure all the steps offhand, but 
install hplip or hp-setup,  run hp-setup.  temp allow net access and print a 
test page from template-vm.  If it works load appvm and it should just work.  
I've never had an issue with it.   

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To 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/72378fd9-9ab7-498f-a269-74a29f37c433%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: FYI: Experimental Qubes coldkernel support now available

2016-12-11 Thread raahelps
On Sunday, December 11, 2016 at 7:45:09 PM UTC-5, Reg Tiangha wrote:
> On 12/11/2016 05:20 PM, Reg Tiangha wrote:
> > On 12/11/2016 06:21 AM, Reg Tiangha wrote:
> >> On 12/10/2016 09:10 PM, Reg Tiangha wrote:
> >>
> >>> Ah, I see!
> >>>
> >>> OK, I think I may know what *might* have happened.
> >>>
> >>> I think the make script did try to do what it said in the instructions
> >>> here when it started to install the generated deb packages:
> >>>
> >>> https://www.qubes-os.org/doc/managing-vm-kernel/
> >>>
> >>> but I remember it throwing an error somewhere along the line saying it
> >>> couldn't find the kernel header files. But *that* was because it was
> >>> installing the kernel header file deb package afterwards; or in other
> >>> words, the gresecurity kernel header package wasn't installed yet at
> >>> that point in time. So maybe a step was missed.
> >>>
> >>> That said, I now have a properly booting debian 8 template with a
> >>> gresecurity kernel. What you need to do is this:
> >>>
> >>> After you follow the github instructions but before you reboot, run:
> >>>
> >>> sudo dkms autoinstall -k 4.8.12-coldkernel-grsec-1
> >>> sudo update-initramfs -u
> >>> sudo update-grub2
> >>>
> >>> which is essentially the final part of the "Installing kernel in Debian
> >>> VM" instructions. And then the machine should boot up fine when you
> >>> switch to the pvgrub2 kernel. Or, at least it did for me.
> >>>
> >>> Thanks for the hint!!
> >>>
> >>
> >> And it looks like in the last 7 hours, they've bumped the kernel up to
> >> 4.8.13, modified the Debian template instructions, and temporarily
> >> pulled down the Fedora template instructions as well. So yeah, it's all
> >> still in flux. Gonna go recompile that 4.8.13 kernel now...
> >>
> > 
> > OK, the weekend is almost over and I can't spend much more time on this.
> > So I thought I'd just wrap up the results of my (light) testing:
> > 
> > 
> > GENERAL:
> > 
> > - You'll want at least 4GB free to build the kernel.
> > 
> > - I can't seem to get it to work with a DispVM. I set my dvm image to
> > use pvgrub2 as its kernel, but every time it launches a new DispVM, the
> > new machine reverts to using my default 4.8.12 kernel. Actually, it
> > seems to resort to using all default values for number of CPUs and RAM;
> > changing those values seem to have no effect on spawned machines.
> > 
> > - I couldn't figure out how to get the RBAC stuff to work. I wanted to
> > use grsecurity's gradm tool, but it would always fail at the
> > installation portion saying that /dev/grsec did not exist (which it
> > didn't). I don't know how to create that device so for now, I've
> > reverted to enabling Apparmor or SELinux depending on the template.
> > You'll need to pass those kernel instructions through the VM's grub
> > config file, though. You can easily do that by creating a
> > /etc/default/grub file and adding a GRUB_CMDLINE_LINUX="apparmor=1
> > security=apparmor" or "selinux=1 security=selinux" line to it (you can
> > also set some other grub options like GRUB_TIMEOUT=0). Those modules are
> > included in the coldkernel and everything seems to work fine together.
> > 
> > 
> > DEBIAN 8:
> > 
> > - Seems to work fine as per the instructions. You can save yourself a
> > bit of grief beforehand by editing the install-deps section of the
> > Makefile and swapping the order it installs the kernel header package
> > and the kernel image package so that the header package is installed
> > first. Else, follow my instructions above (substituting the correct
> > kernel version that becomes recent when you try this) before you shut
> > down the VM.
> > 
> > 
> > FEDORA:
> > 
> > - I tried it on a Fedora 24 template. The instructions were pulled down
> > from the GitHub readme, and for good reason:  They don't work fully. The
> > Makefile will build a kernel image rpm and a kernel header rpm. However,
> > it neglected a kernel-devel package meaning that u2mfn module doesn't
> > get compiled at all. Personally, I would wait for the coldhak crew to
> > release updated Fedora instructions, but if you can't wait, here's what
> > you do (works as the time of this writing):
> > 
> > 1) Install the Fedora packages as listed here (although there's probably
> > more than you need; I don't think you actually need the Development
> > Tools group, for example):
> > 
> > https://github.com/coldhakca/coldkernel/blob/6926736c830e994fc1e4f48df1a665ea78e29f94/README.md
> > 
> > 2) Follow the Qubes Fedora instructions until just before the part about
> > making the grub config file.
> > 
> > 3) Copy or move the linux-4.8.13 (or whatever version it is) directory
> > from the coldkernel directory to /lib/modules/4.8.13-coldkernel-grsec-1
> > and rename it to "build" as this is where the kernel source needed to
> > recompile the u2nfn module is expected to be found.
> > 
> > 4) Recompile u2nfn by running:
> > 
> > sudo dkms autoinstall -k 4.8.13-coldkernel-grsec-1
> > 
> > 5) Regenerate 

Re: [qubes-users] USB hardware firewall

2016-12-11 Thread taii...@gmx.com

On 12/10/2016 05:36 PM, Robert Fisk wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 12/10/2016 08:25 AM, Marek Marczykowski-Górecki wrote:

On Sun, Sep 04, 2016 at 06:35:42PM +1200, Robert Fisk wrote:

On 09/01/2016 06:55 PM, johnyju...@sigaint.org wrote:

I was thinking earlier that some form of a "USB Firewall"
hardware device might be cool to create; one that goes into
each USB port in between each device and the PC, and only
passes a specific device, or only a HID device (and doesn't
permit a drive to add another HID identity).  Yet another side
project for winter. :)  There may be existing products.



Ahem. Allow me to introduce you to a project I have been working
on for a while now:
https://github.com/robertfisk/usg/wiki
https://github.com/robertfisk/USG/wiki/FAQ
The USG (which is Good, not Bad) is a hardware firewall for your
USB ports. It connects between your computer and your untrusted
USB device, isolating the badness with two dedicated processors.
Features: - Isolates low-level USB exploits by using a simple
internal protocol with minimal attack surface
- No hub support blocks 'hidden' malicious devices
- Prevents devices changing their enumerated class after
connection, stopping malicious class changes.



Device support: mass storage (flash drives), keyboards, mice.
Project status: You can build your own USG v0.9 hardware out of
development boards if you are handy with a soldering iron. End
user hardware is approaching production-ready status, samples
will be available in the coming months.
Feedback / pull requests / sales leads are welcome!

This project have great potential! The USB proxy hardware can be
used for somehow more secure USB keyboard usage on Qubes OS, when
only a single USB controller is available. Take a look at this
idea[1]:

Have a piece of hardware plugged between USB keyboard and PC (based
on https://github.com/robertfisk/USG?), to encrypt and
integrity-protect the events. And then decrypt them in dom0 and
check integrity protection, and only then pass them down to input
devices stack. This should at least partially guard against
malicious USB VM. It still will be able to perform timing based
attacks to guess what you're typing - not sure how accurate such
attacks are currently. Such device could introduce artificial delay
(like - inject queued events every 50ms) to at least partially
mitigate such attacks.

What do you think about it? I think the hardware you've designed
is perfect for this!

[1]
https://github.com/QubesOS/qubes-issues/issues/2507#issuecomment-265894809




This sounds like a great idea, and I am keen to be involved. There is
plenty of flash space available on the embedded CPUs to implement some
form of encryption, although the best method of doing so on bare-metal
ARM is certainly open for discussion.

A recent batch of hardware samples sold out in November. Due to Real
Life(TM) the next batch of hardware is likely to be ready late January
or early February. Pricing is currently NZ$80 each (approx US$57).

Regards,
Robert
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJYTINVAAoJEN65WsAVra66UqgP/js8V9oHjYtsVs8wHhBs0Iq+
NL4pWUUtceGlCPBJZnKhmPM2Q7gNve3CS4K1i3JikSGIMw4BTqH59JqRmHIv1UDW
jH3DHfbGRLNXAJQTAUFQVV+M43rMQXcM0BT5xrTUdlwG8dQhe44cS+cW1BzmSBtn
FsszZVEp7UU6IJ/YZMYfEIbd/dhq92YBU5fU16F6PVdAFq8ObQoLCMPxWN8GLSKy
JgYkcRHiC2mjzYWN5hv+iZYFVWfxR33jkUoo7n2Iyaz27bYjHyKCy83sBsnhUaLg
Xr2+HJxGoxtScG9Q42ay1/40W5LQyhLRyvnYg1Yih1p18JrY54oe4k2F5jGnj953
giQri7lg6xWk9Md9rDRKvq7Xc2Kd6VdRAp1ooPfehGSIidGRdyYEAVttaqMxmZB3
7U1j35ELDTN3q79++LxnQr01yERsQHM6cKYQsog5/mOHtSG2+iOK2RoNK5M2fhQB
wrULmBTmwNruRGO+W2RBCcOZCvmP8WTthEb85BSVwHlrra6Vv02oFyAvDTj4Q8RI
NLV9HqwXILW1eICCoQUOzcW41SAYrn3ykX/eWgksg221Lks9RWzfxDItBXtrjXSR
pqKtbqRVZIT0k35GJug8RjTuG2JRaMbSEepblmWCvm9cN4bl/RRkOy9uRgfBLKsx
+k6vRfW54/ly/WT/XVJh
=1NhG
-END PGP SIGNATURE-


For the record there is also http://syncstop.com/

It isn't "smart" like this but it is more secure if you just want 
charging - in case you need to charge an unsafe (friends, colleagues) 
device on your laptop, or charge your device with someone elses charger 
or a public charger.


--
You received this message because you are subscribed to the Google Groups 
"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/3bbdce9f-5819-cbbc-322a-39d5b6a4ec58%40gmx.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: FYI: Experimental Qubes coldkernel support now available

2016-12-11 Thread Reg Tiangha
On 12/11/2016 06:21 AM, Reg Tiangha wrote:
> On 12/10/2016 09:10 PM, Reg Tiangha wrote:
> 
>> Ah, I see!
>>
>> OK, I think I may know what *might* have happened.
>>
>> I think the make script did try to do what it said in the instructions
>> here when it started to install the generated deb packages:
>>
>> https://www.qubes-os.org/doc/managing-vm-kernel/
>>
>> but I remember it throwing an error somewhere along the line saying it
>> couldn't find the kernel header files. But *that* was because it was
>> installing the kernel header file deb package afterwards; or in other
>> words, the gresecurity kernel header package wasn't installed yet at
>> that point in time. So maybe a step was missed.
>>
>> That said, I now have a properly booting debian 8 template with a
>> gresecurity kernel. What you need to do is this:
>>
>> After you follow the github instructions but before you reboot, run:
>>
>> sudo dkms autoinstall -k 4.8.12-coldkernel-grsec-1
>> sudo update-initramfs -u
>> sudo update-grub2
>>
>> which is essentially the final part of the "Installing kernel in Debian
>> VM" instructions. And then the machine should boot up fine when you
>> switch to the pvgrub2 kernel. Or, at least it did for me.
>>
>> Thanks for the hint!!
>>
> 
> And it looks like in the last 7 hours, they've bumped the kernel up to
> 4.8.13, modified the Debian template instructions, and temporarily
> pulled down the Fedora template instructions as well. So yeah, it's all
> still in flux. Gonna go recompile that 4.8.13 kernel now...
> 

OK, the weekend is almost over and I can't spend much more time on this.
So I thought I'd just wrap up the results of my (light) testing:


GENERAL:

- You'll want at least 4GB free to build the kernel.

- I can't seem to get it to work with a DispVM. I set my dvm image to
use pvgrub2 as its kernel, but every time it launches a new DispVM, the
new machine reverts to using my default 4.8.12 kernel. Actually, it
seems to resort to using all default values for number of CPUs and RAM;
changing those values seem to have no effect on spawned machines.

- I couldn't figure out how to get the RBAC stuff to work. I wanted to
use grsecurity's gradm tool, but it would always fail at the
installation portion saying that /dev/grsec did not exist (which it
didn't). I don't know how to create that device so for now, I've
reverted to enabling Apparmor or SELinux depending on the template.
You'll need to pass those kernel instructions through the VM's grub
config file, though. You can easily do that by creating a
/etc/default/grub file and adding a GRUB_CMDLINE_LINUX="apparmor=1
security=apparmor" or "selinux=1 security=selinux" line to it (you can
also set some other grub options like GRUB_TIMEOUT=0). Those modules are
included in the coldkernel and everything seems to work fine together.


DEBIAN 8:

- Seems to work fine as per the instructions. You can save yourself a
bit of grief beforehand by editing the install-deps section of the
Makefile and swapping the order it installs the kernel header package
and the kernel image package so that the header package is installed
first. Else, follow my instructions above (substituting the correct
kernel version that becomes recent when you try this) before you shut
down the VM.


FEDORA:

- I tried it on a Fedora 24 template. The instructions were pulled down
from the GitHub readme, and for good reason:  They don't work fully. The
Makefile will build a kernel image rpm and a kernel header rpm. However,
it neglected a kernel-devel package meaning that u2mfn module doesn't
get compiled at all. Personally, I would wait for the coldhak crew to
release updated Fedora instructions, but if you can't wait, here's what
you do (works as the time of this writing):

1) Install the Fedora packages as listed here (although there's probably
more than you need; I don't think you actually need the Development
Tools group, for example):

https://github.com/coldhakca/coldkernel/blob/6926736c830e994fc1e4f48df1a665ea78e29f94/README.md

2) Follow the Qubes Fedora instructions until just before the part about
making the grub config file.

3) Copy or move the linux-4.8.13 (or whatever version it is) directory
from the coldkernel directory to /lib/modules/4.8.13-coldkernel-grsec-1
and rename it to "build" as this is where the kernel source needed to
recompile the u2nfn module is expected to be found.

4) Recompile u2nfn by running:

sudo dkms autoinstall -k 4.8.13-coldkernel-grsec-1

5) Regenerate initramfs by running:

sudo dracut --regenerate-all --force

6) Create grub config file:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

7) Shutdown template


WHONIX:

- Doesn't seem to work at all by default. The light on Qubes VM Manager
stays yellow and qrexec never connects. Couldn't figure this one out
although I didn't spend much time on it.


So that's all I've been able to figure out thus far. I haven't put this
kernel through its paces yet through standard usage though; only tested
to 

[qubes-users] Allow reverse shell to AppVM

2016-12-11 Thread putnam
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I wonder if anyone can help me to create a reverse shell on
one AppVM (which is connected to sys-firwall) from an external
ip address.

First, I'm using a VPN and netcat to test the connection like
this:

Qubes Debian-9 AppVM:

`nc -nlvp 443`

On remote machine:

`nc -nv 10.11.0.100 443` # 10.11.0.100 is my ip on tap0.

I've tried:

- - Using `sys-net` as NetVM.

- - Using `sys-net` as NetVM and flushing iptables in both
sys-net and Debian-9 AppVM.

- - In qubes-manager firewall: "Allow network access except...",
"Allow ICMP traffic", and "Allow DNS queries" all checked. No
exceptions listed.

I just can't seem to get this reverse shell to work no matter
what combination of the above I do. I've tried both with
`netcat` and with `ncat` explicitly allowing the remote
machine.
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJYTeTaXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQyOEFEMjgzMUIyQjU4MzdFN0I5Q0NGMzdF
OTEwQTE0MzU3RjMzMDU2AAoJEOkQoUNX8zBW+uAP/08ed1X+4mMjMNgqpveQW6s0
A/6irEGo1ViEeau5IMT+4ODpSbNMmIR4bfVSdLe2dqalk+04Up8547oAOqLzP6l0
Ts336hXdjpAixZotiRmPYlfZ7xmXqKfOFRxHbT7otqBq5e2hLmeGvPGxYV/Vl7tx
fRxXgbsKrfqQNbOG8p5hOBnpfT2ayj5FVGUA5tna954uPODbl6pesfrN1AGsjrLO
sOuqSisU2Z/baVIFVjJK3g6+BSA61OVw3zQJt9/OLs9a64M2qE5l08cwgst+GT64
OhvKMrLCBf3Zx77aUGu/u3GkGOR4Y4+Zo9vepqxr1KAbxqLor44L88XO8xlRoQXt
EL5qC1bCQ2ISwQcf80KaUi1f+Vi2OM7ULfljBDj7whM5z1W+cmeIuJi/OXBM85w9
fic9+7MgjCZFjWKqAQd+wEgOMMWW6Evgy2oQdhi2llMT39V1wNJ+MUXKGFuwF6gQ
UBzGtOpXpLFqLQh+bQAJl+9JOE9odThAw11IhKbG98243l/hMnfsboXstSUJphug
pA0lq8A791AZNiMOwPlnldDkmW4YstvjiWYoJals31g/iKOsXxgq+u0W0DQrFhLO
PhB52TQaMGn0BELIOKsobIxdW36z7YtwqqMiZqOXeda7cr90n3TF3cnY3Yzipnb0
swDba+a6/kBsvocNBgNx
=NbPt
-END PGP SIGNATURE-

-- 
putnam | 0xE910A14357F33056

-- 
You received this message because you are subscribed to the Google Groups 
"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/eaeff6be-8ed1-fbc6-7a7c-5ae5bbb1772a%40sigaint.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Kali VM no longer responding

2016-12-11 Thread qubenix
Lucas Arnström:
> Hi, I have been using a debian template converted into kali for quite
> some time. But recently, neither the kali template nor any appvms based
> on it are responding. I can start the vms just fine, but cant do much
> other than that. It seems to be some recent change that induced this
> problem, considering i have been able to use the very same vms for quite
> some time. But after my last update they all stopped working.
> 
> I have attempted to do a complete rebuild of my kali template. I got
> everything set up, but as soon as I restarted the template I got the
> same issue again.
> 
> I'm attaching the logs.
> 
> // Lucas
> 

I've had this same experience after a dist-upgrade on my debian-9
template (d9) about 12 hours ago. I had made a clone of this template
about two weeks ago and added the kali repos and some packages.
Strangely, my kali template (and AppVM based on it) work normal even
though it was also upgraded at the same time.

```
user@dom0:~$ qvm-run -p d9 gnome-terminal
Unable to init server: Could not connect: Connection refused
Failed to parse arguments: Cannot open display:
```

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
You received this message because you are subscribed to the Google Groups 
"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/7851f332-b97d-e5cb-3bb6-02d09be245da%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Networking & firewall

2016-12-11 Thread Jos Bredek
Hello there,

i'm relatively new to the qubes environment. So far, i'm really excited. I just 
love the concept!

Anyhow, today i stubmled into a problem; using my chromecast from one of my 
vm's within in qubes.

As a network-technician, my first thought.. this cant be hard. Boy, was i 
wrong. After quite some reading, i'm still puzzled. I've noticed that the 
netwerking & firewall document has the status TODO. Maybe something i can lend 
a little help with?

I've read the following posts:
https://groups.google.com/forum/#!searchin/qubes-users/inter-vm|sort:relevance/qubes-users/lA2SgPcV9fU/U969uapYAAAJ
https://www.qubes-os.org/doc/firewall/
http://theinvisiblethings.blogspot.nl/2011/09/playing-with-qubes-networking-for-fun.html
 (is this still valid?).

I get the general concept. 
- appVM's are connected to sys-firewall
- Sysfirewall is attached to sys-net
- no bridging involved, all routing.

But then:
- why are there subnets involved of 255.255.255.255?
- how much NATting is going on?
- what role does proxy arp play? Is it still used in 3.2?

Of course i can use wireshark and tcp dump to sort things out... but just maybe 
there is a good pointer to some other documentation? 

Can anyone point out some more reading material? If any?

Cheers!
Jos

-- 
You received this message because you are subscribed to the Google Groups 
"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/1e6e45a2-ec60-4d74-8af6-cfec00d86084%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] How to move/migrate a VM with a Fedora-23 custom template from 3.1 to 3.2?

2016-12-11 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-12-11 09:10, Leeteqxv wrote:
> I have a previous test installation of Qubes 3.1 on a separate HDD
> (now external USB), which cointains a customised (cloned+extra sw
> installs) Fedora-23 template used with a dedicated AppVM.
> 
> Now I have Qubes 3.2 installed on a new HDD on that machine and
> before we move on to Fedora-24 (when F23 "expires" later this
> month), I would like to "import" that custom template AND the
> related VM into the new (fresh) 3.2 install.
> 
> I cannot be sure if I have all the necessary insights into Qubes
> to assume I can just copy / paste some folders/files into the new 
> installation, so I would like to know exactly which folders/files
> are involved, and if there are any special order/steps to take, and
> whatever else is needed for this. I also think that the resulting
> How-To list should be fitted into the documentation somewhere.
> 
> (PS. I have not yet upgraded the new 3.2 system to Fedora-24, so
> that part is not the question here. I will do the upgrade to F24
> after the migration of the template/VM along with the rest of the
> system. Hence, my question here is regarding a "migrate" between
> two F23-based systems, from Q3.1 to Q3.2)
> 
> I am aware of the following docs:
> 
> https://www.qubes-os.org/doc/template/fedora/upgrade-23-to-24/ 
> https://www.qubes-os.org/doc/upgrade-to-r3.2/
> 
> Can someone provide an ordered list of steps for this?
> 
> Thanks.
> 

If I understand you correctly, it sounds like the built-in Qubes
backup tool (qvm-backup from the command-line, also available from the
Qubes Manager GUI) is the right tool for the job:

https://www.qubes-os.org/doc/backup-restore/

Especially this part:

https://www.qubes-os.org/doc/backup-restore/#migrating-between-two-physical-machines

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJYTbuYAAoJENtN07w5UDAwZdcP/itDdBnMY1EDQiFBp8RjpvLr
SgiQtvG7IU0seIZuyTbu0OLiDpMUUNFfYhHqOaYfvMKUFLGuX0UBPoVMWZw+OtzQ
RE144c2yKOZFjdj72LY7koy25aXjXT9jlPr3SyxoBd6+au2Q8yZcQqVZIFmWXy3O
+E3ySp5aBVJu5wKblDtFtE0H4nwdPBFMIJjjFB1RfYusUiuo1vPYwM3Whec0MYcn
4ll0o645V4S0BGCJUYQSOG05DRFPx1eokKKLD0i11gIv1FrJ6At/2JPf+RTOjBxw
LAL+mogyyXXCD6IdD2IiL7RNuNTzkQCwCT5VVTBztESmryDQ5TVcD9W2x+16BzLu
vHMHC7uGkJmcdNRNq8ZAc8OjBp51vRnhoQjseLVIHPxtrxEqMLUlal6IjxNKgt+A
edMC++p1HKVW0lqexl8+hTIcsGkVQ7BjVP6LNSikfm16AsJ7sSJNfKEhWbNFu0qh
ObxOSWsM91e0+VZPnjY2o/llj5Ewss629JB8qxW6N8htuqN/aI5+0LJilqvVS9Bg
MKdNdfnEvG2ZYZLi9FAM3x9Ai8FYzRIDf1LC83eP3IF7Es+8AsWZpWZE1ueDtkva
yf0m/QaL9CMG81DvddFc6Orp40dQwZ4Z20vnY7ELTfrDnPro1abK/ADLKp3t/csN
nVEnrBFTgCUb0lXlMZk9
=cECP
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6e24524e-165b-1c6b-24e2-e8bd4b8f0c06%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.


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

2016-12-11 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-12-11 02:38, Simon wrote:
> Le 2016-12-11 07:36, Andrew David Wong a écrit :
>> That's strange. My dom0 dnf history shows all my updates, including
>> recent ones.
>>
>> Are you sure your dom0 has been getting updated? How are you
>> performing updates?
> 
> Hello Andrew,
> 
> When I do `rpm -qa --last' I can list all installed and updated packages
> with the appropriates dates, so I can confirm that dom0 gets correctly
> updated:
> 
>  8< 
> 
> [user@dom0 ~]$ rpm -qa --last | head
> perf-4.8.12-100.fc23.x86_64   Sat Dec 10 18:10:11 2016
> pciutils-libs-3.5.2-1.fc23.x86_64 Sat Dec 10 18:10:11 2016
> pciutils-3.5.2-1.fc23.x86_64  Sat Dec 10 18:10:11 2016
> dnsmasq-2.76-2.fc23.x86_64Thu Dec  8 23:33:14 2016
> dmidecode-3.0-6.fc23.x86_64   Thu Dec  8 23:33:13 2016
> qubes-input-proxy-1.0.8-1.fc23.x86_64 Thu Dec  8 23:33:12 2016
> qubes-gpg-split-dom0-2.0.24-1.fc23.x86_64 Thu Dec  8 23:33:12 2016
> perl-Time-Local-1.250-1.fc23.noarch   Thu Dec  8 23:33:11 2016
> kernel-qubes-vm-4.4.31-11.pvops.qubes.x86_64  Thu Dec  8 23:33:06 2016
> kernel-4.4.31-11.pvops.qubes.x86_64   Thu Dec  8 23:32:57 2016
> 
>  8< 
> 
> To update, I simply use the Qubes VM Manager. The only things which may
> be noticeable are the following:
> 
> - Usually I update all the templates and Dom0 simultaneously: I right
> click on the AppVM template and click `Update VM', I do this for each
> AppVM in a row (without waiting for the update of the previous AppVM to
> terminate) and finally for Dom0 (since it locks access to the Qubes VM
> Manager during the while Dom0 update process, which is the longest, see
> below).
> 

When you say "AppVM," do you actually mean TemplateVM? There should
normally be no reason to update AppVMs.

> - I have the impression that Dom0 updates are downloaded twice, most
> probably an issue around the proxy feature (there is no such issue with
> the templates, updating Dom0 takes twice as much time as updating the
> templates).
> 

Hm, that would be odd. The normal dom0 update process is for the updates
to b downloaded by the UpdateVM (default sys-firewall), then transferred
to dom0, where the signatures are checked, and the updates are installed.
This might have the appearance of the updates being downloaded twice,
but they're really only downloaded once.

> - I regularly have ghost updates (the icon announcing that updates are
> available while there are none) but I think this is a known issue.
> 

Yes, that's a known issue:

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

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJYTbrxAAoJENtN07w5UDAwhlgP/3zvrF174QxmCIPKM0CO1biT
R74ZdPm67yttn3ONy6YhuBpcVTtggKCjFBsc95lN8YopbqtImUyTIRC180u6RQ1x
EFVtdiGlFijtyBHxFCvkahMXpAdxJl3ZLVB26Ji+M3gr74wdAMESPe5tajQbuw5j
cmPb7q14+zOa5ei84J1b+OD53IryPxe89ZSwN3smIlq/DdhgWw38RpdM8nJbEJe7
rlRi1he52sx+E7aJqlk8oEuRxUFPg6nEBe7ijD+EW4GjPQqb2KS5oC6P1/1kyvFq
0SAnHpxIulW3mULRO7MM3SOhZ7I7H7mWYq7NsMfsVqf4Vl64WkJUgHC7cv58JPLW
b6/NmF+Aes5kre7qVcVTZdXU8gDLA/40NNZr3HRMqMJhWEVCVVAjyZg/ZwhR1B1m
Hr+OIdidMYyy8PoSgqkbB8KW+roZI3may7yXWJ7bDocO4i+ou+GwyX13mtgOGoth
dbvN5g+pPiK9t2XPRRyBxC9HRuoJB4dmfJKa2jK/tSR2p4i9f1/lsZwqGJfckkxc
el0N1VyAes5gL1iV5nQP9bpziKLVaWYcTNt4h21m3zXQYWd6//Ci+lhLuiO36CAK
YTHzWtT45gRCsZVTZRjBQXtgxWq0jf83l2q11fF8P+rqOZG9pK0xxJAP36pnQCvX
qGkjDxzqMf8NT0XvS0tV
=PK+K
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b4194cc9-b819-b6e1-63b1-621fd51857e5%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Kali VM no longer responding

2016-12-11 Thread Lucas Arnström
Hi, I have been using a debian template converted into kali for quite
some time. But recently, neither the kali template nor any appvms based
on it are responding. I can start the vms just fine, but cant do much
other than that. It seems to be some recent change that induced this
problem, considering i have been able to use the very same vms for quite
some time. But after my last update they all stopped working.

I have attempted to do a complete rebuild of my kali template. I got
everything set up, but as soon as I restarted the template I got the
same issue again.

I'm attaching the logs.

// Lucas

-- 
You received this message because you are subscribed to the Google Groups 
"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/aa1e0c52-28d3-a4d9-eae9-a0e0a859ecfa%40arnstrom.se.
For more options, visit https://groups.google.com/d/optout.
[0.00] x86/PAT: Configuration [0-7]: WB  WT  UC- UC  WC  WP  UC  UC  

[0.00] Initializing cgroup subsys cpuset

[0.00] Initializing cgroup subsys cpu

[0.00] Initializing cgroup subsys cpuacct

[0.00] Linux version 4.4.14-11.pvops.qubes.x86_64 (user@release) (gcc 
version 5.3.1 20160406 (Red Hat 5.3.1-6) (GCC) ) #1 SMP Tue Jul 19 01:14:58 UTC 
2016

[0.00] Command line: root=/dev/mapper/dmroot ro nomodeset console=hvc0 
rd_NO_PLYMOUTH rd.plymouth.enable=0 plymouth.enable=0 nopat

[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256

[0.00] x86/fpu: Supporting XSAVE feature 0x01: 'x87 floating point 
registers'

[0.00] x86/fpu: Supporting XSAVE feature 0x02: 'SSE registers'

[0.00] x86/fpu: Supporting XSAVE feature 0x04: 'AVX registers'

[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'standard' format.

[0.00] x86/fpu: Using 'eager' FPU context switches.

[0.00] ACPI in unprivileged domain disabled

[0.00] Released 0 page(s)

[0.00] e820: BIOS-provided physical RAM map:

[0.00] Xen: [mem 0x-0x0009] usable

[0.00] Xen: [mem 0x000a-0x000f] reserved

[0.00] Xen: [mem 0x0010-0xf9ff] usable

[0.00] x86/PAT: PAT support disabled.

[0.00] NX (Execute Disable) protection: active

[0.00] DMI not present or invalid.

[0.00] Hypervisor detected: Xen

[0.00] e820: last_pfn = 0xfa000 max_arch_pfn = 0x4

[0.00] MTRR: Disabled

[0.00] RAMDISK: [mem 0x02055000-0x02b14fff]

[0.00] NUMA turned off

[0.00] Faking a node at [mem 0x-0xf9ff]

[0.00] NODE_DATA(0) allocated [mem 0x18839000-0x1884afff]

[0.00] Zone ranges:

[0.00]   DMA  [mem 0x1000-0x00ff]

[0.00]   DMA32[mem 0x0100-0xf9ff]

[0.00]   Normal   empty

[0.00] Movable zone start for each node

[0.00] Early memory node ranges

[0.00]   node   0: [mem 0x1000-0x0009]

[0.00]   node   0: [mem 0x0010-0xf9ff]

[0.00] Initmem setup node 0 [mem 0x1000-0xf9ff]

[0.00] p2m virtual area at c900, size is 80

[0.00] Remapped 0 page(s)

[0.00] SFI: Simple Firmware Interface v0.81 http://simplefirmware.org

[0.00] smpboot: Allowing 4 CPUs, 0 hotplug CPUs

[0.00] e820: [mem 0xfa00-0x] available for PCI devices

[0.00] Booting paravirtualized kernel on Xen

[0.00] Xen version: 4.6.3 (preserve-AD)

[0.00] clocksource: refined-jiffies: mask: 0x max_cycles: 
0x, max_idle_ns: 1910969940391419 ns

[0.00] setup_percpu: NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:4 
nr_node_ids:1

[0.00] PERCPU: Embedded 34 pages/cpu @880013e0 s98392 r8192 
d32680 u524288

[0.00] PV qspinlock hash table entries: 256 (order: 0, 4096 bytes)

[0.00] Built 1 zonelists in Node order, mobility grouping on.  Total 
pages: 1007882

[0.00] Policy zone: DMA32

[0.00] Kernel command line: root=/dev/mapper/dmroot ro nomodeset 
console=hvc0 rd_NO_PLYMOUTH rd.plymouth.enable=0 plymouth.enable=0 nopat

[0.00] PID hash table entries: 4096 (order: 3, 32768 bytes)

[0.00] Memory: 298936K/4095612K available (7533K kernel code, 1247K 
rwdata, 3404K rodata, 1528K init, 1472K bss, 3796676K reserved, 0K cma-reserved)

[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1

[0.00] Hierarchical RCU implementation.

[0.00]  Build-time adjustment of leaf fanout to 64.

[

[qubes-users] How to move/migrate a VM with a Fedora-23 custom template from 3.1 to 3.2?

2016-12-11 Thread Leeteqxv
I have a previous test installation of Qubes 3.1 on a separate HDD (now 
external USB), which cointains a customised (cloned+extra sw installs) 
Fedora-23 template used with a dedicated AppVM.


Now I have Qubes 3.2 installed on a new HDD on that machine and before 
we move on to Fedora-24 (when F23 "expires" later this month), I would 
like to "import" that custom template AND the related VM into the new 
(fresh) 3.2 install.


I cannot be sure if I have all the necessary insights into Qubes to 
assume I can just copy / paste some folders/files into the new 
installation, so I would like to know exactly which folders/files are 
involved, and if there are any special order/steps to take, and whatever 
else is needed for this. I also think that the resulting How-To list 
should be fitted into the documentation somewhere.


(PS. I have not yet upgraded the new 3.2 system to Fedora-24, so that 
part is not the question here. I will do the upgrade to F24 after the 
migration of the template/VM along with the rest of the system. Hence, 
my question here is regarding a "migrate" between two F23-based systems, 
from Q3.1 to Q3.2)


I am aware of the following docs:

https://www.qubes-os.org/doc/template/fedora/upgrade-23-to-24/
https://www.qubes-os.org/doc/upgrade-to-r3.2/

Can someone provide an ordered list of steps for this?

Thanks.

--
You received this message because you are subscribed to the Google Groups 
"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/ed363f8d-500a-bc74-4382-9550a580221b%40leeteq.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Riseup Services Likely Compromised

2016-12-11 Thread Michael Carbone
Me:
> Qubes users beware. Riseup Services (including email)are likely
> compromised by State actors.
> For more info and to verify above statement visit
> https://riseup.net/canary {here you'll see that the canary statement
> hasn't been updated quarterly as promised} and here
> https://www.whonix.org/blog/riseup.
> Google the topic and you'll see lots of other statements that Riseup is
> no longer trusted.
> Stay Safe

https://theintercept.com/2016/11/29/something-happened-to-activist-email-provider-riseup-but-it-hasnt-been-compromised/

which includes statements from the Riseup team.

It sounds like they were served with something boring, but because of
how they defined their warrant canary they had to not update it.
Removing a warrant canary does not mean compromise, which is one of the
weaknesses of poorly defined (and followed) warrant canaries.

-- 
Michael Carbone

Qubes OS | https://www.qubes-os.org
@QubesOS 

PGP fingerprint: D3D8 BEBF ECE8 91AC 46A7 30DE 63FC 4D26 84A7 33B4


-- 
You received this message because you are subscribed to the Google Groups 
"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/c698484b-4c1c-007f-cb58-582439ddc3dc%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Riseup Services Likely Compromised

2016-12-11 Thread Me
Qubes users beware. Riseup Services (including email)are likely
compromised by State actors.
For more info and to verify above statement visit
https://riseup.net/canary {here you'll see that the canary statement
hasn't been updated quarterly as promised} and here
https://www.whonix.org/blog/riseup.
Google the topic and you'll see lots of other statements that Riseup is
no longer trusted.
Stay Safe

-- 
You received this message because you are subscribed to the Google Groups 
"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/o2jmi7%24prs%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] HCL - SONY VAIO VPCEH2M0E

2016-12-11 Thread carlos gonzalez


-- 
You received this message because you are subscribed to the Google Groups 
"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/CAADO59qjdcMrdRzic%2Bxd-fm5w5HRxxXFS8YFyaOB2dAU4guBEA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-Sony_Corporation-VPCEH2M0E-20161210-192427.yml
Description: Binary data


[qubes-users] Re: FYI: Experimental Qubes coldkernel support now available

2016-12-11 Thread Reg Tiangha
On 12/10/2016 09:10 PM, Reg Tiangha wrote:

> Ah, I see!
> 
> OK, I think I may know what *might* have happened.
> 
> I think the make script did try to do what it said in the instructions
> here when it started to install the generated deb packages:
> 
> https://www.qubes-os.org/doc/managing-vm-kernel/
> 
> but I remember it throwing an error somewhere along the line saying it
> couldn't find the kernel header files. But *that* was because it was
> installing the kernel header file deb package afterwards; or in other
> words, the gresecurity kernel header package wasn't installed yet at
> that point in time. So maybe a step was missed.
> 
> That said, I now have a properly booting debian 8 template with a
> gresecurity kernel. What you need to do is this:
> 
> After you follow the github instructions but before you reboot, run:
> 
> sudo dkms autoinstall -k 4.8.12-coldkernel-grsec-1
> sudo update-initramfs -u
> sudo update-grub2
> 
> which is essentially the final part of the "Installing kernel in Debian
> VM" instructions. And then the machine should boot up fine when you
> switch to the pvgrub2 kernel. Or, at least it did for me.
> 
> Thanks for the hint!!
> 

And it looks like in the last 7 hours, they've bumped the kernel up to
4.8.13, modified the Debian template instructions, and temporarily
pulled down the Fedora template instructions as well. So yeah, it's all
still in flux. Gonna go recompile that 4.8.13 kernel now...

-- 
You received this message because you are subscribed to the Google Groups 
"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/o2jjs2%241s9%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: How to enable permanent full screen mode in appvm ?

2016-12-11 Thread Simon

Hi,

Le 2016-12-11 04:51, raahe...@gmail.com a écrit :

also,  firefox browsers freeze when fullscreen,  you have to use
chrome or chromium.


An issue has been created about this:

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

This is a regression coming with Qubes 3.2 since it was working nicely 
on Qubes R2: when switching a video to "full screen" it occupied the 
whole surface of the corresponding window (without resizing it 
automatically) and the window could then be freely manually resized at 
will (including making it full-screen: right-click on the window title > 
`Full Screen').


I found this to be a really nice feature since it was an easy way to get 
rid of any distracting web or Youtube interface and have a window 
showing just the video content while still having the possibility to 
have other windows around (like a text editor to take or check notes 
while watching the video).


Regards,
Simon.

--
You received this message because you are subscribed to the Google Groups 
"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/f45045890ddcdf004578e664d810c73b%40whitewinterwolf.com.
For more options, visit https://groups.google.com/d/optout.


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

2016-12-11 Thread Simon

Le 2016-12-11 07:36, Andrew David Wong a écrit :
That's strange. My dom0 dnf history shows all my updates, including 
recent ones.


Are you sure your dom0 has been getting updated? How are you performing 
updates?


Hello Andrew,

When I do `rpm -qa --last' I can list all installed and updated packages 
with the appropriates dates, so I can confirm that dom0 gets correctly 
updated:


 8< 

[user@dom0 ~]$ rpm -qa --last | head
perf-4.8.12-100.fc23.x86_64   Sat Dec 10 18:10:11 2016
pciutils-libs-3.5.2-1.fc23.x86_64 Sat Dec 10 18:10:11 2016
pciutils-3.5.2-1.fc23.x86_64  Sat Dec 10 18:10:11 2016
dnsmasq-2.76-2.fc23.x86_64Thu Dec  8 23:33:14 2016
dmidecode-3.0-6.fc23.x86_64   Thu Dec  8 23:33:13 2016
qubes-input-proxy-1.0.8-1.fc23.x86_64 Thu Dec  8 23:33:12 2016
qubes-gpg-split-dom0-2.0.24-1.fc23.x86_64 Thu Dec  8 23:33:12 2016
perl-Time-Local-1.250-1.fc23.noarch   Thu Dec  8 23:33:11 2016
kernel-qubes-vm-4.4.31-11.pvops.qubes.x86_64  Thu Dec  8 23:33:06 2016
kernel-4.4.31-11.pvops.qubes.x86_64   Thu Dec  8 23:32:57 2016

 8< 

To update, I simply use the Qubes VM Manager. The only things which may 
be noticeable are the following:


- Usually I update all the templates and Dom0 simultaneously: I right 
click on the AppVM template and click `Update VM', I do this for each 
AppVM in a row (without waiting for the update of the previous AppVM to 
terminate) and finally for Dom0 (since it locks access to the Qubes VM 
Manager during the while Dom0 update process, which is the longest, see 
below).


- I have the impression that Dom0 updates are downloaded twice, most 
probably an issue around the proxy feature (there is no such issue with 
the templates, updating Dom0 takes twice as much time as updating the 
templates).


- I regularly have ghost updates (the icon announcing that updates are 
available while there are none) but I think this is a known issue.


Best regards,
Simon.

--
You received this message because you are subscribed to the Google Groups 
"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/d3a6b9e1a88e31c6d9ab8a2b936de214%40whitewinterwolf.com.
For more options, visit https://groups.google.com/d/optout.