[qubes-users] Unable to mount DVD-RAM in VM in read-write mode

['David Shleifman' via qubes-users]

   Hi,

A DVD-RAM /dev/sr0 is connected to the same SATA controller as
the system HDDs.  It is visible in dom0 as /dev/sr0.   I attached it 

to a vm. Then, I mounted it in VM as /mnt/removable:
  vm$ mount -o rw /dev/xvdi as /mnt/removable

The system replied:
   mount: /dev/xvdi is write-protected; mounting read-only.
Is it expected?
Will PV SCSI (https://wiki.xen.org/wiki/Paravirtualized_SCSI) support 
DVD-RAM in read-write mode if it is connected to the same SATA
controller as the system HDDs? 
   

   Thanks,
   - David

-- 
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/715865312.2109362.1492427511841%40mail.yahoo.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Installation from a tarball: any Qubes OS particulars?

['David Shleifman' via qubes-users]

Are there any guidelines (specific to Qubes OS) on installation from a tarball?


I am asking since the guidelines for installing software
https://www.qubes-os.org/doc/software-update-vm/#installing-or-updating-software-in-the-templatevm
assume existence of rpm or deb packages.  They do not shed light on the 
installation
from a tarball.  It is not clear, whether any extra steps should be taken.


I wonder how people cope with this situation.  For instance:

1) Do you vet the software installer code before running it?
   (see 
https://www.qubes-os.org/doc/software-update-vm/#notes-on-trusting-your-templatevms)
2) Do you update the list of available applications in dom0?

   (see 
https://www.qubes-os.org/doc/managing-appvm-shortcuts/#what-if-my-application-has-not-been-automatically-included-in-the-list-of-available-apps)
3) Do you assemble RPM (from a tarball) to avoid the hassles 1) and 2) ?

4) From the trust point of view, do you prefer to build binaries from the 
sources?

   because (hypothetical reason):
   a) distributed binaries are not signed

   b) to make sure the software is linked to trusted libraries only

-- 
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/1697922883.10486461.1491102112019%40mail.yahoo.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Validating (DNSSEC) name resolver

['David Shleifman' via qubes-users]

Starting point

--
- Qubes v3.2
- validation of the resolved names takes place at DNS that LAN router gets from 
ISP


Ending point


- same Qubes 3.2
- validation of the resolved names takes place in one of the VMs.
- dnscrypt is not involved




Few years ago Alex Dubois did a great job by posting

http://bowabos.blogspot.ca/2013/11/how-to-set-up-dnscrypt-proxy-on-qubes-os.html
I tried to follow his guidelines and got lost.  In particular:

1) What VM is better suited for running validating name resolver, i.e. 
'unbound'? 
_  I guess that ProxyVM is good enough to isolate the validation process 

_  from both AppVMs and FirewallVM.  Is it a reasonable guess?

2) I copied /etc/unbound/unbound.conf to /rw/config/unbound following the 
guideline.
_  Then I got lost.  

_  a) What value should be used instead of 'x' in the following setting?
_   interface: 10.137.2.x

_ Is it the IP address of eth0 interface in ProxyVM?   

_ Running "ifconfig" in ProxyVM terminal yields inet 10.137.2.21.
_ Is this address stays always the same between reboots of the entire Qubes 
OS?



_  b) What value should be used in the following setting?

_access-control: 10.137.2.0/24 allow
_   access-control: 10.138.2.0/24 allow


_ Are they IP addresses of vif interfaces in the ProxyVM? 

_ Running "ifconfig" in ProxyVM terminal yields inet 10.137.5.1

 

_ Or they are IP addresses of eth0 interfaces in AppVMs that are configured
_ to use this Proxy VM as NetVM?
_ Running "ifconfig" in these AppVMs yields inet 10.137.5.9 and 10.138.5.6 
(DispVM) 


_  c) What value should be used instead of 'x' and 'y'?

_ access-control: x.x.x.x/y allow

_  d) I left 

_val-permissive-mode: yes

_ as shown in the guideline.  I will be using it for debug purposes.  Once I
_ confirm that everything up and running, I will change it to 'no'.
_ Let me know if it will have devastating effect on AppVMs.



_  e) I left it 

_ do-not-query-localhost: no

_  f) Is this setting going to work given that no dnscrypt is listening on 
127.0.0.1@53?
_ If not, what should it be set to so that name is eventually resolved by 
_ DNS that LAN router gets from ISP (same way how it was working at the 
starting point)?

_forward-zone:
_ name: "."
_   forward-addr: 127.0.0.1@53

3) According to the guidelines, rc.local should have INPUT rules 

_  /usr/sbin/iptables -I INPUT 3 -j ACCEPT -d 10.137.2.x -p udp --sport 
1024:65535 --dport 53 -m conntrack --ctstate NEW
_  /usr/sbin/iptables -I INPUT 3 -j ACCEPT -d 10.137.2.x -p tcp --sport 
1024:65535 --dport 53 -m conntrack --ctstate NEW

_   What value should be used instead of 'x'
_   Is it the IP address of eth0 interface in ProxyVM?


I hope, it will get easier to set up Validating (DNSSEC) Name Resolver after
https://github.com/QubesOS/qubes-issues/issues/2344 is addressed.

-- 
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/374093626.4280608.1489949096487%40mail.yahoo.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: How to manage multiple USB controllers

['David Shleifman' via qubes-users]

- Original Message -
From: "raahe...@gmail.com" 
To: qubes-users 
Cc: dimi...@yahoo.com; raahe...@gmail.com
Sent: Monday, October 10, 2016 4:09 PM
Subject: Re: How  to manage multiple USB controllers



> I don't think you really have 6 controllers do you?
dom0$ lspci | grep USB
returns 6 PCI devices:
Bus:Device.Function

00:12.0 ... SB7x0/SB8x0/SB9x0 USB OHCI0 Controller

00:12.1 ... SB7x0 USB OHCI1 Controller

00:12.2 ... SB7x0/SB8x0/SB9x0 USB EHCI  Controller
00:13.0 ... SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:13.1 ... SB7x0 USB OHCI1 Controller

00:13.2 ... SB7x0/SB8x0/SB9x0 USB EHCI   Controller


Is it 6 controllers?




> On mine I have only two echi's.
> one is for the two low speed ports, next to the ps2 port which i use for 
> mouse and keyboard, and is assigned to dom0.  The other 

> controller is for everything else I have in sys-usb.

Thanks for sharing your USB topology and controller assignment.   Have you been 
able to hide the USB controllers from dom0 as described in 
https://www.qubes-os.org/doc/usb/#creating-and-using-a-usb-qube?  So that lspci 
returns an epmty string.




> On another machine with xhvi (usb3.0)  everything gets routed through that 
> one controller.  the two ehvi controllers get routed through
> the usb 3.0 making a single controller not 3.  


How did you determine that the 2 EHCI(s) are routed through XHCI?  What does 

dom0$ lspci | grep USB
return?  Does it show 3 controllers or one?



> so its either use the two controllers the same way I have on this box with 
> xhvi disabled,  

> or enable it then only having a single controller if wanting 3.0 speeds 
> (using the qubes input proxy). 

In the later case, XHCI is attached to sys-usb, and 
https://www.qubes-os.org/doc/usb/#attaching-a-single-usb-device-to-a-qube-usb-passthrough
 is employed to pass it to dom0. Is my understanding correct?   Are you able to 
log in (after the boot) using the USB keyboard? 

-- 
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/376712193.2679434.147614725%40mail.yahoo.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] How to manage multiple USB controllers

['David Shleifman' via qubes-users]

On Oct. 10, 2016 at 9:27 AM, Unman  wrote

> I wouldn't assign back to dom0.
> There's no reason why you shouldn't adopt some variation on A, and have
> different qubes handling different controllers. Of course, you'd have to
> make sure that you follow a consistent pattern with use of sockets.
> You could enforce this with configuration in the policy file, and by
> some udev rules to block anything except storage devices in the relevant
> ports.

> unman

-



Before trying either "A" or "B" direction, I've stumbled upon the following 
difficulty:- after booting, Xfce popes up a dialog box which invites user to 
log in.  At this time, sys-usb hasn't started yet.  That is why, the USB 
keyboard is not operational.  In essence, it is a chicken and egg problem: in 
order to enter a password, the sys-usb VM shall be started; in order to start 
the sys-usb VM, a valid password shall be entered.  



Unman> There's no reason why you shouldn't adopt some variation on AI was 
leaning to adopt some variation of the plan "A".  Unfortunately, the experience 
(see previous paragraph) demonstrates that it is not possible :(



I went forward with the plan "B":
B-1) Stay with a single sys-usb qube and remove rear.OHCI0 controller from 
sys-usb (using Qubes VM Manager).  I assume that the controller will be 
returned back to dom0.  Is it correct?B-2) Remove "sys-usb dom0 ask,user=root" 
from /etc/qubes-rpc/policy/qubes.InputKeyboard.
B-3) Remove "sys-usb dom0 ask,user=root" from 
/etc/qubes-rpc/policy/qubes.InputMouse.

B-4) Remove rd.qubes.hide_all_usb from /etc/default/grub and run
grub2-mkconfig -o /boot/grub2/grub.cfg in dom.  

 
With this plan in place, I am able to log in using the USB keyboard.  



Further enhancements

* In the step B-4, it would be nice to hide all USB controllers from dom0 
except rear.OHCI0.  How to achieve this?

Unman> Of course, you'd have to make sure that you follow a consistent pattern 
with use of sockets.  You could enforce this with configuration in the policy 
file, and by some udev rules to block anything except storage devices in the 
relevant ports. 
* How to achieve this?  Is there some manual?  Do you mind to share an example?


* Correct the policy in 
https://www.qubes-os.org/doc/usb/#how-to-use-a-usb-keyboard manual.  It should 
be:

sys-usb dom0 ask,user=root

-- 
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/1946887460.2653244.1476146051505%40mail.yahoo.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] How to manage multiple USB controllers

['David Shleifman' via qubes-users]

The PC system has 2 USB hubs: the first one is used for USB jacks on the front 
panel, the second one is used for USB jacks on the rear panel. Each hub has 3 
controllers:
front.OHCI0 handles first 3 USB 1.1 devices that are plugged in (nothing at the 
moment)
front.OHCI1 handles next 3 USB 1.1 devices that are plugged in (nothing at the 
moment)
front.EHCI0 handles up to 6 USB 2.0 devices that are plugged in (DVD-RW drive 
and flash stick at the moment)
rear.OHCI0 handles first 3 USB 1.1 devices that are plugged in (USB keyboard 
and USB mouse are plugged in persistently)

rear.OHCI1 handles next 3 USB 1.1 devices that are plugged in (nothing at the 
moment)

rear.EHCI0 handles up to 6 USB 2.0 devices that are plugged in (Web camera, and 
CD-RW drive are plugged in persistently)
I followed the recommendation at 
https://www.qubes-os.org/doc/usb/#creating-and-using-a-usb-qube.  After running 
[dom0]$   qubesctl top.enable qvm.sys-usb

[dom0]$   qubesctl state.highstate 

all 6 controllers have been assigned to sys-usb qube.  It looks like a very bad 
idea to mix security sensitive devices such as keyboard/mouse with other 
devices.  Where do I go from this point?

A) Split controllers into two groups and assign each group to a different 
sys-usb qube? Keyboard/mouse shall end up in a first group, while other devices 
shall end up in the second group.  Is this break down in line with the security 
guidelines (see https://www.qubes-os.org/doc/usb/)?


B) Stay with a single sys-usb qube and assign rear.OHCI0 controller back to 
dom0?  Do 
I need to remove "sys-usb dom0 ask" from 
/etc/qubes-rpc/policy/qubes.InputKeyboard? Do I need to remove 
GRUB_CMDLINE_LINUX rd.qubes.hide_all_usb from /etc/default/grub ?  How to 
instruct GRUB to hide all controllers except rear.OHCI0 ?

-- 
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/791381640.1825127.1476075866991%40mail.yahoo.com.
For more options, visit https://groups.google.com/d/optout.