Re: [qubes-users] Re: sys-usb / template install yubikey tools ?

[ThierryIT]

Le samedi 10 février 2018 22:58:15 UTC+2, Alex Dubois a écrit :
> > On 10 Feb 2018, at 17:46, ThierryIT  wrote:
> > 
> > Le samedi 10 février 2018 01:44:36 UTC+2, Alex Dubois a écrit :
> >> On Saturday, 3 February 2018 22:42:46 UTC, Alex Dubois  wrote:
> >>> On Saturday, 3 February 2018 10:12:25 UTC, ThierryIT  wrote:
>  Le vendredi 19 janvier 2018 13:19:29 UTC+2, Alex Dubois a écrit :
> >> On Friday, 19 January 2018 05:57:16 UTC, ThierryIT  wrote:
> >> Not familiar with this ... Will need procediure to follow.
> >> 
> >> 
> >> Le mercredi 17 janvier 2018 23:03:31 UTC+2, Alex Dubois a écrit :
> >>> On Wednesday, 17 January 2018 15:15:45 UTC, ThierryIT  wrote:
>  No, I am still under R3.2
>  
>  Le mercredi 17 janvier 2018 16:54:58 UTC+2, awokd a écrit :
> > On Wed, January 17, 2018 2:09 pm, ThierryIT wrote:
> >> "https://github.com/adubois/qubes-app-linux-yubikey;
> >> 
> >> 
> >> Le mercredi 17 janvier 2018 16:05:52 UTC+2, awokd a écrit :
> >> 
> >>> On Wed, January 17, 2018 1:09 pm, ThierryIT wrote:
> >>> 
>  Nobody ?
>  
>  
>  
>  Le mercredi 17 janvier 2018 09:23:34 UTC+2, ThierryIT a écrit :
>  
>  
> > Hi,
> > 
> > 
> > 
> > I am going to install a new sys-usb.
> > I have before to install all what I need to the template 
> > (fedora-26)
> > first. When following your procedure:
> > 
> > 
> > ykpers has been installed but: I cannot do the same for
> > qubes-yubikey-vm and qubes-yubikey-dom0 :
> > 
> > no match for argument
> > 
> > ideas ?
> >>> 
> >>> Not quite sure what you are trying to do here. What procedure? 
> >>> What
> >>> command are you entering?
> > 
> > Are you trying this on Qubes 4.0? Those Yubikey packages might not 
> > be in
> > the Qubes repo yet.
> >>> 
> >>> Hi,
> >>> 
> >>> I have not maintained this for some time. So long that I can't 
> >>> remember if the packages had been created/tested, I don't think they 
> >>> have.
> >>> 
> >>> Best is you follow the steps to build it on a new temporary VM, don't 
> >>> be afraid it should not be too hard:
> >>> - Execute the yum command in "Build dependancies"
> >>> - Also install pam-devel
> >>> - Follow the steps in preparing the build and build
> >>> - Deploy the code in Dom0 and the USB VM.
> >>> 
> >>> I am about to upgrade to Qubes 4.0 rc4 (when released) so won't 
> >>> probably be able to help until this is done.
> >>> 
> >>> Any help from someone who is used to packaging under Fedora would be 
> >>> nice.
> >>> 
> >>> Alex
> > 
> > Sure, I'll update the doc and post here. However as I said don't want 
> > to touch my Qubes set-up before my upgrade to 4.0 rc4. So might be in 
> > 2-3weeks
>  
>  Did you upgrade to Q4R4 ?
> >>> 
> >>> I'm in the process. Having issues with PCI path-through of my second NIC 
> >>> that I need to solve. I have to use PV mode for now and not too happy to 
> >>> have too. I'll open another thread if I can't find a way...
> >> 
> >> Hi Thierry,
> >> 
> >> I have recompiled it OK. This was working on R3.2. You can test it on R4 
> >> but no idea if it will work. I hope to have a bit of time to look at it 
> >> this week.
> >> 
> >> To compile it if you want to test / debugInR4
> >> create new VM with network (to get the github) or without network but 
> >> you'll have to copy the download to the VM by another mean. Then:
> >> yum install pam-devel gettext-devel git libtool libyubikey 
> >> libyubikey-devel -y
> >> yum group install "Development Tools"
> >> git clone https://github.com/adubois/qubes-app-linux-yubikey.git
> >> cd qubes-app-linux-yubikey/
> >> libtoolize --install
> >> autoreconf --install
> >> ./configure
> >> make check
> >> 
> >> files to copy to Dom0 are in folder back-end
> >> files to copy to USBVM are in folder front-end
> >> 
> >> USBVM should be a VM started on boot with the USB controller that you 
> >> insert the key in...
> >> 
> >> Read the doc, it is not polished.
> >> There are mechanisms to detect USBVM compromise, hold-replay attacks, 
> >> etc...
> > 
> > Starting to do it, everything went fine, but I do not find the way when I 
> > need to copy a folfder (not a file) to dom0 ...
> > 
> > Thx
> 
> You can compress the folder
> 
> tar czvpf QubesBack.tgz name of folder
> 
> And in dom0
> tar xzvpf QubesBack.tgz
> 
> Might have some typo there...
> > 
> > -- 
> > You received this message because you are subscribed to a topic in the 
> > Google Groups "qubes-users" group.
> > To unsubscribe from this topic, visit 
> > 

[qubes-users] Re: unikernel-firewall: anyone tried this / anyone who wants to help/ already hvm template to download?

[Tim W]

On Wednesday, November 1, 2017 at 7:38:40 AM UTC-4, ludwig jaffe wrote:
> Hi I found an interesting approach of having a small unikernel firewall,
> that does not eat up too much RAM, especially useful for a laptop and also
> as there is a different ip-stack than in Linux one has an advantage against
> common errors:
> (if there is a flaw in the linux kernel it affects sys-net and sys-firewall,
> if there is a flaw in uni-kernel-firewall it only affects the firewall and if
> there is a flaw in the kernel then it affects sys-net and not sys-firewall!)
> 
> look here for the project:
> http://roscidus.com/blog/blog/2016/01/01/a-unikernel-firewall-for-qubesos/ 
> https://github.com/talex5/qubes-mirage-firewall.git
> 
> 
> would be nice to have the mirage-os based firewall as an install option,
> by downloading a signed template with a tested mirage-os based firewall.
> 
> Is there anyone who has experience with it?
> I would like to try it and help developing it further. Who else wants?
> 
> Cheers,
> 
> Ludwig

Tth

-- 
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/dcf7ce83-cc97-481d-a646-e17cbc71051f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] qvm-backup-restore bug qubes 4.0-rc4

[cyberian]

i have successfully backed up and restored several vm's after upgrading from 
rc-1 to rc-4
there is a bug which happens repeatedly when restoring the fedora-25-dvm 
domain.  I have already restored fedora-25 template successfully.
when restore begins the vm is added to the qubes vm menu but soon after it is 
removed from the menu.
vm can still be used using qvm-start drom dom0 but does not appear in the drop 
down menu of qubes domains.
is there a way to manually trigger a refresh for the drop-down menu so that it 
will detect and add the vm to the list of 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/23fbcd0d-c13b-4af2-8506-5995e44b557a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] unikernel-firewall: anyone tried this / anyone who wants to help/ already hvm template to download?

[donoban]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/01/2017 12:38 PM, ludwig jaffe wrote:
> Hi I found an interesting approach of having a small unikernel 
> firewall, that does not eat up too much RAM, especially useful for 
> a laptop and also as there is a different ip-stack than in Linux 
> one has an advantage against common errors: would be nice to have 
> the mirage-os based firewall as an install option, by downloading
> a signed template with a tested mirage-os based firewall.
> 
> Is there anyone who has experience with it? I would like to try it 
> and help developing it further. Who else wants?
> 
> Cheers,
> 
> Ludwig


Hi,

I discovered it when talex released last version. I am trying to store
rules dynamically in memory (which seems near achieved) and compatible
with Qubes firewall management (which seems the hard part).

I just rewrite the hard coded firewall rules as a list of rules which
can be parsed by the firewall (except blocking traffic between VMs, it
stills hard coded).

What I don't know yet is how to handle QubesDB updates and parse them.
It not seem too much difficult but this is my first contact with OCaml :
)

If you want take a look https://github.com/donob4n/qubes-mirage-firewall

It's near useless yet (compared to original version) except you find
easier to define rules in the list format:

{ src = None; dst = Some `NetVM; sport = None; dport = None; proto =
None ; action = `NAT };

'None' is equivalent to 'ANY' and if you define some field you must
add 'Some' since rule fields are defined as 'Option'.

Also you should check cfcs version:
https://github.com/cfcs/qubes-mirage-firewall/tree/user_supplied_rules

It uses modules.img file for store the rules. More flexible than talex
version since you don't need rebuild but I think you need to reboot
the vm for apply new rules. It uses BSD PF format:
https://github.com/cfcs/qubes-mirage-firewall/blob/user_supplied_rules/R
ULES.JSON

I will try to get some time and progress on it. At least for learn
some OCaml and Qubes internals.
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEznLCgPSfWTT+LPrmFBMQ2OPtCKUFAlp9c00ACgkQFBMQ2OPt
CKUMBhAAjNw2kVyGO3Ugh2AWC/7hXNzTB4ovw71BmPLXcB11n87ThO6L9mW7Xhaa
03xgJshuDE7+Y7Zk0QU1mcCiDsT/NCFh60zHskoUmWG1UtnKD0WoYF4J/IK7gtmj
EfxV0iYFRXk2I0rjnIb9JUFteKXNB6eaLt9APhYJPUxrLyivQc8SlRdWpYs4DdUY
72/Sijgs9g0g7dNMP4+dfjvlD3491MQN18cHaoXXEePq0hLvBMw+DiCkzi/rJw9v
pxSqHIvscJOiqd+d20cjEAQvptUTgZsS4ek8j8UubJgISft6P0yLLK5FlMwzLcdK
/cNQPb1KhzQdxsHmC6Ar48b2rNPgD3+8XLpNCALszMNL+0OrhalMMxN914fSxAB8
us2NIfjp5e/N4XukuBr5oc24VbPJ0wurblxjL9aCrrJGUTuF9f3+dJfKsz7afJbk
Xrb7rpyl3KUM/hJYWFeYFlcigIrxlFMkofrC++4QNwE88iVrcMZTsuDgZc35coX8
P7x9Gy0GMM0upjgWwTAfMCvn8P5xWRliAPFT373NDHMq5kOuqo6KANnaZZPLEnZ1
UAvpdyHdWqtIwRngYCFF5XdmiHCjRw0FqIcyQdiDq1ppIbySgA5fR4Q0VsC8aJip
ZMNXYCt8JjtpT938fH6eRI4Y8rV2ZszWwg9g6fYAhMzdfBYqMRg=
=S8NZ
-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/fec6262e-f4b4-ce8e-f69a-fa2cfb87b061%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: sys-usb / template install yubikey tools ?

[Alex Dubois]

> On 10 Feb 2018, at 17:46, ThierryIT  wrote:
> 
> Le samedi 10 février 2018 01:44:36 UTC+2, Alex Dubois a écrit :
>> On Saturday, 3 February 2018 22:42:46 UTC, Alex Dubois  wrote:
>>> On Saturday, 3 February 2018 10:12:25 UTC, ThierryIT  wrote:
 Le vendredi 19 janvier 2018 13:19:29 UTC+2, Alex Dubois a écrit :
>> On Friday, 19 January 2018 05:57:16 UTC, ThierryIT  wrote:
>> Not familiar with this ... Will need procediure to follow.
>> 
>> 
>> Le mercredi 17 janvier 2018 23:03:31 UTC+2, Alex Dubois a écrit :
>>> On Wednesday, 17 January 2018 15:15:45 UTC, ThierryIT  wrote:
 No, I am still under R3.2
 
 Le mercredi 17 janvier 2018 16:54:58 UTC+2, awokd a écrit :
> On Wed, January 17, 2018 2:09 pm, ThierryIT wrote:
>> "https://github.com/adubois/qubes-app-linux-yubikey;
>> 
>> 
>> Le mercredi 17 janvier 2018 16:05:52 UTC+2, awokd a écrit :
>> 
>>> On Wed, January 17, 2018 1:09 pm, ThierryIT wrote:
>>> 
 Nobody ?
 
 
 
 Le mercredi 17 janvier 2018 09:23:34 UTC+2, ThierryIT a écrit :
 
 
> Hi,
> 
> 
> 
> I am going to install a new sys-usb.
> I have before to install all what I need to the template 
> (fedora-26)
> first. When following your procedure:
> 
> 
> ykpers has been installed but: I cannot do the same for
> qubes-yubikey-vm and qubes-yubikey-dom0 :
> 
> no match for argument
> 
> ideas ?
>>> 
>>> Not quite sure what you are trying to do here. What procedure? What
>>> command are you entering?
> 
> Are you trying this on Qubes 4.0? Those Yubikey packages might not be 
> in
> the Qubes repo yet.
>>> 
>>> Hi,
>>> 
>>> I have not maintained this for some time. So long that I can't remember 
>>> if the packages had been created/tested, I don't think they have.
>>> 
>>> Best is you follow the steps to build it on a new temporary VM, don't 
>>> be afraid it should not be too hard:
>>> - Execute the yum command in "Build dependancies"
>>> - Also install pam-devel
>>> - Follow the steps in preparing the build and build
>>> - Deploy the code in Dom0 and the USB VM.
>>> 
>>> I am about to upgrade to Qubes 4.0 rc4 (when released) so won't 
>>> probably be able to help until this is done.
>>> 
>>> Any help from someone who is used to packaging under Fedora would be 
>>> nice.
>>> 
>>> Alex
> 
> Sure, I'll update the doc and post here. However as I said don't want to 
> touch my Qubes set-up before my upgrade to 4.0 rc4. So might be in 
> 2-3weeks
 
 Did you upgrade to Q4R4 ?
>>> 
>>> I'm in the process. Having issues with PCI path-through of my second NIC 
>>> that I need to solve. I have to use PV mode for now and not too happy to 
>>> have too. I'll open another thread if I can't find a way...
>> 
>> Hi Thierry,
>> 
>> I have recompiled it OK. This was working on R3.2. You can test it on R4 but 
>> no idea if it will work. I hope to have a bit of time to look at it this 
>> week.
>> 
>> To compile it if you want to test / debugInR4
>> create new VM with network (to get the github) or without network but you'll 
>> have to copy the download to the VM by another mean. Then:
>> yum install pam-devel gettext-devel git libtool libyubikey libyubikey-devel 
>> -y
>> yum group install "Development Tools"
>> git clone https://github.com/adubois/qubes-app-linux-yubikey.git
>> cd qubes-app-linux-yubikey/
>> libtoolize --install
>> autoreconf --install
>> ./configure
>> make check
>> 
>> files to copy to Dom0 are in folder back-end
>> files to copy to USBVM are in folder front-end
>> 
>> USBVM should be a VM started on boot with the USB controller that you insert 
>> the key in...
>> 
>> Read the doc, it is not polished.
>> There are mechanisms to detect USBVM compromise, hold-replay attacks, etc...
> 
> Starting to do it, everything went fine, but I do not find the way when I 
> need to copy a folfder (not a file) to dom0 ...
> 
> Thx

You can compress the folder

tar czvpf QubesBack.tgz name of folder

And in dom0
tar xzvpf QubesBack.tgz

Might have some typo there...
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "qubes-users" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/qubes-users/BkdTuXZZnwE/unsubscribe.
> To unsubscribe from this group and all its topics, 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 
> 

Re: [qubes-users] Re: sys-usb / template install yubikey tools ?

[Alex Dubois]

> On 10 Feb 2018, at 20:16, joevio...@gmail.com wrote:
> 
> Yubikey can have different modes of authentication.  I remember looking at 
> the work of adubois last year as a possible solution.
> My Yubikey has a slot used for Challenge/Response, which is MUCH easier to 
> work with when you have multiple systems and devices.
> 
> I guess YubicoOTP would require something like a custom PAM module... but 
> with Challenge/Response, my solution was to use the built-in pam_exec.so to 
> run a very short script when authenticating.

My solution is a custom PAM module with password + OTP and master password (to 
use if compromised USB VM).
This OTP slot of the Yubikey is then dedicated for 1 Qubes. 
I made sure you can’t forget the yubikey in the slot, the OTP is transmitted to 
USBVM when key is pressed and transmitted to Dom0 when you remove the key. 
If on key removal you are not authenticated you have to assume that USBVM is 
compromised and may be used for hold and replay attack. You have to go to a 
secure area, login with master password, destroy USBVM and reinstall front-end 
+ re-initialise the PAM. 
If you press by mistake the yubikey, I think you have also a risk of compromise 
and have to do the same. 

The challenge response is more practical but I feel less secure (I might be 
wrong), I have not looked deeply into it. Influencing the generation of the 
challenge (to be the same as a previous one) via clock. 
> 
> The only dependency is to install ykpers on sys-usb as it uses ykchalresp.
> 
> https://gist.github.com/Joeviocoe/929ebde1066a22491bf93ccc9d6c0ba3
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "qubes-users" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/qubes-users/BkdTuXZZnwE/unsubscribe.
> To unsubscribe from this group and all its topics, 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/e5d1abf4-4627-4a09-927c-ec4294cc481d%40googlegroups.com.
> 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/EF1BE37B-21E0-44BE-866C-2BE99DD1726E%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Do you use Qubes OS as your main OS on primary PC? What kind of work do you get done on it?

[Utility Panel]

On Friday, February 9, 2018 at 5:20:16 PM UTC-5, lemond...@gmail.com wrote:
> Without support for hardware acceleration of virtual machines, plus needing 
> specific hardware compatible with Qubes OS, what kinds of work do you get 
> done if Qubes is your main OS on primary PC?
> 
> I want to run Davinci Resolve, which is a video editor that runs on Linux, 
> but it takes advantage of the discrete GPU, and it seems Qubes does not 
> support hardware acceleration nor virtual machines.
> 
> So, I'm curious, for those who use Qubes, what actual work do you get done?
> 
> I've also tried playing youtube videos but found audio out of sync and I 
> could not resize or maximize the playback window.
> 
> I may have tried the second to latest version released so maybe things have 
> changed or will change in 4.x?
> 
> Not being able to run VMs, Davinci Resolve, or youtube are making me have to 
> look at other options like OS X, Windows 10, and Linux.
> 
> I was leaning towards OS X but enabling case sensitivity for the file system 
> can break certain apps like those from Adobe, or cause other problems.. And I 
> prefer linux/unix like command-lines to DOS, so kind of leaning away from 
> Windows 10.
> 
> That leaves Linux distros like Debian, Mint, e bv  But I'm wondering how 
> secure it will be compared to Qubes?

Wow! @Yuraeitha & @billollib! Can we sticky these responses? I mean, I know 
this is a a distribution list and not a discussion forum, but daum! Wish I 
could write responses like yours.

I don't actually have much to add. I use Qubes for everything that I care 
about. I only use Windows for stuff that I use so seldom that I haven't figured 
out how to do it in Qubes. Insofar as I'm limited in Qubes, it's on account of 
my own laziness or real life issues rather than any inherent limitation in the 
OS. And I'm a total hack-job when it comes to computers in general, Linux, or 
Qubes OS in particular. How I wish I could take a good course in whatever makes 
Qubes tick! Alas, I'm just an end-user. Not much more to say. Just love Qubes. 
Don't need to do much else.

-- 
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/433fc806-0510-4ec8-90c2-d65fb719de2f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: sys-usb / template install yubikey tools ?

[joeviocoe]

Yubikey can have different modes of authentication.  I remember looking at the 
work of adubois last year as a possible solution.
My Yubikey has a slot used for Challenge/Response, which is MUCH easier to work 
with when you have multiple systems and devices.

I guess YubicoOTP would require something like a custom PAM module... but with 
Challenge/Response, my solution was to use the built-in pam_exec.so to run a 
very short script when authenticating.

The only dependency is to install ykpers on sys-usb as it uses ykchalresp.

https://gist.github.com/Joeviocoe/929ebde1066a22491bf93ccc9d6c0ba3

-- 
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/e5d1abf4-4627-4a09-927c-ec4294cc481d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: sys-usb / template install yubikey tools ?

[ThierryIT]

Le samedi 10 février 2018 01:44:36 UTC+2, Alex Dubois a écrit :
> On Saturday, 3 February 2018 22:42:46 UTC, Alex Dubois  wrote:
> > On Saturday, 3 February 2018 10:12:25 UTC, ThierryIT  wrote:
> > > Le vendredi 19 janvier 2018 13:19:29 UTC+2, Alex Dubois a écrit :
> > > > On Friday, 19 January 2018 05:57:16 UTC, ThierryIT  wrote:
> > > > > Not familiar with this ... Will need procediure to follow.
> > > > > 
> > > > > 
> > > > > Le mercredi 17 janvier 2018 23:03:31 UTC+2, Alex Dubois a écrit :
> > > > > > On Wednesday, 17 January 2018 15:15:45 UTC, ThierryIT  wrote:
> > > > > > > No, I am still under R3.2
> > > > > > > 
> > > > > > > Le mercredi 17 janvier 2018 16:54:58 UTC+2, awokd a écrit :
> > > > > > > > On Wed, January 17, 2018 2:09 pm, ThierryIT wrote:
> > > > > > > > > "https://github.com/adubois/qubes-app-linux-yubikey;
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Le mercredi 17 janvier 2018 16:05:52 UTC+2, awokd a écrit :
> > > > > > > > >
> > > > > > > > >> On Wed, January 17, 2018 1:09 pm, ThierryIT wrote:
> > > > > > > > >>
> > > > > > > > >>> Nobody ?
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>> Le mercredi 17 janvier 2018 09:23:34 UTC+2, ThierryIT a 
> > > > > > > > >>> écrit :
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > >  Hi,
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > >  I am going to install a new sys-usb.
> > > > > > > >  I have before to install all what I need to the template 
> > > > > > > >  (fedora-26)
> > > > > > > >   first. When following your procedure:
> > > > > > > > 
> > > > > > > > 
> > > > > > > >  ykpers has been installed but: I cannot do the same for
> > > > > > > >  qubes-yubikey-vm and qubes-yubikey-dom0 :
> > > > > > > > 
> > > > > > > >  no match for argument
> > > > > > > > 
> > > > > > > >  ideas ?
> > > > > > > > >>
> > > > > > > > >> Not quite sure what you are trying to do here. What 
> > > > > > > > >> procedure? What
> > > > > > > > >> command are you entering?
> > > > > > > > 
> > > > > > > > Are you trying this on Qubes 4.0? Those Yubikey packages might 
> > > > > > > > not be in
> > > > > > > > the Qubes repo yet.
> > > > > > 
> > > > > > Hi,
> > > > > > 
> > > > > > I have not maintained this for some time. So long that I can't 
> > > > > > remember if the packages had been created/tested, I don't think 
> > > > > > they have.
> > > > > > 
> > > > > > Best is you follow the steps to build it on a new temporary VM, 
> > > > > > don't be afraid it should not be too hard:
> > > > > > - Execute the yum command in "Build dependancies"
> > > > > > - Also install pam-devel
> > > > > > - Follow the steps in preparing the build and build
> > > > > > - Deploy the code in Dom0 and the USB VM.
> > > > > > 
> > > > > > I am about to upgrade to Qubes 4.0 rc4 (when released) so won't 
> > > > > > probably be able to help until this is done.
> > > > > > 
> > > > > > Any help from someone who is used to packaging under Fedora would 
> > > > > > be nice.
> > > > > > 
> > > > > > Alex
> > > > 
> > > > Sure, I'll update the doc and post here. However as I said don't want 
> > > > to touch my Qubes set-up before my upgrade to 4.0 rc4. So might be in 
> > > > 2-3weeks
> > > 
> > > Did you upgrade to Q4R4 ?
> > 
> > I'm in the process. Having issues with PCI path-through of my second NIC 
> > that I need to solve. I have to use PV mode for now and not too happy to 
> > have too. I'll open another thread if I can't find a way...
> 
> Hi Thierry,
> 
> I have recompiled it OK. This was working on R3.2. You can test it on R4 but 
> no idea if it will work. I hope to have a bit of time to look at it this week.
> 
> To compile it if you want to test / debugInR4
> create new VM with network (to get the github) or without network but you'll 
> have to copy the download to the VM by another mean. Then:
> yum install pam-devel gettext-devel git libtool libyubikey libyubikey-devel -y
> yum group install "Development Tools"
> git clone https://github.com/adubois/qubes-app-linux-yubikey.git
> cd qubes-app-linux-yubikey/
> libtoolize --install
> autoreconf --install
> ./configure
> make check
> 
> files to copy to Dom0 are in folder back-end
> files to copy to USBVM are in folder front-end
> 
> USBVM should be a VM started on boot with the USB controller that you insert 
> the key in...
> 
> Read the doc, it is not polished.
> There are mechanisms to detect USBVM compromise, hold-replay attacks, etc...

Starting to do it, everything went fine, but I do not find the way when I need 
to copy a folfder (not a file) to dom0 ...

Thx

-- 
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 

[qubes-users] Re: Qubes 4.0 backup vm to USB from dom0

[cyberian]

thank you!
qvm-backup --help 
didnt display too much information, so i was mostly guessing at usage, thank 
you for your thorough answer

-- 
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/fe6467ae-5e4c-4397-92c0-3e593d27b0e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Do you use Qubes OS as your main OS on primary PC? What kind of work do you get done on it?

[billollib]

I'm in a slightly similar situation.  I am a very new Qubes user and am in the 
process of getting used to it.  My impression is that Qubes right now is a 
little like linux in general in the 1990s.  I can remember running linux on my 
boxes and I could do about 70% of what I needed to do, but there was always 
something that I had to do in Windows.  Then 80%.  Then 90%.  Then 95%. And 
now, the *only* thing I use Windows for is to check my PowerPoint format 
lectures that I created with LibreOffice on linux to make sure that there are 
no font changes that screw up the screen formatting.  And I don't even do that 
if the venue allows me to use my own laptop for presentations.

So, the same thing seems to be true here.  The developers of this system have 
done an amazing job and have a tremendous idea.  But you always solve the big 
easy  problems first.   I have found that I can use Qubes for about 85% of what 
I want to do.  I can run LibreOffice, analytical programs, compilers, email, 
and surf the web.  Videos work fine out of the box for me.

What doesn't work is the 3D graphics.  I'm having an issue with some games, the 
Blender modeling program, Paraview, and stuff like that.  Image processing and 
image manipulation (e.g. GIMP, Hugin, etc.) all work fine.

That's not a deal killer for me.  Currently, I run KDE Neon as my base OS, and 
it works great -- but I don't pay much attention to security on it.  I dual 
boot with Windows 10 for the PowerPoint thing, and now Qubes (on an external 
hard drive) for fun and maybe more in the future.  I'm slowly moving more and 
more of my work over to the Qubes installation.

Thinking back to the "old" linux days, it seemed that making linux an OS that 
you *really* could use for everything took the involvement of some major 
investors.  Linux had been bumping along at about 80% useful until a bunch of 
major companies decided to start dumping money into development -- and then it 
jumped to about 95% in just a couple of years.  Anyway, that's how I remember 
it.

My impression is that Qubes is going to be a little like that.  The amount of 
effort and talent it takes to pull off something like that is pretty mind 
boggling.  With linux, you have people in the open source community who have 
devoted 20 years to some damn little subsystem that nobody really thinks about 
until they don't work.  How long did Eric Raymond work on fetchmail or sed or 
gpsd?

Personally, I am stunned that the folk here have pulled this off as well as 
they have.  And God bless them for it.  But there's an old saw in my business 
that it's trivial to set up a system that works 80% of the time, easy to make 
one that works 90% of the time, very, very hard to get to 95%, and almost 
impossible to get to 99%.  What that means to me is that Qubes will likely 
never be at that 99% as long as the people currently working on it are the sum 
total of the resources devoted to it.  It will just very slowly creep up now 
that they are dealing with the really hard, really labor intensive small 
incremental stuff.

However, there's always the chance that a Canonical or Apache or Sun or Oracle 
will come along and say "Hey, this is a good idea.  Let's dump a hundred 
million bucks into it and see what happens."  Then it will move to the next 
level.

I don't know, of course, but that's the pattern I've seen before.  In the 
meantime, my solution is to use a very easy, but not all that secure, OS for my 
graphics-intensive stuff, and don't do anything on it that I care about 
security for.  Personally, I use KDE neon because I like KDE, but I'm also a 
fan of fedora.  

The thing about security, though, is that almost all of the linux variants are 
good "enough" for most things -- as long as you don't do something stupid.  
Qubes is good because it mitigates the damage when you do stupid stuff, not 
really because it is this totally different linux.  Compartmentalization is 
great, but if you download apps from "let_me_screw_with_your_computer.com", you 
will always have problems.  And that behavioral stuff is where most problems 
come from now.  Look at the recent arrests of folk on the dark web, or more 
recently the studies in tracking bitcoin transactions.  How was this done?  
Because people use the same identifiers in the dark web for open transactions. 
There's no technology that will save you from that kind of thing.

I have also started storing my data on the Qubes side of things, but that 
requires booting into Qubes, copying to a flash drive, and then booting into 
KDE neon.  Cheap laptops are pretty cheap now, so I'm thinking about dropping 
$400 into another box and running Qubes on one and KDE neon on the other...

-- 
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] Looking for the 'alt+space+f' (fullscreen) command - Purpose is to place a new keybind

[Yuraeitha]

Does anyone know the 'alt+space+f'(fullscreen) command, or where to find it? Or 
are there none available in /bin /usr/bin or similar?

Maybe an approach to change the keybind if the command is not available?

Much appreciated, 
Yu

-- 
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/3c45bafc-a754-4f16-a635-c0fc39122a9f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Problem with Qubes4 rc4 -- "GLX is not supported."

[billollib]

Thanks all, for your replies.  So, it's a feature, not a bug :-).  That's cool 
-- I mostly just need to know to stop trying to fix it.  For the moment, it's 
not a big deal.  Most of my work does not involve fancy 3D graphics, and I can 
easily boot into something else for 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/623450f7-d893-444f-9ada-b5cbc6856221%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] If you get 'no authenticators available' with mutt

['awokd' via qubes-users]

On Fri, February 9, 2018 5:32 pm, Konstantin Ryabitsev wrote:
> If you are trying to use mutt with the default Fedora-26 template and
> can't figure out why authenticated smtp sending is giving you a "No
> Authenticators Available" error, you need to install cyrus-sasl-plain.
>
>
> Drove me half-mad before I figured that out. Hopefully it saves you a
> bunch of clicks (and hair).

Did you use https://www.qubes-os.org/doc/mutt/ to set it up? Apart from
yum vs. dnf and what you mentioned, were there any other changes needed
for R4.0?

-- 
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/ec2a2c4d2ff311c2c157a204eeb7ef16.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes OS screensharing

[Vít Šesták]

Just another idea: Since the video approach is sooo slow, I've tried another 
approach. This one is suboptimal by design, but it is much faster than the 
recordMyDesktop variant. This one requires a VNC loopback session or other way 
of getting another session with its own background. (This is something that 
would be required for real screensharing anyway.) You can easily get it by apt 
install tigervnc-standalone-server tigervnc-viewer openbox (or similar command 
on non-Debian system), running vncpasswd (configure any password, you don't 
have to remember it), running tigervncserver and then running the viewer 
command mentioned it server's output.

There is my hack. It assumes that:
* /tmp/out.bmp is a symlink to /dev/stdout. The reason is the same as with the 
video approach.
* You have scrot installed in dom0.
* You have feh installed in the target VM.
* Your VNC loopback session has display :1. (You can change it.)
* You want to pipe it to disp3. (You can change it.)

The command to run in dom0:

while true; do (scrot /tmp/out.bmp | qvm-run disp3 -p 'env DISPLAY=:1 feh 
--bg-center --no-fehbg -'); done

It is suboptimal for many reasons:

* It forks several processes in both dom0 and domU for each screenshot.
* It opens a new RPC call for each frame. (Which causes previous unoptimality.)
* All screenshots are saved in /tmp (internal behavior of feh). This probably 
matters less when /tmp is tmpfs, but still.
* Works fully synchronously.

Actual performance on my laptop was about 2 FPS (measured by my eyes), which is 
not great, but it works much better than the video. For some purposes, 2FPs 
might be useable. Not sure why this is better than the video, maybe it is due 
to missing compression and decompression, maybe it is due to missing buffering.

How the performance can be improved:

1. Use a single pipe, don't open a new RPC call for each frame. (This might get 
tricky due to buffering. It might be important to verify that it works well 
even if the consumer is slower than producer.)
2. Use a single process as producer instead of looped scrot.
3. Use a single process as consumer instead of looped feh.

Another idea is to use half-duplex VNC, but this might be also tricky. The goal 
is not to allow to pass any input from the untrusted VM to VNC server in dom0, 
maybe except information about potential congestion (i.e., situation when 
consumer is slower than producer). I am not sure if VNC is designed for that, 
but Wireshark capture of session with -ViewOnly on client-side looks still a 
bit chatty. There are many Authentication Response messages for some time 
(WTF?) and many Fence messages (hmm, probably synchronization).

Regards,
Vít Šesták 'v6ak'

-- 
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/4a8bff52-744b-4233-b87a-ddebe23a52c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Privacy in Qubes

[Tim W]

On Friday, February 9, 2018 at 4:33:00 AM UTC-5, Yuraeitha wrote:
> On Friday, February 9, 2018 at 7:09:32 AM UTC+1, Tim W wrote:
> > On Wednesday, September 20, 2017 at 4:47:16 PM UTC-4, Yuraeitha wrote:
> > > On Wednesday, September 20, 2017 at 12:50:46 PM UTC, Dominique St-Pierre 
> > > Boucher wrote:
> > > > On Wednesday, September 20, 2017 at 8:27:40 AM UTC-4, cooloutac wrote:
> > > > > On Monday, September 18, 2017 at 11:02:50 PM UTC-4, Person wrote:
> > > > > > Let's say you have an online identity that you want to keep 
> > > > > > separate from your personal information. On Qubes, is it possible 
> > > > > > to keep i information completely separate without physical 
> > > > > > separation? I have considered using a separate OS virtualized in 
> > > > > > Qubes, but it may possibly leak the same device data. Multibooting 
> > > > > > with Qubes is also not the safest idea. 
> > > > > > 
> > > > > > What is the best way to keep online information from being traced 
> > > > > > back to you on Qubes?
> > > > > 
> > > > > Not really sure what you are asking, or what information 
> > > > > specifically.   Keeping information separate is the general purpose 
> > > > > of Qubes.  One vm doesn't know what data is on the other one.
> > > > > 
> > > > > If you are talking about keeping your identity hidden from the 
> > > > > internet.  Just don't let the vm connect to the internet?
> > > > > 
> > > > > As far as information like device id's,  that would depend on the 
> > > > > program you are connecting to the internet and if it gathers such 
> > > > > information.  I really don't know if what core linux processes do 
> > > > > this.  Browsers prolly do yes?
> > > > > 
> > > > > In general, hiding your identity is not really something thats Qubes 
> > > > > specific.  Use multiple whonix qubes with tor browser?  Don't log in 
> > > > > the same online identities on the same vm?
> > > > 
> > > > If you are talking about the first the identity of your computer, that 
> > > > will always be the same hostname, mac address if you connect both vm 
> > > > through the same network card. If you have 2 network card (and 
> > > > different sys-net), you can maybe have the traffic through one card for 
> > > > one ID and the other ID through the other card but if you are using it 
> > > > at home on the same lan, I don't see the point. But doing it on a 
> > > > public wifi and using 2 differents network card (and different sys-net 
> > > > vm) you can have 2 different session on the same website and I don't 
> > > > see a way from the server side to figure out that you are doing it from 
> > > > the same computer.
> > > > 
> > > > Hope I make sense!!!
> > > > 
> > > > Dominique
> > > 
> > > I second Dominique here, this is what I would do too if I wanted to 
> > > maximize anonymity. However be mindful that it's still risky if its a 
> > > matter of life and death, or anything other really serious/important. 
> > > There is always a remote chance that something can be used to track back 
> > > to you, be it something brand new, zero-day exploits, or what else hidden 
> > > tricks is out there. Although these is mostly only used against 
> > > high-profile targets, and typically, or most likely not,on your everyday 
> > > internet users.
> > > 
> > > For example virtualization isn't perfect. To my knowledge, this is one of 
> > > the reasons Qubes is switching from PV to HVM. And even then, HVM seems 
> > > to only be a temporay solution, as while it's better than the current PV, 
> > > it isn't perfect either. Generally, you're in deep trouble if someone is 
> > > hunting you as a high-profile, but if its the average joe-hacker? 
> > > Probably not. From what I can gather, Qubes attacks are difficult to pull 
> > > off, so much that it hasn't been observed in the wild. However one of 
> > > Qubes's weakpoints is the lack of reward pools for white-hat hackers who 
> > > hunt for bugs and weakenesses, although it may be solved soon through 
> > > donations I think? Anyway, just be careful, don't do anything that you 
> > > can't pay for afterwards, be it your life, prison, or what else may be 
> > > hunting you.
> > > 
> > > Also to do Qubes justice, it's still pretty darn secure. It requires 
> > > exotic and probably difficult hacks to get through, such as hacking one 
> > > DomU and mess up your memory in other to break into another DOmU, and 
> > > thereby indirectly get access to Dom0, or something like that. Presumably 
> > > the Qubes 4 system is much better protected against this kind of 
> > > difficult but theoretical possible attack, than Qubes 3.2 is. 
> > > 
> > > Then again, I'm no security expert, take my words with some salt. But 
> > > definitely don't believe Qubes has perfect isolation, it doesn't, not 
> > > with modern technology anyway. However it's a massive leap in the right 
> > > direction for better security. 
> > > 
> > > Furthermore, be extremely mindful of user-habits and which websites 

Re: [qubes-users] Re: Qubes OS screensharing

[Vít Šesták]

I've implemented my approach of screensharing. It pipes content scrapped from 
dom0 to a VM. I don't call it a success, because the FPS is terribly low. But 
maybe someone can try to get it even further.

Recording:
* VLC and ffmpeg could be good choices (with probably many options for 
adjusting it for your needs), but they aren't available in Fedora unless you 
use some third-party repository, which is not what I wanted.
* recordMyDesktop works with some hacks and config, but its FPS is terribly low 
(at least when using --on-the-fly-encoding). It also does not have much 
encoding options. It would be probably ideal to use uncompressed video, because 
transfer is cheap and encoding/decoding is GPU/CPU-intensive. (Actually, GPU 
can at least theoretically help with encoding, as it happens in dom0. It can't 
help with video decoding.) I haven't tried to adjust video quality, because I 
am not sure about the effect on encoding performance.
* Not sure about other alternatives available in Fedora without additional 
repositories. I am not aware about any.
* Maybe we could try the software intended to pipe windows from domUs to dom0 
for the other way?

Playback:

* I use MPlayer, but any player capable of playing a pipe can do the job.
* If you want to use it in a VNC session, you will probably want to add 
something like “env DISPLAY=:1”. But now, it is too early.
* In my experiment, the domU part was Debian 9, but I don't think this matters 
much.

The script with comments: 
https://gist.github.com/v6ak/1678244cd71a0ebd019531d02a149c8f

Regards,
Vít Šesták 'v6ak'

-- 
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/43dae632-d8a9-4735-bb40-a6ed71053501%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes 4.0 backup vm to USB from dom0

[Yuraeitha]

On Saturday, February 10, 2018 at 6:51:47 AM UTC+1, 
cybe...@national.shitposting.agency wrote:
> I have a usb drive attached to sys-usb, lets say its mounted at /mnt on 
> sys-usb and im trying to backup a vm named MyVm
> from dom0 the command:
> 
> sudo qvm-backup sys-usb:/mnt MyVm
> 
> returns the error: 
> 
> The backup directory does not exist
> 
> how can i make a backup to USB when USB devices are not exposed to dom0?

and yes, this works for USB too. Just ensure the USB is mounted inside your 
AppVM, and then just throw the path to your USB which it is mounted on :-)

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

[qubes-users] Re: Qubes 4.0 backup vm to USB from dom0

[Yuraeitha]

On Saturday, February 10, 2018 at 6:51:47 AM UTC+1, 
cybe...@national.shitposting.agency wrote:
> I have a usb drive attached to sys-usb, lets say its mounted at /mnt on 
> sys-usb and im trying to backup a vm named MyVm
> from dom0 the command:
> 
> sudo qvm-backup sys-usb:/mnt MyVm
> 
> returns the error: 
> 
> The backup directory does not exist
> 
> how can i make a backup to USB when USB devices are not exposed to dom0?

Correction, I must be still sleeping, but of course you can't mix the approachs 
as mentioned above, because they are polar opposite approaches to either 
include everything "except", or no VM's "besides only a few". My bad.

Also the python code which the new backup tool is based on, as python code's 
natural nature I believe, does not give easy to read error messages. So even a 
simple typo, like in the path, or forgetting '' marks in paths with space or 
special letters, etc. may give you a complete python error that does not give 
any hints as to what went wrong. So if it doesn't work, try look for typo's in 
the command, especially if you're sleepy in the early morning or late night.

-- 
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/4638b225-c221-4e4f-beda-8e120b3f82cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.