date:20170312

On Monday, 13 March 2017 15:02:42 UTC+11, Jean-Philippe Ouellet  wrote:
> On Sun, Mar 12, 2017 at 10:59 PM, Drew White  wrote:
> > Question: Why does it not work properly then?
> 
> Answer: Must be because of something you changed on your system.
> 
> It *does* appear to work properly by default, confirmed by not seeing
> the NTP traffic you describe on two Qubes machines, one of which is
> literally a perfectly unmodified default install of 3.2 I have just
> for testing things.
> 
> > Thus, it kept running /usr/sbin/ntpdate pool.ntp.org
> >
> > Until I changed that, it was futile.
> 
> Feel free to send patches to allow users to easily specify an ntp server(s).
 
Well, at this time, it's easiest to change it in the templates, and let it be 
populated downwards. Until a better functionality is implemented, it's not 
going to be more useful.

If I myself provided applications/services to enable this, then that would take 
me a bit of time to achieve properly due to the fact that it would have to work 
in version 4 as well.

> >> >> > The "ClockVM" does not seem to be operating the way I would have 
> >> >> > thought a "ClockVM" would.
> >> >>
> >> >> Only the ClockVM to uses NTP at all, and it sends the time back to
> >> >> dom0. The rest of the VMs get their time set by dom0 via
> >> >> qubes.SetDateTime service.
> >> >
> >> > So the ClockVM ONLY interacts with Dom0. Fair enough. Then it would be a 
> >> > good addition to allow it to update each Guest.
> >>
> >> No. That would be a bad design for several reasons. Dom0 already does
> >> this periodically. This is better than what I assume you suggest
> >> (ClockVM directly invoking qubes.setDateTime in each guest) because
> >> the service invocations are implicitly rate-limited and contents
> >> filtered by dom0. It is also not desired for the ClockVM VM to even
> >> know which other VMs exist, let alone know which ones are running and
> >> need their clock set.
> >
> > I was more thinking the ClockVM (CVM) gets the time, then Dom0 gets the 
> > time, then Dom0 updates everything, it would all be via Dom0, but the CVM 
> > gets the time initially, and if it has a difference in the NTP compared to 
> > the time set in the CVM it then proceeds to update each guests time without 
> > calling an external NTP server, and keeps it all inside the Guest regime.
> 
> Exactly.
> 
> From my quick reading of the source and observations of my systems,
> that appears to be exactly how it is implemented right now.

In other words, the way it is right now is in a form in which it is yet to be 
complete because they have not instantiated the way that it's meant to work?

 
> Note also that this is not what you initially described in your first email.

It is not what I initially described because I was making an enquiry not 
providing details on what I had to do to change it per guest and not on a 
global level in such a way to reduce the impact on the system and the NTP 
server and DNS server.

I posted on the forums, not sent an email, but I understand that you may think 
so because it's a forum that has a mailing list on it available.

-- 
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/2e4348d2-8d4d-41be-a56f-33fa2925454f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] NTP Global alteration.

On Sun, Mar 12, 2017 at 10:59 PM, Drew White  wrote:
> Question: Why does it not work properly then?

Answer: Must be because of something you changed on your system.

It *does* appear to work properly by default, confirmed by not seeing
the NTP traffic you describe on two Qubes machines, one of which is
literally a perfectly unmodified default install of 3.2 I have just
for testing things.

> Thus, it kept running /usr/sbin/ntpdate pool.ntp.org
>
> Until I changed that, it was futile.

Feel free to send patches to allow users to easily specify an ntp server(s).

>> >> > The "ClockVM" does not seem to be operating the way I would have 
>> >> > thought a "ClockVM" would.
>> >>
>> >> Only the ClockVM to uses NTP at all, and it sends the time back to
>> >> dom0. The rest of the VMs get their time set by dom0 via
>> >> qubes.SetDateTime service.
>> >
>> > So the ClockVM ONLY interacts with Dom0. Fair enough. Then it would be a 
>> > good addition to allow it to update each Guest.
>>
>> No. That would be a bad design for several reasons. Dom0 already does
>> this periodically. This is better than what I assume you suggest
>> (ClockVM directly invoking qubes.setDateTime in each guest) because
>> the service invocations are implicitly rate-limited and contents
>> filtered by dom0. It is also not desired for the ClockVM VM to even
>> know which other VMs exist, let alone know which ones are running and
>> need their clock set.
>
> I was more thinking the ClockVM (CVM) gets the time, then Dom0 gets the time, 
> then Dom0 updates everything, it would all be via Dom0, but the CVM gets the 
> time initially, and if it has a difference in the NTP compared to the time 
> set in the CVM it then proceeds to update each guests time without calling an 
> external NTP server, and keeps it all inside the Guest regime.

Exactly.

>From my quick reading of the source and observations of my systems,
that appears to be exactly how it is implemented right now.

Note also that this is not what you initially described in your first email.

-- 
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/CABQWM_Ar6OEp2_Ar0fxW265mjVBEYmdM5_hC%2B5u7hH%2Bt3bXRww%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] NTP Global alteration.

On Monday, 13 March 2017 13:44:17 UTC+11, Jean-Philippe Ouellet  wrote:
> On Sun, Mar 12, 2017 at 10:24 PM, Drew White  wrote:
> > On Monday, 13 March 2017 12:36:55 UTC+11, Jean-Philippe Ouellet  wrote:
> >> On Sun, Mar 12, 2017 at 9:19 PM, Drew White  wrote:
> >> > I want to set the NTP protocol to target the parent VM and on the NetVM 
> >> > or Sys-Firewall have that as the NTP server that feeds everything under 
> >> > it.
> >>
> >> No, you don't want that.
> >
> > Why don't I want what I want?
> 
> For the reasons I already stated, and that you appear to already
> understand. Only the ClockVM is intended to generate any NTP traffic
> which leaves your machine.
> 
> The rest of the VMs are synchronized not via NTP, but via a qrexec
> service. This works even when the VMs are not networked, whereas NTP
> to a proxy NTP server in sys-net (or somewhere) would not.
 
Question: Why does it not work properly then?


> >> > Thus only one VM calls the external source at a lesser interval to do 
> >> > the requests.
> >>
> >> That is already how it works.
> >
> > Then why does EVERY GUEST call pool.ntp.org? (unless I change it in the 
> > template for every VM)
> 
> That is not the behavior I observe on my system, confirmed by lack of
> output from:
> 
> [user@sys-firewall ~]$ sudo tcpdump -ni eth0 'udp port ntp'
> 
> Have you changed every guest on your system to do that or something?
 
Nope, I altered the sync-ntp-clock file. I changed it from pool.ntp.org to the 
local server in each guest.

Then every guest I changed stopped trying to get the time via ntp from 
pool.ntp.org. 

Until I changed that in each guest, it kept doing it EVERY 10 MINUTES from 
EVERY Guest that was running.

So that was about 15 requests every 10 minutes. Sometimes more.

One request for every guest. 

Thus, it kept running /usr/sbin/ntpdate pool.ntp.org

Until I changed that, it was futile.

> >> > How, in this system, do I perform this to get that to work please?
> >>
> >> Well, one would start by reading and understanding the relevant source:
> >>
> >> https://github.com/QubesOS/qubes-core-agent-linux/blob/master/qubes-rpc/qubes.SetDateTime
> >> https://github.com/QubesOS/qubes-core-agent-linux/blob/master/qubes-rpc/qubes.SyncNtpClock
> >> https://github.com/QubesOS/qubes-core-agent-linux/blob/master/qubes-rpc/sync-ntp-clock
> >
> > I read all that, that's why I found out how to change it in the first 
> > place, but every time I do something like add a NewGuest and install, with 
> > it's defaults to pool.ntp.org, it goes off and gets the NTP from an outside 
> > source. (not very secure), so I have to keep changing it to be the local 
> > server. I want to capture it all so only the NetVM performs that action.
> 
> I get the impression that maybe you are just changing config files of
> services which are not running?
 
Actually, it all came back to sync-ntp-clock file, as I said in previous.

I looked for other config files first, and nothing changed no matter what I 
changed. the system wasn't getting the NTP from the server or the router, or 
discovering the NTP server on it's own, I found it hard-coded there.


> >> > The "ClockVM" does not seem to be operating the way I would have thought 
> >> > a "ClockVM" would.
> >>
> >> Only the ClockVM to uses NTP at all, and it sends the time back to
> >> dom0. The rest of the VMs get their time set by dom0 via
> >> qubes.SetDateTime service.
> >
> > So the ClockVM ONLY interacts with Dom0. Fair enough. Then it would be a 
> > good addition to allow it to update each Guest.
> 
> No. That would be a bad design for several reasons. Dom0 already does
> this periodically. This is better than what I assume you suggest
> (ClockVM directly invoking qubes.setDateTime in each guest) because
> the service invocations are implicitly rate-limited and contents
> filtered by dom0. It is also not desired for the ClockVM VM to even
> know which other VMs exist, let alone know which ones are running and
> need their clock set.
 
I was more thinking the ClockVM (CVM) gets the time, then Dom0 gets the time, 
then Dom0 updates everything, it would all be via Dom0, but the CVM gets the 
time initially, and if it has a difference in the NTP compared to the time set 
in the CVM it then proceeds to update each guests time without calling an 
external NTP server, and keeps it all inside the Guest regime.


> >> There are many reasons for this, including eliminating redundant
> >> network traffic, and the fact that it is desirable for time to be
> >> correct in all VMs (including those intentionally without any network
> >> access).
> >
> > redundant network traffic... so every 10 minute PER GUEST, it contacts 
> > pool.ntp.org and gets the time. That isn't redundant network traffic.
> 
> Again. I do not observe this. Have you verified with an unmodified template?
 
Yes, brand new installation.


> >> > Is there a bug in it?
> >>
> >> Lets see...
> >>
> >>

Re: [qubes-users] Re: Non UEFI

On Sun, Mar 12, 2017 at 10:14 PM, Drew White  wrote:
> If only the minimal template doesn't have it, then that's not very good, 
> because the minimal template won't even update for me, I don't know if it's 
> something I've done or not, but it can't perform any dnf or yum actions for 
> some reason.

Can confirm that it does work.

Double check its firewall settings or try reinstalling it:
https://www.qubes-os.org/doc/reinstall-template/

-- 
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/CABQWM_Ar%2BWsmti78f4mNXznRtfd5xfRa9NAt%2BMHbnqSK8_d0bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] NTP Global alteration.

On Sun, Mar 12, 2017 at 10:24 PM, Drew White  wrote:
> On Monday, 13 March 2017 12:36:55 UTC+11, Jean-Philippe Ouellet  wrote:
>> On Sun, Mar 12, 2017 at 9:19 PM, Drew White  wrote:
>> > I want to set the NTP protocol to target the parent VM and on the NetVM or 
>> > Sys-Firewall have that as the NTP server that feeds everything under it.
>>
>> No, you don't want that.
>
> Why don't I want what I want?

For the reasons I already stated, and that you appear to already
understand. Only the ClockVM is intended to generate any NTP traffic
which leaves your machine.

The rest of the VMs are synchronized not via NTP, but via a qrexec
service. This works even when the VMs are not networked, whereas NTP
to a proxy NTP server in sys-net (or somewhere) would not.

>> > Thus only one VM calls the external source at a lesser interval to do the 
>> > requests.
>>
>> That is already how it works.
>
> Then why does EVERY GUEST call pool.ntp.org? (unless I change it in the 
> template for every VM)

That is not the behavior I observe on my system, confirmed by lack of
output from:

[user@sys-firewall ~]$ sudo tcpdump -ni eth0 'udp port ntp'

Have you changed every guest on your system to do that or something?

>> > How, in this system, do I perform this to get that to work please?
>>
>> Well, one would start by reading and understanding the relevant source:
>>
>> https://github.com/QubesOS/qubes-core-agent-linux/blob/master/qubes-rpc/qubes.SetDateTime
>> https://github.com/QubesOS/qubes-core-agent-linux/blob/master/qubes-rpc/qubes.SyncNtpClock
>> https://github.com/QubesOS/qubes-core-agent-linux/blob/master/qubes-rpc/sync-ntp-clock
>
> I read all that, that's why I found out how to change it in the first place, 
> but every time I do something like add a NewGuest and install, with it's 
> defaults to pool.ntp.org, it goes off and gets the NTP from an outside 
> source. (not very secure), so I have to keep changing it to be the local 
> server. I want to capture it all so only the NetVM performs that action.

I get the impression that maybe you are just changing config files of
services which are not running?

>> > The "ClockVM" does not seem to be operating the way I would have thought a 
>> > "ClockVM" would.
>>
>> Only the ClockVM to uses NTP at all, and it sends the time back to
>> dom0. The rest of the VMs get their time set by dom0 via
>> qubes.SetDateTime service.
>
> So the ClockVM ONLY interacts with Dom0. Fair enough. Then it would be a good 
> addition to allow it to update each Guest.

No. That would be a bad design for several reasons. Dom0 already does
this periodically. This is better than what I assume you suggest
(ClockVM directly invoking qubes.setDateTime in each guest) because
the service invocations are implicitly rate-limited and contents
filtered by dom0. It is also not desired for the ClockVM VM to even
know which other VMs exist, let alone know which ones are running and
need their clock set.

>> There are many reasons for this, including eliminating redundant
>> network traffic, and the fact that it is desirable for time to be
>> correct in all VMs (including those intentionally without any network
>> access).
>
> redundant network traffic... so every 10 minute PER GUEST, it contacts 
> pool.ntp.org and gets the time. That isn't redundant network traffic.

Again. I do not observe this. Have you verified with an unmodified template?

>> > Is there a bug in it?
>>
>> Lets see...
>>
>> https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue%20is%3Aopen%20ntp
>> https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue%20is%3Aopen%20clockvm
>>
>> doesn't look like it!
>
> Well, none that have been reported by anyone other than myself when asking 
> questions in the first place about it. But none opened a bug about it because 
> it's "not a bug" even though it is, (in my personal opinion) a very big bug 
> to have EVERY GUEST contact pool.ntp.org every 10 minutes. wether it's a 
> guest that's behind a proxy, or the proxy itself, or the net vm.

Things do not work as you claim they do.

> This is a security concern, and a big one at that.

Nope.

> for all unix types, the clock VM should contact the NTP server once every 6 
> hours (or on boot and then every 6 hours), and every guest should be updated 
> by that guest for time, unless set to otherwise update from elsewhere.

Where do you get this 6 hours figure from? Neither the RFC [1] or the
pool recommendations [2] suggest this.

[1]: https://tools.ietf.org/html/rfc1305
[2]: http://www.pool.ntp.org/tos.html

> I have my own NTP server, and yet I install things, and I just want to 
> capture all NTP from everything behind the NetVM and make it all get the NTP 
> from the NetVM. Unless it's requesting to the designated Network NTP server.

So... perhaps by "I have my own NTP server" do you mean "I installed
and enabled an ntp client in my default template"? That might explain
some of your confusion.

[qubes-users] Re: [qubes-devel] Qubes Canary #11

2017-03-12 Thread Marek Marczykowski-Górecki

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, Mar 12, 2017 at 10:24:05PM -0400, Jean-Philippe Ouellet wrote:
> On Wed, Mar 8, 2017 at 4:10 PM, Andrew David Wong  wrote:
> > ---===[ Qubes Canary #11 ]===---
> >
> > Special announcements
> > - --
> >
> > None.
> 
> Previously the "Special announcements" section contained:
> 
> > * We would like to remind you that Qubes OS has been designed under
> > the assumption that all relevant infrastructure is permanently
> > compromised.  This means that we assume NO trust in any of the servers
> > or services which host or provide any Qubes-related data, in
> > particular, software updates, source code repositories, and Qubes ISO
> > downloads.
> 
> Granted, "Special announcements" contents have come and gone in
> previous canaries, but this particular statement (or equivalent with
> slightly different wording) has been present in every one since canary
> 002.
> 
> Should we be interested in why this section has been removed?
> 
> I will interpret the a lack of a properly-signed quickly-delivered
> official answer as "Yes, we should be interested" and attempt to
> investigate further.

It is there, just moved to "Disclaimers and notes" section, as it isn't
really special - given it's in every canary...

https://github.com/QubesOS/qubes-secpack/commit/67f48082a6d66452ca28fea697b9933c9066bb33

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJYxgO6AAoJENuP0xzK19csyQgH/j6xim5x65i4/MsrYCaWhK+N
iizFDo5Wc5ZT92+a8Fhe/MjCKB+bTysoVd9Kc0SFF+Fr26wjdH3bk8C5mI4HgOt0
Qx35pfhaEjvN9SVbiyskQti1thoCg7cQGa/swv8EAMzY3KsopUfIyrzzIoGOi+i+
1CHWR/TzgWO7lstxxWGISzJ+7x+RcyCLu6eSTGbapswNjHgqo9mqTlQ9f2iWSJ6i
fWj9ISJDPs7WhcpynBNsyfZDGkdj+a6wKkzabVyM0QJeue8zsZUTV3QoHcf/+0RX
oS+8zBjQsB7LKzHcBfC7fHywo23s2nMgtSCeRMTKtoCoPBipZNqiv/H62EiUH+8=
=xrf0
-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/20170313022810.GV1208%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: [qubes-devel] Qubes Canary #11

On Wed, Mar 8, 2017 at 4:10 PM, Andrew David Wong  wrote:
> ---===[ Qubes Canary #11 ]===---
>
> Special announcements
> - --
>
> None.

Previously the "Special announcements" section contained:

> * We would like to remind you that Qubes OS has been designed under
> the assumption that all relevant infrastructure is permanently
> compromised.  This means that we assume NO trust in any of the servers
> or services which host or provide any Qubes-related data, in
> particular, software updates, source code repositories, and Qubes ISO
> downloads.

Granted, "Special announcements" contents have come and gone in
previous canaries, but this particular statement (or equivalent with
slightly different wording) has been present in every one since canary
002.

Should we be interested in why this section has been removed?

I will interpret the a lack of a properly-signed quickly-delivered
official answer as "Yes, we should be interested" and attempt to
investigate further.

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

Re: [qubes-users] Re: Non UEFI

On Monday, 13 March 2017 12:49:41 UTC+11, Jean-Philippe Ouellet  wrote:
> On Sun, Mar 12, 2017 at 9:03 PM, Drew White  wrote:
> > ... [snip] ...
> > well, if you look at the Fedora Template, it has EFI on it.
> > I want to know if there are templates out there that don't have EFI or uEFI 
> > on it. Because it's not needed or anything.
> 
> If you read the documentation about how VMs boot, you would realize
> that no, they don't use UEFI. Things are booted via either pvgrub or
> qemu's bios emulation. No (U)EFI involved anywhere at all.
> 
> If perhaps you looked in your template's /boot and saw /boot/efi and
> were alarmed, well... don't be. They are only pulled in by these
> packages:
> 
> [root@fedora-24 ~]# find /boot/efi -type f -exec rpm -qf {} ';' | sort -u
> fwupdate-efi-8-2.fc24.x86_64
> shim-0.8-9.x86_64
 
I wasn't alarmed, I never said that it used it or not, I know that it doesn't 
use it, which is why I was asking if there were any out there without it in the 
template.

If only the minimal template doesn't have it, then that's not very good, 
because the minimal template won't even update for me, I don't know if it's 
something I've done or not, but it can't perform any dnf or yum actions for 
some reason.

Thanks for letting me know.



> And to answer your original question of if there are any templates
> without those packages: yes, fedora-24-minimal does not have them.
> However, this *really* does not matter.
> 
> 
> On Thu, Mar 9, 2017 at 11:47 PM, cooloutac  wrote:
> > what?
> 
> +1

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0dcff144-3438-4867-b82c-cc354923eac0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes 3.2 on Macbook Pro Retina 11,5 [SOLVED]. Maybe useful for other Macbook models

On Sun, Mar 12, 2017 at 7:25 PM,   wrote:
> On Thursday, March 2, 2017 at 8:59:00 PM UTC, Marco Pozzato wrote:
>> Hi
>>
>> I am using Qubes 3.2 since a couple of months on a daily basis on Intel NUC 
>> NUC6i5SYK and it is amazing.
>>
>> I would like to use it also on one of my MacBooks:
>> * MacBook Pro 15" early-2011 8,2: my first attempt and I was not even able 
>> to start the installer. At that time I did not have enough knowledge and 
>> abandoned. Maybe, in the forthcoming weeks, I will retry
>> * MacBook Pro 15" mid-2015 11,5: I have been able to install Qubes booting 
>> with rEFInd, despite a lot of issues.
>>
>> The two main issues I faced are:
>> * no boot, due to empty xen.cfg file
>> * system freeze, due to Broadcom BCM43602 wifi adapter.
>>
>> I spent many hours and nights googling, experimenting, reading git tickets 
>> and messages in the ML. None provided the final guide, but many little 
>> pieces that I am assembling in the Macbook troubleshooting document.
>>
>> I came up with a running system, that still need more work. For the time 
>> being I have a working setup and I hope to be helpful to other macbook users.
>>
>> Dear Qubes developers: please, review my guide and maybe let's open some 
>> specific mail/ticket to discuss and troubleshoot specific issues. I am more 
>> than willing to help.
>>
>> Thanks
>> Marco
>
> Hi Marco,
>
> I've been trying to get Qubes R3.2 running on my MacBookPro11,1 without any 
> luck (I posted here for help a few weeks ago). I was wondering whether I 
> could read your guide?
>
> Take care,
> Chris

It has been merged into the main documentation available on qubes-os.org

You can view the specific changes he's referring to here:
https://github.com/QubesOS/qubes-doc/pull/295/files

-- 
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/CABQWM_Cd%3DFUa8e8VNuPUQwagYb%2BdauSntrOYMz6Afx2iBpvqyA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] USG - AFirewall For USB's

On Sun, Mar 12, 2017 at 3:06 AM,   wrote:
> This guy claims to have created a firewall for untrusted USB's
> https://github.com/robertfisk/USG/wiki .
> Anyone tested this?

Previously discussed here:

https://groups.google.com/d/msg/qubes-users/MEzOZ_naupo/lMjdMDwFAwAJ
https://groups.google.com/d/topic/qubes-users/UHiDauas4rM/discussion

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

Re: [qubes-users] very frequent crashes (about every other hour)

No guarantees about this fixing your specific problem, but you might
want to try a newer kernel.

https://www.qubes-os.org/doc/software-update-dom0/#how-is-software-updated-securely-in-dom0

See section "Testing repositories"

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

Re: [qubes-users] Re: Non UEFI

On Sun, Mar 12, 2017 at 9:03 PM, Drew White  wrote:
> ... [snip] ...
> well, if you look at the Fedora Template, it has EFI on it.
> I want to know if there are templates out there that don't have EFI or uEFI 
> on it. Because it's not needed or anything.

If you read the documentation about how VMs boot, you would realize
that no, they don't use UEFI. Things are booted via either pvgrub or
qemu's bios emulation. No (U)EFI involved anywhere at all.

If perhaps you looked in your template's /boot and saw /boot/efi and
were alarmed, well... don't be. They are only pulled in by these
packages:

[root@fedora-24 ~]# find /boot/efi -type f -exec rpm -qf {} ';' | sort -u
fwupdate-efi-8-2.fc24.x86_64
shim-0.8-9.x86_64

And to answer your original question of if there are any templates
without those packages: yes, fedora-24-minimal does not have them.
However, this *really* does not matter.

On Thu, Mar 9, 2017 at 11:47 PM, cooloutac  wrote:
> what?

+1

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

Re: [qubes-users] NTP Global alteration.

On Sun, Mar 12, 2017 at 9:19 PM, Drew White  wrote:
> Hi folks,

Hi,

> I want to set the NTP protocol to target the parent VM and on the NetVM or 
> Sys-Firewall have that as the NTP server that feeds everything under it.

No, you don't want that.

> Thus only one VM calls the external source at a lesser interval to do the 
> requests.

That is already how it works.

> How, in this system, do I perform this to get that to work please?

Well, one would start by reading and understanding the relevant source:

https://github.com/QubesOS/qubes-core-agent-linux/blob/master/qubes-rpc/qubes.SetDateTime
https://github.com/QubesOS/qubes-core-agent-linux/blob/master/qubes-rpc/qubes.SyncNtpClock
https://github.com/QubesOS/qubes-core-agent-linux/blob/master/qubes-rpc/sync-ntp-clock

> The "ClockVM" does not seem to be operating the way I would have thought a 
> "ClockVM" would.

Only the ClockVM to uses NTP at all, and it sends the time back to
dom0. The rest of the VMs get their time set by dom0 via
qubes.SetDateTime service.

There are many reasons for this, including eliminating redundant
network traffic, and the fact that it is desirable for time to be
correct in all VMs (including those intentionally without any network
access).

> Is there a bug in it?

Lets see...

https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue%20is%3Aopen%20ntp
https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue%20is%3Aopen%20clockvm

doesn't look like it!

> Sincerely,
> Drew.

Sincerely,
Jean-Philippe.

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

[qubes-users] NTP Global alteration.

Hi folks,

I want to set the NTP protocol to target the parent VM and on the NetVM or 
Sys-Firewall have that as the NTP server that feeds everything under it.

Thus only one VM calls the external source at a lesser interval to do the 
requests.

How, in this system, do I perform this to get that to work please?

The "ClockVM" does not seem to be operating the way I would have thought a 
"ClockVM" would.

Is there a bug in it?

Sincerely,
Drew.

-- 
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/3e20f522-fb27-4fa9-99ec-c65c82459a39%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: SystemD sucks - qubes shouldn't use it

On Saturday, 11 March 2017 05:09:26 UTC+11, cooloutac  wrote:
> On Friday, March 10, 2017 at 1:14:47 AM UTC-5, Drew White wrote:
> > On Friday, 10 March 2017 15:36:49 UTC+11, cooloutac  wrote:
> > > My problem with Qubes is that i'm still noob.  I don't even know what 
> > > alot of system processes are or what they do. Qubes is more complicated 
> > > then a normal os even just to monitor network traffic. I'm mostly in the 
> > > dark compared to on bare metal os.
> > > 
> > 
> > I know more about qubes than the developers do by now.
> > monitoring is easy, just have a proxy that does it after the netvm.
> > NetVM -> Firewall/Proxy running WireShark or similar -> AppVM/HVM
> > 
> > 
> > > I'm basically at mercy of a default setup lol.  But I think thats part of 
> > > qubes goal.  It has the misnomer of being called for nerds or 
> > > enthusiasts.  But its really for noobs.  The hard part is just taking a 
> > > step in these waters of a new world, even for most security experts. 
> > > 
> > 
> > I wrote my own applications for qubes because the developers wouldn't fix 
> > things and didn't change things to use less RAM.
> > I wrote my own manager that uses only 200 MB VRAM, instead of the current 
> > one that uses over 1 GB VRAM. (Approximations)
> > 
> > Qubes is built for end users, not nerds or developers or anything (or so 
> > they claimed, will post reference later).
> > 
> > > The hard part is just accepting the fact you will be compartmentalizing 
> > > diff aspects of your daily activity on your pc.  Its a different way of 
> > > thinking.  
> > > 
> > 
> > it is a different way for many people. Those of us that are like me, and 
> > are developers and such, we use virtualisation every day just to do our 
> > jobs.
> > 
> > 
> > > Its about accepting the fact you are never 100% secure and its just a 
> > > matter of how persistent your assailant is.  No matter what OS you are 
> > > using. Everyone gets compromised imo, even most security experts.  The 
> > > only people that don't are people that use their computers like monks.  
> > > All we can do most of the time is mitigate it.
> > 
> > Accept you aren't secure. Accept that you are compromised. Then try your 
> > best to prevent things from going wrong.
> > 
> > It's always good to prevent what you can.
> > 
> > I have a way of doing things that permits me to protect myself up the 
> > wahzoo.
> > 
> > More advanced than the way qubes initially did it.
> > It involves me doing different things with the iptables rules, but it's 
> > workable.
> > 
> > I've done things and tested things, even the vulnerabilities that they say 
> > there are that makes qubes super duper easy to break, and mine hasn't 
> > broken or had that vulnerability.
> > 
> > Default setups, they can cause issues.
> > SystemD, issues.
> > 
> > Hopefully one day, things will be back to being better, but until then, we 
> > just have to try to protect ourselves as best as we can. What else can we 
> > do when people like Google and Microsoft and all those others are trying to 
> > steal your data and take over your life and your pc and everything about 
> > you, then sell your data to the everyone
> 
> true.   Why not just use wireshark in sys-net, since its considered unsafe 
> anyways?
 
because I keep the data and logs separate. I have a proxyMV with it. That way, 
I can restrict the VM, and pass everything to something else, thus providing 
another layer of security by having the data come into the monitor, but go no 
further. So I can see what's going on, and then release or halt things myself.

> The problem for me is identifying what vm and what process is causing the 
> traffic.  To use baremetal methods on every vm is impractical.
 
true, but that's where certain things come in handy.
That's one thing I will look at adding, thanks for the thought.

> I still never figured out how to make the firewall scripts to control 
> everything outgoing. I still don't even believe its possible for some system 
> processes. Sure i've made iptables rules file on baremetal linux no probs.  
> But I have to be honest, with Qubes its too complicated for me.
> 

It's easy, use the firewall editor for the VMs.

> another issue for is monitoring hdd activity in similar manner.

On Dom0, use disk monitoring software.

-- 
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/01585f73-b385-47bc-ab54-1c82821c358d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: SystemD sucks - qubes shouldn't use it

On Saturday, 11 March 2017 07:35:42 UTC+11, Jean-Philippe Ouellet  wrote:
> On Fri, Mar 10, 2017 at 1:14 AM, Drew White  wrote:
> > I wrote my own applications for qubes because the developers wouldn't fix 
> > things and didn't change things to use less RAM.
> > I wrote my own manager that uses only 200 MB VRAM, instead of the current 
> > one that uses over 1 GB VRAM. (Approximations)
> 
> Feel free to share ;)

Well, I will have to fix it up to make it available.
It's not exactly "end-user" friendly at the moment.

But in the long run, I just may.
It is NOT open-source though.
And many of the things are hard-coded to what I use, so I'd have to build an 
options section for that aspect.

I'll let you know when it's 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/8a8f7d74-48e3-4f3b-91a9-d645e5beb732%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Win 7, Qubes 3.2, qubes-windows-tools 3.2.2-3 struggles

On Saturday, 11 March 2017 03:47:03 UTC+11, Ed Welch  wrote:
> On 03/10/2017 01:28 AM, Drew White wrote:
> > Problem is, they don't care.
> I'm new to this OS and new to this community, however, after searching 
> many many threads for info, looking at git/documentation/etc.  I really 
> have not gotten this impression at all, I regularly see developers 
> responding to threads and offering assistance.

Perhaps I should have provided more information in that one statement than 
providing the information in the whole post.

It's the whole post that provides the full details, not just one line.

Things change, things get passed from person to person and not everything is 
passed on properly. So things go wrong. They do their best, and there are bugs. 
Thing is, they aren't really focused on the Windows side for the tools, because 
the bugs that were there in version 2, if they were fixed, then the bugs they 
are trying to fix now would not be there due to the root cause being fixed. And 
that gives the impression that they don't care that much about the GFX side, 
because everything else is working, and there are just some idiosyncrasies of 
it. I don't mean that they don't actually care, it's more of a turn of phrase 
rather than a literal meaning.


> >
> > There are bugs in the tools that I pointed out in version 2 of the tools, 
> > and they still aren't fixed.
> >
> > The worse the issues got, the more I pressed it, and the more issues they 
> > put in instead of fixing.
> >
> > Then they fixed one issue, and then started putting more in.
> >
> > 3.2.1.3 is alright and works, as I posted about months ago after I upgraded 
> > to 3.2.2.3 and it broke Windows and caused lag in the Qubes Video Driver 
> > along with a major flicker.
> >
> > The only way to resolve that was to remove QWT and then perform a complete 
> > reinstall of it, without the video driver.
> > But to do that I had to start in safe mode, and enable the standard display 
> > adapter and disable the Qubes Video.
> >
> > I've been complaining for so long about things it's not funny, and they 
> > have not resolved the issues. (yet) That was stared in Qubes 2.
> >
> > Now at Qubes 4, I don't expect there to be any advancement in the Windows 
> > integration for the GPU side of things.
> >
> > But I stick to Qubes for security, that's one thing that they did get 
> > right, the whole reason behind it.
> >
> > So all in all, since QWT changed hands a couple of times, things went wrong.
> > So in essence, I just hope for the future because having multiple people 
> > work on the QWT system and it going wrong mainly after it changed hands, 
> > was expected.
> >
> > So, in a few years, the bugs in QWT 2* GFX side might be fixed.
> > Maybe they might do a complete re-write and get it all resolved in a month 
> > or 2.
> >
> 
> I would say my experiences thus far have given me the impression windows 
> support is not a primary focus of this project.  Windows tools/support 
> seems to be mainly user contributed, and while mostly functional, Qubes 
> in no way offers the kind of windows experience running on bare metal 
> would get you.
> 

Well, as soon ass they started work on version 4, version 3 went to the very 
back burner. The developers told me that version 3 would be not worked on very 
much, if at all, by the developers after version 4 comes out.


> This is perfectly ok with me, and in my personal opinion I think if 
> someone is looking for a windows machine with full hardware acceleration 
> (to support something like game playing), Qubes (or almost any 
> virtualization technology) is not going to be the answer.
> 
> If I were to offer any criticism to the qubes project, strictly 
> regarding Windows support, it would be that their documentation should 
> set expectations of what Windows support is available a little more 
> clearly.  After looking at the Qubes homepage a few weeks ago before 
> heading down the road of installing it myself, I was mostly expecting 
> windows support to be on par with linux ( I was never expecting graphics 
> acceleration or much direct hardware, as it is made clear linux appvm's 
> do not support hardware acceleration). I was however expecting things 
> like usb passthrough to work, and I was troubled by problems with the 
> most recent version of QWT which the docs I don't think quite explained 
> (so I decided to help by submitting my experience to the news group 
> archive to hopefully help others)
> 
> 
> On a personal note, after reading a handful of your emails last night, I 
> found the tone of all your emails leaving a rather poor taste in my 
> mouth.  There was an arrogance and sense of entitlement that I think 
> totally detract from any useful information you may have been providing.
> 
> It sounds like you are doing good work with slackware and with good 
> purpose, but then I read comments like "I know more about qubes than the 
> developers do by now." and "I've been complaining for

[qubes-users] Re: Non UEFI

On Saturday, 11 March 2017 05:21:59 UTC+11, cooloutac  wrote:
> On Friday, March 10, 2017 at 1:02:58 AM UTC-5, Drew White wrote:
> > On Friday, 10 March 2017 15:47:25 UTC+11, cooloutac  wrote:
> > > On Thursday, March 9, 2017 at 10:38:36 PM UTC-5, Drew White wrote:
> > > > Is there any version of all the templates that are NON UEFI?
> > > > i.e. without EFI?
> > > 
> > > what?
> > 
> > The question is straight forward and simple.
> > What of it do you not comprehend completely and query?
> 
> well i know what template and uefi is.  Don't know what they have to do with 
> each other though.

well, if you look at the Fedora Template, it has EFI on it.
I want to know if there are templates out there that don't have EFI or uEFI on 
it. Because it's not needed or anything.

-- 
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/668a45da-e303-4669-b970-67744c9ae497%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes 3.2 on Macbook Pro Retina 11,5 [SOLVED]. Maybe useful for other Macbook models

2017-03-12 Thread berzerkatives

On Thursday, March 2, 2017 at 8:59:00 PM UTC, Marco Pozzato wrote:
> Hi 
> 
> I am using Qubes 3.2 since a couple of months on a daily basis on Intel NUC 
> NUC6i5SYK and it is amazing.
> 
> I would like to use it also on one of my MacBooks:
> * MacBook Pro 15" early-2011 8,2: my first attempt and I was not even able to 
> start the installer. At that time I did not have enough knowledge and 
> abandoned. Maybe, in the forthcoming weeks, I will retry
> * MacBook Pro 15" mid-2015 11,5: I have been able to install Qubes booting 
> with rEFInd, despite a lot of issues.
> 
> The two main issues I faced are:
> * no boot, due to empty xen.cfg file
> * system freeze, due to Broadcom BCM43602 wifi adapter.
> 
> I spent many hours and nights googling, experimenting, reading git tickets 
> and messages in the ML. None provided the final guide, but many little pieces 
> that I am assembling in the Macbook troubleshooting document.
> 
> I came up with a running system, that still need more work. For the time 
> being I have a working setup and I hope to be helpful to other macbook users.
> 
> Dear Qubes developers: please, review my guide and maybe let's open some 
> specific mail/ticket to discuss and troubleshoot specific issues. I am more 
> than willing to help. 
> 
> Thanks
> Marco

Hi Marco,

I've been trying to get Qubes R3.2 running on my MacBookPro11,1 without any 
luck (I posted here for help a few weeks ago). I was wondering whether I could 
read your guide?

Take care,
Chris

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/4158f3e1-19a6-419e-9f6a-3b7541ddaeff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Kicking the sudoers dead horse

2017-03-12 Thread 7v5w7go9ub0o

On 03/12/2017 12:45 PM, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 2017-03-11 19:41, Unman wrote:
>> On Sat, Mar 11, 2017 at 08:47:05PM -0500, Chris Laprise wrote:
>>> On 03/11/2017 11:56 AM, Unman wrote:
 On Sat, Mar 11, 2017 at 04:43:41PM +, sm8ax1 wrote:
> 7v5w7go9ub0o:
>> Yep! And ISTM this is an argument for using dispvms to
>> handle mail (or any other WAN-exposed client/server):
>> start a dispvm; copy mail client and mail "file" into it;
>> do your mail; copy out and save the updated mail file
>> (which is text); flush away the dispvm - all handled by a
>> script(s).
> How do you figure that's less of a pain in the ass than
> typing a sudo password?
>
 You're missing the point - that procedure is trivial to set up
 in Qubes and addresses real security concerns. Just putting a
 password on root access, or requiring some dom0 interaction
 doesn't.

 This is important - security IS a pain in the ass. Qubes can
 make it less so.

>>> Yes, sm8ax1 got you there. :)
>>>
>>> DispVMs are nice to have when we think that certain operations
>>> carry threats. But its ridiculous to expect a typical user to do
>>> a majority of their tasks in them.
>>>
>> No, it isn't ridiculous to expect a typical user to work in
>> disposableVMs. I've set up a number of users with a range of
>> experience, and they are very comfortable with this. If the
>> implementation is kept hidden generally speaking everything goes
>> fine. Some scripting to make things easier, and support is
>> probably no greater than usual ,except for "that funny copy thing".
>> I've said this before.
>>
>> Set up right I don't think that Qubes is outrageously difficult to
>> use, even with disposableVMs doing most of the heavy lifting. But
>> that's a separate issue.

Agree with all of this. Working in a DispVM (e.g. browser, or mail) is
the same experience as working in a VM. Only difference is clicking a
script to start it up; inform the script of the DispVM to work in; and
telling the script to shutdown (copy updates) at the end - in my case by
entering a 

> I'd be interested in hearing more about this (in a separate thread,
> perhaps).
>
> In particular, no one has, to my knowledge, attempted to rebut the
> arguments I advanced against the "doing everything in DispVMs"
> approach here:
>
> https://groups.google.com/d/msg/qubes-users/nDrOM7dzLNE/Kr5W3BUkcG4J

RATS!  I missed that.

>
> Granted, that was almost two years ago, and some of the things I wrote
> there no longer apply. However, I still haven't seen a strong case
> made *in favor* of this approach to begin with. I would like to see one.
>
> - -- 
> Andrew David Wong (Axon)

This is the first I've seen your 4/1/15 note - sorry - wish we could
have discussed it then. You have the basic idea except for the vital
point of what happens at end of DispVM session (copying as few as
possible user files back to a VM or Vaulted user configuration). I take 
your point 4 on
space, and point 6 on RAM and CPU usage.

I disagree on critical point 5.

For example running a browser in a VM is indeed "more secure" than
running it in a VM because only specific updated files (bookmarks -
places.sqlite) are retained and copied back to the vault at end of
session; no other user-land files (and surprise relics) are copied back;
this is contrary to what is presumed in that write up. If if the
bookmarks weren't changed, simply flush the DispVM away.

Doing mail in a DispVM is also "more secure" for the same reason - only
specific updated files are retained at end of session - no other
user-land files (and relics) are copied back to a VM. This is key, and
why this is more secure.

   At startup, the user configuration file (.Thunderbird) is copied into
the DispVM, followed by the latest volatile user data files.

(If there is need to permanently change something in the user
configuration - I haven't in years - one simply starts up the
DispVM/tbird proggy, makes the configuration change doing no mail,
Usenet, etc., and promptly copies the newly changed, whole user
configuration back to the vault, followed by immediate shutdown.)

Also disagree on your second part of 6; I've been using this and other
DispVM scripts since Q2.0 or Q2.1; I've become lazy as they just work!
Infrequently I'll get a "failed to start" DispVM message, in which case
I'll start one manually and tell the script to use it (script pauses
'til the DispVM is up and running).

And also on point 6; yes there is a startup delay, but it is a
completely acceptable trade off to me for the reassurance and relaxed
comfort of running mail, browser, etc. in a DispVM.

Thank you for the thoughtful analysis of 4/1/15; apologies for not
responding at that time.

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

Re: [qubes-users] Kicking the sudoers dead horse

2017-03-12 Thread 7v5w7go9ub0o

On 03/12/2017 12:45 PM, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 2017-03-11 19:41, Unman wrote:
>> On Sat, Mar 11, 2017 at 08:47:05PM -0500, Chris Laprise wrote:
>>> On 03/11/2017 11:56 AM, Unman wrote:
 On Sat, Mar 11, 2017 at 04:43:41PM +, sm8ax1 wrote:
> 7v5w7go9ub0o:
>> Yep! And ISTM this is an argument for using dispvms to
>> handle mail (or any other WAN-exposed client/server):
>> start a dispvm; copy mail client and mail "file" into it;
>> do your mail; copy out and save the updated mail file
>> (which is text); flush away the dispvm - all handled by a
>> script(s).
> How do you figure that's less of a pain in the ass than
> typing a sudo password?
>
 You're missing the point - that procedure is trivial to set up
 in Qubes and addresses real security concerns. Just putting a
 password on root access, or requiring some dom0 interaction
 doesn't.

 This is important - security IS a pain in the ass. Qubes can
 make it less so.

>>> Yes, sm8ax1 got you there. :)
>>>
>>> DispVMs are nice to have when we think that certain operations
>>> carry threats. But its ridiculous to expect a typical user to do
>>> a majority of their tasks in them.
>>>
>> No, it isn't ridiculous to expect a typical user to work in
>> disposableVMs. I've set up a number of users with a range of
>> experience, and they are very comfortable with this. If the
>> implementation is kept hidden generally speaking everything goes
>> fine. Some scripting to make things easier, and support is
>> probably no greater than usual ,except for "that funny copy thing".
>> I've said this before.
>>
>> Set up right I don't think that Qubes is outrageously difficult to
>> use, even with disposableVMs doing most of the heavy lifting. But
>> that's a separate issue.

Agree with all of this. Working in a DispVM (e.g. browser, or mail) is 
the same experience as working in a VM. Only difference is clicking a 
script to start it up; inform the script of the DispVM to work in; and 
telling the script to shutdown (copy updates) at the end - in my case by 
entering a 

> I'd be interested in hearing more about this (in a separate thread,
> perhaps).
>
> In particular, no one has, to my knowledge, attempted to rebut the
> arguments I advanced against the "doing everything in DispVMs"
> approach here:
>
> https://groups.google.com/d/msg/qubes-users/nDrOM7dzLNE/Kr5W3BUkcG4J

RATS!  I missed that.

> Granted, that was almost two years ago, and some of the things I wrote
> there no longer apply. However, I still haven't seen a strong case
> made *in favor* of this approach to begin with. I would like to see one.
>
> - -- 
> Andrew David Wong (Axon)
>

This is the first I've seen your 4/1/15 note - sorry - wish we could 
have discussed it then. You have the basic idea except for the vital 
point of what happens at end of DispVM session (copying as few as 
possible user files back to a VM or Vault). I take your point 4 on 
space, and point 6 on RAM and CPU usage.

I disagree on critical point 5.

For example running a browser in a VM is indeed "more secure" than 
running it in a VM because only specific updated files (bookmarks - 
places.sqlite) are retained and copied back to the vault at end of 
session; no other user-land files (and surprise relics) are copied back; 
this is contrary to what is presumed in that write up. If if the 
bookmarks weren't changed, simply flush the DispVM away.

Doing mail in a DispVM is also "more secure" for the same reason - only 
specific updated files are retained at end of session - no other 
user-land files (and relics) are copied back to a VM. This is key, and 
why this is more secure.

  At startup, the user configuration file (.Thunderbird) is copied into 
the DispVM, followed by the latest volatile user data files.

(If there is need to permanently change something in the user 
configuration - I haven't in years - one simply starts up the 
DispVM/tbird proggy, makes the configuration change doing no mail, 
usenet, etc., and promptly copies the newly changed, whole user 
configuration back to the vault, followed by immediate shutdown.)

Also disagree on your second part of 6; I've been using this and other 
DispVM scripts since Q2.0 or Q2.1; I've become lazy as they just work! 
Infrequently I'll get a "failed to start" DispVM message, in which case 
I'll start one manually and tell the script to use it (script pauses 
'til the DispVM is up and running).

And also on point 6; yes there is a startup delay, but it is a 
completely acceptable trade off to me for the reassurance and relaxed 
comfort of running mail, browser, etc. in a DispVM.

Thank you for the thoughtful analysis of 4/1/15; apologies for not 
responding at that time.

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

Re: [qubes-users] Dealing with ssh

I have a dedicated minimal template used only for SSHing into remote
machines. Basically fedora-24-minimal template clone with only
openssh-client installed, and separate AppVMs based on that for
different groups of servers I log into from there with respective SSH
keys in each. This way if one machine compromised my template via e.g.
arcane terminal escapes or something, it shouldn't gain lateral access
to other machines belonging to different organizations that I also
have access to.

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

Re: [qubes-users] DNS

2017-03-12 Thread 'Antoine Sirinelli' via qubes-users

On Thu, Mar 09, 2017 at 12:30:21AM +, Unman wrote:
> If you had two servers on your network, or your DHCP server gave out two
> addresses both would be used, I think.
> If you want to lose one, you could overwrite it from rc.local or use
> bind-dirs on resolv.conf: both methods are covered in the docs.  
> Look at www.qubes-os.org/doc/config-files
> 

On Sat, Mar 11, 2017 at 11:02:29PM +, Unman wrote:
> No the issue is that the 1 DNS server you use doesn't resolve some
> addresses. I assume this is how you like it so I'm not clear really on
> what the problem is.
> 
> I have suggested to you how you can easily remove the second listing if
> that bothers you. (You've cut that from my reply).
> Alternatively you could customise sys-net to provide
> DNS services from some other servers, or add a second redirect rule to
> the one server you have. I don't see why that would be an advantage -
> surely your applications would time out in exactly the same way that
> they do at present?
> And if you added a second server that *doesn't* filter requests, why have
> one that *does* as your primary server?

Thank you for spending time to answer me but I still do not understand
why Qubes configures 2 DNS servers in /etc/resolv.conf in the VMs.

To summarise, I have one DNS server on my network. My DHCP server passes
only this DNS server adresses (Option 6). I may have missed something on
Qubes behaviour but why does Qubes decides to use 2 DNS server?

I understand your workaround to remove the second DNS server in VMs but
I would like to understand why it appears.

On a side note, on this network, I have plenty of different devices
connected with OS and I never had any issue with a second DNS server
appearing in the auto-configuration.

Thank you again for your help,

Antoine

-- 
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/20170312215619.mzfujwhpvrttkd6a%40fedora-23-dvm.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [qubes-users] Kicking the sudoers dead horse

On Saturday, March 11, 2017 at 11:13:43 PM UTC-5, Chris Laprise wrote:
> On 03/11/2017 09:49 PM, cooloutac wrote:
> 
> > Also what does Joanna mean by this statement on that page?  " At the
> > same time allowing for easy user-to-root escalation in a VM is simply
> > convenient for users, especially for update installation."
> 
> The statement was originally written a long time ago. Qubes can now 
> easily tell VM programs to run as root, so its not a real concern.
> 
> It does so happen there is a small bug when the GUI update script tries 
> to escalate from user to root (and it doesn't run). Its the only gotcha 
> I've encountered and its easy to tell the script to run as root in the 
> first place...
> 
> https://github.com/QubesOS/qubes-issues/issues/2693
> 
> >
> > If you are talking about some other form of authentication (sorry I
> > have a hard time following your convo with Uman, 0 timeout period for
> > sudo?) then what would make it inconvenient for users? We already
> > have to hit y or n to update templates.
> 
> This is a type of authorization where 'Yes' input from dom0 GUI takes 
> the place of a password. If it defaults to Yes as the doc has it, then 
> you just need to hit Enter.
> 
> The sudoers config allows you to specify how long sudo 'remembers' the 
> authorization... if that is a concern. This link explains it:
> 
> https://github.com/QubesOS/qubes-issues/issues/2693
> 
> 
> >
> > I still think its more about usability then whats trivial to bypass.
> > And in that case its based on threat model. Sure security is
> > difficult, but its more about controlling yourself then your machine,
> > imo.
> >
> > But I know you are genius Chris and if there is some method to
> > authenticate to sudo without a password that would not be cumbersome
> > for users I would be for that option.
> 
> When you are prompted to allow file copying between two VMs, thats based 
> on the same dom0 auth method. It feels the same as using that.
> :)
> 
> 
> -- 
> 
> Chris Laprise, tas...@openmailbox.org
> https://twitter.com/ttaskett

oh of course I see, that's not so bad at all.

-- 
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/30694e6b-a2a8-479d-aad4-809d2c294cc8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Dealing with ssh

On Sunday, March 12, 2017 at 5:17:39 PM UTC-4, cooloutac wrote:
> On Sunday, March 12, 2017 at 5:16:00 PM UTC-4, cooloutac wrote:
> > On Sunday, March 12, 2017 at 11:00:21 AM UTC-4, lok...@gmail.com wrote:
> > > What is the best way to handle ssh in Qubes?
> > > 
> > > I have a set of machines I often log in to remotely, and I want to make 
> > > sure the sessions (as well as the private keys) are protected from 
> > > vulnerabilities in other applications.
> > > 
> > > Currently I have set of a dedicates ssh qube from which I run all my ssh 
> > > sessions. I've also set its firewall to only allow access to the machines 
> > > I normally connect to.
> > > 
> > > Is there a better way to handle this? Ideally, I'd like to be able to use 
> > > dispvms for ssh, but how would I handle the private keys?
> > > 
> > > How do other people do this?
> > > 
> > > Regards,
> > > Elias
> > 
> > I do it same as you, a seperate qube allowed only access to the server I 
> > ssh into.  I use regular ssh command from terminal.  You can save key or 
> > password in vault vm if you want and copy and paste it.  But I don't bother 
> > cause I have it in .ssh folder anyways.
> 
> if you want to use the key in adispvm folder you can probably put it in the 
> internal dvm.

I wouldn;t want to do this though cause iI use dispvm for untrusted tasks and 
wouldn't want key in there.

-- 
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/91d19e91-9b5a-46d5-9c21-71faee2db26f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Dealing with ssh

On Sunday, March 12, 2017 at 5:16:00 PM UTC-4, cooloutac wrote:
> On Sunday, March 12, 2017 at 11:00:21 AM UTC-4, lok...@gmail.com wrote:
> > What is the best way to handle ssh in Qubes?
> > 
> > I have a set of machines I often log in to remotely, and I want to make 
> > sure the sessions (as well as the private keys) are protected from 
> > vulnerabilities in other applications.
> > 
> > Currently I have set of a dedicates ssh qube from which I run all my ssh 
> > sessions. I've also set its firewall to only allow access to the machines I 
> > normally connect to.
> > 
> > Is there a better way to handle this? Ideally, I'd like to be able to use 
> > dispvms for ssh, but how would I handle the private keys?
> > 
> > How do other people do this?
> > 
> > Regards,
> > Elias
> 
> I do it same as you, a seperate qube allowed only access to the server I ssh 
> into.  I use regular ssh command from terminal.  You can save key or password 
> in vault vm if you want and copy and paste it.  But I don't bother cause I 
> have it in .ssh folder anyways.

if you want to use the key in adispvm folder you can probably put it in the 
internal dvm.

-- 
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/0b4da48a-f3a4-44b2-b34b-1f791f17c1ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Dealing with ssh

On Sunday, March 12, 2017 at 11:00:21 AM UTC-4, lok...@gmail.com wrote:
> What is the best way to handle ssh in Qubes?
> 
> I have a set of machines I often log in to remotely, and I want to make sure 
> the sessions (as well as the private keys) are protected from vulnerabilities 
> in other applications.
> 
> Currently I have set of a dedicates ssh qube from which I run all my ssh 
> sessions. I've also set its firewall to only allow access to the machines I 
> normally connect to.
> 
> Is there a better way to handle this? Ideally, I'd like to be able to use 
> dispvms for ssh, but how would I handle the private keys?
> 
> How do other people do this?
> 
> Regards,
> Elias

I do it same as you, a seperate qube allowed only access to the server I ssh 
into.  I use regular ssh command from terminal.  You can save key or password 
in vault vm if you want and copy and paste it.  But I don't bother cause I have 
it in .ssh folder anyways.

-- 
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/35ad4b4d-bbb0-4dab-ac9f-427c560047f6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] very frequent crashes (about every other hour)

2017-03-12 Thread Steffen Hartmann

Hello,

after installation and some weeks of using cubes 3.2 I'm still facing troubles 
with the system hanging comletly.
It starts with very delayed mouse and keyboard input - finally everything stops.
When looking with top in dom0 no obvious memory hungry tasks.

However I have to reboot or even stop the computer the hard way pulling the 
mains.

With my other OS's on the same computer no such troubles.

Where can I look into to trace down this problem?

I have a dell precision 5500 with 16 GB Ram an 3 VM running (sys-firewall, 
sys-net, fed23) and dom0 of course.

Everything is pretty much standard installation.

thank you

-- 
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/13d1e4ed-ea58-41a8-a47a-110aa91972a6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] problems by changing template on sys-net and sys-firewall

2017-03-12 Thread haaber

> i killed my fedora23 template, so it won't start because of the
> non-executed qrexec-daemon.
> So i decided to change to debian8.
> 
> but the problem is, if i change to debian, i can not see any
> network-connection. Just if i go to network manager of the sys-net, i
> can see them, but i can not start them, because they are not at the
> right top of the screen... there are NO connections at all.
> 
> is there some options i must change manually, by changing the template
> of sys-net and sys-firewall?

Please try  "Add more shortcuts" and make sure that Networkmanager is in
the selected list. This is necessary when switching from fedora-x to
debian-y back or forth.
Greets, Bernhard

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9ca2b562-a0e6-a15f-8be2-34ec36602f43%40web.de.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] "Failed to save domain" when trying to create Whonix DisposableVMs.

2017-03-12 Thread 'Lolint' via qubes-users

Good day,

I've been trying to create Whonix Disposable VMs based on, 
https://www.whonix.org/wiki/Qubes/Disposable_VM#Creating_a_new_DisposableVM-Template_based_on_Whonix-Workstation
 but there is a problem I encounter with the very first step when typing

qvm-create-default-dvm whonix-ws

in the dom0 terminal. I get (skipped some lines):

Connecting to VM's GUI agent: ...connected
Waiting for DVM whonix-ws-dvm ...
/qubes-used-mem
Disk detached successfully

DVM book complete, memory used=509576. Saving image...

error: Failed to save domain whonix-ws-dvm to 
/var/lib/qubes/appvms/whonix-ws-dvm/dvm-savefile
error: internal error: Failed to save domain '11' with libxenlight

How can I fix this?

Thx,

--Jeff

-- 
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/dC_KyZFG9scbDtE6pqqeKVksBxir4UIsLKDvHKedC8DN92lvU-BmkqbQeGlfFFdPPgq4Ka0DVez4_uLcrg0Zt9xVd6Gbtrmy6UGvMhb-6Do%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: can not execute qrexec-daemon after uninstall of gstreamer.



Zitat von Grzesiek Chodzicki :

W dniu niedziela, 12 marca 2017 17:35:46 UTC+1 użytkownik  
evol...@aliaks.de napisał:

Zitat von Grzesiek Chodzicki :

> W dniu niedziela, 12 marca 2017 16:50:18 UTC+1 użytkownik
> evol...@aliaks.de napisał:
>> Hello everybody!
>>
>> after tweaking this and that, i killed my fedora and killed my
>> internet on Qubes.
>>
>> The thing i tried was to uninstall gstreamer from fedora template.
>> so i uninstalled three packages over software center (because i did
>> not know the whole installed packages of gstreamer). After that i
>> wanted to install gstreamer1-libav. BUT...
>>
>> after reboot of fedora template, i could NOT start it. It shows me
>> "can not execute qrexec-daemon" and remains yellow. After reboot of
>> App-VMs with fedora i can not also start any VM with fedora. So my
>> sys-firewall and sys-net were down.
>>
>> I changed firewall and net to debian, they start now... but without
>> any network. I can see my old network connections in the network
>> manager, but i can not connect any of them, because they are not
>> visible in the icon up the screen. As i puted a cable, it showed me 1
>> of 2 connection, but it was no possible to get any connection over it.
>>
>> so fedora is "dead" and debian give me no connection to the net.
>>
>> i have no idea why fedora gets this BIG problem because of gstreamer
>> and why debian gives me no connection.
>> how can i fix my fedora, or get connection with debian?
>>
>> Qubes is a fragile thing, as it seems :)
>
> Switch the sys-net and sys-firewall back to fedora template, Start
> the fedora template and then execute sudo xl console fedora024, that
> should give you access to the terminal and then try sudo dnf history
> undo last (dunno if that will actually work but it's worth a try).

ok, i thought it was x1, but it was xl (so the letter L)
and in my case fedora-23

there i have login. but which user and password??


both root


if i make just dnf history i don't see any deinstallations, so the  
deinstallation did not work... but why these problems with fedora  
then? hmmm...


--
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/20170312174850.Horde.gF8NqvXC3LKu4fDoK7Sy-w1%40webmail.df.eu.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: can not execute qrexec-daemon after uninstall of gstreamer.



Zitat von Grzesiek Chodzicki :

W dniu niedziela, 12 marca 2017 17:35:46 UTC+1 użytkownik  
evol...@aliaks.de napisał:

Zitat von Grzesiek Chodzicki :

> W dniu niedziela, 12 marca 2017 16:50:18 UTC+1 użytkownik
> evol...@aliaks.de napisał:
>> Hello everybody!
>>
>> after tweaking this and that, i killed my fedora and killed my
>> internet on Qubes.
>>
>> The thing i tried was to uninstall gstreamer from fedora template.
>> so i uninstalled three packages over software center (because i did
>> not know the whole installed packages of gstreamer). After that i
>> wanted to install gstreamer1-libav. BUT...
>>
>> after reboot of fedora template, i could NOT start it. It shows me
>> "can not execute qrexec-daemon" and remains yellow. After reboot of
>> App-VMs with fedora i can not also start any VM with fedora. So my
>> sys-firewall and sys-net were down.
>>
>> I changed firewall and net to debian, they start now... but without
>> any network. I can see my old network connections in the network
>> manager, but i can not connect any of them, because they are not
>> visible in the icon up the screen. As i puted a cable, it showed me 1
>> of 2 connection, but it was no possible to get any connection over it.
>>
>> so fedora is "dead" and debian give me no connection to the net.
>>
>> i have no idea why fedora gets this BIG problem because of gstreamer
>> and why debian gives me no connection.
>> how can i fix my fedora, or get connection with debian?
>>
>> Qubes is a fragile thing, as it seems :)
>
> Switch the sys-net and sys-firewall back to fedora template, Start
> the fedora template and then execute sudo xl console fedora024, that
> should give you access to the terminal and then try sudo dnf history
> undo last (dunno if that will actually work but it's worth a try).

ok, i thought it was x1, but it was xl (so the letter L)
and in my case fedora-23

there i have login. but which user and password??


both root


"failed to synchronize cache from repo updates" after dnf history undo last


--
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/20170312174031.Horde.j-7wuxNTGJZi1XupCd-Byg1%40webmail.df.eu.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: can not execute qrexec-daemon after uninstall of gstreamer.

2017-03-12 Thread Grzesiek Chodzicki

W dniu niedziela, 12 marca 2017 17:35:46 UTC+1 użytkownik evol...@aliaks.de 
napisał:
> Zitat von Grzesiek Chodzicki :
> 
> > W dniu niedziela, 12 marca 2017 16:50:18 UTC+1 użytkownik  
> > evol...@aliaks.de napisał:
> >> Hello everybody!
> >>
> >> after tweaking this and that, i killed my fedora and killed my
> >> internet on Qubes.
> >>
> >> The thing i tried was to uninstall gstreamer from fedora template.
> >> so i uninstalled three packages over software center (because i did
> >> not know the whole installed packages of gstreamer). After that i
> >> wanted to install gstreamer1-libav. BUT...
> >>
> >> after reboot of fedora template, i could NOT start it. It shows me
> >> "can not execute qrexec-daemon" and remains yellow. After reboot of
> >> App-VMs with fedora i can not also start any VM with fedora. So my
> >> sys-firewall and sys-net were down.
> >>
> >> I changed firewall and net to debian, they start now... but without
> >> any network. I can see my old network connections in the network
> >> manager, but i can not connect any of them, because they are not
> >> visible in the icon up the screen. As i puted a cable, it showed me 1
> >> of 2 connection, but it was no possible to get any connection over it.
> >>
> >> so fedora is "dead" and debian give me no connection to the net.
> >>
> >> i have no idea why fedora gets this BIG problem because of gstreamer
> >> and why debian gives me no connection.
> >> how can i fix my fedora, or get connection with debian?
> >>
> >> Qubes is a fragile thing, as it seems :)
> >
> > Switch the sys-net and sys-firewall back to fedora template, Start  
> > the fedora template and then execute sudo xl console fedora024, that  
> > should give you access to the terminal and then try sudo dnf history  
> > undo last (dunno if that will actually work but it's worth a try).
> 
> ok, i thought it was x1, but it was xl (so the letter L)
> and in my case fedora-23
> 
> there i have login. but which user and password??

both 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/fc3dbf57-2ad7-4f3d-b0b8-7dd19643d639%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: can not execute qrexec-daemon after uninstall of gstreamer.

Zitat von Grzesiek Chodzicki :

W dniu niedziela, 12 marca 2017 16:50:18 UTC+1 użytkownik
evol...@aliaks.de napisał:

Hello everybody!

after tweaking this and that, i killed my fedora and killed my
internet on Qubes.

The thing i tried was to uninstall gstreamer from fedora template.
so i uninstalled three packages over software center (because i did
not know the whole installed packages of gstreamer). After that i
wanted to install gstreamer1-libav. BUT...

after reboot of fedora template, i could NOT start it. It shows me
"can not execute qrexec-daemon" and remains yellow. After reboot of
App-VMs with fedora i can not also start any VM with fedora. So my
sys-firewall and sys-net were down.

I changed firewall and net to debian, they start now... but without
any network. I can see my old network connections in the network
manager, but i can not connect any of them, because they are not
visible in the icon up the screen. As i puted a cable, it showed me 1
of 2 connection, but it was no possible to get any connection over it.

so fedora is "dead" and debian give me no connection to the net.

i have no idea why fedora gets this BIG problem because of gstreamer
and why debian gives me no connection.
how can i fix my fedora, or get connection with debian?

Qubes is a fragile thing, as it seems :)

Switch the sys-net and sys-firewall back to fedora template, Start
the fedora template and then execute sudo xl console fedora024, that
should give you access to the terminal and then try sudo dnf history
undo last (dunno if that will actually work but it's worth a try).

what do you mean with "sudo xl console fedora024"?
by the way, i have fedora23, did not updated yet.

--
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/20170312172352.Horde.JpZAAeukYmaQbxbYK3WLug8%40webmail.df.eu.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: can not execute qrexec-daemon after uninstall of gstreamer.

2017-03-12 Thread Grzesiek Chodzicki

W dniu niedziela, 12 marca 2017 16:50:18 UTC+1 użytkownik evol...@aliaks.de 
napisał:
> Hello everybody!
> 
> after tweaking this and that, i killed my fedora and killed my  
> internet on Qubes.
> 
> The thing i tried was to uninstall gstreamer from fedora template.
> so i uninstalled three packages over software center (because i did  
> not know the whole installed packages of gstreamer). After that i  
> wanted to install gstreamer1-libav. BUT...
> 
> after reboot of fedora template, i could NOT start it. It shows me  
> "can not execute qrexec-daemon" and remains yellow. After reboot of  
> App-VMs with fedora i can not also start any VM with fedora. So my  
> sys-firewall and sys-net were down.
> 
> I changed firewall and net to debian, they start now... but without  
> any network. I can see my old network connections in the network  
> manager, but i can not connect any of them, because they are not  
> visible in the icon up the screen. As i puted a cable, it showed me 1  
> of 2 connection, but it was no possible to get any connection over it.
> 
> so fedora is "dead" and debian give me no connection to the net.
> 
> i have no idea why fedora gets this BIG problem because of gstreamer  
> and why debian gives me no connection.
> how can i fix my fedora, or get connection with debian?
> 
> Qubes is a fragile thing, as it seems :)

Switch the sys-net and sys-firewall back to fedora template, Start the fedora 
template and then execute sudo xl console fedora024, that should give you 
access to the terminal and then try sudo dnf history undo last (dunno if that 
will actually work but it's worth a try).

-- 
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/db306c0b-9140-411d-b18e-90eb1f9e0832%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] can not execute qrexec-daemon after uninstall of gstreamer.

Hello everybody!

after tweaking this and that, i killed my fedora and killed my
internet on Qubes.

so fedora is "dead" and debian give me no connection to the net.

i have no idea why fedora gets this BIG problem because of gstreamer
and why debian gives me no connection.

how can i fix my fedora, or get connection with debian?

Qubes is a fragile thing, as it seems :)

--
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/20170312165016.Horde.SqJGI3ignbqoj4FqmSnieA1%40webmail.df.eu.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: change template of App-VM in terminal