Re: [qubes-users] Qrexec - Monero-Wallet-WS connection via Monerod-WS (Daemon)

2018-12-25 Thread OGBaby
Perfect. 

Sound good to me. I'm going to quickly run through your checklist first to 
re-verify everything then I'll get on the IRC. 

I've never been on either but I'll send a quick update here when I've got it 
going.

-- 
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/008a3242-3d05-48a1-b4c6-a4bcafb99e98%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Issues with https certificate for Fedora yum repo

2018-12-25 Thread lowdown
The short version is, the certificate for the https URL listed in
/etc/yum.repos.d/qubes-r4.repo is throwing the below error, and browsing
to the same URL returns an invalid certificate. 

URL: https://yum.qubes-os.org/r4.0/current/vm/

The certificate expired earlier today, approximately 6 hours ago I
believe. It is a lets encrypt certificate.

The error from running:
'sudo yum upgrade'
is: 'Error: Failed to synchronize cache for repo 'qubes-vm-r4.0-current'

Certificate info is:
Fingerprint: 04:34:6A:84:D9:A9:3C:EF:E7:BD:03:D2:24:DA:CC:84:06:70
Issuer: CN = Let's Encrypt Authority X3
O = Let's Encrypt
C = US
Validity:
  Not Before: (September 26, 2018, 11:27:47 PM GMT)
  Not After: (December 25, 2018, 11:27:47 PM GMT)

A side question, What is the better chat service to use. I was trying
OFTC IRC and riseup.net XMPP. 

Jason

-- 
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/2b5d05948e8168f804deea8ea1c17c50%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qrexec - Monero-Wallet-WS connection via Monerod-WS (Daemon)

2018-12-25 Thread qubenix
OGBaby:
> Hey Qubenix, I have an update for you and anyone curious. The MDB_BAD_TXN 
> error has been resolved. For anyone wondering this error most likely mean 
> your blockchain was interrupted during sync and is now corrupt. 
> 
> The solution advised by Monero channels is to delete the blockchain data 
> ("lmdb") amd resync. 
> 
> I was recommended to include the flag '--db-sync-mode=safe' to monerod upon 
> startup to protect against unexpected interruptions or reboots during sync.
> 
> You should be able to locate the blockchain within /home/user/.bitmonero/
> 
> Keep in mind .bitmonero is a hidden directory.
> 
> After the resync everything regarding the daemon seem to be in place and 
> running. I will repost the most recent logs and provide fresh ones as well. 
> 
> I am being redirected back here since that particular monerod error appear to 
> be resolved, there may be a minor issue with the separation setup of wallet 
> and daemon VMs. The lower-left Network Status is 'disconnected' and of course 
> "Wallet is not connected to daemon" is still visible above. 
> 
> If there is anything specific I should verify and confirm, I  would gladly 
> take a look. 
> 
> Thanks everyone
> 
> Monerod status (previous)
> https://pastebin.com/v95gn1aB
> 
> Monerod Bitmonero.log (previous)
> https://pastebin.com/3mzhuSHt
> 
> Monerod Status (fresh)
> https://pastebin.com/XwAy91dh
> 
> Monerod Bitmonero.log (fresh)
> https://pastebin.com/CHSHg9Zz
> 
> 
> Hopefully it's just something I'm overlooking.
> 

Your daemon issues seem solved, so that's a step in the right direction.
Can you come on irc to resolve this (either freenode or oftc)? I suspect
we're going to be doing a lot of back and forth to find out which step
in the guide wasn't completed correctly.

If you want to, you can go back through the guide first and pay special
attention that you have done the following correctly:

1. Set up qrexec policy (/etc/qubes-rpc/policy/whonix.monerod-mainnet)
in dom0. Guide section 1.4.
2. Set up qrexec file
(/rw/usrlocal/etc/qubes-rpc/whonix.monerod-mainnet) on the daemon vm.
Guide section 3.2.
3. Set up /rw/config/rc.local on wallet vm. Guide section 4.2.

If all of that is done correct, the gui is set to use a local node, and
you still have no connection then we will need to do a lot of back and
forth with running commands in vms and telling me the output.

-- 
qubenix

CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20
EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765

-- 
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/86c93f8b-5a4c-4c83-a521-79e708c54e6c%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qrexec - Monero-Wallet-WS connection via Monerod-WS (Daemon)

2018-12-25 Thread OGBaby
Hey Qubenix, I have an update for you and anyone curious. The MDB_BAD_TXN error 
has been resolved. For anyone wondering this error most likely mean your 
blockchain was interrupted during sync and is now corrupt. 

The solution advised by Monero channels is to delete the blockchain data 
("lmdb") amd resync. 

I was recommended to include the flag '--db-sync-mode=safe' to monerod upon 
startup to protect against unexpected interruptions or reboots during sync.

You should be able to locate the blockchain within /home/user/.bitmonero/

Keep in mind .bitmonero is a hidden directory.

After the resync everything regarding the daemon seem to be in place and 
running. I will repost the most recent logs and provide fresh ones as well. 

I am being redirected back here since that particular monerod error appear to 
be resolved, there may be a minor issue with the separation setup of wallet and 
daemon VMs. The lower-left Network Status is 'disconnected' and of course 
"Wallet is not connected to daemon" is still visible above. 

If there is anything specific I should verify and confirm, I  would gladly take 
a look. 

Thanks everyone

Monerod status (previous)
https://pastebin.com/v95gn1aB

Monerod Bitmonero.log (previous)
https://pastebin.com/3mzhuSHt

Monerod Status (fresh)
https://pastebin.com/XwAy91dh

Monerod Bitmonero.log (fresh)
https://pastebin.com/CHSHg9Zz


Hopefully it's just something I'm overlooking.

-- 
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/acef13dc-6dda-4a96-bf97-9a7917f06fed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] 4.0rc2 is not the same as 4.0.1-rc2.

2018-12-25 Thread John Smiley
I see several posts citing 4.0rc2 when it is clear from context that they are 
talking about 4.0.1-rc2. They are completely different releases. Take care to 
cite the correct release in your posts. 

-- 
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/9e5aa214-d164-4ebe-aee6-ab7c80331898%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Split gpg is just too cool.

2018-12-25 Thread John Smiley
U2F Proxy is not so cool. So far no joy getting it to work. Someone on reddit 
had similar issues and questions and resolved by installing USB keyboard 
support. That’s not mentioned in the Qubes docs and I hope we don’t have to 
resort to that. If that were a requirement, surely the docs would have 
mentioned 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/ae2f8918-4485-4a94-b812-17d3ecdae544%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Newb Help with Installation

2018-12-25 Thread John Smiley
I install from USB3 stick all the time and it’s fast. Even if it is dropping 
back to 2.0, it should not be as slow as you describe. 

-- 
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/8357b8f1-4d4b-405c-9074-e5d2cb24892a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Newb Help with Installation

2018-12-25 Thread John Smiley
I would be more concerned about security than drivers. I connected a Caldigit 
Plus TB3 hub to my Qubes laptop and it worked fine, but now I had a new threat 
vector since TB has direct access to the PCI bus. As someone else here noted, 
there may be a time when they vector is secure, but not yet. I promptly removed 
the TB3 dock after that. 

-- 
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/026a0361-b0e9-461e-9aa0-f644cd858067%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Broadcom brcm 4356 Wifi card not working

2018-12-25 Thread unman
On Tue, Dec 25, 2018 at 04:22:32AM -0800, Martin Weck wrote:
> Hi,
> I have got a Lenovo L460 with Broadcom brcm4356 Wifi Adapter that I don't get 
> working on Qubes.
> To isolate the problem, I have first installed a debian-9 directly on the 
> machine and got this after some problems working 
> (https://www.linuxquestions.org/questions/linux-wireless-networking-41/debian-broadcom-bcm4356-802-11ac-wireless-not-working-4175644801/)
> 
> Steps to reproduce:
> - Have Qubes 3.2.1 (also tried Qubes 4.0.1-rc2 without success)
> - Create NetVM debian-9 based with device:
> -- 00:1f.6 Ethernet controller: Intel Corporation l219-LM (rev21)
> -- 03:00.0 Network controller: Broadcom Limited BCM4356 802.11ac Wireless 
> Network Adapter (rev02)
> (cable based Ethernet works on qube without flaws)
> - install firmware-brcm80211_20180825+dfsg-1_all.deb and add 
> brcmfmac4356-pcie.txt
> - Unload kernel module sudo modprobe -f brcmfmac
> - Load kernel module sudo modprobe brcmfmac
> - sudo dmesg | less
> [3.476763] usbcore: registered new interface driver brcmfmac
> [3.532479] e1000e :00:00.6 eth0: (PCI Express:2.5GT/s:Width x1) 
> c8:5b:76:5c:5a:06
> [3.532497] e1000e :00:00.6 eth0: Intel(R) PRO/1000 Network Connection
> [3.532587] e1000e :00:00.6 eth0: MAC: 12, PHY: 12, PBA No: FF-0FF
> [3.535156] brcmfmac :00:01.0: Xen PCI mapped GSI18 to IRQ28
> [3.537736] brcmfmac: brcmf_chip_recognition: SB chip is not supported
> [3.537749] brcmfmac: brcmf_pcie_probe: failed 14e4:43ec
> [3.539846] e1000e :00:00.6 enp0s0f6: renamed from eth0
> 
> - user@debian-net:/lib64$ sudo lspci -k
> 00:00.6 Ethernet controller: Intel Corporation Ethernet Connection I219-LM 
> (rev 21)
> Subsystem: Lenovo Ethernet Connection I219-LM
> Kernel driver in use: e1000e
> Kernel modules: e1000e
> 00:01.0 Network controller: Broadcom Limited BCM4356 802.11ac Wireless 
> Network Adapter (rev 02)
> Subsystem: Lenovo BCM4356 802.11ac Wireless Network Adapter
> Kernel modules: brcmfmac
> 
> user@debian-net:/lib64$ sudo ifconfig
> enp0s0f6: flags=4163  mtu 1500
> inet 192.168.45.172  netmask 255.255.255.0  broadcast 192.168.45.255
> inet6 fe80::eacd:816d:b465:e28a  prefixlen 64  scopeid 0x20
> ether c8:5b:76:5c:5a:06  txqueuelen 1000  (Ethernet)
> RX packets 29359  bytes 35630763 (33.9 MiB)
> RX errors 0  dropped 0  overruns 0  frame 0
> TX packets 17109  bytes 1910984 (1.8 MiB)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> device interrupt 26  memory 0xe160-e162  
> 
> lo: flags=73  mtu 65536
> inet 127.0.0.1  netmask 255.0.0.0
> inet6 ::1  prefixlen 128  scopeid 0x10
> loop  txqueuelen 1000  (Local Loopback)
> RX packets 8  bytes 380 (380.0 B)
> RX errors 0  dropped 0  overruns 0  frame 0
> TX packets 8  bytes 380 (380.0 B)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> 
> => if I install on the same machine debian-9 directly the wifi works
> => if I use qubes debian-9 NetVM I get "SB chip is not supported" even though 
> device is attached to VM
> => Has anyone an idea/suggestion what I could do to get rid of the "SB chip 
> is not supported"? I assumed I had the wrong firmware, but why can I use the 
> exact same *deb package on the same machine successfully if I install debian 
> directly on the same machine without qubes?
> 
> P.S.: I have also tried to create a HVM with debian-9 installer:
> - if I install debian on the HVM the X Window gets messed up  => black screen 
> => need to switch on/off the machine
> - if I use live DVD on HVM => I can install package until reboot, run the 
> modprobe brcmfmac command without error in dmesg, but the Wifi Adapter is not 
> shown in the Network Manager
> 
> Thanks for any help!
> 

That driver is quite buggy, and broadcom linux support is woeful.
Try the driver from testing - search packages.debian.org, and look under
testing for the latest version. It should install ok.

-- 
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/20181226003715.sbgoqbik5ltarfty%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: How risky is GPU pass-through?

2018-12-25 Thread qubenix
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Zrubi:
> On 12/23/18 9:34 PM, Demi M. Obenour wrote:
>> Someone I know is interested in using QubesOS.  However, they
>> are also a gamer: if they could not have a Windows VM with access
>> to a dedicated graphics card for use by games, then QubesOS is
>> not an option for them.
> 
> Short answer: Qubes OS is not an option for them.
> 

Why do you say that? If you search this list there are people that
successfully game on Win vm with gpu passthrough.

> 
> The risk part would come only after this feature exists in practice
> ;) Search back for the details.
> 
> 

I can't speak to the security risk from personal experience or
knowledge, but I found this:
https://security.stackexchange.com/questions/162122/gpu-passthrough-security/162175.

- -- 
qubenix

CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20
EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765
-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEElgluTKCHDxxbr33ZCdFZ4SQfnFQFAlwgMjdfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk2
MDk2RTRDQTA4NzBGMUM1QkFGN0REOTA5RDE1OUUxMjQxRjlDNTQACgkQCdFZ4SQf
nFR7IA//YE7rVNDmYFiXmIU9v7d7j9Bg3bPNSQ6wFnWNclylA3NSvzJ2k/uurcXW
HSz/7r3jDSnJgD6trVan8SMOLlVhU48Hz9FCOxrVagwU69Ch+70vEZplauDcbEC7
UKu3vTFaC5Gawu8EHSqeT97eYCjSqvc/K82g6Wlij9uYOp7juTpQXX9ekIYH4i94
2TI+ZEYCJ/IaoL12aNQbDz6TzR6lsQDnsUiEppd1hnCX/yQphVymRlFG4qBQsXUA
40cAiqSUvpoAchxiWuTS7o4wCblSgrYkHHNzBvX0i+8JhSVmiknloPb+rBZmUVrs
0AoS2cqW3ojKIDXdfQ5Yn27p9TSR9AkoGbNDN9hZSl0CQTjXDGKV/Lcdj9qSSy+X
+xOEJL63nYp94hofsDmZhg7EfcARA5C5JbLF0TzA2fyXlO7hgoX/SsCAv+KaDWhE
8B3Sq+sWH7MAfiJOK/UZN52Bi+I5hUsYsdXPTDSxqkhc6aOnYL8i9wi89gPZ4iVi
JTQ6Tzn87Y5fWeBnz10viMWyfj71rD1AktA9GM20zsw60jx+GcDwtxOHxQLWRTNb
vR1KuET9E+XaS4oEmTcNDACNj0ui+H7OgCRt64plfOttrc9FDtUXgTLMHypMx0bV
zNsV02DucRNWaFSpG6ZrXJMarqvC4NLihAFzhpo2QsGQSpTgiME=
=suwp
-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/174d9e11-0e0a-7924-b8f8-5339b138358f%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Port Forward in qubes-OS.

2018-12-25 Thread menoldstyle
Hello friends! Pls, help me :(
I need to configure port forwarding to Kali linux VM via sys-net ---> 
sys-firewall ---> sys-whonix ---> VPN-VM ---> KaliVM to use meterpreter and 
apache2 on my Kali linux VM. At first I tried to use scripts:
https://gist.github.com/jpouellet/d8cd0eb8589a5b9bf0c53a28fc530369
https://gist.github.com/Joeviocoe/6c4dc0c283f6d6c5b1a3f5af8793292b
https://github.com/niccokunzmann/qvm-expose-port
I transferred them to the dom0 machine in the / usr / local / bin / folder
I tried to run these scripts, but ports 443, 8080, 80 do not work on Kali linux 
VM.
Then i tried to do it manually
https://www.qubes-os.org/doc/firewall/#port-forwarding-to-a-qube-from-the-outside-world
[user@sys-net ~]$ ifconfig | grep -i cast
ens6: flags=4099  mtu 1500
ens5f0u1: flags=4163  mtu 1500
inet 192.168.0.157  netmask 255.255.255.0  broadcast 192.168.0.255
vif3.0: flags=4163  mtu 1500
inet 10.137.0.5  netmask 255.255.255.255  broadcast 0.0.0.0
wls7: flags=4099  mtu 1500
[user@sys-net ~]$ ifconfig | grep -i cast
ens6: flags=4099  mtu 1500
ens5f0u1: flags=4163  mtu 1500
inet 192.168.0.157  netmask 255.255.255.0  broadcast 192.168.0.255
vif3.0: flags=4163  mtu 1500
inet 10.137.0.5  netmask 255.255.255.255  broadcast 0.0.0.0
wls7: flags=4099  mtu 1500


[user@sys-net ~]$ sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 
-d 192.168.0.157 -j DNAT --to-destination 10.137.0.6

[user@sys-net ~]$ sudo iptables -I FORWARD 2 -i eth0 -d 10.137.1.6 -p tcp 
--dport 443 -m conntrack --ctstate NEW -j ACCEPT 
 
[user@sys-net ~]$ sudo nft add rule ip qubes-firewall forward meta iifname eth0 
ip daddr 10.137.0.6 tcp dport 443 ct state new counter accept

[user@sys-net ~]$ sudo iptables -t nat -L -v -n
Chain PREROUTING (policy ACCEPT 3 packets, 156 bytes)
 pkts bytes target prot opt in out source   destination 

15233  807K PR-QBS all  --  *  *   0.0.0.0/00.0.0.0/0   

15220  806K PR-QBS-SERVICES  all  --  *  *   0.0.0.0/0
0.0.0.0/0   
0 0 DNAT   tcp  --  eth0   *   0.0.0.0/0
192.168.0.157tcp dpt:443 to:10.137.0.6

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

Chain OUTPUT (policy ACCEPT 1546 packets, 104K bytes)
 pkts bytes target prot opt in out source   destination 
   

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

0 0 ACCEPT all  --  *  vif+0.0.0.0/00.0.0.0/0   

3   156 ACCEPT all  --  *  lo  0.0.0.0/00.0.0.0/0   

30894 2067K MASQUERADE  all  --  *  *   0.0.0.0/00.0.0.0/0  


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

0 0 DNAT   udp  --  *  *   0.0.0.0/010.139.1.1  
 udp dpt:53 to:10.139.1.1
0 0 DNAT   tcp  --  *  *   0.0.0.0/010.139.1.1  
 tcp dpt:53 to:10.139.1.1
0 0 DNAT   udp  --  *  *   0.0.0.0/010.139.1.2  
 udp dpt:53 to:10.139.1.2
0 0 DNAT   tcp  --  *  *   0.0.0.0/010.139.1.2  
 tcp dpt:53 to:10.139.1.2

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

0 0 REDIRECT   tcp  --  vif+   *   0.0.0.0/0
10.137.255.254   tcp dpt:8082
[user@sys-net ~]$ sudo iptables -L -v -n
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target prot opt in out source   destination 

0 0 ACCEPT tcp  --  vif+   *   0.0.0.0/00.0.0.0/0   
 tcp dpt:8082
0 0 DROP   udp  --  vif+   *   0.0.0.0/00.0.0.0/0   
 udp dpt:68
44760 4252K ACCEPT all  --  *  *   0.0.0.0/00.0.0.0/0   
 ctstate RELATED,ESTABLISHED
0 0 ACCEPT icmp --  vif+   *   0.0.0.0/00.0.0.0/0   

3   156 ACCEPT all  --  lo *   0.0.0.0/00.0.0.0/0   

0 0 REJECT all  --  vif+   *   0.0.0.0/00.0.0.0/0   
 reject-with icmp-host-prohibited
   62  2480 DROP   all  --  *  *   0.0.0.0/00.0.0.0/0   
   

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

 660K  438M ACCEPT all  --  *  *   0.0.0.0/00.0.0.0/0   
 ctstate RELATED,ESTABLISHED
0 0 ACCEPT tcp  --  eth0   *   0.0.0.0/0 

[qubes-users] Re: Broadcom brcm 4356 Wifi card not working

2018-12-25 Thread Martin Weck
regarding the HVM approach, I have noticed that the whole device is missing, 
although I have added it to the VM:
user@debian:~$ sudo lspci -k
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
Subsystem: Red Hat, Inc Qemu virtual machine
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
Subsystem: Red Hat, Inc Qemu virtual machine
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
Subsystem: XenSource, Inc. 82371SB PIIX3 IDE [Natoma/Triton II]
Kernel driver in use: ata_piix
Kernel modules: ata_piix, ata_generic
00:01.2 USB controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] 
(rev 01)
Subsystem: Red Hat, Inc QEMU Virtual Machine
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01)
Subsystem: Red Hat, Inc Qemu virtual machine
Kernel modules: i2c_piix4
00:02.0 VGA compatible controller: Device 1234:
Subsystem: XenSource, Inc. Device 0001
Kernel modules: bochs_drm
00:03.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
Subsystem: XenSource, Inc. Xen Platform Device
Kernel driver in use: xen-platform-pci
00:04.0 Ethernet controller: Intel Corporation Ethernet Connection I219-LM (rev 
21)
Subsystem: Lenovo Ethernet Connection I219-LM
Kernel driver in use: e1000e
Kernel modules: e1000e

-- 
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/8370ba03-aa9f-4a7f-995b-c5574c41e4b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Broadcom brcm 4356 Wifi card not working

2018-12-25 Thread Martin Weck
Hi,
I have got a Lenovo L460 with Broadcom brcm4356 Wifi Adapter that I don't get 
working on Qubes.
To isolate the problem, I have first installed a debian-9 directly on the 
machine and got this after some problems working 
(https://www.linuxquestions.org/questions/linux-wireless-networking-41/debian-broadcom-bcm4356-802-11ac-wireless-not-working-4175644801/)

Steps to reproduce:
- Have Qubes 3.2.1 (also tried Qubes 4.0.1-rc2 without success)
- Create NetVM debian-9 based with device:
-- 00:1f.6 Ethernet controller: Intel Corporation l219-LM (rev21)
-- 03:00.0 Network controller: Broadcom Limited BCM4356 802.11ac Wireless 
Network Adapter (rev02)
(cable based Ethernet works on qube without flaws)
- install firmware-brcm80211_20180825+dfsg-1_all.deb and add 
brcmfmac4356-pcie.txt
- Unload kernel module sudo modprobe -f brcmfmac
- Load kernel module sudo modprobe brcmfmac
- sudo dmesg | less
[3.476763] usbcore: registered new interface driver brcmfmac
[3.532479] e1000e :00:00.6 eth0: (PCI Express:2.5GT/s:Width x1) 
c8:5b:76:5c:5a:06
[3.532497] e1000e :00:00.6 eth0: Intel(R) PRO/1000 Network Connection
[3.532587] e1000e :00:00.6 eth0: MAC: 12, PHY: 12, PBA No: FF-0FF
[3.535156] brcmfmac :00:01.0: Xen PCI mapped GSI18 to IRQ28
[3.537736] brcmfmac: brcmf_chip_recognition: SB chip is not supported
[3.537749] brcmfmac: brcmf_pcie_probe: failed 14e4:43ec
[3.539846] e1000e :00:00.6 enp0s0f6: renamed from eth0

- user@debian-net:/lib64$ sudo lspci -k
00:00.6 Ethernet controller: Intel Corporation Ethernet Connection I219-LM (rev 
21)
Subsystem: Lenovo Ethernet Connection I219-LM
Kernel driver in use: e1000e
Kernel modules: e1000e
00:01.0 Network controller: Broadcom Limited BCM4356 802.11ac Wireless Network 
Adapter (rev 02)
Subsystem: Lenovo BCM4356 802.11ac Wireless Network Adapter
Kernel modules: brcmfmac

user@debian-net:/lib64$ sudo ifconfig
enp0s0f6: flags=4163  mtu 1500
inet 192.168.45.172  netmask 255.255.255.0  broadcast 192.168.45.255
inet6 fe80::eacd:816d:b465:e28a  prefixlen 64  scopeid 0x20
ether c8:5b:76:5c:5a:06  txqueuelen 1000  (Ethernet)
RX packets 29359  bytes 35630763 (33.9 MiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 17109  bytes 1910984 (1.8 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
device interrupt 26  memory 0xe160-e162  

lo: flags=73  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10
loop  txqueuelen 1000  (Local Loopback)
RX packets 8  bytes 380 (380.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 8  bytes 380 (380.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

=> if I install on the same machine debian-9 directly the wifi works
=> if I use qubes debian-9 NetVM I get "SB chip is not supported" even though 
device is attached to VM
=> Has anyone an idea/suggestion what I could do to get rid of the "SB chip is 
not supported"? I assumed I had the wrong firmware, but why can I use the exact 
same *deb package on the same machine successfully if I install debian directly 
on the same machine without qubes?

P.S.: I have also tried to create a HVM with debian-9 installer:
- if I install debian on the HVM the X Window gets messed up  => black screen 
=> need to switch on/off the machine
- if I use live DVD on HVM => I can install package until reboot, run the 
modprobe brcmfmac command without error in dmesg, but the Wifi Adapter is not 
shown in the Network Manager

Thanks for 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/fa5c257b-f282-4291-ac3e-6197d51a45ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Fed-28 update error

2018-12-25 Thread max via qubes-users
onsdag den 19. december 2018 kl. 05.34.37 UTC-5 skrev qube...@tutanota.com:
> Hi, I updated the dom0 and after I tried to update the Fed-28 template. I get 
> following error:
> 
> [user@fedora-28 ~]$ sudo dnf update
> Last metadata expiration check: 0:27:37 ago on Wed 19 Dec 2018 11:04:23 AM 
> CET.
> Dependencies resolved.
> 
> Problem 1: cannot install the best update candidate for package 
> hplip-3.18.6-10.fc28.x86_64
>   - nothing provides libnetsnmp.so.35()(64bit) needed by 
> hplip-3.18.6-11.fc28.x86_64
> Problem 2: cannot install the best update candidate for package 
> hplip-libs-3.18.6-10.fc28.x86_64
>   - nothing provides libnetsnmp.so.35()(64bit) needed by 
> hplip-libs-3.18.6-11.fc28.x86_64
> Problem 3: cannot install the best update candidate for package 
> libsane-hpaio-3.18.6-10.fc28.x86_64
>   - nothing provides libnetsnmp.so.35()(64bit) needed by 
> libsane-hpaio-3.18.6-11.fc28.x86_64
> Problem 4: package hplip-libs-3.18.6-10.fc28.x86_64 requires 
> hplip-common(x86-64) = 3.18.6-10.fc28, but none of the providers can be 
> installed
>   - cannot install both hplip-common-3.18.6-11.fc28.x86_64 and 
> hplip-common-3.18.6-10.fc28.x86_64
>   - problem with installed package hplip-libs-3.18.6-10.fc28.x86_64
>   - cannot install the best update candidate for package 
> hplip-common-3.18.6-10.fc28.x86_64
>   - nothing provides libnetsnmp.so.35()(64bit) needed by 
> hplip-libs-3.18.6-11.fc28.x86_64
> 
> Package  Arch  Version    Repository  Size
> 
> Skipping packages with conflicts:
> (add '--best --allowerasing' to command line to force their upgrade):
> hplip-common x86_64    3.18.6-11.fc28 updates    110 k
> Skipping packages with broken dependencies:
> hplip    x86_64    3.18.6-11.fc28 updates 16 M
> hplip-libs   x86_64    3.18.6-11.fc28 updates    204 k
> libsane-hpaio    x86_64    3.18.6-11.fc28 updates    127 k
> 
> Transaction Summary
> 
> Skip  4 Packages
> 
> Nothing to do.
> Complete!
> 
> ***
> 
> When doing the --best --allowerasing I get this:
> 
> [user@fedora-28 ~]$ sudo dnf --best --allowerasing update
> Last metadata expiration check: 0:28:55 ago on Wed 19 Dec 2018 11:04:23 AM 
> CET.
> Error:
> Problem 1: cannot install the best update candidate for package 
> libsane-hpaio-3.18.6-10.fc28.x86_64
>   - problem with installed package libsane-hpaio-3.18.6-10.fc28.x86_64
>   - nothing provides libnetsnmp.so.35()(64bit) needed by 
> libsane-hpaio-3.18.6-11.fc28.x86_64
> Problem 2: cannot install the best update candidate for package 
> hplip-libs-3.18.6-10.fc28.x86_64
>   - problem with installed package hplip-libs-3.18.6-10.fc28.x86_64
>   - nothing provides libnetsnmp.so.35()(64bit) needed by 
> hplip-libs-3.18.6-11.fc28.x86_64
> Problem 3: cannot install the best update candidate for package 
> hplip-3.18.6-10.fc28.x86_64
>   - problem with installed package hplip-3.18.6-10.fc28.x86_64
>   - nothing provides libnetsnmp.so.35()(64bit) needed by 
> hplip-3.18.6-11.fc28.x86_64
> 
> *
> 
> Any help appreciated. 
> Thank you!

I could not resolve the issue with the answers in this thread, but fedora 
mailinglist did help me resolve the issue. The solution provided is provided 
here:
https://www.spinics.net/linux/fedora/fedora-users/msg488308.html

The command resolving the issue is:
sudo dnf --best --allowerasing --enablerepo=updates-testing update hplip

Sincerely
Max

-- 
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/8fe25630-8b8f-4ff8-974b-9e6ffdf5912e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Port Forward in qubes-OS.

2018-12-25 Thread menoldstyle
Packets are not transmitted after I added port 80 and 8080 to sys-net.

[user@sys-net ~]$ sudo iptables -t nat -L -v -n
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source   destination 

15234  807K PR-QBS all  --  *  *   0.0.0.0/00.0.0.0/0   

15221  806K PR-QBS-SERVICES  all  --  *  *   0.0.0.0/0
0.0.0.0/0   
0 0 DNAT   tcp  --  eth0   *   0.0.0.0/0
192.168.0.157tcp dpt:443 to:10.137.0.6
0 0 DNAT   tcp  --  eth0   *   0.0.0.0/0
192.168.0.157tcp dpt:80 to:10.137.0.6
0 0 DNAT   tcp  --  eth0   *   0.0.0.0/0
192.168.0.157tcp dpt:8080 to:10.137.0.6

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


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


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

0 0 ACCEPT all  --  *  vif+0.0.0.0/00.0.0.0/0   

3   156 ACCEPT all  --  *  lo  0.0.0.0/00.0.0.0/0   

32702 2189K MASQUERADE  all  --  *  *   0.0.0.0/00.0.0.0/0  
 

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

0 0 DNAT   udp  --  *  *   0.0.0.0/010.139.1.1  
 udp dpt:53 to:10.139.1.1
0 0 DNAT   tcp  --  *  *   0.0.0.0/010.139.1.1  
 tcp dpt:53 to:10.139.1.1
0 0 DNAT   udp  --  *  *   0.0.0.0/010.139.1.2  
 udp dpt:53 to:10.139.1.2
0 0 DNAT   tcp  --  *  *   0.0.0.0/010.139.1.2  
 tcp dpt:53 to:10.139.1.2

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

0 0 REDIRECT   tcp  --  vif+   *   0.0.0.0/0
10.137.255.254   tcp dpt:8082

-- 
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/b836b2de-d402-45a0-92a7-3e77f8b0cdbe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: How risky is GPU pass-through?

2018-12-25 Thread John Mitchell
On Monday, December 24, 2018 at 1:52:53 PM UTC+1, Hugo Costa wrote:
> On Sunday, 23 December 2018 20:34:48 UTC, Demi M. Obenour  wrote:
> > Someone I know is interested in using QubesOS.  However, they are also a
> > gamer: if they could not have a Windows VM with access to a dedicated
> > graphics card for use by games, then QubesOS is not an option for them.
> > 
> > How risky is GPU pass-through?  My understanding is that on most
> > laptops, the primary (internal) display is connected to the integrated
> > GPU.  Therefore, it appears to me that the risks are no more than
> > pass-through of the USB, Ethernet, or wireless controllers, all of which
> > QubesOS does by default.
> 
> Best option would be to dual boot. Unless that person is always switching 
> from game to desktop, this solution could probably be an acceptable 
> compromise.

In my opinion, dual booting is just as risky as GPU pass-through, maybe more 
so.  Having a GPU sandboxed in a VM that will never see production VMs would be 
ideal.  Although if you only have one GPU then there is no better option at the 
moment.

-- 
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/ec711eb1-db78-417b-bf95-2e280cd474ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Port Forward in qubes-OS.

2018-12-25 Thread menoldstyle
I need to forward the port to Kali Vm in order to use meterpreter and apache2 
on my KaliVM:
sys-net ---> sys-firewall ---> sys-whonix ---> VPN ---> KaliVM.
This can be done?

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


Re: [qubes-users] Port Forward in qubes-OS.

2018-12-25 Thread menoldstyle
What mistake do I make?

-

[user@sys-net ~]$ ifconfig | grep -i cast
ens6: flags=4099  mtu 1500
ens5f0u1: flags=4163  mtu 1500
inet 192.168.0.157  netmask 255.255.255.0  broadcast 192.168.0.255
vif3.0: flags=4163  mtu 1500
inet 10.137.0.5  netmask 255.255.255.255  broadcast 0.0.0.0
wls7: flags=4099  mtu 1500
[user@sys-net ~]$ ifconfig | grep -i cast
ens6: flags=4099  mtu 1500
ens5f0u1: flags=4163  mtu 1500
inet 192.168.0.157  netmask 255.255.255.0  broadcast 192.168.0.255
vif3.0: flags=4163  mtu 1500
inet 10.137.0.5  netmask 255.255.255.255  broadcast 0.0.0.0
wls7: flags=4099  mtu 1500

[user@sys-net ~]$ sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 
-d 192.168.0.157 -j DNAT --to-destination 10.137.0.6

[user@sys-net ~]$ sudo iptables -I FORWARD 2 -i eth0 -d 10.137.1.6 -p tcp 
--dport 443 -m conntrack --ctstate NEW -j ACCEPT 
   ^
[user@sys-net ~]$ sudo nft add rule ip qubes-firewall forward meta iifname eth0 
ip daddr 10.137.0.6 tcp dport 443 ct state new counter accept

[user@sys-net ~]$ sudo iptables -t nat -L -v -n
Chain PREROUTING (policy ACCEPT 3 packets, 156 bytes)
 pkts bytes target prot opt in out source   destination 

15233  807K PR-QBS all  --  *  *   0.0.0.0/00.0.0.0/0   

15220  806K PR-QBS-SERVICES  all  --  *  *   0.0.0.0/0
0.0.0.0/0   
0 0 DNAT   tcp  --  eth0   *   0.0.0.0/0
192.168.0.157tcp dpt:443 to:10.137.0.6

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


Chain OUTPUT (policy ACCEPT 1546 packets, 104K bytes)
 pkts bytes target prot opt in out source   destination 


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

0 0 ACCEPT all  --  *  vif+0.0.0.0/00.0.0.0/0   

3   156 ACCEPT all  --  *  lo  0.0.0.0/00.0.0.0/0   

30894 2067K MASQUERADE  all  --  *  *   0.0.0.0/00.0.0.0/0  
 

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

0 0 DNAT   udp  --  *  *   0.0.0.0/010.139.1.1  
 udp dpt:53 to:10.139.1.1
0 0 DNAT   tcp  --  *  *   0.0.0.0/010.139.1.1  
 tcp dpt:53 to:10.139.1.1
0 0 DNAT   udp  --  *  *   0.0.0.0/010.139.1.2  
 udp dpt:53 to:10.139.1.2
0 0 DNAT   tcp  --  *  *   0.0.0.0/010.139.1.2  
 tcp dpt:53 to:10.139.1.2

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

0 0 REDIRECT   tcp  --  vif+   *   0.0.0.0/0
10.137.255.254   tcp dpt:8082

[user@sys-net ~]$ sudo iptables -L -v -n
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target prot opt in out source   destination 

0 0 ACCEPT tcp  --  vif+   *   0.0.0.0/00.0.0.0/0   
 tcp dpt:8082
0 0 DROP   udp  --  vif+   *   0.0.0.0/00.0.0.0/0   
 udp dpt:68
44760 4252K ACCEPT all  --  *  *   0.0.0.0/00.0.0.0/0   
 ctstate RELATED,ESTABLISHED
0 0 ACCEPT icmp --  vif+   *   0.0.0.0/00.0.0.0/0   

3   156 ACCEPT all  --  lo *   0.0.0.0/00.0.0.0/0   

0 0 REJECT all  --  vif+   *   0.0.0.0/00.0.0.0/0   
 reject-with icmp-host-prohibited
   62  2480 DROP   all  --  *  *   0.0.0.0/00.0.0.0/0   


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

 660K  438M ACCEPT all  --  *  *   0.0.0.0/00.0.0.0/0   
 ctstate RELATED,ESTABLISHED
0 0 ACCEPT tcp  --  eth0   *   0.0.0.0/010.137.1.6  
 tcp dpt:443 ctstate NEW
  163  8531 QBS-FORWARD  all  --  *  *   0.0.0.0/00.0.0.0/0 
  
0 0 DROP   all  --  vif+   vif+0.0.0.0/00.0.0.0/0   

  163  8531 ACCEPT all  --  vif+   *   0.0.0.0/00.0.0.0/0   

0 0 DROP   all  --  *  *   0.0.0.0/00.0.0.0/0   


Chain OUTPUT (policy ACCEPT 3220 packets, 216K bytes)
 pkts bytes target prot opt in out source   destination 


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


[user@sys-net ~]$ sudo nft list table ip 

Re: [qubes-users] Port Forward in qubes-OS.

2018-12-25 Thread Achim Patzner
On 20181225 at 00:25 -0800 menoldst...@gmail.com wrote:
>  Permission denied (you must be root)

Sometimes a closer look at the error mesage solves the riddle.


Achim


-- 
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/4e1bb1c4675aa2a607af4e23d27dc01f4b720f92.camel%40noses.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] HCL - R4.0 - AS Rock Z370 Extreme4, i7-8700k

2018-12-25 Thread tburkhart
Thanks for the brilliant work with qubes, I took value from the hardware 
support page to wanted to send in my data aswell.


Can confirm everything works pretty much out of the box.

Only issue I have is the Corsair k70 keyboard does need to be unplugged 
then plugged back in at boot when entering the password to decrypt, 
other than that works fine.


Motherboard: ASRock Z370 Extreme4
CPU: Intel i7-8700k
RAM: Corsair Vengance


Please see attached HCL log

Thanks
Tristão Burkhart

--
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/02d1737a8e6952f24e7d6fee3474d021%40cock.li.
For more options, visit https://groups.google.com/d/optout.
---
layout:
  'hcl'
type:
  'desktop'
hvm:
  'yes'
iommu:
  'yes'
slat:
  'yes'
tpm:
  'unknown'
remap:
  'yes'
brand: |
  ASRock
model: |
  Z370 Extreme4
bios: |
  P3.10
cpu: |
  Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz
cpu-short: |
  FIXME
chipset: |
  Intel Corporation Device [8086:3ec2] (rev 07)
chipset-short: |
  FIXME
gpu: |
  Advanced Micro Devices, Inc. [AMD/ATI] Malta [Radeon HD 7990/8990 OEM] 
[1002:679b] (prog-if 00 [VGA controller])
  Advanced Micro Devices, Inc. [AMD/ATI] Malta [Radeon HD 7990/8990 OEM] 
[1002:679b]
gpu-short: |
  FIXME
network: |
  Intel Corporation Ethernet Connection (2) I219-V
memory: |
  32701
scsi: |
  TOSHIBA DT01ACA2 Rev: ABB0
  CDDVDW SH-224DB  Rev: SB01
  Samsung SSD 840  Rev: BB6Q
usb: |
  2
versions:

- works:
'FIXME:yes|no|partial'
  qubes: |
R4.0
  xen: |
4.8.3
  kernel: |
4.14.18-1
  remark: |
FIXME
  credit: |
FIXAUTHOR
  link: |
FIXLINK

---



[qubes-users] SINIT module RACM update: access denied (Anti-Evil-Maid)

2018-12-25 Thread Lorenzo Lamas
I'm installing AEM for the first time in Qubes 4 and noticed that the 
readme(https://github.com/QubesOS/qubes-antievilmaid/blob/master/anti-evil-maid/README)
 has been significantly expanded since 3.2, specifically it mentions to make 
sure to get the latest RACM update at the SINIT module instructions:

"Also, make sure you have the latest RACM update, if available (2nd & 3rd gen):
https://software.intel.com/system/files/article/183305/intel-txt-sinit-acm-revocation-tools-guide-rev1-0_2.pdf

It's possible to use 3rd gen SINIT/RACM on 2nd gen platforms. In fact, the
only RACM available at the time of writing is for the 3rd gen, while the 2nd
gen platforms were also affected by the buffer overflow bug in old SINIT
version."

That is not a public link however, you need to login with an account. I have 
successfully registered an account and logged in, but then I get an Access 
Denied message when opening the link.

-- 
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/a8782179-ad68-4728-9da1-64229d71593d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Port Forward in qubes-OS.

2018-12-25 Thread menoldstyle
вторник, 25 декабря 2018 г., 5:26:04 UTC+3 пользователь unman написал:
> On Mon, Dec 24, 2018 at 06:08:27AM -0800, menoldst...@gmail.com wrote:
> > Hello. Qubes-users. I installed Kali linux and now I need to make it so 
> > that apache2 would work not only on the local network, but also on the 
> > Internet. I need to do port forwarding ?? If so, can anyone tell me how to 
> > do this?
> > 
> 
> Have you looked at the docs?
> https://www.qubes-os.org/doc/firewall/#port-forwarding-to-a-qube-from-the-outside-world
Thank you. What needs to be done to upgrade?

[user@sys-net ~]$ iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 
192.168.0.151 -j DNAT --to-destination 10.137.0.4
iptables v1.6.1: can't initialize iptables table `nat': Permission denied (you 
must be root)
Perhaps iptables or your kernel needs to be upgraded.

-- 
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/6d3adcc9-c04d-4077-83d9-510f4657fb2d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.