[qubes-users] Re: Just realized one of the major disadvantages of Qubes OS...

2017-01-25 Thread pixel fairy
On Wednesday, January 25, 2017 at 7:12:56 PM UTC-8, jkitt wrote:
> On Tuesday, 24 January 2017 11:54:34 UTC, qmast...@gmail.com  wrote:
> 
> > I was sad when installed VirtualBox, tried launching it and it said that 
> > something like "not supported on Xen hosts"
> 
> But why would you want to do that? You already have virtual machines at your 
> disposal..

for development purposes, you might want other kinds. for example, vagrant is a 
big sticking point. its how we share and collaborate across platforms, so if 
you want to work on those projects, you better be able to run its vagrantfile. 
its also used as codified description of processes, sometimes across machines. 
so you can have a vagrantfile for your a web project that includes a vm for the 
back end database. more on that here, https://www.vagrantup.com/ 

another reason you might want it is nested virtualization for its own sake. for 
example, developing hypervisor management software.

for both cases, i just made a vagrant server to use remotely. but that has 
obvious limitations. 

-- 
You received this message because you are subscribed to the Google Groups 
"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/9d9aba2e-0e6e-4e77-b549-3d30c12ea788%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Just realized one of the major disadvantages of Qubes OS...

2017-01-25 Thread jkitt
On Tuesday, 24 January 2017 11:54:34 UTC, qmast...@gmail.com  wrote:

> I was sad when installed VirtualBox, tried launching it and it said that 
> something like "not supported on Xen hosts"

But why would you want to do that? You already have virtual machines at your 
disposal..

-- 
You received this message because you are subscribed to the Google Groups 
"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/92fe7061-0ef1-4d28-9ebe-bf9e927f9b39%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] fixed desktop numbers for VMs or at least fixed start desktop for a VM?

2017-01-25 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-01-25 17:26, Oleg Artemiev wrote:
> I'm lazy enough to still use old Qubes. Is it possible to assign
> fixed start desktop (or range) for a VM in new Qubes? Ability to
> bind last window position for next session start is also a good
> motivation to upgrade. Qubrs VM manager may appear on diffrent
> desktop and this is annoying. It would be grate to be able to
> configure 20 virtual desktops and assign their ranges to a specific
> VM.
> 

You'd need to install a program for this in Qubes 3.2. There was a
thread about it:

https://groups.google.com/d/topic/qubes-users/jtjyq8N6bY0/discussion

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

iQIcBAEBCgAGBQJYiVS2AAoJENtN07w5UDAwMNwQAIecrazZ+Fvva8OApD7f3tmL
Iv0CCrbQTa/2eqpYOJoCuUrQlE7dl3MdGhl8vknPtW5G22zlc3R0fc4sAjMwKpi2
5FY+lQ+xAUxkzTEvQPqMDYDxMMQBPOiFyQ0CqC56yekRDDp0Ke0HCsseYP5o9YhW
kIaFi7frNCA/F53az8s1RTV7A0j+8xaePmxK+UwF2tRNJ0hkOq9f0Jj48vTlxNgE
LPV4FdPSBXThoIGnoygjetshnPjvdIEcct0DABeh2NfTF7zr0RWLqqBvLtkj/Esf
GX+gTyltz4FIooBw2QONh8g+0Nrw2K0SUrMLk5OL2YilIq31/JFXA55pfUlytOAd
CRwYI1LvITp6fd3Xe/+ZBYeg1k1GubnAb4DXqZZIN6c39wzqvlXQCnLbnHtvHlLP
B0Cd3XDOe7rDNv50ld8DmI8hTq9vWqy/hZ35BLFQ5aNb5aIj8pSN06gLKi5OkJqB
b950CfW/o5yGjr/n/FCsXL3S6CICFhJzdhX7d+u3rT8UrcoG9Z5yg5mh0Hh80Vxg
pRFxZIxRl+42wIAByVK86vaM7WcDqzV95W4fjP+IAELMsGb0Mc9FXV+f1vWR9IA4
QEufZuioU6rNpLi0Ey5fBu2E3X0HmWw5cpisWkPSEoNQB1zM62krwfKthWJ19gGi
uoJ5Pwc/KJpsBbnLxme+
=bL8i
-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/da08a5ed-fbfd-6079-4a71-a6573e150763%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Unable to start any VM. Getting: error starting vm: internal error: unable to reset PCI device 0000:

2017-01-25 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-01-25 14:22, Pietro Speroni di Fenizio wrote:
> On Wednesday, January 25, 2017 at 11:13:54 PM UTC+1, Andrew David Wong wrote:
> On 2017-01-25 13:27, Pietro Speroni di Fenizio wrote:
 Hello, we just installed a Qubes in a linux machine I had.

 Unfortunately the system seem to be unable to start any VM.

 I always get the same error: ERROR: internal error: unable to reset
 PCI device :03:00.2 internal error: Active :03:00.0 devices
 on bus with 000:03:00.2, not doing bus reset

 Can someone point me to the right direction? I seem stuck as
 anything requires me first to start a VM, but no VM seem to be able
 to start. In fact when the computer turns on at the beginning only
 dom0 is active and even sys-net and sys-firewall are inactive.

 Many thanks, Pietro

> 
> It sounds like you have this device assigned to more than one VM.
> Check the "Devices" tab in the VM Settings for each VM that has any
> devices assigned to it.
> 
> 
> Thanks,
> I just checked. Nothing is assigned in the other VM. Only sys-net had 2 of 
> the three PCI assigned. Once I assigned the third it started working. But now 
> it gives me a Device not Managed next to the red network icon above.
> 
> Thank you very much
> 

Have you tried setting pci_strictreset to false? (Make sure you understand the 
security implications first.)

https://www.qubes-os.org/doc/user-faq/#i-created-a-usbvm-and-assigned-usb-controllers-to-it-now-the-usbvm-wont-boot

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

iQIcBAEBCgAGBQJYiVQ5AAoJENtN07w5UDAwXRsP/1miXII9AR/4fTQ5rHQGMGUs
/zDhB098GKLgfP+x415tV376HjcGVuLM2wD61BTx+6etJdljwjwvuQ9YSzCYX4Uy
AMzIPlwmC/H7/Mqi0L2Dv95paNepKQnOin+W3uFWqejhOInMSR7mwYm5Nb0HBbRu
omsMQ9hsGwjpE6FErbT6H15D9mVYlDSGI8+pHqTciTMZgRQORXz8vUUJB1b6lQ+0
BRoflHllYKILVmQd4QL9nzO3fBEApgSPf4Psmvzl+V4wxt2seL27hux5lqgzay9l
VgPeNkMfmUqWXQodfy/9NP0Vb1YwZpTumCiDNDDxO20ju8cwgn6bMe1rd3CMsDB8
lSJZRnJ93tYh12IXbxd1vkaORH47HtZhfXEHSsuBNic8kazHhIDjQhawYfVFQnXd
S4waYC/cdE2NlJqRNrCyjbyUJxD4i1Wq+MvVjm7u4WnAwlJAcMw1vGR8RsxUg9VD
W8jkyCLTNk3JTC1sydTHH++uZ4z6RZ77WaPgVmsB2Wnw/63iiHbqiomLniPJLsrS
FI2r2YgNm+SE/LsM4hVzug7cKnlrL2dwBmEOcRhDn1qHLe+66rxxrAWGT9lsjxh7
Vni+SR40kAkgP/PZAbiAoI+7o3UXnUVoKKRH7eC4GwzQ2B9q6nWMj21uY0W79Njc
84Ko8UGtCu0PNezI/5jr
=YE9m
-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/f03031a3-fb7e-a077-9339-b3341e2632f8%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] fixed desktop numbers for VMs or at least fixed start desktop for a VM?

2017-01-25 Thread Oleg Artemiev
I'm lazy enough to still use old Qubes. Is it possible to assign fixed
start desktop (or range) for a VM in new Qubes? Ability to bind last
window position for next session start is also a good motivation to
upgrade. Qubrs VM manager may appear on diffrent desktop and this is
annoying.
It would be grate to be able to configure 20 virtual desktops and
assign their ranges to a specific VM.

-- 
Bye.Olli.
gpg --search-keys grey_olli , use key w/ fingerprint below:
Key fingerprint = 9901 6808 768C 8B89 544C  9BE0 49F9 5A46 2B98 147E
Blog keys (the blog is mostly in Russian): http://grey-olli.livejournal.com/tag/

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


Re: [qubes-users] Unable to start any VM. Getting: error starting vm: internal error: unable to reset PCI device 0000:

2017-01-25 Thread Pietro Speroni di Fenizio
On Wednesday, January 25, 2017 at 11:13:54 PM UTC+1, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 2017-01-25 13:27, Pietro Speroni di Fenizio wrote:
> > Hello, we just installed a Qubes in a linux machine I had.
> > 
> > Unfortunately the system seem to be unable to start any VM.
> > 
> > I always get the same error: ERROR: internal error: unable to reset
> > PCI device :03:00.2 internal error: Active :03:00.0 devices
> > on bus with 000:03:00.2, not doing bus reset
> > 
> > Can someone point me to the right direction? I seem stuck as
> > anything requires me first to start a VM, but no VM seem to be able
> > to start. In fact when the computer turns on at the beginning only
> > dom0 is active and even sys-net and sys-firewall are inactive.
> > 
> > Many thanks, Pietro
> > 
> 
> It sounds like you have this device assigned to more than one VM.
> Check the "Devices" tab in the VM Settings for each VM that has any
> devices assigned to it.
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> -BEGIN PGP SIGNATURE-
> 
> iQIcBAEBCgAGBQJYiSMSAAoJENtN07w5UDAw7P4P+wYMA1LsNPhGqKLKZuGLICgk
> MfxYtldPdbhlLRC1RFx6bKTdZxpUVpSVtfNszKS56/0dZERonfKwMcGREvZxdHvu
> lMxSVvfsPqPG436MH8mEDNU9iMBttNzPKC5tuoxhLGJBz+GPvi708nDRvAXWFylY
> IbaU7cih0/7IF8JgQ7/qgE5g4xbGY8nStsJby6aPxumtcrXzt6NHTnFE31KeVDEh
> Rw4nARrOc2wrTH6PrEF6AEMjORQbXJau9pzsmQSSFMyLTIpiLIa9LBrEtaRwC6fM
> PXJ+NvYtu8YDVT7sli7mdhsdpN0sS83W2ao78yKyfjLHjtPt72o+xLC5a2Y0jg2L
> 537EROJpCRpjiwgH5myDSBtGfbfHXzU0d3D9Va6mClxWDPnZ6eThc0/R4ds0CcnN
> F2SQsq3LZrXEN1HO2Ec3rUL/AnR2LSuQBRIwznOg+5Q7y9InUcpdO9vQyQPyVl2Q
> mWgxc+13nl0DweCNpugbrOa8DXyEKYjt93IuW2/83wG7wQykCDZwkGM2y7sFdBFh
> r1bgNpQU2NnN0r6IFHMCcjOV//X54cWYUWVFEHw/AZk86FybclyIhsX/0qFeCvj5
> dgzOD1HLQyOfVH6YKPzglB1GEPelqaEDTri2Jpwx+fR47zyr3UbdM2yrTVOU99WP
> 3R04DPOH5UV2m/jUxzYP
> =6Ai6
> -END PGP SIGNATURE-

Thanks,
I just checked. Nothing is assigned in the other VM. Only sys-net had 2 of the 
three PCI assigned. Once I assigned the third it started working. But now it 
gives me a Device not Managed next to the red network icon above.

Thank you very much

-- 
You received this message because you are subscribed to the Google Groups 
"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/2129ba99-cd38-4f01-bba3-35491642d482%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Suggestions for RBAC for grsecurity-enabled kernel?

2017-01-25 Thread Kopimi Security
On Wednesday, January 25, 2017 at 6:22:14 PM UTC+1, raah...@gmail.com wrote:
> On Tuesday, January 24, 2017 at 9:15:10 AM UTC-5, Kopimi Security wrote:
> > On Monday, January 23, 2017 at 8:38:56 PM UTC+1, Reg Tiangha wrote:
> > > Yeah, I tried it myself leaving my laptop turned on and on learning mode
> > > for three weeks straight, but it didn't catch everything and certain
> > > things still failed so there's definitely some manual massaging that
> > > needs to be done.
> > 
> > Thank you for your input!
> > 
> > Would you think a sniffing approach, or a tripwire approach, to be better*?
> > 
> > * On a RAM-limited system
> 
> what do you mean by sniffing approach?  

Sorry for being unclear, I'm not a native speaker.

By "sniffing", I meant to refer to active monitoring of known attack types,  a 
pro-active approach as opposed to a more after-the-fact intrusion detection 
system.
Kind of like watchdogs for memory, and snort for ports.

Google recently wrote up some advice for hardening KVMs: 
https://cloudplatform.googleblog.com/2017/01/7-ways-we-harden-our-KVM-hypervisor-at-Google-Cloud-security-in-plaintext.html

Their number one advice is using a pro-active approach.

-- 
You received this message because you are subscribed to the Google Groups 
"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/02fa0201-0f4f-43c4-a786-164a6147d35d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Unable to start any VM. Getting: error starting vm: internal error: unable to reset PCI device 0000:

2017-01-25 Thread Pietro Speroni di Fenizio

> If you run lspci in dom0 you will get the list of devices and their bus 
> numbers. If you look for devices on :03:00  this should give clues about 
> what is going on.

Thank you. So apparently the 03:00.2 is the Ethernet controller,
the 03:00.0 is a PCI express card reader.

In any case I went to the sys-netVM under VM settings> devices and made sure to 
move all three on the selected list (that was an intuition after seeing part of 
the video in the quebes that spoke about pci). After that it did not give mt 
that error anymore. We have moved on the the next error :-).

I get an Ethernet Network Device not managed.

I added a "vpn connection" or at least I opened vpn connection, and added the 
data of my wifi, security and password. 
SSID: [ssid name
Mode: hotspot
Band: Automatic
Channel: default
Device: LEFT THIS BLANK
Wi-fi security: [wrote the password]

But apparently that is not enough.

Thanks again for any hint

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


Re: [qubes-users] Unable to start any VM. Getting: error starting vm: internal error: unable to reset PCI device 0000:

2017-01-25 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-01-25 13:27, Pietro Speroni di Fenizio wrote:
> Hello, we just installed a Qubes in a linux machine I had.
> 
> Unfortunately the system seem to be unable to start any VM.
> 
> I always get the same error: ERROR: internal error: unable to reset
> PCI device :03:00.2 internal error: Active :03:00.0 devices
> on bus with 000:03:00.2, not doing bus reset
> 
> Can someone point me to the right direction? I seem stuck as
> anything requires me first to start a VM, but no VM seem to be able
> to start. In fact when the computer turns on at the beginning only
> dom0 is active and even sys-net and sys-firewall are inactive.
> 
> Many thanks, Pietro
> 

It sounds like you have this device assigned to more than one VM.
Check the "Devices" tab in the VM Settings for each VM that has any
devices assigned to it.

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

iQIcBAEBCgAGBQJYiSMSAAoJENtN07w5UDAw7P4P+wYMA1LsNPhGqKLKZuGLICgk
MfxYtldPdbhlLRC1RFx6bKTdZxpUVpSVtfNszKS56/0dZERonfKwMcGREvZxdHvu
lMxSVvfsPqPG436MH8mEDNU9iMBttNzPKC5tuoxhLGJBz+GPvi708nDRvAXWFylY
IbaU7cih0/7IF8JgQ7/qgE5g4xbGY8nStsJby6aPxumtcrXzt6NHTnFE31KeVDEh
Rw4nARrOc2wrTH6PrEF6AEMjORQbXJau9pzsmQSSFMyLTIpiLIa9LBrEtaRwC6fM
PXJ+NvYtu8YDVT7sli7mdhsdpN0sS83W2ao78yKyfjLHjtPt72o+xLC5a2Y0jg2L
537EROJpCRpjiwgH5myDSBtGfbfHXzU0d3D9Va6mClxWDPnZ6eThc0/R4ds0CcnN
F2SQsq3LZrXEN1HO2Ec3rUL/AnR2LSuQBRIwznOg+5Q7y9InUcpdO9vQyQPyVl2Q
mWgxc+13nl0DweCNpugbrOa8DXyEKYjt93IuW2/83wG7wQykCDZwkGM2y7sFdBFh
r1bgNpQU2NnN0r6IFHMCcjOV//X54cWYUWVFEHw/AZk86FybclyIhsX/0qFeCvj5
dgzOD1HLQyOfVH6YKPzglB1GEPelqaEDTri2Jpwx+fR47zyr3UbdM2yrTVOU99WP
3R04DPOH5UV2m/jUxzYP
=6Ai6
-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/b0271ec1-59d1-61d0-4c9c-7c1271cf3e9d%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Linux HVM through Whonix Gateway or VPN

2017-01-25 Thread Ángel
Chris Bensch wrote:
> I'm running Qubes 3.2.  I have a Debian HVM that works perfect when using the 
> default sys-firewall as the netvm.  If I change the netvm to another proxyvm 
> such as a VPN (https://github.com/Rudd-O/qubes-vpn) or change it to the 
> default sys-whonix, I lose all connectivity.  Can someone point me in the 
> right direction?
> 

Do you have it configured using a static IP address? I would try
manually changing the route to the configured NetVM.

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


Re: [qubes-users] qubes r3.2 bricked

2017-01-25 Thread Ángel
Bernhard wrote:
> Thank you Angel, for helping me.
> 

You're welcome, Bernhard.


> and, as I said, nothing starts. I start thinking of a disaster-mode data
> recovery since I do not know how I could possibly unbrick a system that
> has no network anymore?! 

That's just because most VMs depends on sys-net, and sys-net is not
available. Can you still edit them with Qubes VM Manager? The VMs should
at least start if you set their NetVM to none. Then you could create a
new sys-vm if it still doesn't get fixed.

Best

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


[qubes-users] Re: Unable to start any VM. Getting: error starting vm: internal error: unable to reset PCI device 0000:

2017-01-25 Thread bbrr3332
On Wednesday, January 25, 2017 at 9:27:10 PM UTC, Pietro Speroni di Fenizio 
wrote:
> Hello,
> we just installed a Qubes in a linux machine I had.
> 
> Unfortunately the system seem to be unable to start any VM.
> 
> I always get the same error:
> ERROR: internal error: unable to reset PCI device :03:00.2
> internal error: Active :03:00.0 devices on bus with
> 000:03:00.2, not doing bus reset
> 
> Can someone point me to the right direction? I seem stuck as anything 
> requires me first to start a VM, but no VM seem to be able to start. In fact 
> when the computer turns on at the beginning only dom0 is active and even 
> sys-net and sys-firewall are inactive.
> 
> Many thanks,
> Pietro

If you run lspci in dom0 you will get the list of devices and their bus 
numbers. If you look for devices on :03:00  this should give clues about 
what is going on.

-- 
You received this message because you are subscribed to the Google Groups 
"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/6d3ffc21-2e6f-421a-9584-2440618c5b39%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Unable to start any VM. Getting: error starting vm: internal error: unable to reset PCI device 0000:

2017-01-25 Thread Pietro Speroni di Fenizio
Hello,
we just installed a Qubes in a linux machine I had.

Unfortunately the system seem to be unable to start any VM.

I always get the same error:
ERROR: internal error: unable to reset PCI device :03:00.2
internal error: Active :03:00.0 devices on bus with
000:03:00.2, not doing bus reset

Can someone point me to the right direction? I seem stuck as anything requires 
me first to start a VM, but no VM seem to be able to start. In fact when the 
computer turns on at the beginning only dom0 is active and even sys-net and 
sys-firewall are inactive.

Many thanks,
Pietro

-- 
You received this message because you are subscribed to the Google Groups 
"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/65f4422b-4578-486e-8e5f-ac7c1c5e1929%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Spoofing MAC

2017-01-25 Thread Sae
 Forwarded Message ---

Subject:Re: [qubes-users] Spoofing MAC
Date:   Wed, 25 Jan 2017 20:52:35 +0100
From:   Sae 
To: pl1...@sigaint.org



On 25/01/2017 20:34, pl1...@sigaint.org wrote:
> Hi
> I followed the guide that explains how to spoof MAC using debian based
> appVM. Now will my ISP "see" this new or it anonymize just my surfing?
>
Hello.
You ISP never sees your MAC. Your MAC is used for the communication
between your computer and your router.
Spoofing your MAC is usefull in networks which are not under your
control (hotspots, school, work, …).
Then, from that network point of view, your computer won't identify
itself with your mac address that is closely tied to your computer hardware.
Spoofing your mac address has no impact on your IP address, so it won't
anonymise your surfing.

forwarding because I forgot to send to the list. 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To 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/7b18c8fa-cd6f-5376-4a4a-63ef2fae04ca%40nopping.eu.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Spoofing MAC

2017-01-25 Thread pl11ty
Hi
I followed the guide that explains how to spoof MAC using debian based
appVM. Now will my ISP "see" this new or it anonymize just my surfing?

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


[qubes-users] Re: Suggestions for RBAC for grsecurity-enabled kernel?

2017-01-25 Thread raahelps
On Wednesday, January 25, 2017 at 12:39:07 PM UTC-5, Reg Tiangha wrote:
> On 2017-01-25 10:24 AM, raahe...@gmail.com
> wrote:
> 
> > 
> > It should tell you what rbac is blocking in dmesg or journal no?  it will 
> > say gradm I believe.   You should also be seeing grsec and pax messages in 
> > there as well.
> > 
> 
> It probably did, although sometimes it'll say what was killed, but not
> specifically why. For example, if a process is denied access to a
> directory (ex. /var/run or something), it may not be specific enough.
> 
> But in my case, during training, there's a lot of crap that goes into
> dmesg, and I didn't discover the actual issues until I restarted the
> machines with the new rulesets and I never saved the syslogs before
> rebooting. In the case of the UpdateVM where no AppVMs were able to
> connect to it and thus wouldn't start, absolutely nothing appeared in
> the UpdateVMs logs, dmesg or otherwise. I assume it's some kind of Qubes
> process on the UpdateVM that failed to start (or it did but kills
> whatever is responsible for allowing an AppVM to connect), but I have no
> idea which one; like I said, the developer documentation is a bit
> lacking in terms of specifying what exact processes are responsible for
> certain tasks, and I think the architecture document is like 10 years
> old now and doesn't even reflect how the system works currently.
> 
> Anyways, I'm sure with some more troubleshooting I'd eventually be able
> to figure it out, but like I've said, I've dumped enough hours into this
> as it is. I'm hoping someone out there with more skill will be able to
> come up with a generic Qubes RBAC policy rule set, since I believe it's
> something the Qubes community could share among ourselves as whatever
> base rules are needed for the Qubes/Xen architecture to work properly
> under RBAC would be consistent across all VMs.
> 
> >
> > yes you can shut down the system in the middle of training.
> >
> 
> Ah, I did not know that. Will it pick up and append where it left off
> training wise on the next reboot? Or will it overwrite the training log?
> It did not occur to me to shut down in the middle because all the
> examples in the documentation say to put the learning log in /etc/grsec,
> so I just did it knowing that it'd get blown away on the next reboot. It
> didn't occur to me until after I finished testing that perhaps I should
> have put those logs in /home instead. But like I said, at that point, I
> had already wasted 3 weeks worth of time, and I didn't feel like trying
> again. Maybe I'll try again later, but I don't have the time right now.

well you got further then I ever did, lol,  if you get it working let us know.

-- 
You received this message because you are subscribed to the Google Groups 
"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/5a5e4ef5-c4d8-42ba-8556-3d96b4332ce8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Suggestions for RBAC for grsecurity-enabled kernel?

2017-01-25 Thread Reg Tiangha
On 2017-01-25 10:24 AM, raahe...@gmail.com
wrote:

> 
> It should tell you what rbac is blocking in dmesg or journal no?  it will say 
> gradm I believe.   You should also be seeing grsec and pax messages in there 
> as well.
> 

It probably did, although sometimes it'll say what was killed, but not
specifically why. For example, if a process is denied access to a
directory (ex. /var/run or something), it may not be specific enough.

But in my case, during training, there's a lot of crap that goes into
dmesg, and I didn't discover the actual issues until I restarted the
machines with the new rulesets and I never saved the syslogs before
rebooting. In the case of the UpdateVM where no AppVMs were able to
connect to it and thus wouldn't start, absolutely nothing appeared in
the UpdateVMs logs, dmesg or otherwise. I assume it's some kind of Qubes
process on the UpdateVM that failed to start (or it did but kills
whatever is responsible for allowing an AppVM to connect), but I have no
idea which one; like I said, the developer documentation is a bit
lacking in terms of specifying what exact processes are responsible for
certain tasks, and I think the architecture document is like 10 years
old now and doesn't even reflect how the system works currently.

Anyways, I'm sure with some more troubleshooting I'd eventually be able
to figure it out, but like I've said, I've dumped enough hours into this
as it is. I'm hoping someone out there with more skill will be able to
come up with a generic Qubes RBAC policy rule set, since I believe it's
something the Qubes community could share among ourselves as whatever
base rules are needed for the Qubes/Xen architecture to work properly
under RBAC would be consistent across all VMs.

>
> yes you can shut down the system in the middle of training.
>

Ah, I did not know that. Will it pick up and append where it left off
training wise on the next reboot? Or will it overwrite the training log?
It did not occur to me to shut down in the middle because all the
examples in the documentation say to put the learning log in /etc/grsec,
so I just did it knowing that it'd get blown away on the next reboot. It
didn't occur to me until after I finished testing that perhaps I should
have put those logs in /home instead. But like I said, at that point, I
had already wasted 3 weeks worth of time, and I didn't feel like trying
again. Maybe I'll try again later, but I don't have the time right 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/o6anqh%248d4%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Suggestions for RBAC for grsecurity-enabled kernel?

2017-01-25 Thread raahelps
On Wednesday, January 25, 2017 at 12:24:57 PM UTC-5, raah...@gmail.com wrote:
> On Tuesday, January 24, 2017 at 10:32:18 AM UTC-5, Reg Tiangha wrote:
> > On 2017-01-24 7:15 AM, Kopimi Security wrote:
> > > On Monday, January 23, 2017 at 8:38:56 PM UTC+1, Reg Tiangha wrote:
> > >> Yeah, I tried it myself leaving my laptop turned on and on learning mode
> > >> for three weeks straight, but it didn't catch everything and certain
> > >> things still failed so there's definitely some manual massaging that
> > >> needs to be done.
> > > 
> > > Thank you for your input!
> > > 
> > > Would you think a sniffing approach, or a tripwire approach, to be 
> > > better*?
> > > 
> > > * On a RAM-limited system
> > > 
> > 
> > That could help with the networking stuff. When I said stuff failed for
> > me, I meant more along the lines of certain services or processes that
> > were getting killed by the kernel that may or may not be integral to the
> > way Qubes does things.
> > 
> > For example, I have both a FirewallVM and an caching UpdateVM running
> > squid. The only real difference between the two is squid; otherwise, the
> > UpdateVM is just a glorified FirewallVM. Therefore, one would expect
> > that the final RBAC ruleset after training between the two would only
> > differ with the squid bits.
> > 
> > After my training and applying the custom rulesets for each VM, for
> > whatever reason, no AppVM could connect to the UpdateVM once it was
> > active (and therefore, the AppVM wouldn't start), but they had no
> > problems connecting to the FirewallVM. So obviously, something was
> > missed when training the UpdateVM, but I don't know what it was.
> > Furthermore, since I don't know how Qubes is archetectured and what
> > binaries and libraries are responsible for certain functions (or even
> > where they live!), I don't know what to whitelist. And I don't want to
> > whitelist entire directories that have or need access for Qubes or Xen
> > bits like /usr/bin or /var because I'd be whitelisting a bunch of other
> > things I wouldn't want to be doing either.
> > 
> > That's just one example, though. There were some other things I
> > encountered as well, but I also concede that some measure of manual
> > massaging of rules is probably going to be inevitable in the end.
> > 
> > Could I figure out exactly what was failing with enough time by tracing
> > logs and whatnot? Sure, I suppose. But I've sunk in a lot of hours into
> > this project already so I don't have as much time to troubleshoot as I
> > did over the holidays. So I'm hoping someone smarter than me can figure
> > out next steps, at least when it comes to the RBAC stuff. Or at least
> > give some hints on what may need to be white listed.
> > 
> > When it comes to the unexpected behaviors that I encountered, I'm still
> > leaning towards certain things in the Qubes/Xen chain for various use
> > cases that are getting killed without warning that the training didn't
> > catch to add to its whitelist. The Grsecurity documentation says that a
> > process or library needs to be triggered at least four times during the
> > training in order for it to be a bit more lax when it comes time to
> > analyze the training log and whitelist more things related to that
> > binary or library rather than just whitelisting the binary or library on
> > its own, and so maybe certain processes that are needed for Qubes to
> > operate just weren't being called enough even after having three weeks
> > worth of training.
> > 
> > For example, stuff being called during start up and shut down would
> > never trigger that four time threshold, and it'd be hard to record since
> > an AppVM's root file system would be nuked every time (in fact, if
> > you're not careful with your training or how you invoke it, your VM may
> > not start because none of the Qubes startup processes would be captured
> > with the training; I worked around it by adding a line to rc.local to
> > start the training right away, which helped with start up, but I was
> > never able to find a way to capture what Qubes processes were
> > responsible when shutting down so I ended up having to kill all my VMs
> > to turn them off since RBAC would kill whatever processes were
> > responsible for shut down because it never caught them in its training).
> > 
> > Perhaps the training log could be made to be persistent by placing it
> > within /home, but I was under the impression that the system couldn't be
> > shut down in the middle of training. I could be mistaken, though, but I
> > never tried it regardless. I suppose one could write a shutdown script
> > that flushed the training log, the question would be when in the
> > shutdown process would it be called. It would need to be one of the last
> > things in the sequence, otherwise you would risk not catching everything
> > possible.
> 
> It should tell you what rbac is blocking in dmesg or journal no?  it will say 
> gradm I believe.   You should also be seeing 

[qubes-users] Re: Suggestions for RBAC for grsecurity-enabled kernel?

2017-01-25 Thread raahelps
On Tuesday, January 24, 2017 at 9:15:10 AM UTC-5, Kopimi Security wrote:
> On Monday, January 23, 2017 at 8:38:56 PM UTC+1, Reg Tiangha wrote:
> > Yeah, I tried it myself leaving my laptop turned on and on learning mode
> > for three weeks straight, but it didn't catch everything and certain
> > things still failed so there's definitely some manual massaging that
> > needs to be done.
> 
> Thank you for your input!
> 
> Would you think a sniffing approach, or a tripwire approach, to be better*?
> 
> * On a RAM-limited system

what do you mean by sniffing approach?  

 Tripwire is good to have but it will take alot of fine tuning as well so its 
not so noisy.  The open source version default setups are for outdated 
operating systems.  It also takes strict discipline so you don't miss nothing, 
don't forget to keep keys separate.

-- 
You received this message because you are subscribed to the Google Groups 
"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/99bff6b9-45da-44c3-a770-a77bdd96a94b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2017-01-25 Thread fredletamanoir
On Friday, July 15, 2016 at 3:34:12 PM UTC+2, Chris Laprise wrote:
> 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

Hi Chris,

can you confirm that AEM is working now on this preceise laptop :
LENOVO T450s (20BWS01D00)

If yes, please describe what is required to be modified/setup to make it work.

And if confirmed, can someone update the line on the HCL page ?
https://www.qubes-os.org/hcl/

Regards
--
Fred

-- 
You received this message because you are subscribed to the Google Groups 
"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/bd3423bf-4a89-40e7-8f2f-366528a733ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Redshift in dom0?

2017-01-25 Thread ms . amnesia
On Tuesday, January 24, 2017 at 7:16:54 PM UTC+1, Jimmy Axenhus wrote:
> Den 2017-01-24 kl. 18:34, skrev ms.amne...@donotusemy.info:
> > On Monday, January 23, 2017 at 4:22:56 PM UTC+1, Kopimi Security wrote:
> > 
> > The only "tweak" I still need is the mouse pointer, as it is unaffected by 
> > redshift on my Qubes.
> > 
> > Anyone any ideas about that?
> > 
> 
> 
> You need to disable the hardware cursor. It's a known limitation. [1]
> 
> I got this in /etc/X11/xorg.conf and it's doing the job nicely.
> 
> Section "Device"
> Identifier "Device0"
> Driver "radeon"   # Replace with your driver
> Option "SWCursor" "on"
> EndSection
> 
> 
> [1]: http://jonls.dk/redshift/

Thank you for the suggestion. There wasn't an xorg.conf on my system and 
generating one "broke" my desktop (only tty worked). I guess I'll have to live 
with the brighter cursor until I've smartened up on how to get the graphics 
drivers to work with xorg.conf.

A bit off-topic:
My laptop has an on-board Intel HD and additional Nvidia GT970m. I was able to 
install Qubes by switching the graphics to Discreet mode in the BIOS. I have 
read up on how to install Nvidia drivers, but apparently I didn't need them, 
unless I want to generate an xorg.conf.

My previous linux installation on this laptop didn't like the nouveau drivers 
and was only willing to play nicely if I installed the Nvidia drivers, but 
somehow it also worked with the on-board intel HD while being in MSHybrid mode 
(BIOS). I'm still unsure what exactly the MSHybrid mode does, switching it to 
Discreet seems to disable the on-board Intel HD as lspci only lists the Nvidia.

Maybe one day I'll figure it all out. Having a fully functioning Qubes laptop  
with a wonky mouse pointer is more than I expected. :)

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


[qubes-users] Linux HVM through Whonix Gateway or VPN

2017-01-25 Thread Chris Bensch
I'm running Qubes 3.2.  I have a Debian HVM that works perfect when using the 
default sys-firewall as the netvm.  If I change the netvm to another proxyvm 
such as a VPN (https://github.com/Rudd-O/qubes-vpn) or change it to the default 
sys-whonix, I lose all connectivity.  Can someone point me in the right 
direction?

-- 
You received this message because you are subscribed to the Google Groups 
"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/280f12a5-6f63-4186-948a-562f11bbba50%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Cannot persistently mount extra partitions

2017-01-25 Thread Connor Page
you can specify your modified config copy in qvm-start 
--custom-config=/path/to/config vm-name

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


Re: [qubes-users] qubes r3.2 bricked

2017-01-25 Thread Bernhard
On 24/01/2017 23:30, Ángel wrote:
> Bernhard wrote:
>> Hello, I bricked my system a bit. Yesterady I decided  to follow the
>> ..onion update procedure. For dom0 all went well (after reading that I
>> must change to whonix-net),but I had to modify the debian-8 and
>> fedora-24 repo-files "by hand". No big deal. I could update f24 (this
>> morning), but debian bugged a bit. Suddenly I thought that maybe I had
>> to put netVM to whonix for the templateVM's as well. With a doubt on it
>> I looked up what I did with f24 .. and there, by accident I let the
>> dropdown box on "sys-net" instead on sys-firewall (or whonix-net).
> I would expect that this would make you lose the firewall protection...
>
>
>> Immediately sys-net derailed and lost network. 
> ...not sys-net to die.
>
>
> Is any of your /var/lib/qubes/*/*/firewall.xml files 0-bytes?
> (if so, delete it -so it gets replaced with default settings- and
> restart)
>
Thank you Angel, for helping me.

me@dom0 qubes]$find /var/lib/qubes -iname *.xml

finds only some files qubes-*somedate* in backup two xml fies in updates
and qubes.xml itself. When I run in

me@dom0 qubes]$ dom0qvm-start [some appvm] I get  some lines like


File "/usr/bin/qvm-start, line 136 then 120

File "/usr/lib64/python2.7/../000QubesVM.py

File "/usr/lib64/python2.7/../006QubesProxyVM.py

qubes.qdb.Error: (2, 'No such file or directory')


and, as I said, nothing starts. I start thinking of a disaster-mode data
recovery since I do not know how I could possibly unbrick a system that
has no network anymore?! I add some history: after having changed to the
.onion repo's,  the fedora24 system suggested 123(!) package updates (I
agreed). That seemed a lot to me, since I check for updates every day.
If I have to guess, it is there that it became a brick. Is it sure that
the f24 on qubes-os.org and the onion repo are the same? Can I unroll
the last update?

Thank you for any hint or help  Bernhard

-- 
You received this message because you are subscribed to the Google Groups 
"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/3e0562fc-916d-72aa-8aa2-656bd6428c63%40web.de.
For more options, visit https://groups.google.com/d/optout.