[qubes-users] [bug] qubes-guid crashes when putting debian-9 VM in true XFCE fullscreen

2017-01-19 Thread Andrew
Hi,

Sorry for the verbose title.  If I put a debian-9 VM in true fullscreen
in XFCE, I get a short hang, then the window disappears.  The VM then
goes 'yellow', and while I can xl console into the VM, I lose all windows.

The GUID log has:
ErrorHandler: BadAccess (attempt to access private resource denied)
 Major opcode: 130 (MIT-SHM)
 Minor opcode: 1 (X_ShmAttach)
 ResourceID:   0x440003c
 Failed serial number:  548
 Current serial number: 549

And indeed, using 'ps' in Dom0 shows that the corresponding qubes-guid
has crashed :(.

The VM dmesg logs are also filled with a bunch of messages like the
following:
[   15.385864] U2MFN_GET_MFN_FOR_PAGE: get_user_pages failed,
ret=0xfff2

I suspect this is related to my most recent qubes-guid update, as this
behavior never occurred before.

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"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/ef42c32b-0922-952a-df9d-7de7d15541cb%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Archlinux Community Template Qubes OS 3.2

2017-01-19 Thread Franz
On Thu, Jan 19, 2017 at 3:39 PM, 'Olivier Médoc' via qubes-users <
qubes-users@googlegroups.com> wrote:

> On 01/17/2017 02:00 PM, dfghsdhj...@gmail.com wrote:
> > Hi to all, new bug. Any ideas?
> >
> > error: failed to prepare transaction (could not satisfy dependencies)
> > :: qubes-vm-gui: installing xorg-server (1.19.1-1) breaks dependency
> 'xorg-server<1.19.0'
> >
>
> Hello,
>
> I'm currently trying to rebuild the gui-agent to fix this. I will
> provide feedback as soon as possible.
>
>
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/ea997223-0342-3614-7eee-2f8014793b84%40yahoo.fr.
> 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/CAPzH-qDsOdmk8QWgDvqvv0S%2BrzO2%3DKEmCAfRU%2BW0V%2B1g1S4daA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: OnionShare

2017-01-19 Thread haxy
> Valko quote:
> I can confirm it works on whonix appvm and whonix templatevm also without
> any modifications.

I was under the impression that it wasn't usable in whonix yet, at least
not safely.
A search in whonix forums for onionshare shows progress being made but not
ready yet.
Do you have other info?

http://kk63ava6.onion/wiki/Onionshare

"Using onionshare in Whonix will most likely be possible with the next
release, Whonix 14. By then, the documentation here will be updated."


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


Re: [qubes-users] Default UpdateVM and Issues while updating VM

2017-01-19 Thread Unman
On Thu, Jan 19, 2017 at 07:01:56PM -0500, Chris Laprise wrote:
> On 01/19/2017 05:46 PM, Unman wrote:
> >On Thu, Jan 19, 2017 at 10:02:38AM -0800, adonis28...@gmail.com wrote:
> >>On Thursday, January 19, 2017 at 12:22:35 PM UTC-5, Chris Laprise wrote:
> >>>On 01/18/2017 09:32 PM, wrote:
> Hi guys,
> 
> I'm having a hard time trying to figure out this. When I installed Qubes 
> OS I think I chose Whonix as the default to update VMs, but eventually I 
> ended up changing it after a couple of days and set the UpdateVM to 
> "sys-firewall".
> 
> Now, everything seems to be fine, except for when I try to upgrade the 
> Debian 8 template to Debian 9. No matter what I try, I keep getting this 
> sort of error after running apt-get update && apt-get upgrade:
> 
> ***
> E: Failed to fetch [...]  Unable to connect to 10.137.255.254:8082:
> E: Failed to fetch [...]  Unable to connect to 10.137.255.254:8082:
> ***
> 
> If you notice, it says it can't connect to that IP, which after debugging 
> I've found out corresponds to the Whonix Gateway VM! So for some reason 
> when I clone the current Debian 8 template and try to update it it tries 
> to do it through Whonix, and not through the sys-firewall VM as I have it 
> configured.
> 
> I've found something similar being described here: 
> https://forums.whonix.org/t/templates-incorrectly-think-theyre-not-connected-to-a-whonix-gateway/2258
>  . But in that case it is a Whonix VM suffering the issue, which makes 
> more sense...
> 
> So, in short, any idea or tips on how to properly (re)configure a VM so 
> the updates go through the sys-firewall VM and not through Whonix?!.
> 
> Cheers
> 
> >>>What it sounds like is the new debian template VM is not making any
> >>>connection at all, and the IP you're seeing is coming from a cache. It
> >>>should resolve itself and go away if you manage to correct the
> >>>connection issue.
> >>>
> >>>Sometimes when people configure VMs they inadvertently end up with
> >>>firewall settings that block everything. For a template VM, having "Deny
> >>>network access except" and "Allow connections to update proxy" are
> >>>normal. This works IF the sys-firewall and sys-net are basically default
> >>>and not configured with extra options like VPNs. You can also try
> >>>setting the debian VM to allow full access for 5 min. to see if that
> >>>allows it to connect during an update.
> >>>
> >>>Chris
> >>Hi Chris,
> >>
> >>Thanks for your response!.
> >>
> >>I do have a VPN set up, but I have that configured as per the docs (ProxyVM 
> >>as a VPN gateway): https://www.qubes-os.org/doc/vpn/. So I didn't 
> >>(purposely) modified anything in sys-firewall or sys-net.
> >>
> >>I have tried to enable full internet access, but it didn't work either. The 
> >>strange thing is that when I do that, I can ping let's say 8.8.8.8, or 
> >>resolve any domain, i.e. Debian repos...
> >>
> >>Cheers,
> >>
> >The IP that you are seeing is NOT the IP of the Whonix Gateway - at least
> >not just the address of the Whonix gateway. It is also the address set for
> >the qubes update proxy.
> >
> >Look in /etc/apt/apt.conf.d/01qubes-proxy, and you may find  the standard
> >Qubes proxy set-up.
> >
> >If this is the case, then the problem you have would seem to be that
> >you do not have the update proxy enabled on sys-firewall.
> >You can check this by looking at the nat table: you should see a
> >redirect to local port 8028 for all traffic addressed to 10.137.255.254.
> >
> >If that redirect is there then check that you have tinyproxy running.
> >If it isn't look at the page below and check your configuration on
> >sys-firewall, in particular that you have the qubes-updates-proxy
> >service enabled.
> >
> >You should be able to watch the traffic on sys-firewall using IP tables
> >iptables -L -nv  for normal and nat tables and seeing the counters
> >increment as you attempt to update.
> >If you don't see the counters going up then try resetting the debian-8
> >netvm again.
> >
> >The relevant page is:
> >www.qubes-os.org/doc/software-update-vm/  in the Updates proxy section.
> 
> IIRC the update proxy normally runs in sys-net, not proxy/firewall VMs.
> 
> If the VPN is between the template and sys-net, then the updates will be
> blocked as described. The way around this is to setup a proxy VM downstream
> from the VPN and have it run the update proxy.
> 
> But if its only template->sys-firewall->sys-net then it should be able to
> connect.
> 
> Chris

Yes, but as adonis28850 said he configured this as per the instructions
he will have to have the service running on the firewall below the VPN,
and this is explicitly in the instructions, so it seems natural to look
there. 

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

Re: [qubes-users] Default UpdateVM and Issues while updating VM

2017-01-19 Thread Chris Laprise

On 01/19/2017 05:46 PM, Unman wrote:

On Thu, Jan 19, 2017 at 10:02:38AM -0800, adonis28...@gmail.com wrote:

On Thursday, January 19, 2017 at 12:22:35 PM UTC-5, Chris Laprise wrote:

On 01/18/2017 09:32 PM, wrote:

Hi guys,

I'm having a hard time trying to figure out this. When I installed Qubes OS I think I 
chose Whonix as the default to update VMs, but eventually I ended up changing it after a 
couple of days and set the UpdateVM to "sys-firewall".

Now, everything seems to be fine, except for when I try to upgrade the Debian 8 
template to Debian 9. No matter what I try, I keep getting this sort of error after 
running apt-get update && apt-get upgrade:

***
E: Failed to fetch [...]  Unable to connect to 10.137.255.254:8082:
E: Failed to fetch [...]  Unable to connect to 10.137.255.254:8082:
***

If you notice, it says it can't connect to that IP, which after debugging I've 
found out corresponds to the Whonix Gateway VM! So for some reason when I clone 
the current Debian 8 template and try to update it it tries to do it through 
Whonix, and not through the sys-firewall VM as I have it configured.

I've found something similar being described here: 
https://forums.whonix.org/t/templates-incorrectly-think-theyre-not-connected-to-a-whonix-gateway/2258
 . But in that case it is a Whonix VM suffering the issue, which makes more 
sense...

So, in short, any idea or tips on how to properly (re)configure a VM so the 
updates go through the sys-firewall VM and not through Whonix?!.

Cheers


What it sounds like is the new debian template VM is not making any
connection at all, and the IP you're seeing is coming from a cache. It
should resolve itself and go away if you manage to correct the
connection issue.

Sometimes when people configure VMs they inadvertently end up with
firewall settings that block everything. For a template VM, having "Deny
network access except" and "Allow connections to update proxy" are
normal. This works IF the sys-firewall and sys-net are basically default
and not configured with extra options like VPNs. You can also try
setting the debian VM to allow full access for 5 min. to see if that
allows it to connect during an update.

Chris

Hi Chris,

Thanks for your response!.

I do have a VPN set up, but I have that configured as per the docs (ProxyVM as 
a VPN gateway): https://www.qubes-os.org/doc/vpn/. So I didn't (purposely) 
modified anything in sys-firewall or sys-net.

I have tried to enable full internet access, but it didn't work either. The 
strange thing is that when I do that, I can ping let's say 8.8.8.8, or resolve 
any domain, i.e. Debian repos...

Cheers,


The IP that you are seeing is NOT the IP of the Whonix Gateway - at least
not just the address of the Whonix gateway. It is also the address set for
the qubes update proxy.

Look in /etc/apt/apt.conf.d/01qubes-proxy, and you may find  the standard
Qubes proxy set-up.

If this is the case, then the problem you have would seem to be that
you do not have the update proxy enabled on sys-firewall.
You can check this by looking at the nat table: you should see a
redirect to local port 8028 for all traffic addressed to 10.137.255.254.

If that redirect is there then check that you have tinyproxy running.
If it isn't look at the page below and check your configuration on
sys-firewall, in particular that you have the qubes-updates-proxy
service enabled.

You should be able to watch the traffic on sys-firewall using IP tables
iptables -L -nv  for normal and nat tables and seeing the counters
increment as you attempt to update.
If you don't see the counters going up then try resetting the debian-8
netvm again.

The relevant page is:
www.qubes-os.org/doc/software-update-vm/  in the Updates proxy section.


IIRC the update proxy normally runs in sys-net, not proxy/firewall VMs.

If the VPN is between the template and sys-net, then the updates will be 
blocked as described. The way around this is to setup a proxy VM 
downstream from the VPN and have it run the update proxy.


But if its only template->sys-firewall->sys-net then it should be able 
to connect.


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/503230d2-064e-557a-dd9f-f68c4a4cff96%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Drive Passthrough not functioning correctly.

2017-01-19 Thread Unman
On Wed, Jan 18, 2017 at 05:22:01PM -0800, Drew White wrote:
> On Thursday, 19 January 2017 12:05:07 UTC+11, 01v3g4n10  wrote:
> > On Thursday, January 19, 2017 at 12:48:17 AM UTC, Drew White wrote:
> > > Hi folks,
> > > 
> > > Here is what I was trying to do..
> > > Pass the drive to the guest.
> > > 
> > > 
> > > [{user}@dom0 {folder}]$ qvm-block -a {vmname} dom0:/dev/sdc
> > > Usage: qvm-block -l [options]
> > > usage: qvm-block -a [options]  :
> > > usage: qvm-block -A [options]  :
> > > usage: qvm-block -d [options] :
> > > usage: qvm-block -d [options] 
> > > List/set VM block devices.
> > > 
> > > qvm-block: error: Invalid device name: dom0:/dev/sdc
> > > 
> > > 
> > > 
> > > Why does it say that it's invalid device?
> > > 
> > > Disk /dev/sdc: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
> > > 
> > > The device is there, so what's happenned?
> > > 
> > > Hope someone can help please.
> > > 
> > > Sincerely,
> > > Drew.
> > Try removing /dev/ from /dev/sdc and instead use dom0:sdc
> > qvm-block -a {vmname} dom0:sdc
> > https://www.qubes-os.org/doc/usb/
> 
> Same thing, just doesn't have the "/dev/" in the text...
> 
> Thanks for the link... Aparently.
> root@dom0 {folder}]$ xl block-attach {VMNAME} phy:/dev/sdc xvdr
> 
> I had to use that.
> 
> So that worked, but qvm-block doesn't.
> 
> Is this a bug in qvm-block?
> 

Hi Drew

Are you sure that sdc isn't already in use in dom0?
Those are the cases where I have been able to attach using xl but not
with qvm-block, and where qvm-block reports an invalid device name.

What's the output of qvm-block -l ?

unman

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


Re: [qubes-users] Default UpdateVM and Issues while updating VM

2017-01-19 Thread adonis28850
On Thursday, January 19, 2017 at 12:22:35 PM UTC-5, Chris Laprise wrote:
> On 01/18/2017 09:32 PM, wrote:
> > Hi guys,
> >
> > I'm having a hard time trying to figure out this. When I installed Qubes OS 
> > I think I chose Whonix as the default to update VMs, but eventually I ended 
> > up changing it after a couple of days and set the UpdateVM to 
> > "sys-firewall".
> >
> > Now, everything seems to be fine, except for when I try to upgrade the 
> > Debian 8 template to Debian 9. No matter what I try, I keep getting this 
> > sort of error after running apt-get update && apt-get upgrade:
> >
> > ***
> > E: Failed to fetch [...]  Unable to connect to 10.137.255.254:8082:
> > E: Failed to fetch [...]  Unable to connect to 10.137.255.254:8082:
> > ***
> >
> > If you notice, it says it can't connect to that IP, which after debugging 
> > I've found out corresponds to the Whonix Gateway VM! So for some reason 
> > when I clone the current Debian 8 template and try to update it it tries to 
> > do it through Whonix, and not through the sys-firewall VM as I have it 
> > configured.
> >
> > I've found something similar being described here: 
> > https://forums.whonix.org/t/templates-incorrectly-think-theyre-not-connected-to-a-whonix-gateway/2258
> >  . But in that case it is a Whonix VM suffering the issue, which makes more 
> > sense...
> >
> > So, in short, any idea or tips on how to properly (re)configure a VM so the 
> > updates go through the sys-firewall VM and not through Whonix?!.
> >
> > Cheers
> >
> 
> What it sounds like is the new debian template VM is not making any 
> connection at all, and the IP you're seeing is coming from a cache. It 
> should resolve itself and go away if you manage to correct the 
> connection issue.
> 
> Sometimes when people configure VMs they inadvertently end up with 
> firewall settings that block everything. For a template VM, having "Deny 
> network access except" and "Allow connections to update proxy" are 
> normal. This works IF the sys-firewall and sys-net are basically default 
> and not configured with extra options like VPNs. You can also try 
> setting the debian VM to allow full access for 5 min. to see if that 
> allows it to connect during an update.
> 
> Chris

Hi Chris,

Thanks for your response!.

I do have a VPN set up, but I have that configured as per the docs (ProxyVM as 
a VPN gateway): https://www.qubes-os.org/doc/vpn/. So I didn't (purposely) 
modified anything in sys-firewall or sys-net.

I have tried to enable full internet access, but it didn't work either. The 
strange thing is that when I do that, I can ping let's say 8.8.8.8, or resolve 
any domain, i.e. Debian repos...

Cheers,

-- 
You received this message because you are subscribed to the Google Groups 
"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/39c2428c-84e3-418d-8353-f9dd88250a51%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2017-01-19 Thread Антон Чехов
On Thursday, January 19, 2017 at 6:33:30 PM UTC+1, Reg Tiangha wrote:
> On 2017-01-19 10:30 AM, Антон Чехов wrote:
> > On Thursday, January 19, 2017 at 6:11:19 PM UTC+1, Reg Tiangha wrote:
> >>> Ah, okay. Mine don't start anymore. They jump from green to yellow but 
> >>> the AppVM and templateVM don't start anymore. So I can't change anything 
> >>> in the template anymore which makes it unusable. 
> >>> I did everything by the book, like described by coldhak:
> >>> https://github.com/coldhakca/coldkernel
> >>> I tried the kernel mostly on debian based VM. I built mostly debian based 
> >>> apps after some time. Debian 8, that is. 
> >>>
> >>
> >> Hmm...do you get a qrexec error? This behaviour (in my experience)
> >> usually means that the u2mfm kernel module didn't get compiled or
> >> installed correctly. On Debian VMs, you need to make sure the kernel
> >> header package is installed first before the kernel image package to
> >> make sure that u2mfm is compiled and installed correctly and the proper
> >> initramfs file is generated.
> >>
> >> If you need to fix things in your template, you can switch back to a
> >> normal Qubes kernel using Qubes Manager, rather than using pvgrub2. The
> >> machine should come up fine after that and you can double-check your
> >> settings that way.
> >>
> >> So maybe retry compiling and installing the coldkernel again by pulling
> >> a fresh copy off of github and starting from scratch, and if things
> >> still don't work, try that again using a fresh template.
> > 
> > No qrexex error.
> > Re update: I meant both cases, like you assumed but primarily recompiling 
> > with changes to the coldkernel.config. I did all these steps again, like 
> > described. That includes update grub. I did have the same errors mentioned 
> > earlier in the thread. (/usr/sbin/grub-probe: error: cannot find a GRUB 
> > drive for /dev/mapper/dmroot.  Check your device.map.) but other than that 
> > everything looked fine. Something must have gone wrong. 
> > I will try again like you described. Thanks very much for your help and the 
> > tip with switching back to normal kernel...so obvious that I would have 
> > missed it.
> > 
> 
> Well, keep us posted on how it goes. To be fair, I'm still running
> 4.8.15 of the kernel and haven't had a chance to update it to 4.8.17 so
> there could very well be some issues with the latest version that I
> haven't encountered yet. My plan is to attempt the upgrade this weekend
> when I have more time to play around with things.

Will do. I used the latest kernel 4.8.17 and there were no problems until I 
recompiled so I guess it should work. I mostly run AppVM behind a proxyVM. I 
will try again and report how it went.

-- 
You received this message because you are subscribed to the Google Groups 
"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/1fa9c6e5-2264-40ce-9483-832a563f9c0c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2017-01-19 Thread Антон Чехов
On Thursday, January 19, 2017 at 6:11:19 PM UTC+1, Reg Tiangha wrote:
> > Ah, okay. Mine don't start anymore. They jump from green to yellow but the 
> > AppVM and templateVM don't start anymore. So I can't change anything in the 
> > template anymore which makes it unusable. 
> > I did everything by the book, like described by coldhak:
> > https://github.com/coldhakca/coldkernel
> > I tried the kernel mostly on debian based VM. I built mostly debian based 
> > apps after some time. Debian 8, that is. 
> > 
> 
> Hmm...do you get a qrexec error? This behaviour (in my experience)
> usually means that the u2mfm kernel module didn't get compiled or
> installed correctly. On Debian VMs, you need to make sure the kernel
> header package is installed first before the kernel image package to
> make sure that u2mfm is compiled and installed correctly and the proper
> initramfs file is generated.
> 
> If you need to fix things in your template, you can switch back to a
> normal Qubes kernel using Qubes Manager, rather than using pvgrub2. The
> machine should come up fine after that and you can double-check your
> settings that way.
> 
> So maybe retry compiling and installing the coldkernel again by pulling
> a fresh copy off of github and starting from scratch, and if things
> still don't work, try that again using a fresh template.

No qrexex error.
Re update: I meant both cases, like you assumed but primarily recompiling with 
changes to the coldkernel.config. I did all these steps again, like described. 
That includes update grub. I did have the same errors mentioned earlier in the 
thread. (/usr/sbin/grub-probe: error: cannot find a GRUB drive for 
/dev/mapper/dmroot.  Check your device.map.) but other than that everything 
looked fine. Something must have gone wrong. 
I will try again like you described. Thanks very much for your help and the tip 
with switching back to normal kernel...so obvious that I would have missed 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/a0fb61bd-c2bf-4ea7-b7e7-b9d32082e277%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2017-01-19 Thread Reg Tiangha
On 2017-01-19 10:30 AM, Антон Чехов wrote:
> On Thursday, January 19, 2017 at 6:11:19 PM UTC+1, Reg Tiangha wrote:
>>> Ah, okay. Mine don't start anymore. They jump from green to yellow but the 
>>> AppVM and templateVM don't start anymore. So I can't change anything in the 
>>> template anymore which makes it unusable. 
>>> I did everything by the book, like described by coldhak:
>>> https://github.com/coldhakca/coldkernel
>>> I tried the kernel mostly on debian based VM. I built mostly debian based 
>>> apps after some time. Debian 8, that is. 
>>>
>>
>> Hmm...do you get a qrexec error? This behaviour (in my experience)
>> usually means that the u2mfm kernel module didn't get compiled or
>> installed correctly. On Debian VMs, you need to make sure the kernel
>> header package is installed first before the kernel image package to
>> make sure that u2mfm is compiled and installed correctly and the proper
>> initramfs file is generated.
>>
>> If you need to fix things in your template, you can switch back to a
>> normal Qubes kernel using Qubes Manager, rather than using pvgrub2. The
>> machine should come up fine after that and you can double-check your
>> settings that way.
>>
>> So maybe retry compiling and installing the coldkernel again by pulling
>> a fresh copy off of github and starting from scratch, and if things
>> still don't work, try that again using a fresh template.
> 
> No qrexex error.
> Re update: I meant both cases, like you assumed but primarily recompiling 
> with changes to the coldkernel.config. I did all these steps again, like 
> described. That includes update grub. I did have the same errors mentioned 
> earlier in the thread. (/usr/sbin/grub-probe: error: cannot find a GRUB drive 
> for /dev/mapper/dmroot.  Check your device.map.) but other than that 
> everything looked fine. Something must have gone wrong. 
> I will try again like you described. Thanks very much for your help and the 
> tip with switching back to normal kernel...so obvious that I would have 
> missed it.
> 

Well, keep us posted on how it goes. To be fair, I'm still running
4.8.15 of the kernel and haven't had a chance to update it to 4.8.17 so
there could very well be some issues with the latest version that I
haven't encountered yet. My plan is to attempt the upgrade this weekend
when I have more time to play around with things.

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


Re: [qubes-users] Default UpdateVM and Issues while updating VM

2017-01-19 Thread Chris Laprise

On 01/18/2017 09:32 PM, adonis28...@gmail.com wrote:

Hi guys,

I'm having a hard time trying to figure out this. When I installed Qubes OS I think I 
chose Whonix as the default to update VMs, but eventually I ended up changing it after a 
couple of days and set the UpdateVM to "sys-firewall".

Now, everything seems to be fine, except for when I try to upgrade the Debian 8 
template to Debian 9. No matter what I try, I keep getting this sort of error after 
running apt-get update && apt-get upgrade:

***
E: Failed to fetch [...]  Unable to connect to 10.137.255.254:8082:
E: Failed to fetch [...]  Unable to connect to 10.137.255.254:8082:
***

If you notice, it says it can't connect to that IP, which after debugging I've 
found out corresponds to the Whonix Gateway VM! So for some reason when I clone 
the current Debian 8 template and try to update it it tries to do it through 
Whonix, and not through the sys-firewall VM as I have it configured.

I've found something similar being described here: 
https://forums.whonix.org/t/templates-incorrectly-think-theyre-not-connected-to-a-whonix-gateway/2258
 . But in that case it is a Whonix VM suffering the issue, which makes more 
sense...

So, in short, any idea or tips on how to properly (re)configure a VM so the 
updates go through the sys-firewall VM and not through Whonix?!.

Cheers



What it sounds like is the new debian template VM is not making any 
connection at all, and the IP you're seeing is coming from a cache. It 
should resolve itself and go away if you manage to correct the 
connection issue.


Sometimes when people configure VMs they inadvertently end up with 
firewall settings that block everything. For a template VM, having "Deny 
network access except" and "Allow connections to update proxy" are 
normal. This works IF the sys-firewall and sys-net are basically default 
and not configured with extra options like VPNs. You can also try 
setting the debian VM to allow full access for 5 min. to see if that 
allows it to connect during an update.


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/6892f2bb-280c-6b57-8e4b-dd841bdd3c1b%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.


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

2017-01-19 Thread Reg Tiangha
On 2017-01-19 9:43 AM, Reg Tiangha wrote:
> On 2017-01-19 9:39 AM, Антон Чехов wrote:
>> On Thursday, January 19, 2017 at 5:25:00 PM UTC+1, Reg Tiangha wrote:
>>> On 2017-01-19 9:18 AM, Антон Чехов wrote:
 On Wednesday, January 18, 2017 at 5:35:53 PM UTC+1, Reg Tiangha wrote:
> On 2017-01-18 7:14 AM, Антон Чехов wrote:
>> Hello,
>>
>> I am testing coldkernel and I have a few questions. Does or should it 
>> work with a vpn gateway? Do I have to change some config file or special 
>> permissions?
>> I did not use grsec much in the past so I am in the process of 
>> learning.. 
>> I could connect to my coldkernel appvm via vpn gateway after freshly 
>> compiling and starting the appvm. After reboot none of my coldkernel 
>> appvm is connecting to the internet via vpn gateway anymore but 
>> connecting to clearnet without a proxyvm.
>>
>
> To get the coldkernel working properly with net/proxyVMs and usbVMs, you
> need to add at least two more drivers to the kernel's .config file:
>
> CONFIG_XEN_BLKDEV_BACKEND=m   
> CONFIG_XEN_NETDEV_BACKEND=m   
>
> The easiest way to do that is to add those two lines to the
> coldkernel.config file *before* running "make qubes-guest"

 Thanks for your answer. I added the lines to the coldkernel.config and 
 compiled the kernel again (in the existing coldkernel-template). Don't 
 know if that's a mistake? Upon starting an appVM with coldkernel the VM 
 pauses (yellow) and the log is giving me loads of this:
 "grsec: denied priority change of process rtkit-daemon:1115 (...)"
 This applies to the templateVM as well so I am asking myself what's best 
 practice of updating the coldkernel template?
 It is obvious that I don't know my way around grsec and I have to do more 
 research into how to do things.

>>>
>>> Yeah, I get that too. I think you can ignore it in the sense that the
>>> VMs will still work despite the error, although I don't know if there
>>> are really any adverse effects.
>>>
>>> I haven't tried to fix it myself, though, but I assume a PAX exception
>>> would need to be set for the daemon in order to "fix" it (not hard to
>>> do, but I lack the time to troubleshoot at the moment).
>>>
>>> What the rtkit-daemon is:
>>>
>>> "RealtimeKit is a D-Bus system service that changes the
>>> scheduling policy of user processes/threads to SCHED_RR (i.e. realtime
>>> scheduling mode) on request. It is intended to be used as a secure
>>> mechanism to allow real-time scheduling to be used by normal user
>>> processes."
>>>
>>> I don't know how it affects the operations of VMs though and whether or
>>> not it being denied by the grsec kernel is actually a big deal.
>>
>> But I can't start neither the AppVm nor the template anymore so it is kind 
>> of a big deal, don't you think?
>> That's why I am asking how to update. 
>> Do I have to start over from scratch or should it work from the template? 
>> Apparently something went wrong although everything looked fine during the 
>> process of compiling.
>>
> 
> My templates and AppVMs start up just fine despite having that error.
> What do you mean when you say yours don't? As in, they don't start up at
> all, or they do but the indicator on Qubes Manager for that VM is yellow
> instead of green and never changes even after the CPU usage drops to 0%?
> And what VMs are you running the kernel on? Are they Debian based or
> Fedora based? And what versions of those distros?
> 

And one more question:  What do you mean when you say that you're trying
to "update?" As in, update the coldkernel to a newer version? If that's
what you're trying to do (ex. Upgrade an installed kernel from 4.8.15 to
4.8.17), you need to also a) update grub by re-running the grub command
from the coldkernel instructions and b) optionally, uninstall the older
version of the kernel. Otherwise, if you don't update grub, then the VM
will try to boot the old version of the kernel. Installing the updated
kernel does not automatically update grub like it does on a normal
distro; you have to do it manually.


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


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

2017-01-19 Thread Антон Чехов
On Thursday, January 19, 2017 at 5:43:56 PM UTC+1, Reg Tiangha wrote:
> On 2017-01-19 9:39 AM, Антон Чехов wrote:
> > On Thursday, January 19, 2017 at 5:25:00 PM UTC+1, Reg Tiangha wrote:
> >> On 2017-01-19 9:18 AM, Антон Чехов wrote:
> >>> On Wednesday, January 18, 2017 at 5:35:53 PM UTC+1, Reg Tiangha wrote:
>  On 2017-01-18 7:14 AM, Антон Чехов wrote:
> > Hello,
> >
> > I am testing coldkernel and I have a few questions. Does or should it 
> > work with a vpn gateway? Do I have to change some config file or 
> > special permissions?
> > I did not use grsec much in the past so I am in the process of 
> > learning.. 
> > I could connect to my coldkernel appvm via vpn gateway after freshly 
> > compiling and starting the appvm. After reboot none of my coldkernel 
> > appvm is connecting to the internet via vpn gateway anymore but 
> > connecting to clearnet without a proxyvm.
> >
> 
>  To get the coldkernel working properly with net/proxyVMs and usbVMs, you
>  need to add at least two more drivers to the kernel's .config file:
> 
>  CONFIG_XEN_BLKDEV_BACKEND=m  
>  CONFIG_XEN_NETDEV_BACKEND=m  
> 
>  The easiest way to do that is to add those two lines to the
>  coldkernel.config file *before* running "make qubes-guest"
> >>>
> >>> Thanks for your answer. I added the lines to the coldkernel.config and 
> >>> compiled the kernel again (in the existing coldkernel-template). Don't 
> >>> know if that's a mistake? Upon starting an appVM with coldkernel the VM 
> >>> pauses (yellow) and the log is giving me loads of this:
> >>> "grsec: denied priority change of process rtkit-daemon:1115 (...)"
> >>> This applies to the templateVM as well so I am asking myself what's best 
> >>> practice of updating the coldkernel template?
> >>> It is obvious that I don't know my way around grsec and I have to do more 
> >>> research into how to do things.
> >>>
> >>
> >> Yeah, I get that too. I think you can ignore it in the sense that the
> >> VMs will still work despite the error, although I don't know if there
> >> are really any adverse effects.
> >>
> >> I haven't tried to fix it myself, though, but I assume a PAX exception
> >> would need to be set for the daemon in order to "fix" it (not hard to
> >> do, but I lack the time to troubleshoot at the moment).
> >>
> >> What the rtkit-daemon is:
> >>
> >> "RealtimeKit is a D-Bus system service that changes the
> >> scheduling policy of user processes/threads to SCHED_RR (i.e. realtime
> >> scheduling mode) on request. It is intended to be used as a secure
> >> mechanism to allow real-time scheduling to be used by normal user
> >> processes."
> >>
> >> I don't know how it affects the operations of VMs though and whether or
> >> not it being denied by the grsec kernel is actually a big deal.
> > 
> > But I can't start neither the AppVm nor the template anymore so it is kind 
> > of a big deal, don't you think?
> > That's why I am asking how to update. 
> > Do I have to start over from scratch or should it work from the template? 
> > Apparently something went wrong although everything looked fine during the 
> > process of compiling.
> > 
> 
> My templates and AppVMs start up just fine despite having that error.
> What do you mean when you say yours don't? As in, they don't start up at
> all, or they do but the indicator on Qubes Manager for that VM is yellow
> instead of green and never changes even after the CPU usage drops to 0%?
> And what VMs are you running the kernel on? Are they Debian based or
> Fedora based? And what versions of those distros?

Ah, okay. Mine don't start anymore. They jump from green to yellow but the 
AppVM and templateVM don't start anymore. So I can't change anything in the 
template anymore which makes it unusable. 
I did everything by the book, like described by coldhak:
https://github.com/coldhakca/coldkernel
I tried the kernel mostly on debian based VM. I built mostly debian based apps 
after some time. Debian 8, that is. 

-- 
You received this message because you are subscribed to the Google Groups 
"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/3a1a3a5d-10b8-4033-a085-da0f9bc9cb2b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2017-01-19 Thread Антон Чехов
On Thursday, January 19, 2017 at 5:25:00 PM UTC+1, Reg Tiangha wrote:
> On 2017-01-19 9:18 AM, Антон Чехов wrote:
> > On Wednesday, January 18, 2017 at 5:35:53 PM UTC+1, Reg Tiangha wrote:
> >> On 2017-01-18 7:14 AM, Антон Чехов wrote:
> >>> Hello,
> >>>
> >>> I am testing coldkernel and I have a few questions. Does or should it 
> >>> work with a vpn gateway? Do I have to change some config file or special 
> >>> permissions?
> >>> I did not use grsec much in the past so I am in the process of learning.. 
> >>> I could connect to my coldkernel appvm via vpn gateway after freshly 
> >>> compiling and starting the appvm. After reboot none of my coldkernel 
> >>> appvm is connecting to the internet via vpn gateway anymore but 
> >>> connecting to clearnet without a proxyvm.
> >>>
> >>
> >> To get the coldkernel working properly with net/proxyVMs and usbVMs, you
> >> need to add at least two more drivers to the kernel's .config file:
> >>
> >> CONFIG_XEN_BLKDEV_BACKEND=m
> >> CONFIG_XEN_NETDEV_BACKEND=m
> >>
> >> The easiest way to do that is to add those two lines to the
> >> coldkernel.config file *before* running "make qubes-guest"
> > 
> > Thanks for your answer. I added the lines to the coldkernel.config and 
> > compiled the kernel again (in the existing coldkernel-template). Don't know 
> > if that's a mistake? Upon starting an appVM with coldkernel the VM pauses 
> > (yellow) and the log is giving me loads of this:
> > "grsec: denied priority change of process rtkit-daemon:1115 (...)"
> > This applies to the templateVM as well so I am asking myself what's best 
> > practice of updating the coldkernel template?
> > It is obvious that I don't know my way around grsec and I have to do more 
> > research into how to do things.
> > 
> 
> Yeah, I get that too. I think you can ignore it in the sense that the
> VMs will still work despite the error, although I don't know if there
> are really any adverse effects.
> 
> I haven't tried to fix it myself, though, but I assume a PAX exception
> would need to be set for the daemon in order to "fix" it (not hard to
> do, but I lack the time to troubleshoot at the moment).
> 
> What the rtkit-daemon is:
> 
> "RealtimeKit is a D-Bus system service that changes the
> scheduling policy of user processes/threads to SCHED_RR (i.e. realtime
> scheduling mode) on request. It is intended to be used as a secure
> mechanism to allow real-time scheduling to be used by normal user
> processes."
> 
> I don't know how it affects the operations of VMs though and whether or
> not it being denied by the grsec kernel is actually a big deal.

But I can't start neither the AppVm nor the template anymore so it is kind of a 
big deal, don't you think?
That's why I am asking how to update. 
Do I have to start over from scratch or should it work from the template? 
Apparently something went wrong although everything looked fine during the 
process of compiling.

-- 
You received this message because you are subscribed to the Google Groups 
"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/9d5a2e68-04a0-406a-bdd1-fcc3e96fe0fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] A drop-box User sent you a Document

2017-01-19 Thread DropBox Team
[image: Inline image 1] 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To 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/CAOgCznuQqe7afFmfhT5f-wu7ow5sN%2B537N_xAHY6zoyu2roV%2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Question to Mirage OS firewall users

2017-01-19 Thread Антон Чехов
On Thursday, January 19, 2017 at 1:07:17 AM UTC+1, Reg Tiangha wrote:
> On 2017-01-18 7:30 AM, Антон Чехов wrote:
> > Hi!
> > 
> > Is anyone using the mirage firewall in connection with a proxyVM? How do 
> > you configure it properly? Does it handle qubes-firewall-users-scripts?
> > 
> 
> I've run a Mirage-based firewall both in front of and behind a
> firewallVM and they chain together fine. Mirage Firewall in its current
> iteration does *not* respect modifications to firewall rules via Qubes
> and has to be inputted manually (there are some instructions on how to
> do that on the software author's blog). It isn't to say that Mirage
> Firewall couldn't do it one day, but I believe the author of the code is
> leaving it up as an exercise for the reader. Maybe he'll get around to
> implementing it, or maybe not, but from a purely technical standpoint,
> there's no reason why it couldn't be modified to work with Qubes
> firewall user scripts, it's just that it hasn't been implemented yet.
> 
> Note that even if you're running the latest code off of GitHub,
> currently, Mirage Firewall still doesn't work correctly with DispVMs (or
> at least, I haven't been able to get it to work; the DispVM connects to
> it, but there's no traffic), even though there were some minimal fixes
> applied to try to handle how it handles IP addresses from a different
> pool. Works fine with AppVMs, though, as well as TemplateVMs, at least
> in my experience.

@Reg & Willy
Thank you for sharing your experiences and the advice. I will try to wrap my 
head around this topic.
I have been trying the firewall with an AppVM already and it looked like it was 
working fine but I have to dig deeper into the process (for my understanding). 

-- 
You received this message because you are subscribed to the Google Groups 
"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/00f397a6-f227-4051-8c93-02a566c91887%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2017-01-19 Thread Reg Tiangha
On 2017-01-19 9:18 AM, Антон Чехов wrote:
> On Wednesday, January 18, 2017 at 5:35:53 PM UTC+1, Reg Tiangha wrote:
>> On 2017-01-18 7:14 AM, Антон Чехов wrote:
>>> Hello,
>>>
>>> I am testing coldkernel and I have a few questions. Does or should it work 
>>> with a vpn gateway? Do I have to change some config file or special 
>>> permissions?
>>> I did not use grsec much in the past so I am in the process of learning.. 
>>> I could connect to my coldkernel appvm via vpn gateway after freshly 
>>> compiling and starting the appvm. After reboot none of my coldkernel appvm 
>>> is connecting to the internet via vpn gateway anymore but connecting to 
>>> clearnet without a proxyvm.
>>>
>>
>> To get the coldkernel working properly with net/proxyVMs and usbVMs, you
>> need to add at least two more drivers to the kernel's .config file:
>>
>> CONFIG_XEN_BLKDEV_BACKEND=m  
>> CONFIG_XEN_NETDEV_BACKEND=m  
>>
>> The easiest way to do that is to add those two lines to the
>> coldkernel.config file *before* running "make qubes-guest"
> 
> Thanks for your answer. I added the lines to the coldkernel.config and 
> compiled the kernel again (in the existing coldkernel-template). Don't know 
> if that's a mistake? Upon starting an appVM with coldkernel the VM pauses 
> (yellow) and the log is giving me loads of this:
> "grsec: denied priority change of process rtkit-daemon:1115 (...)"
> This applies to the templateVM as well so I am asking myself what's best 
> practice of updating the coldkernel template?
> It is obvious that I don't know my way around grsec and I have to do more 
> research into how to do things.
> 

Yeah, I get that too. I think you can ignore it in the sense that the
VMs will still work despite the error, although I don't know if there
are really any adverse effects.

I haven't tried to fix it myself, though, but I assume a PAX exception
would need to be set for the daemon in order to "fix" it (not hard to
do, but I lack the time to troubleshoot at the moment).

What the rtkit-daemon is:

"RealtimeKit is a D-Bus system service that changes the
scheduling policy of user processes/threads to SCHED_RR (i.e. realtime
scheduling mode) on request. It is intended to be used as a secure
mechanism to allow real-time scheduling to be used by normal user
processes."

I don't know how it affects the operations of VMs though and whether or
not it being denied by the grsec kernel is actually a big deal.

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


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

2017-01-19 Thread Антон Чехов
On Wednesday, January 18, 2017 at 5:35:53 PM UTC+1, Reg Tiangha wrote:
> On 2017-01-18 7:14 AM, Антон Чехов wrote:
> > Hello,
> > 
> > I am testing coldkernel and I have a few questions. Does or should it work 
> > with a vpn gateway? Do I have to change some config file or special 
> > permissions?
> > I did not use grsec much in the past so I am in the process of learning. 
> > I could connect to my coldkernel appvm via vpn gateway after freshly 
> > compiling and starting the appvm. After reboot none of my coldkernel appvm 
> > is connecting to the internet via vpn gateway anymore but connecting to 
> > clearnet without a proxyvm.
> > 
> 
> To get the coldkernel working properly with net/proxyVMs and usbVMs, you
> need to add at least two more drivers to the kernel's .config file:
> 
> CONFIG_XEN_BLKDEV_BACKEND=m   
> CONFIG_XEN_NETDEV_BACKEND=m   
> 
> The easiest way to do that is to add those two lines to the
> coldkernel.config file *before* running "make qubes-guest"

Thanks for your answer. I added the lines to the coldkernel.config and compiled 
the kernel again (in the existing coldkernel-template). Don't know if that's a 
mistake? Upon starting an appVM with coldkernel the VM pauses (yellow) and the 
log is giving me loads of this:
"grsec: denied priority change of process rtkit-daemon:1115 (...)"
This applies to the templateVM as well so I am asking myself what's best 
practice of updating the coldkernel template?
It is obvious that I don't know my way around grsec and I have to do more 
research into how to do things.

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


Re: [qubes-users] Re: Lenovo G505S Coreboot

2017-01-19 Thread qmastery16
четверг, 19 января 2017 г., 18:31:35 UTC+3 пользователь Asterysk написал:
> On Thursday, 19 January 2017 17:28:12 UTC+4, qmast...@gmail.com  wrote:
> > четверг, 19 января 2017 г., 12:16:12 UTC+3 пользователь qmast...@gmail.com 
> > написал:
> > > четверг, 19 января 2017 г., 7:08:46 UTC+3 пользователь Asterysk написал:
> > > > On Thursday, 19 January 2017 03:04:32 UTC+4, tai...@gmx.com  wrote:
> > > > > As always physical access is a checkmate situation, you need to not 
> > > > > be 
> > > > > an idiot and don't leave your stuff in overseas hotel rooms or not 
> > > > > have 
> > > > > secure locks on your door.
> > > > 
> > > > Unless USB port seals (e.g. 
> > > > http://www.padjack.com/padjack-versions/usb-port-lock/) are put in 
> > > > place as soon as the laptop is removed from the manufacturers box it is 
> > > > impossible to know whether someone has installed a device that has in 
> > > > turn infected firmware. A similar situation for any DMA access ports 
> > > > (Thunderbolt etc) 
> > > > 
> > > > I'm interested in being able to take a possibly infected laptop (i.e. 
> > > > infected with firmware malware) and reset it to a known safe starting 
> > > > point. Coreboot seems to handle the BIOS (thank you for clarification 
> > > > that it completely rewrite legacy and UEFI). Replacing the HD with a 
> > > > new SSD should handle that firmware attack vector. That leaves the 
> > > > other EEPROMS.
> > > > 
> > > > I figure, if I'm going to strip down my G505S to reflash with Coreboot, 
> > > > I should see what other EEPROMs I can reflash.
> > > > 
> > > > Apart from the obvious RAM and SSD upgrade and possible putting 
> > > > switches on peripherals, are there any other hardware mods you can 
> > > > suggest for the G505S.
> > > > 
> > > > Having sorted out the hardware, I am then going to be looking to use 
> > > > Qubes to protect against any attempts to reflash through Malware and 
> > > > after thats done, I'll be looking for ways to detect that any attack is 
> > > > being attempted.
> > > > 
> > > > All in all I think I've got about a years work ahead !
> > > 
> > > To reduce the number of "EEPROMs" you could disconnect: a touch pad, DVD 
> > > drive, web camera ; Maybe also a small board with LS-9901P part number 
> > > (dont confuse with LA-9901P), see its' google pictures online - and 
> > > according to G505S laptop's LA-A091P motherboard datasheet (which also 
> > > contains a datasheet for laptop's smaller boards) this board has a 
> > > Realtek chip for card reader. By the way, you could either find out what 
> > > lines of flex cable the card reader is using, and install a custom jumper 
> > > on them ; or maybe get a flex cable with the same number of pins / same 
> > > pitch between them , find (from datasheet?) what lines that lonely USB 
> > > port is using to get to Bolton-M3 FCH, get a USB female header and solder 
> > > a custom adapter which adds only a USB port to laptop (so no card reader 
> > > chip). Probably the hardest thing to do is to disconnect a web camera - 
> > > you will need to tear down a screen which is quite risky. BTW screen also 
> > > contains the internal reprogrammable memory (e.g. for storing EDID), and 
> > > a malicious firmware could cause screen to transfer information through 
> > > electromagnetic impulses (TEMPEST? - 
> > > http://www.surasoft.com/articles/tempest.php )
> > > 
> > > Actually it is possible to remove a motherboard with CPU, CPU Fan, 
> > > Heatsink, Power Jack Wire, and Power Button Board attached (could make a 
> > > custom power button adapter with huge convenient buttons!) and create a 
> > > custom case for all this stuff. If you are lucky you could find someone 
> > > selling a used G505S with broken screen for very cheap price, and do 
> > > that. This way you avoid webcam, screen, dvd drive, touchpad, card reader 
> > > chip, and internal keyboard (see below why)
> > > 
> > > Maybe don't need to seal the USB ports yet: it not just seriously 
> > > reducing the usability of this laptop, but also makes it impossible to 
> > > connect a USB keyboard. Maybe you would prefer that, when you type, your 
> > > keystrokes are going through external keyboard's USB controller, rather 
> > > than through laptop's Embedded Controller KB9012 which has a closed 
> > > source firmware and controls PS/2-like laptop's internal keyboard. You 
> > > could make your own open hardware USB keyboard with open source firmware, 
> > > and using it will be slightly safer (and slightly less convenient) than 
> > > laptop's internal one
> > > 
> > > Also, another possible hardware mod (not related to security) - instead 
> > > of DVD drive you could install a fan for extra cooling, see 
> > > http://forum.notebookreview.com/threads/10mm-5v-cooler-instead-of-laptops-dvd-slimline-sata.797064/
> > >  . Although dont know if it worth it, because some really great external 
> > > USB coolers are available - 
> > > 

Re: [qubes-users] Re: Lenovo G505S Coreboot

2017-01-19 Thread Asterysk
On Thursday, 19 January 2017 17:28:12 UTC+4, qmast...@gmail.com  wrote:
> четверг, 19 января 2017 г., 12:16:12 UTC+3 пользователь qmast...@gmail.com 
> написал:
> > четверг, 19 января 2017 г., 7:08:46 UTC+3 пользователь Asterysk написал:
> > > On Thursday, 19 January 2017 03:04:32 UTC+4, tai...@gmx.com  wrote:
> > > > As always physical access is a checkmate situation, you need to not be 
> > > > an idiot and don't leave your stuff in overseas hotel rooms or not have 
> > > > secure locks on your door.
> > > 
> > > Unless USB port seals (e.g. 
> > > http://www.padjack.com/padjack-versions/usb-port-lock/) are put in place 
> > > as soon as the laptop is removed from the manufacturers box it is 
> > > impossible to know whether someone has installed a device that has in 
> > > turn infected firmware. A similar situation for any DMA access ports 
> > > (Thunderbolt etc) 
> > > 
> > > I'm interested in being able to take a possibly infected laptop (i.e. 
> > > infected with firmware malware) and reset it to a known safe starting 
> > > point. Coreboot seems to handle the BIOS (thank you for clarification 
> > > that it completely rewrite legacy and UEFI). Replacing the HD with a new 
> > > SSD should handle that firmware attack vector. That leaves the other 
> > > EEPROMS.
> > > 
> > > I figure, if I'm going to strip down my G505S to reflash with Coreboot, I 
> > > should see what other EEPROMs I can reflash.
> > > 
> > > Apart from the obvious RAM and SSD upgrade and possible putting switches 
> > > on peripherals, are there any other hardware mods you can suggest for the 
> > > G505S.
> > > 
> > > Having sorted out the hardware, I am then going to be looking to use 
> > > Qubes to protect against any attempts to reflash through Malware and 
> > > after thats done, I'll be looking for ways to detect that any attack is 
> > > being attempted.
> > > 
> > > All in all I think I've got about a years work ahead !
> > 
> > To reduce the number of "EEPROMs" you could disconnect: a touch pad, DVD 
> > drive, web camera ; Maybe also a small board with LS-9901P part number 
> > (dont confuse with LA-9901P), see its' google pictures online - and 
> > according to G505S laptop's LA-A091P motherboard datasheet (which also 
> > contains a datasheet for laptop's smaller boards) this board has a Realtek 
> > chip for card reader. By the way, you could either find out what lines of 
> > flex cable the card reader is using, and install a custom jumper on them ; 
> > or maybe get a flex cable with the same number of pins / same pitch between 
> > them , find (from datasheet?) what lines that lonely USB port is using to 
> > get to Bolton-M3 FCH, get a USB female header and solder a custom adapter 
> > which adds only a USB port to laptop (so no card reader chip). Probably the 
> > hardest thing to do is to disconnect a web camera - you will need to tear 
> > down a screen which is quite risky. BTW screen also contains the internal 
> > reprogrammable memory (e.g. for storing EDID), and a malicious firmware 
> > could cause screen to transfer information through electromagnetic impulses 
> > (TEMPEST? - http://www.surasoft.com/articles/tempest.php )
> > 
> > Actually it is possible to remove a motherboard with CPU, CPU Fan, 
> > Heatsink, Power Jack Wire, and Power Button Board attached (could make a 
> > custom power button adapter with huge convenient buttons!) and create a 
> > custom case for all this stuff. If you are lucky you could find someone 
> > selling a used G505S with broken screen for very cheap price, and do that. 
> > This way you avoid webcam, screen, dvd drive, touchpad, card reader chip, 
> > and internal keyboard (see below why)
> > 
> > Maybe don't need to seal the USB ports yet: it not just seriously reducing 
> > the usability of this laptop, but also makes it impossible to connect a USB 
> > keyboard. Maybe you would prefer that, when you type, your keystrokes are 
> > going through external keyboard's USB controller, rather than through 
> > laptop's Embedded Controller KB9012 which has a closed source firmware and 
> > controls PS/2-like laptop's internal keyboard. You could make your own open 
> > hardware USB keyboard with open source firmware, and using it will be 
> > slightly safer (and slightly less convenient) than laptop's internal one
> > 
> > Also, another possible hardware mod (not related to security) - instead of 
> > DVD drive you could install a fan for extra cooling, see 
> > http://forum.notebookreview.com/threads/10mm-5v-cooler-instead-of-laptops-dvd-slimline-sata.797064/
> >  . Although dont know if it worth it, because some really great external 
> > USB coolers are available - 
> > https://www.aliexpress.com/item/Mini-LCD-Vacuum-USB-Cooler-Air-Extracting-Cooling-Fan-Turbo-Radiator-Low-Noise-Desgin-for-Laptop/32231641439.html
> 
> Please read a message above... If we are talking about the motherboard, main 
> board of this laptop : aside from 4MB BIOS flash chip and 128KB EC 

Re: [qubes-users] Re: Lenovo G505S Coreboot

2017-01-19 Thread Asterysk
On Thursday, 19 January 2017 18:17:59 UTC+4, Asterysk  wrote:
> "1) Erase a BIOS chip and flash it with coreboot 
> http://dangerousprototypes.com/docs/Flashing_a_BIOS_chip_with_Bus_Pirate "
> 
> Did you buy the necessary components from AliExpress as linked in the article 
> ? They are saying a couple of months delivery time !!

All components now ordered, most from Ali Express but a couple from USA. I 
should hopefully be good to start in about a month

-- 
You received this message because you are subscribed to the Google Groups 
"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/f96c4e71-3529-45bd-bfd6-0436ad6bc506%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Question to Mirage OS firewall users

2017-01-19 Thread WillyPillow
 Original Message 
Subject: [qubes-users] Re: Question to Mirage OS firewall users
Local Time: January 19, 2017 12:06 AM
UTC Time: January 19, 2017 12:06 AM
From: r...@reginaldtiangha.com
To: qubes-users@googlegroups.com

On 2017-01-18 7:30 AM, Антон Чехов wrote:
> Hi!
>
> Is anyone using the mirage firewall in connection with a proxyVM? How do you 
> configure it properly? Does it handle qubes-firewall-users-scripts?
>

I've run a Mirage-based firewall both in front of and behind a
firewallVM and they chain together fine. Mirage Firewall in its current
iteration does *not* respect modifications to firewall rules via Qubes
and has to be inputted manually (there are some instructions on how to
do that on the software author's blog). It isn't to say that Mirage
Firewall couldn't do it one day, but I believe the author of the code is
leaving it up as an exercise for the reader. Maybe he'll get around to
implementing it, or maybe not, but from a purely technical standpoint,
there's no reason why it couldn't be modified to work with Qubes
firewall user scripts, it's just that it hasn't been implemented yet.

Note that even if you're running the latest code off of GitHub,
currently, Mirage Firewall still doesn't work correctly with DispVMs (or
at least, I haven't been able to get it to work; the DispVM connects to
it, but there's no traffic), even though there were some minimal fixes
applied to try to handle how it handles IP addresses from a different
pool. Works fine with AppVMs, though, as well as TemplateVMs, at least
in my experience.


A workaround for dispVMs is creating the savefile without a firewallVM (i.e. 
set as "none"), then for each fresh dispVM, manually assign it to sys-mirage 
after it has been started.

--WillyPillow

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


Re: [qubes-users] Re: Lenovo G505S Coreboot

2017-01-19 Thread Asterysk
"1) Erase a BIOS chip and flash it with coreboot 
http://dangerousprototypes.com/docs/Flashing_a_BIOS_chip_with_Bus_Pirate "

Did you buy the necessary components from AliExpress as linked in the article ? 
They are saying a couple of months delivery time !!

-- 
You received this message because you are subscribed to the Google Groups 
"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/379e48f9-0f41-4057-a1f4-e2a318ae1f38%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Lenovo G505S Coreboot

2017-01-19 Thread qmastery16
четверг, 19 января 2017 г., 12:16:12 UTC+3 пользователь qmast...@gmail.com 
написал:
> четверг, 19 января 2017 г., 7:08:46 UTC+3 пользователь Asterysk написал:
> > On Thursday, 19 January 2017 03:04:32 UTC+4, tai...@gmx.com  wrote:
> > > As always physical access is a checkmate situation, you need to not be 
> > > an idiot and don't leave your stuff in overseas hotel rooms or not have 
> > > secure locks on your door.
> > 
> > Unless USB port seals (e.g. 
> > http://www.padjack.com/padjack-versions/usb-port-lock/) are put in place as 
> > soon as the laptop is removed from the manufacturers box it is impossible 
> > to know whether someone has installed a device that has in turn infected 
> > firmware. A similar situation for any DMA access ports (Thunderbolt etc) 
> > 
> > I'm interested in being able to take a possibly infected laptop (i.e. 
> > infected with firmware malware) and reset it to a known safe starting 
> > point. Coreboot seems to handle the BIOS (thank you for clarification that 
> > it completely rewrite legacy and UEFI). Replacing the HD with a new SSD 
> > should handle that firmware attack vector. That leaves the other EEPROMS.
> > 
> > I figure, if I'm going to strip down my G505S to reflash with Coreboot, I 
> > should see what other EEPROMs I can reflash.
> > 
> > Apart from the obvious RAM and SSD upgrade and possible putting switches on 
> > peripherals, are there any other hardware mods you can suggest for the 
> > G505S.
> > 
> > Having sorted out the hardware, I am then going to be looking to use Qubes 
> > to protect against any attempts to reflash through Malware and after thats 
> > done, I'll be looking for ways to detect that any attack is being attempted.
> > 
> > All in all I think I've got about a years work ahead !
> 
> To reduce the number of "EEPROMs" you could disconnect: a touch pad, DVD 
> drive, web camera ; Maybe also a small board with LS-9901P part number (dont 
> confuse with LA-9901P), see its' google pictures online - and according to 
> G505S laptop's LA-A091P motherboard datasheet (which also contains a 
> datasheet for laptop's smaller boards) this board has a Realtek chip for card 
> reader. By the way, you could either find out what lines of flex cable the 
> card reader is using, and install a custom jumper on them ; or maybe get a 
> flex cable with the same number of pins / same pitch between them , find 
> (from datasheet?) what lines that lonely USB port is using to get to 
> Bolton-M3 FCH, get a USB female header and solder a custom adapter which adds 
> only a USB port to laptop (so no card reader chip). Probably the hardest 
> thing to do is to disconnect a web camera - you will need to tear down a 
> screen which is quite risky. BTW screen also contains the internal 
> reprogrammable memory (e.g. for storing EDID), and a malicious firmware could 
> cause screen to transfer information through electromagnetic impulses 
> (TEMPEST? - http://www.surasoft.com/articles/tempest.php )
> 
> Actually it is possible to remove a motherboard with CPU, CPU Fan, Heatsink, 
> Power Jack Wire, and Power Button Board attached (could make a custom power 
> button adapter with huge convenient buttons!) and create a custom case for 
> all this stuff. If you are lucky you could find someone selling a used G505S 
> with broken screen for very cheap price, and do that. This way you avoid 
> webcam, screen, dvd drive, touchpad, card reader chip, and internal keyboard 
> (see below why)
> 
> Maybe don't need to seal the USB ports yet: it not just seriously reducing 
> the usability of this laptop, but also makes it impossible to connect a USB 
> keyboard. Maybe you would prefer that, when you type, your keystrokes are 
> going through external keyboard's USB controller, rather than through 
> laptop's Embedded Controller KB9012 which has a closed source firmware and 
> controls PS/2-like laptop's internal keyboard. You could make your own open 
> hardware USB keyboard with open source firmware, and using it will be 
> slightly safer (and slightly less convenient) than laptop's internal one
> 
> Also, another possible hardware mod (not related to security) - instead of 
> DVD drive you could install a fan for extra cooling, see 
> http://forum.notebookreview.com/threads/10mm-5v-cooler-instead-of-laptops-dvd-slimline-sata.797064/
>  . Although dont know if it worth it, because some really great external USB 
> coolers are available - 
> https://www.aliexpress.com/item/Mini-LCD-Vacuum-USB-Cooler-Air-Extracting-Cooling-Fan-Turbo-Radiator-Low-Noise-Desgin-for-Laptop/32231641439.html

Please read a message above... If we are talking about the motherboard, main 
board of this laptop : aside from 4MB BIOS flash chip and 128KB EC KB9012's 
internal memory, I am not aware about any other "EEPROMs" on this board which 
could be reflashed and how to reflash them. Well, there is probably a CMOS 
memory somewhere, but I dont know where it is located and dont know how to 
access 

[qubes-users] Re: Problem adding USB controller to win7 VM

2017-01-19 Thread Jarle Thorsen
Grzesiek Chodzicki:
> > I'm trying to have my phone connected via USB to my win7 VM so that I can 
> > flash it with custom firmware.
> > 
> > I have three different USB controllers so I don't mind giving up one of the 
> > controllers to the win7 VM.
> > 
> > The controllers work just fine when connected to sys-usb, but when I 
> > connect either one to the win7 VM it will not boot...
> > 
> > How should I go about debugging this?
> 
> Run following command in dom0 terminal:
> xl dmesg|grep -i vt-d

XEN) Intel VT-d iommu 0 supported page sizes: 4kB, 2MB, 1GB.
(XEN) Intel VT-d iommu 1 supported page sizes: 4kB, 2MB, 1GB.
(XEN) Intel VT-d Snoop Control enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping enabled.
(XEN) Intel VT-d Shared EPT tables enabled.

any help?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To 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/20b26354-ad19-4e49-96bb-b2ce06292d84%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] manual update dom0 to newest 4.5 kernel

2017-01-19 Thread R F
On Thu, 19 Jan 2017 at 12:22, R F  wrote:

>
>
> On Thu, 19 Jan 2017 at 10:46, Foppe de Haan <0spinbo...@gmail.com> wrote:
>
> On Thursday, January 19, 2017 at 10:04:38 AM UTC+1, R F wrote:
>
> > On Wed, Jan 18, 2017 at 10:52 PM,   wrote:
>
> > My problem exactly.  Had Qubes running well on an old Lenovo & would
> love to run it on this more capable Zenbook.
>
> >
>
> >
>
> >
>
> > Did you get this working in the end?  Alternative is to spare myself the
> headache & keep running Mint until the next release.
>
> >
>
> >
>
> >
>
> > --
>
> >
>
> >
>
> >
>
> > It almost works on the current Qubes. But no mouse pad and wifi. So I'm
> using F25 atm and waiting for the next Qubes to roll out.
>
> > If the next Qubes uses F25 as its base, the kernel will be high enough
> for it to fully function.
>
> >
>
> > Lets hope the Qubes team will go for F25. This will help get more
> hardware compatible and expand.
>
> >
>
> > Until then, patience :)
>
>
>
> just checking: you two are aware of the fact that you can get the 4.8.12
> kernel via --enablerepo=qubes-dom0-unstable ?
>
>
>
> --
>
>
> For me the thing is I want the touchpad and wifi to work from the start to
> keep my laptop usb free.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"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/CAGqf3ZERno-FVZQ3qw%3D7iorhLv2bLyjs1_%3D2m1Y%2BgEH%2BP17%3Dvg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] How to switch to xfce in Whonix?

2017-01-19 Thread Patrick Schleizer
6057tx+48r8anehh4c4wazsony08z2dlvc via qubes-users:
> Hello @all,
> 
> I noticed that Whonix (in particular whonix-ws) uses a lot of RAM.
> It seems to me that this is due in part to the fact that it is
> based on KDE. So how can I disable KDE in it and switch to xfce?
> 
> Thanks in advance.

This was answered here:

https://forums.whonix.org/t/how-to-switch-to-xfce-in-whonix-qubes

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To 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/0e9c055c-a2d7-c3c0-f7b2-45d9541c6d32%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] manual update dom0 to newest 4.5 kernel

2017-01-19 Thread Foppe de Haan
On Thursday, January 19, 2017 at 10:04:38 AM UTC+1, R F wrote:
> On Wed, Jan 18, 2017 at 10:52 PM,   wrote:
> My problem exactly.  Had Qubes running well on an old Lenovo & would love to 
> run it on this more capable Zenbook.
> 
> 
> 
> Did you get this working in the end?  Alternative is to spare myself the 
> headache & keep running Mint until the next release.
> 
> 
> 
> --
> 
> 
> 
> It almost works on the current Qubes. But no mouse pad and wifi. So I'm using 
> F25 atm and waiting for the next Qubes to roll out. 
> If the next Qubes uses F25 as its base, the kernel will be high enough for it 
> to fully function.
> 
> Lets hope the Qubes team will go for F25. This will help get more hardware 
> compatible and expand.
> 
> Until then, patience :)

just checking: you two are aware of the fact that you can get the 4.8.12 kernel 
via --enablerepo=qubes-dom0-unstable ?

-- 
You received this message because you are subscribed to the Google Groups 
"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/782fc801-6bd1-4134-ae9d-c671df80b499%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Lenovo G505S Coreboot

2017-01-19 Thread qmastery16
четверг, 19 января 2017 г., 7:08:46 UTC+3 пользователь Asterysk написал:
> On Thursday, 19 January 2017 03:04:32 UTC+4, tai...@gmx.com  wrote:
> > As always physical access is a checkmate situation, you need to not be 
> > an idiot and don't leave your stuff in overseas hotel rooms or not have 
> > secure locks on your door.
> 
> Unless USB port seals (e.g. 
> http://www.padjack.com/padjack-versions/usb-port-lock/) are put in place as 
> soon as the laptop is removed from the manufacturers box it is impossible to 
> know whether someone has installed a device that has in turn infected 
> firmware. A similar situation for any DMA access ports (Thunderbolt etc) 
> 
> I'm interested in being able to take a possibly infected laptop (i.e. 
> infected with firmware malware) and reset it to a known safe starting point. 
> Coreboot seems to handle the BIOS (thank you for clarification that it 
> completely rewrite legacy and UEFI). Replacing the HD with a new SSD should 
> handle that firmware attack vector. That leaves the other EEPROMS.
> 
> I figure, if I'm going to strip down my G505S to reflash with Coreboot, I 
> should see what other EEPROMs I can reflash.
> 
> Apart from the obvious RAM and SSD upgrade and possible putting switches on 
> peripherals, are there any other hardware mods you can suggest for the G505S.
> 
> Having sorted out the hardware, I am then going to be looking to use Qubes to 
> protect against any attempts to reflash through Malware and after thats done, 
> I'll be looking for ways to detect that any attack is being attempted.
> 
> All in all I think I've got about a years work ahead !

To reduce the number of "EEPROMs" you could disconnect: a touch pad, DVD drive, 
web camera ; Maybe also a small board with LS-9901P part number (dont confuse 
with LA-9901P), see its' google pictures online - and according to G505S 
laptop's LA-A091P motherboard datasheet (which also contains a datasheet for 
laptop's smaller boards) this board has a Realtek chip for card reader. By the 
way, you could either find out what lines of flex cable the card reader is 
using, and install a custom jumper on them ; or maybe get a flex cable with the 
same number of pins / same pitch between them , find (from datasheet?) what 
lines that lonely USB port is using to get to Bolton-M3 FCH, get a USB female 
header and solder a custom adapter which adds only a USB port to laptop (so no 
card reader chip). Probably the hardest thing to do is to disconnect a web 
camera - you will need to tear down a screen which is quite risky. BTW screen 
also contains the internal reprogrammable memory (e.g. for storing EDID), and a 
malicious firmware could cause screen to transfer information through 
electromagnetic impulses (TEMPEST? - 
http://www.surasoft.com/articles/tempest.php )

Actually it is possible to remove a motherboard with CPU, CPU Fan, Heatsink, 
Power Jack Wire, and Power Button Board attached (could make a custom power 
button adapter with huge convenient buttons!) and create a custom case for all 
this stuff. If you are lucky you could find someone selling a used G505S with 
broken screen for very cheap price, and do that. This way you avoid webcam, 
screen, dvd drive, touchpad, card reader chip, and internal keyboard (see below 
why)

Maybe don't need to seal the USB ports yet: it not just seriously reducing the 
usability of this laptop, but also makes it impossible to connect a USB 
keyboard. Maybe you would prefer that, when you type, your keystrokes are going 
through external keyboard's USB controller, rather than through laptop's 
Embedded Controller KB9012 which has a closed source firmware and controls 
PS/2-like laptop's internal keyboard. You could make your own open hardware USB 
keyboard with open source firmware, and using it will be slightly safer (and 
slightly less convenient) than laptop's internal one

Also, another possible hardware mod (not related to security) - instead of DVD 
drive you could install a fan for extra cooling, see 
http://forum.notebookreview.com/threads/10mm-5v-cooler-instead-of-laptops-dvd-slimline-sata.797064/
 . Although dont know if it worth it, because some really great external USB 
coolers are available - 
https://www.aliexpress.com/item/Mini-LCD-Vacuum-USB-Cooler-Air-Extracting-Cooling-Fan-Turbo-Radiator-Low-Noise-Desgin-for-Laptop/32231641439.html

-- 
You received this message because you are subscribed to the Google Groups 
"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/80b3bae1-4efe-44eb-bbe2-d45d459db4ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Problem adding USB controller to win7 VM

2017-01-19 Thread Grzesiek Chodzicki
W dniu czwartek, 19 stycznia 2017 08:12:17 UTC+1 użytkownik Jarle Thorsen 
napisał:
> I'm trying to have my phone connected via USB to my win7 VM so that I can 
> flash it with custom firmware.
> 
> I have three different USB controllers so I don't mind giving up one of the 
> controllers to the win7 VM.
> 
> The controllers work just fine when connected to sys-usb, but when I connect 
> either one to the win7 VM it will not boot...
> 
> How should I go about debugging this?

Run following command in dom0 terminal:
xl dmesg|grep -i vt-d

-- 
You received this message because you are subscribed to the Google Groups 
"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/52e21064-e5d9-45a6-b777-ec181b8ec4c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.