date:20180228

On 02/28/2018 08:23 PM, 'awokd' via qubes-users wrote:

On Thu, March 1, 2018 1:14 am, billol...@gmail.com wrote:

This is not qubes-specific. It hasn't worked in fedora for a long time,
and I don't think it works in ubuntu/debian either, as long as
NetworkManager is turned on. In regular fedora, you can use macchanger
if you turn off NetworkManager and manage all your connections yourself,
but that's quite a hassle.

BTW, as an example of Qubes-specifics in this issue, on sleep/wake
networkVMs don't process the normal array of events and system states
that bare-metal Linux distros do. At least this was the case for 3.x.
The result was that advocates of the macchanger script method (which
relied on such events and related hooks) recommended that users keep a
watch on the current MAC address and restart sys-net whenever it
reverted (waking from sleep was the most common/blatant example). They
didn't care to address the fact that the waking system was already
broadcasting the original address before the user had a chance to
restart sys-net (and not to mention the unmitigated headache of
restarting/reassigning all the dependant VMs).

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

--
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/01db7573-f65e-a48d-9a48-431f85177421%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Anonymizing your MAC Address with macchanger and scripts

On 02/28/2018 03:58 PM, Yuraeitha wrote:

On Wednesday, February 28, 2018 at 9:14:30 PM UTC+1, vel...@tutamail.com wrote:

Chris if you could replicate the simplicity in your instruction for a
"kill-switc-VPN" for the this feature that would be awesome...

This seems like a great feature...I am getting up to speed on the Linux
commands but I suspect a lot of the laypeople(who likely need the security)
would appreciate this feature if they could understand the detailed steps, even
if simple.

Thanks again for all you do

https://groups.google.com/forum/#!searchin/qubes-users/vpn$20github%7Csort:date/qubes-users/FUQaRPWXPj8/SMlPfhwuAgAJ

To add to your thoughts V, maybe this could even be implemented it in Qubes
directly, with a simple turn on/off switch or command? It seems like this would
be helpful for new users seeking Qubes for privacy concerns. I know Qubes is
primary focused on security, but it'd be a one step closer to make Qubes easy
to use for people not into the terminal/how-to guides. It would also make it
easier when upgrading a new Qubes, for example when Qubes 4.1. and Qubes 5 is
out, and guides once again face questions as to if they work on a Qubes version
or not (all over again).

What do you think Chris? is this realistic, feasible in terms of no newly
introduces downsides, or even desired?

I can't tell if MAC addresses or VPNs are being discussed at this point.
If the latter, then I've already posted the new code and done 90% of the
changes needed to make the doc simpler (essentially 3 steps, not
counting "test the connection" and "restart the VM"). So, we'll see
when/if the new solution gets integrated.

For MAC addresses, I'd actually recommend making randomization the
default _at some point_. But right now the exercise is academic because
firmware and driver vendors haven't addressed the problem of unique
non-address metadata that NICs are also transmitting.

Even though its academic, I'd rather not see people struggle with
macchanger when it could still leak the original address, whether or not
the other metadata is sent.

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

--
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/bbdf93a4-40a1-4304-3352-2d35d0557d9f%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Anonymizing your MAC Address with macchanger and scripts

On 02/28/2018 08:23 PM, 'awokd' via qubes-users wrote:

On Thu, March 1, 2018 1:14 am, billol...@gmail.com wrote:

The thing I don't like about NetworkManager MAC address randomization
compared to macchanger, is that it is connection-specific, not network
device-specific, and I prefer the latter.

Yes, NM does it that way because the main necessity is to prevent users
being tracked as their machines are moved geographically. (Of course,
the prevention is theoretical at this point because other metadata has
not yet been suppressed.)

Might be worth keeping the content around then if all we need to do is add
that note about disabling NetworkManager.

Unfortunately, even when they worked the macchanger scripts still had
some big issues with the address reverting back to original when certain
system events occurred. That's why the feature had to be integrated.

There are now three places in Linux where MAC randomization can be
managed properly: WPA Supplicant (I think for wifi only), NM and
systemd. NM seems to provide the best overlap between simplicity and
flexibility. OTOH using macchanger is much more complicated and likely
to leak your hardware address.

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

--
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/53524cc5-4dc7-470b-f8ad-eabde7db557a%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Anonymizing your MAC Address with macchanger and scripts

2018-02-28 Thread 'awokd' via qubes-users

On Thu, March 1, 2018 1:14 am, billol...@gmail.com wrote:

>
> This is not qubes-specific.  It hasn't worked in fedora for a long time,
> and I don't think it works in ubuntu/debian either, as long as
> NetworkManager is turned on.  In regular fedora, you can use macchanger
> if you turn off NetworkManager and manage all your connections yourself,
> but that's quite a hassle.
>
> The thing I don't like about NetworkManager MAC address randomization
> compared to macchanger, is that it is connection-specific, not network
> device-specific, and I prefer the latter.

Might be worth keeping the content around then if all we need to do is add
that note about disabling NetworkManager.

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

Re: [qubes-users] Anonymizing your MAC Address with macchanger and scripts

2018-02-28 Thread billollib

On Wednesday, February 28, 2018 at 1:34:28 PM UTC-5, Chris Laprise wrote:

> Hi,
> 
> The macchanger section of the doc hasn't worked for a long time (search 
> the mailing list to see issues) and it never did work correctly, IMO.
> 
> > What should i do?
> > 
> 
> You should use the MAC randomization feature integrated into Network 
> Manager, shown at the beginning of the doc.
> 
> -- 
> 
> Chris Laprise, tas...@posteo.net
> https://github.com/tasket
> https://twitter.com/ttaskett
> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

This is not qubes-specific.  It hasn't worked in fedora for a long time, and I 
don't think it works in ubuntu/debian either, as long as NetworkManager is 
turned on.  In regular fedora, you can use macchanger if you turn off 
NetworkManager and manage all your connections yourself, but that's quite a 
hassle.

The thing I don't like about NetworkManager MAC address randomization compared 
to macchanger, is that it is connection-specific, not network device-specific, 
and I prefer the latter.

billo

-- 
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/b1332f71-9630-44fd-a316-6f866089f48e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: firewall/proxy VM not working with Qubes 4.0-rc4

2018-02-28 Thread Alex Dubois

On Wednesday, 28 February 2018 17:41:06 UTC, thorsten...@gmail.com  wrote:
> > Could you try this:
> > qvm-prefs sys-firewall | grep netvm
> > it should say sys-net? Y/N
> 
> yes, result is sys-net
> 
> 
> > Even if it states sys-net, let's try to force it again
> > qvm-prefs sys-firewall -s netvm sys-net
> 
> that command did not work due to wrong syntax, so I did:
> 
> qvm-prefs --set sys-firewall netvm sys-net
> 
> If sys-firewall is shut down, the command works.
> If sys-firewall is running, the command fails with the error:
> "no such preoperty: 'netvm'", in addition if sys-firewall is running while I 
> do this, the eth0 interface is removed from sys-firewall.
> 
> 
> > and try the arp -an in sys-firewall again
> 
> Still the same result:
> ? (10.137.0.5) at  on eth0
> 
> Maybe I should try to look into the script(s) that are running when using 
> "qvm-prefs --set sys-firewall netvm sys-net"?

Yes good idea. I would need to do so too to be able to help now... I'm not 
familiar with this part.

-- 
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/19ea3dbe-7b8a-4a60-8935-e2f5f50be320%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

AW: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-02-28 Thread '[799]' via qubes-users

Hello Yuraeitha,

 Original-Nachricht 
An 28. Feb. 2018, 21:39, Yuraeitha schrieb:

> It seems from time to time that various
> people have shared a good unofficial script,
> guides and 'how to's', and even code, for
> Qubes related content, on their github page or
> similar. The problem however is that while
> shared, it isn't very visible, and even if they are
> from time to time mentioned in a mail thread,
> it quickly gets buried under many new mails.

I have recognized the same and was wondering already what could be the reason 
that people have written own small projects which I only knew of because 
following this mailing list.
Honestly I started the same, after coming up with the first draft of ma 
qvm-screenshot-to-clipboard script.

The main reason why I didn't upload it (yet) to Qubes docs:

1) it is on a very early stage and while it is working I would feel a bit 
ashamed, as there is no error handling etc.

2) I am unsure if the script is not only working but also "reasonable secure" 
to use

3) I like the quality of the existing Qubes documentation, but it takes some 
time for a newbie user not only to write a good how-to but also include all the 
valuable feedback or keep the discussion ongoing.

Maybe those are the reasons why others like to keep developing their stuff 
outside of the Qubes doc repository. Summarized:

1. Scripts are not yet ready/to basic
2. Unknown impact on security
3. Not enough time to craft a quality "product"

> To solve an issue like this, it'd be helpful to
> have a place where we can keep track of
> everyone's projects which are shared for
> others to use. It may also be worth discussing
> on quality and security, and how we "censor"?
> bad scripts/guides/code.

Yes, please! His could also be a good ressource to browse looking to fine-tune 
Qubes.

> It could be done in many various of different
> ways, which is also why I think it'd make
> sense to open a discussion on the matter, so
> we can find the most preferred method. First
> though, a location might be ideal starting
> place, where to keep everything updated?
> (...)
> A https://www.qubes-os.org/doc/ page listing
> all the unofficial projects. The most simple
> and easy way.

I like the idea having it available at GitHub as we can easily contribute to 
the code and GitHub has all the features to keep discussion ongoing etc.
It is also allows to keep a copy of the latest version of the scripts and 
people don't have to learn another tool when their code is ready to be released.

The bad thing:
If you're not a developer and have never worked with GitHub the learning curve 
might be high.
At least I had to click some time arround to understand what is located where 
and how it is working.

> Generally the main concern is the visibility of
> the effort that the community puts in Qubes,
> from the bottom-up, often goes to waste and
> few people see's it.

The other benefit is, that I learn a lot from reading other person's scripts 
and of course following the discussion.

Maybe some of the ideas there could also be mentioned in a maybe monthly blog 
post, so that new users can see that Qubes is a living project.

I would call this site/place where all the ideas are summarize "Qubes Garden" 
or "Qubes Playground" :-)

[799]

-- 
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/0pr2C-ky5f2cKco20qOf5PtKmsLafq7Xmw0-9qKvG0demT1mbPRyAv1QOkn6w6oYvxjrv-XP_eVgyhuqrbNE8Hac1U2BLhioUJ9M6l5SlkA%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] error opening sys-net & dom0 flashing yellow triangle

2018-02-28 Thread yrebstv

Today opening sys-net  I get these errors in the terminal , though
sys-net continues  on and  seems OK ,  I suppose by now, it is expected
behavior that sys-net takes a long time and sometimes never shutsdown ??

  File "/usr/bin/qvm-start", line 136, in 
main()
  File "/usr/bin/qvm-start", line 120, in main
xid = vm.start(verbose=options.verbose,
preparing_dvm=options.preparing_dvm, start_guid=not options.noguid,
notify_function=tray_notify_generic if options.tray else None)
  File
"/usr/lib64/python2.7/site-packages/qubes/modules/005QubesNetVm.py",
line 143, in start
vm.attach_network(wait=False)
  File "/usr/lib64/python2.7/site-packages/qubes/modules/000QubesVm.py",
line 1738, in attach_network
self._format_net_dev(self.ip, self.mac, self.netvm.name))
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 530, in
attachDevice
if ret == -1: raise libvirtError ('virDomainAttachDevice() failed',
dom=self)
libvirt.libvirtError: invalid argument: network device with mac
00:16:3e:5e:6c:06 already exists



I cont'd on after  sys-net  started  via CLI  above  but occasionally I
see a dom0 flashing triangle  FWIW, maybe not related to below ??

(XEN) [VT-D]DMAR:[DMA Write] Request device [:04:00.0] fault addr
fff0, iommu reg = 82c0009f4000
(XEN) [VT-D]DMAR: reason 05 - PTE Write access is not set
(XEN) [VT-D]DMAR:[DMA Write] Request device [:04:00.0] fault addr
fff0, iommu reg = 82c0009f4000
(XEN) [VT-D]DMAR: reason 05 - PTE Write access is not set
(XEN) [VT-D]DMAR:[DMA Write] Request device [:04:00.0] fault addr
fff0, iommu reg = 82c0009f4000
(XEN) [VT-D]DMAR: reason 05 - PTE Write access is not set



THIRDLY,
of late qvm-shutdown --all   has been hanging and I must do a hard
reboot , or  do  qvm-shutdown VM1 VM2 VM3  etc ,  which is kind of a
pain ...


I'm not really geeky enough to know if any of these might be related or 
fix themselves,  Lastly,  I am running  the security update repo  , but
don't recall if any of these started before or after installing the
security patch  for  the intel  issues.


any suggestions to do something or nothing appreciated  

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

[qubes-users] HCL - Dell XPS 8920

2018-02-28 Thread Jascha

Attached.

Most everything I have tested seems to be working. Only the monitor
seems to have issue going into sleep/power save. When installing
computer has a SSD and Magnetic HD was forced to install to Magnetic HD
since install kept failing with SSD.

-Jascha

-- 
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/6f5459a6-87b5-14c9-dafd-f53173f0d538%40cryptocartel.com.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-Dell_Inc_-XPS_8920-20180228-144337.yml
Description: application/yaml


Qubes-HCL-Dell_Inc_-XPS_8920-20180228-144337.cpio.gz
Description: application/gzip

[qubes-users] Cron not working on AppVMS based on Debian 9

2018-02-28 Thread maurice

Hi,

I'm not able to get the user crontab running, apparently this happens because 
threre's no crond service nor unit files:

systemctl status crond
Unit crond.service could not be found.

Being the only service available the cron mount:

systemctl | grep -i cron
var-spool-cron.mount loaded active mounted /var/spool/cron 

Does anyone knows how to get cron running persistently (i.e. after every 
reboot) so the user can run its cronta job?

Thank you.

John

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

Re: [qubes-users] Anonymizing your MAC Address with macchanger and scripts

On Wednesday, February 28, 2018 at 9:14:30 PM UTC+1, vel...@tutamail.com wrote:
> Chris if you could replicate the simplicity in your instruction for a 
> "kill-switc-VPN" for the this feature that would be awesome...
> 
> This seems like a great feature...I am getting up to speed on the Linux 
> commands but I suspect a lot of the laypeople(who likely need the security) 
> would appreciate this feature if they could understand the detailed steps, 
> even if simple.
> 
> Thanks again for all you do
> 
> V 
> 
> 
> https://groups.google.com/forum/#!searchin/qubes-users/vpn$20github%7Csort:date/qubes-users/FUQaRPWXPj8/SMlPfhwuAgAJ

To add to your thoughts V, maybe this could even be implemented it in Qubes 
directly, with a simple turn on/off switch or command? It seems like this would 
be helpful for new users seeking Qubes for privacy concerns. I know Qubes is 
primary focused on security, but it'd be a one step closer to make Qubes easy 
to use for people not into the terminal/how-to guides. It would also make it 
easier when upgrading a new Qubes, for example when Qubes 4.1. and Qubes 5 is 
out, and guides once again face questions as to if they work on a Qubes version 
or not (all over again).

What do you think Chris? is this realistic, feasible in terms of no newly 
introduces downsides, or even desired?

-- 
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/563b393e-e5f9-4e3f-ac41-982a4220b0ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

It seems from time to time that various people have shared a good unofficial
script, guides and 'how to's', and even code, for Qubes related content, on
their github page or similar. The problem however is that while shared, it
isn't very visible, and even if they are from time to time mentioned in a mail
thread, it quickly gets buried under many new mails. It often isn't feasible to
use the search engine to find these either.

Of course everything could be put into the Qubes doc page. But first, it's
getting pretty large and cluttered and will probably only grow bigger. Second,
the Qubes doc page does not show on-going and un-finished work. The strength of
seeing unfinished projects, is that we can help each others finish and test
them. Scrutinize them for security issues and reliability issues, before they
are considered for the Qubes doc page.

To solve an issue like this, it'd be helpful to have a place where we can keep
track of everyone's projects which are shared for others to use. It may also be
worth discussing on quality and security, and how we "censor"? bad
scripts/guides/code. It could be done in many various of different ways, which
is also why I think it'd make sense to open a discussion on the matter, so we
can find the most preferred method. First though, a location might be ideal
starting place, where to keep everything updated?

Initial thoughts
- A https://www.qubes-os.org/doc/ page listing all the unofficial projects. The
most simple and easy way.

- A decentralized network shared links through wiki pages, linking from one to
the next. Takes some work to maintain, but could be useful if properly done.
The weakness is that it is very redundant and requires edits on every wiki page
containing shared content in order to keep a network based source system up. A
single maintained overview page would therefore be easier. The strength is that
it builds up a stronger sense of inter-connected community and inter-awareness
of each others github pages.

- An off-sight website which can build on unofficial content, keeping the Qubes
official website clean from unofficial releases. The strength here is that more
can be done to make answers to redundant questions more visible, and highlight
unofficial solutions to which many people keep facing. The weakness is that it
once more segments where Qubes users hangout, which might not be something we
currently can afford. There are only about 30.000 Qubes users tops? and from
them we often see the same people posting, and many of the new faces don't
re-post very often. It would also require a reputation of reliability and
trust, including carrying out these responsibilities too, on its own.

Generally the main concern is the visibility of the effort that the community
puts in Qubes, from the bottom-up, often goes to waste and few people see's it.

Thoughts? maybe other new solutions or a modified one to one mentioned? I'm
pretty sure there are many good ideas, opinions and insights out there, lets
discuss this issue.

--
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/5d1fd248-de9c-4d4a-a8a8-c716a5e251a6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Anonymizing your MAC Address with macchanger and scripts

2018-02-28 Thread velcro

Chris if you could replicate the simplicity in your instruction for a 
"kill-switc-VPN" for the this feature that would be awesome...

This seems like a great feature...I am getting up to speed on the Linux 
commands but I suspect a lot of the laypeople(who likely need the security) 
would appreciate this feature if they could understand the detailed steps, even 
if simple.

Thanks again for all you do

V 


https://groups.google.com/forum/#!searchin/qubes-users/vpn$20github%7Csort:date/qubes-users/FUQaRPWXPj8/SMlPfhwuAgAJ

-- 
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/861e424b-3955-4fb4-a6fa-2915ff776105%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Anonymizing your MAC Address with macchanger and scripts

On 02/28/2018 01:49 PM, awokd wrote:

On Wed, February 28, 2018 6:34 pm, Chris Laprise wrote:

On 02/28/2018 11:31 AM, klausdiet...@mail2tor.com wrote:

Hey guys,

i have a big problem with "Anonymizing your MAC Address with macchanger
and scripts". I used this Tutorial on the Qubes Doc:
https://www.qubes-os.org/doc/anonymizing-your-mac-address/

Hi,

The macchanger section of the doc hasn't worked for a long time (search
the mailing list to see issues) and it never did work correctly, IMO.

Should it be deleted? I can put in a PR, but that won't leave much left on
that doc. Should what's left work on R4.0?

To answer your other question: Yes, the NM instructions work equally
well under 3.2 and 4.0.

There's not much verbiage but that is often a good thing. I can expand
it a bit by showing an additional NM config that generates a random MAC
only once and retains it for each wifi access point.

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

--
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/4a79e561-33ae-8c58-3639-0ecc8cff6a41%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Anonymizing your MAC Address with macchanger and scripts

On 02/28/2018 01:49 PM, awokd wrote:

On Wed, February 28, 2018 6:34 pm, Chris Laprise wrote:

On 02/28/2018 11:31 AM, klausdiet...@mail2tor.com wrote:

Hey guys,

i have a big problem with "Anonymizing your MAC Address with macchanger
and scripts". I used this Tutorial on the Qubes Doc:
https://www.qubes-os.org/doc/anonymizing-your-mac-address/

Hi,

The macchanger section of the doc hasn't worked for a long time (search
the mailing list to see issues) and it never did work correctly, IMO.

Should it be deleted? I can put in a PR, but that won't leave much left on
that doc. Should what's left work on R4.0?

That section has been defunct/abandoned for almost 2 years, so yeah it
should be deleted. I know initially a lot of work went into it, but then
interest quickly dropped off probably because the scripted approach
wasn't practical for that task.

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

--
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/f7cb9dec-4ca1-21fd-d486-de2d6dd980d4%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: qrexec demon fails to load any VM when I attach any device

On Tuesday, February 27, 2018 at 7:55:09 PM UTC+1, Allen Larocque wrote:
> Thanks for the help.
> 
> The intel audio pci device is indeed listed in the qvm-pci list, and the 
> pulseaudio manager is 'connected', However, under 'devices' there's nothing 
> about the intel device - just 'combined monitor' as the source
> 
> 
> On Tuesday, 27 February 2018 10:09:37 UTC-8, Yuraeitha  wrote:
> > On Tuesday, February 27, 2018 at 6:58:11 PM UTC+1, Allen Larocque wrote:
> > > Thanks Yuraeitha for the thoughtful reply!
> > > 
> > > Hm. It doesn't seem to work in the other templates. I think it is a 
> > > driver issue. I've tried volume etc.; and switching through the 
> > > pulseaudio menus shows only 'simultaneous output' devices (which DO have 
> > > actively fluctuating 'volume bars' when playback is happening!). Under 
> > > 'config' there is 'no sound cards available for configuration'. 
> > > I've been trying some things and let me try to clarify:
> > > 
> > > 'lspci' lists '00:1b:0 Audio device: Intel Corporation 7 Serices/c210 
> > > Series Chipset Family High Definition Audio Controller (rev04)'
> > > I interpret that as the audio card being on the chipset (hence 'plugged 
> > > in' automatically).
> > > 
> > > 'aplay -l' however lists "no soundcards found". So alsa doesn't see it?
> > > 
> > > Alsa is a deeper level than pulseaudio generally, right? So if alsa 
> > > doesn't see it then it makes sense that pulseaudio doesn't either.
> > > 
> > > So: how to get alsa/pulseaudio to see it?
> > > 
> > > Thanks again for the gracious help!
> > > - Allen
> > > 
> > > On Tuesday, 27 February 2018 04:16:15 UTC-8, Yuraeitha  wrote:
> > > > On Tuesday, February 27, 2018 at 10:42:30 AM UTC+1, Allen Larocque 
> > > > wrote:
> > > > > Hi Qubes,
> > > > > First time installer here, trying to get my sound to work. Strangely, 
> > > > > speakers are broken, but headphones work fine.
> > > > > 
> > > > > Anytime I move my sound device from 'available' to 'selected' in a 
> > > > > given VM, the VM won't load and I get the 'qeexec demon' error. Same 
> > > > > thing when I move various other devices over (tested with USB ones). 
> > > > > I should need the audio device moved over in order for it to work in 
> > > > > a given VM, right?
> > > > > 
> > > > > Any thoughts? Running 3.2 on a Zenbook UX31A.
> > > > > 
> > > > > Thanks,
> > > > > Allen
> > > > 
> > > > Also if you moved the soundcard to a direct pass-through, and the 
> > > > soundcard hardware does not support the PCI pass-through feature. Then 
> > > > you need to make a full restart of Qubes OS (fully power down power in 
> > > > order to clean hardware memory). This is due to security reasons. If 
> > > > this is hitting you, then you may want to first undo the pass-through 
> > > > you made of your soundcard, and then make a full restart before trying 
> > > > the above suggestions.
> > 
> > np's :)
> > 
> > Try compare "qvm-pci list" with lspci, it's the same list, but it'll show 
> > you if the Qubes tools register the sound card. Also try look in the Qubes 
> > menu --> Systems Tools --> Pulseaudio Manager. See if the sound server is 
> > connected or disconnected here.
> > 
> > I can't write much more right now as I'm on the road and need to close the 
> > lid and move now, but checking these might get us a little closer with more 
> > information.
> > 
> > I can confirm I see my own soundcards with "aplay -l", so this command 
> > should indeed be working in Qubes it seems?
> > 
> > It sounds like a problem that is out of my league though, but I'll try to 
> > help where I can.

I apologies for the delay. I divided this post into two sections, one if you 
got USB controller in dom0, and the other if you got the USB controller in an 
AppVM. You'll need the link if you got your USB controller anywhere else but 
your dom0. If you got a sys-usb, then your USB controller is likely tied to 
that VM. If you don't have a sys-usb, and you didn't move the USB controller 
yourself, then the USB controller is still likely tied to dom0. The Qubes 
installer can automatically make a sys-usb at first system boot, but it won't 
always do it, for example if the USB controller can't be pass-through or if 
something important is tied to it, like touch devices often are.

Assuming your USB controller is indeed not located in dom0, then I believe your 
issue is actually a split two-part issue. It might be that system sound isn't 
working as you also suggested by being a driver issue, but your second issue is 
that your other soundcard, which is based on USB, won't work because you got 
your USB controller in sys-sub, and if the sound is passed to the sys-usb from 
your USB soundcard, then it can't communicate with your speakers since it's cut 
off from dom0. There is a small adjustment, which I haven't tried my self, that 
can make this work. See the link below for the official method to do this.

https://www.qubes-os.org/doc/external-audio/

I'm not 100% sure, but this

Re: [qubes-users] Anonymizing your MAC Address with macchanger and scripts

2018-02-28 Thread 'awokd' via qubes-users

On Wed, February 28, 2018 6:34 pm, Chris Laprise wrote:
> On 02/28/2018 11:31 AM, klausdiet...@mail2tor.com wrote:
>
>> Hey guys,
>>
>>
>> i have a big problem with "Anonymizing your MAC Address with macchanger
>>  and scripts". I used this Tutorial on the Qubes Doc:
>> https://www.qubes-os.org/doc/anonymizing-your-mac-address/
>>
>
> Hi,
>
>
> The macchanger section of the doc hasn't worked for a long time (search
> the mailing list to see issues) and it never did work correctly, IMO.
>

Should it be deleted? I can put in a PR, but that won't leave much left on
that doc. Should what's left work on 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/291b23e0548f10b6c2c9a9c025f9ad48.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Anonymizing your MAC Address with macchanger and scripts


On 02/28/2018 11:31 AM, klausdiet...@mail2tor.com wrote:

Hey guys,

i have a big problem with "Anonymizing your MAC Address with macchanger
and scripts". I used this Tutorial on the Qubes Doc:
https://www.qubes-os.org/doc/anonymizing-your-mac-address/


Hi,

The macchanger section of the doc hasn't worked for a long time (search 
the mailing list to see issues) and it never did work correctly, IMO.



What should i do?



You should use the MAC randomization feature integrated into Network 
Manager, shown at the beginning of the doc.


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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/5889aec9-7b15-0537-db74-f4ffbe54f938%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Dom0 connectivity for maintenance

On Wednesday, February 28, 2018 at 7:10:33 PM UTC+1, Braden wrote:
> On Wednesday, February 28, 2018 at 12:50:23 PM UTC-5, Unman wrote:
> > On Wed, Feb 28, 2018 at 09:48:43AM -0800, Yuraeitha wrote:
> > > On Wednesday, February 28, 2018 at 6:38:49 PM UTC+1, Unman wrote:
> > > > On Wed, Feb 28, 2018 at 08:52:07AM -0800, Braden wrote:
> > > > > Performing some modifications to dom0, but when I run apps like wget 
> > > > > from dom0 terminal I am unable to resolve addresses. Same if I were 
> > > > > to try running firefox from dom0. Know this is because of security 
> > > > > benefits, but how can I enable networking from there. Say I wanted to 
> > > > > connect to dom0 from a vnc temporarily.
> > > > > 
> > > > There's almost never any need to do this. If you want to install
> > > > packages you can use the update mechanism. Otherwise download files in a
> > > > qube and then copy them in to dom0 and install them there.
> > > > If dom0 is compromised then all your qubes are open.
> > > > 
> > > > But you probably know this already.
> > > > 
> > > > As things stand it's difficult, but not impossible to access dom0. You
> > > > could open a channel to allow vnc to a qube and use socat and an rpc
> > > > service to front to dom0. But really just dont do it: it subverts the
> > > > whole point in using Qubes.
> > > 
> > > btw, isn't it possible that he can use the Qubes 4 dom0 admin features to 
> > > make changes to VM's from a remote location? Could the solution be to 
> > > upgrade to Qubes 4 and use that instead? I haven't yet went 
> > > discovering/understood the limitations of the Qubes 4 dom0 admin tools, 
> > > but isn't this a perfect match to his goal if he upgrades? Apologies if I 
> > > misunderstood how the dom0 admin features work, I haven't started using 
> > > it my self yet.
> > > 
> > 
> > Yes, it is.
> > OP could read this post
> > https://www.qubes-os.org/news/2017/06/27/qubes-admin-api/
> My hardware is only 3.2 supported rn as you guessed, suppose I could explore 
> the unique service idea, is there anything similar on *nix

>From a security point of view, Qubes 4 is probably long past the point to 
>surpass the security risk there is to opening up dom0 to networking (if 
>comparing the two situations purely from a security risk point of view). So if 
>you got the time for it, it might be worth it to install Qubes to gain access 
>to the dom0 admin tools. In terms of reliability, well personally I feel Qubes 
>4 is pretty stable, I haven't had any major issues. But they're still working 
>on it, though, I believe it's because they want it to as perfect as possible. 
>It's very different from being ready to release, and to release something near 
>a perfection goal. Well obviously perfection is a dangerous word to use, but 
>it can translated into high quality instead. That's how I perceive it at 
>least. If you got the time, it may be worth upgrading.

Perhaps others may put in a word for how ready they perceive Qubes 4 is for 
productivity and mission critical work. Since it isn't officially released as 
as a final release yet, the more views on this matter, the merrier and more 
accurate it'll be. 

-- 
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/be1bf8de-b80e-46ab-b0c0-5e20e89eb281%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Dom0 connectivity for maintenance

On Wednesday, February 28, 2018 at 12:50:23 PM UTC-5, Unman wrote:
> On Wed, Feb 28, 2018 at 09:48:43AM -0800, Yuraeitha wrote:
> > On Wednesday, February 28, 2018 at 6:38:49 PM UTC+1, Unman wrote:
> > > On Wed, Feb 28, 2018 at 08:52:07AM -0800, Braden wrote:
> > > > Performing some modifications to dom0, but when I run apps like wget 
> > > > from dom0 terminal I am unable to resolve addresses. Same if I were to 
> > > > try running firefox from dom0. Know this is because of security 
> > > > benefits, but how can I enable networking from there. Say I wanted to 
> > > > connect to dom0 from a vnc temporarily.
> > > > 
> > > There's almost never any need to do this. If you want to install
> > > packages you can use the update mechanism. Otherwise download files in a
> > > qube and then copy them in to dom0 and install them there.
> > > If dom0 is compromised then all your qubes are open.
> > > 
> > > But you probably know this already.
> > > 
> > > As things stand it's difficult, but not impossible to access dom0. You
> > > could open a channel to allow vnc to a qube and use socat and an rpc
> > > service to front to dom0. But really just dont do it: it subverts the
> > > whole point in using Qubes.
> > 
> > btw, isn't it possible that he can use the Qubes 4 dom0 admin features to 
> > make changes to VM's from a remote location? Could the solution be to 
> > upgrade to Qubes 4 and use that instead? I haven't yet went 
> > discovering/understood the limitations of the Qubes 4 dom0 admin tools, but 
> > isn't this a perfect match to his goal if he upgrades? Apologies if I 
> > misunderstood how the dom0 admin features work, I haven't started using it 
> > my self yet.
> > 
> 
> Yes, it is.
> OP could read this post
> https://www.qubes-os.org/news/2017/06/27/qubes-admin-api/
My hardware is only 3.2 supported rn as you guessed, suppose I could explore 
the unique service idea, is there anything similar on *nix

-- 
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/e82e49e9-823a-4b81-8e85-db14b5edb6ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Anonymizing your MAC Address with macchanger and scripts

On Wednesday, February 28, 2018 at 5:55:03 PM UTC+1, klausd...@mail2tor.com 
wrote:
> Hey guys,
> 
> i have a big problem with "Anonymizing your MAC Address with macchanger
> and scripts". I used this Tutorial on the Qubes Doc:
> https://www.qubes-os.org/doc/anonymizing-your-mac-address/
> 
> Everytime it happens the same:
> 
> 1) I create the file macspoof@.service with sudo gedit
> /etc/systemd/system/macspoof@.service
> 
> 
> 2) I copie the text in the newly created gedit file:
> 
> [Unit]
> Description=macchanger on %I
> # Hack since macspoof@%i contains @ which is not allowed yet
> ConditionPathExists=/var/run/qubes-service/macspoof-%i
> Wants=network-pre.target
> Before=network-pre.target
> BindsTo=sys-subsystem-net-devices-%i.device
> After=sys-subsystem-net-devices-%i.device
> 
> [Service]
> ExecStart=/usr/bin/macchanger -e %I
> Type=oneshot
> 
> [Install]
> WantedBy=multi-user.target
> 
> 
> 3) In the Fedora Terminal is says:
> 
> [user@fedora-23 ~]$ sudo gedit /etc/systemd/system/macspoof@.service
> 
> (gedit:1029): Gtk-WARNING **: Calling Inhibit failed:
> GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
> org.gnome.SessionManager was not provided by any .service files
> 
> What should i do?

It could be that you're using fedora 23? It's no longer supported, and maybe 
it's unable of talking with the rest of your Qubes system in a proper way, thus 
perhaps that is why it fails for you. Are you sure you keep dom0/templates 
updated in sync with each others? For example your dom0 may be updated, but 
your fedora-23 template isn't since its no longer maintained.

Fedora 24/25 is no good either, you need to go all the way to fedora-26. Fedora 
27 is out too, but it's not fully supported by Qubes yet. So fedora-26 is what 
you want. You can download and install it with "sudo qubes-dom0-update 
qubes-template-fedora-26" <--- it will take a while, especially if you got a 
slow connection or system. Be sure you got plenty of gigabyte space ready for 
it to install on, it'll take a bit more space to install before it shrinks 
again when finished.

Update the template fully, and try perform your script in the fedora-26 
template instead.

Also be sure you change your sys-net and sys-firewall, and other VM's that run 
on out of date and no longer supported templates. You need to fully change all 
of them away from fedora-23, before you can delete the old fedora-23 as well.

-- 
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/d87520ac-fd1f-4e81-bc31-cccfac16c89e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Dom0 connectivity for maintenance

On Wednesday, February 28, 2018 at 6:51:14 PM UTC+1, Braden wrote:
> On Wednesday, February 28, 2018 at 12:50:17 PM UTC-5, Braden wrote:
> > On Wednesday, February 28, 2018 at 12:38:49 PM UTC-5, Unman wrote:
> > > On Wed, Feb 28, 2018 at 08:52:07AM -0800, Braden wrote:
> > > > Performing some modifications to dom0, but when I run apps like wget 
> > > > from dom0 terminal I am unable to resolve addresses. Same if I were to 
> > > > try running firefox from dom0. Know this is because of security 
> > > > benefits, but how can I enable networking from there. Say I wanted to 
> > > > connect to dom0 from a vnc temporarily.
> > > > 
> > > There's almost never any need to do this. If you want to install
> > > packages you can use the update mechanism. Otherwise download files in a
> > > qube and then copy them in to dom0 and install them there.
> > > If dom0 is compromised then all your qubes are open.
> > > 
> > > But you probably know this already.
> > > 
> > > As things stand it's difficult, but not impossible to access dom0. You
> > > could open a channel to allow vnc to a qube and use socat and an rpc
> > > service to front to dom0. But really just dont do it: it subverts the
> > > whole point in using Qubes.
> > 
> > Fair enough, suppose will copy the package to dom0 and then install my vnc 
> > server there, but would the firewall refuse to allow connections just like 
> > how firefox and wget refuse in dom0?
> 
> Only need VNC client connections working that is

Is VNC capable of something that can't be done with the Qubes 4 dom0/admin 
tools? Just curious, maybe it can be solved.

-- 
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/d0f68731-3750-4ad4-bc00-d8b193b770f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Dom0 connectivity for maintenance

2018-02-28 Thread 'awokd' via qubes-users

On Wed, February 28, 2018 5:53 pm, Unman wrote:

>
> By design dom0 has no networking.
> If you MUST break Qubes , and you cant use the admin features in 4.0
> (see my last post),then you'll have to use some service to pass data in
> and out of dom0 WITHOUT networking.

Another option for remote access might be a TCP/IP based hardware KVM, or
equivalent built in to your computer already like IPMI or DRAC. Obviously,
Qubes can't provide any security beyond a screensaver password from an
attack using those.



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

Re: [qubes-users] Dom0 connectivity for maintenance

2018-02-28 Thread Unman

On Wed, Feb 28, 2018 at 09:50:17AM -0800, Braden wrote:
> On Wednesday, February 28, 2018 at 12:38:49 PM UTC-5, Unman wrote:
> > On Wed, Feb 28, 2018 at 08:52:07AM -0800, Braden wrote:
> > > Performing some modifications to dom0, but when I run apps like wget from 
> > > dom0 terminal I am unable to resolve addresses. Same if I were to try 
> > > running firefox from dom0. Know this is because of security benefits, but 
> > > how can I enable networking from there. Say I wanted to connect to dom0 
> > > from a vnc temporarily.
> > > 
> > There's almost never any need to do this. If you want to install
> > packages you can use the update mechanism. Otherwise download files in a
> > qube and then copy them in to dom0 and install them there.
> > If dom0 is compromised then all your qubes are open.
> > 
> > But you probably know this already.
> > 
> > As things stand it's difficult, but not impossible to access dom0. You
> > could open a channel to allow vnc to a qube and use socat and an rpc
> > service to front to dom0. But really just dont do it: it subverts the
> > whole point in using Qubes.
> 
> Fair enough, suppose will copy the package to dom0 and then install my vnc 
> server there, but would the firewall refuse to allow connections just like 
> how firefox and wget refuse in dom0?
> 

By design dom0 has no networking.
If you MUST break Qubes , and you cant use the admin features in 4.0
(see my last post),then you'll have to use some service to pass data in
and out of dom0 WITHOUT networking.


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

Re: [qubes-users] Dom0 connectivity for maintenance

On Wednesday, February 28, 2018 at 12:50:17 PM UTC-5, Braden wrote:
> On Wednesday, February 28, 2018 at 12:38:49 PM UTC-5, Unman wrote:
> > On Wed, Feb 28, 2018 at 08:52:07AM -0800, Braden wrote:
> > > Performing some modifications to dom0, but when I run apps like wget from 
> > > dom0 terminal I am unable to resolve addresses. Same if I were to try 
> > > running firefox from dom0. Know this is because of security benefits, but 
> > > how can I enable networking from there. Say I wanted to connect to dom0 
> > > from a vnc temporarily.
> > > 
> > There's almost never any need to do this. If you want to install
> > packages you can use the update mechanism. Otherwise download files in a
> > qube and then copy them in to dom0 and install them there.
> > If dom0 is compromised then all your qubes are open.
> > 
> > But you probably know this already.
> > 
> > As things stand it's difficult, but not impossible to access dom0. You
> > could open a channel to allow vnc to a qube and use socat and an rpc
> > service to front to dom0. But really just dont do it: it subverts the
> > whole point in using Qubes.
> 
> Fair enough, suppose will copy the package to dom0 and then install my vnc 
> server there, but would the firewall refuse to allow connections just like 
> how firefox and wget refuse in dom0?

Only need VNC client connections working that is

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/75ce23b7-1350-473c-b89c-2ceb75274e7c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Dom0 connectivity for maintenance

2018-02-28 Thread Unman

On Wed, Feb 28, 2018 at 09:48:43AM -0800, Yuraeitha wrote:
> On Wednesday, February 28, 2018 at 6:38:49 PM UTC+1, Unman wrote:
> > On Wed, Feb 28, 2018 at 08:52:07AM -0800, Braden wrote:
> > > Performing some modifications to dom0, but when I run apps like wget from 
> > > dom0 terminal I am unable to resolve addresses. Same if I were to try 
> > > running firefox from dom0. Know this is because of security benefits, but 
> > > how can I enable networking from there. Say I wanted to connect to dom0 
> > > from a vnc temporarily.
> > > 
> > There's almost never any need to do this. If you want to install
> > packages you can use the update mechanism. Otherwise download files in a
> > qube and then copy them in to dom0 and install them there.
> > If dom0 is compromised then all your qubes are open.
> > 
> > But you probably know this already.
> > 
> > As things stand it's difficult, but not impossible to access dom0. You
> > could open a channel to allow vnc to a qube and use socat and an rpc
> > service to front to dom0. But really just dont do it: it subverts the
> > whole point in using Qubes.
> 
> btw, isn't it possible that he can use the Qubes 4 dom0 admin features to 
> make changes to VM's from a remote location? Could the solution be to upgrade 
> to Qubes 4 and use that instead? I haven't yet went discovering/understood 
> the limitations of the Qubes 4 dom0 admin tools, but isn't this a perfect 
> match to his goal if he upgrades? Apologies if I misunderstood how the dom0 
> admin features work, I haven't started using it my self yet.
> 

Yes, it is.
OP could read this post
https://www.qubes-os.org/news/2017/06/27/qubes-admin-api/

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

Re: [qubes-users] Dom0 connectivity for maintenance

On Wednesday, February 28, 2018 at 6:38:49 PM UTC+1, Unman wrote:
> On Wed, Feb 28, 2018 at 08:52:07AM -0800, Braden wrote:
> > Performing some modifications to dom0, but when I run apps like wget from 
> > dom0 terminal I am unable to resolve addresses. Same if I were to try 
> > running firefox from dom0. Know this is because of security benefits, but 
> > how can I enable networking from there. Say I wanted to connect to dom0 
> > from a vnc temporarily.
> > 
> There's almost never any need to do this. If you want to install
> packages you can use the update mechanism. Otherwise download files in a
> qube and then copy them in to dom0 and install them there.
> If dom0 is compromised then all your qubes are open.
> 
> But you probably know this already.
> 
> As things stand it's difficult, but not impossible to access dom0. You
> could open a channel to allow vnc to a qube and use socat and an rpc
> service to front to dom0. But really just dont do it: it subverts the
> whole point in using Qubes.

btw, isn't it possible that he can use the Qubes 4 dom0 admin features to make 
changes to VM's from a remote location? Could the solution be to upgrade to 
Qubes 4 and use that instead? I haven't yet went discovering/understood the 
limitations of the Qubes 4 dom0 admin tools, but isn't this a perfect match to 
his goal if he upgrades? Apologies if I misunderstood how the dom0 admin 
features work, I haven't started using it my self 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/ae2f8296-7702-4db2-a327-b73bda521016%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: firewall/proxy VM not working with Qubes 4.0-rc4

2018-02-28 Thread thorsten . schierer

> Could you try this:
> qvm-prefs sys-firewall | grep netvm
> it should say sys-net? Y/N

yes, result is sys-net


> Even if it states sys-net, let's try to force it again
> qvm-prefs sys-firewall -s netvm sys-net

that command did not work due to wrong syntax, so I did:

qvm-prefs --set sys-firewall netvm sys-net

If sys-firewall is shut down, the command works.
If sys-firewall is running, the command fails with the error:
"no such preoperty: 'netvm'", in addition if sys-firewall is running while I do 
this, the eth0 interface is removed from sys-firewall.


> and try the arp -an in sys-firewall again

Still the same result:
? (10.137.0.5) at  on eth0

Maybe I should try to look into the script(s) that are running when using 
"qvm-prefs --set sys-firewall netvm sys-net"?

-- 
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/72a9400d-c705-4360-b0c1-b55afe3a496d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Dom0 connectivity for maintenance

2018-02-28 Thread Unman

On Wed, Feb 28, 2018 at 08:52:07AM -0800, Braden wrote:
> Performing some modifications to dom0, but when I run apps like wget from 
> dom0 terminal I am unable to resolve addresses. Same if I were to try running 
> firefox from dom0. Know this is because of security benefits, but how can I 
> enable networking from there. Say I wanted to connect to dom0 from a vnc 
> temporarily.
> 
There's almost never any need to do this. If you want to install
packages you can use the update mechanism. Otherwise download files in a
qube and then copy them in to dom0 and install them there.
If dom0 is compromised then all your qubes are open.

But you probably know this already.

As things stand it's difficult, but not impossible to access dom0. You
could open a channel to allow vnc to a qube and use socat and an rpc
service to front to dom0. But really just dont do it: it subverts the
whole point in using 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/20180228173843.q24zbrs6csjrue7w%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Dom0 connectivity for maintenance

On Wednesday, February 28, 2018 at 12:11:34 PM UTC-5, Yuraeitha wrote:
> On Wednesday, February 28, 2018 at 5:52:07 PM UTC+1, Braden wrote:
> > Performing some modifications to dom0, but when I run apps like wget from 
> > dom0 terminal I am unable to resolve addresses. Same if I were to try 
> > running firefox from dom0. Know this is because of security benefits, but 
> > how can I enable networking from there. Say I wanted to connect to dom0 
> > from a vnc temporarily.
> 
> I also believe you can just add the extra repository to make dom0 
> install/update in a secure way, without attaching the network directly to 
> dom0. But as mentioned above, first, what is it you actually want to do?

Understandable, I'd need to install a VNC into dom0 so I can easily change hvms 
and appvm settings from work, so how should I go about attaching the network. 

-- 
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/b2ed9145-6b74-4cbb-9eba-f34548bd9c66%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Dom0 connectivity for maintenance

On Wednesday, February 28, 2018 at 5:52:07 PM UTC+1, Braden wrote:
> Performing some modifications to dom0, but when I run apps like wget from 
> dom0 terminal I am unable to resolve addresses. Same if I were to try running 
> firefox from dom0. Know this is because of security benefits, but how can I 
> enable networking from there. Say I wanted to connect to dom0 from a vnc 
> temporarily.

I also believe you can just add the extra repository to make dom0 
install/update in a secure way, without attaching the network directly to dom0. 
But as mentioned above, first, what is it you actually want to do?

-- 
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/98cf3860-685f-4d1b-9562-b11ad62dfebe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Dom0 connectivity for maintenance

On Wednesday, February 28, 2018 at 5:52:07 PM UTC+1, Braden wrote:
> Performing some modifications to dom0, but when I run apps like wget from 
> dom0 terminal I am unable to resolve addresses. Same if I were to try running 
> firefox from dom0. Know this is because of security benefits, but how can I 
> enable networking from there. Say I wanted to connect to dom0 from a vnc 
> temporarily.

I think this might be possible without too much trouble, but before that, what 
is it you want to install in dom0? Are you sure you can't use existing means or 
do it from an AppVM? 

For example if you need htop or something else in the fedora repositories, you 
can do "sudo qubes-dom0-update htop" which will install htop in dom0. Same with 
everything else in fedora repositories.

What kind of program is it you need to install in dom0? The general notion is 
that its best to not install anything there at all, which becomes a stronger 
and stronger reinforced point at every new Qubes released version, when less 
and less is needed to be done in dom0. 

Does what you want to archive have to be in dom0 to get it working? 
Is it possible you can tell us what you want to archive/install? There might be 
other/better ways to do it. 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0560b097-2dc2-41bd-8c0e-104d2c215cda%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Anonymizing your MAC Address with macchanger and scripts

2018-02-28 Thread KlausDieter2

Hey guys,

i have a big problem with "Anonymizing your MAC Address with macchanger
and scripts". I used this Tutorial on the Qubes Doc:
https://www.qubes-os.org/doc/anonymizing-your-mac-address/

Everytime it happens the same:

1) I create the file macspoof@.service with sudo gedit
/etc/systemd/system/macspoof@.service


2) I copie the text in the newly created gedit file:

[Unit]
Description=macchanger on %I
# Hack since macspoof@%i contains @ which is not allowed yet
ConditionPathExists=/var/run/qubes-service/macspoof-%i
Wants=network-pre.target
Before=network-pre.target
BindsTo=sys-subsystem-net-devices-%i.device
After=sys-subsystem-net-devices-%i.device

[Service]
ExecStart=/usr/bin/macchanger -e %I
Type=oneshot

[Install]
WantedBy=multi-user.target


3) In the Fedora Terminal is says:

[user@fedora-23 ~]$ sudo gedit /etc/systemd/system/macspoof@.service

(gedit:1029): Gtk-WARNING **: Calling Inhibit failed:
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
org.gnome.SessionManager was not provided by any .service files

What should i do?

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

Re: Re: Re: AW: Re: [qubes-users] Installing Chrome

On Tuesday, February 27, 2018 at 11:16:46 PM UTC+1, [799] wrote:
> Hello Yuraeitha,
> 
> Thanks for the clarification, I think we share some common values.
> 
> 
> 
> -- 
> Qubes 4rc3 > Lenovo X230 + Lenovo W540
> 
> Gesendet von ProtonMail mobile
> 
> 
> 
> 
>  Original-Nachricht 
> An 27. Feb. 2018, 02:48, Yuraeitha schrieb:
> 
> 
> 
> > Okay I may have come on a bit strong worded,
> > I apologize that I ended up being rude.
> > Nevertheless I'm not reclaiming my criticism
> > before convinced otherwise. 
> 
> Thanks for the reply, as always in written communication it's sometimes hard 
> to read the intention by just reading the words.
> 
> 
> > I definitely have projects I'm working on, such
> > as QubesTV, QubesNAS, Qubes update script,
> > Qubes screenshot scripts, etc. 
> 
> If possible share it, I am heavily interested in a better screenshot solution 
> and come up with a first prototype to be able to copy a screenshot (made in 
> dom0) into the clipboard of a predefined AppVM.
> (Search for qvm-screenshot-to-clipboard on GitHub)
> Warning: it is a working solution but currently without any error handling, 
> happy to hear feedback from a security view as I am far away from being an 
> expert there.
> 
> > My beef with this is that Qubes is about being
> > open source, decentralization (Qubes Air
> > which was planned almost a decade ago
> > now), retaining control of ones own system,
> > etc. If there are just as good open source
> > solutions, or even nearly just as good ones,
> > then these should be mentioned and
> > included. 
> 
> I totally agree and that is what I am doing  everyday when I talk to my 
> "enterprise" customers when the decide to use windows or VMware just because 
> it is "more of an enterprise solution" (mainly because it costs money :-/).
> Of course I don't agree with this argument.
> Open Source is great, and if I would have known about an open source solution 
> I would have mention this.
> 
> > While sure Qubes is primarily about security
> > and less focused about privacy, but Qubes is
> > also about open source and retaining control
> > of your system.
> 
> Agreed and I think that you can still gain privacy and security benefits when 
> using "closed source" solution with Qubes just by using different Qubes.
> Let me put it this way, if I am really concerned about privacy I would not 
> use Amazon Prime/Netflix at all because you become very transparent when 
> someone knows what you are watching/reading and when.
> 
> > To put this straight, I don't care if users can
> > just choose to do something else, the fact
> > that it's not following the spirit of what Qubes
> > is all about, is what I care about.
> 
> Understand you point, still I think that every person who is using Linux or 
> even better Qubes is a large win as more people learn that there are 
> alternatives.
> Maybe the use Linux and Chrome in the beginning and some day companies see 
> that there is a critical mass, so that it makes sense to develop cross 
> platform solution.
> I don't expect that every company has to go open source, maybe because they 
> want to protect their ownership/development costs. But I would like to use 
> their software on my Operation System of choice.
> So the biggest topic is not that I have to use closed source/proprietary 
> software but that I need to sacrifice lots of features  when working in the 
> classic "enterprise app" environment.
> Example:
> 
> Our ERP System, Our CTI Application (ESTOS), Cisco WebEx/Cisco Jabber/Spark, 
> Microsoft Office/Outlook, our main IT Service Tool (Remote Desktop Manager) 
> are mainly running on top of of Windows, some offer a limited feature set 
> when using web-alternatives, but there are no native Linux Apps, which is 
> shame.
> I am running Qubes OS as primary OS but it is (for my job role) impossible 
> without using Windows or other closed source apps.
> That's also why I really hope to see ongoing Windows AppVM support in Qubes 
> which I honestly think is a major feature being able to run Qubes.
> 
> > (...) I also enjoy discussions trying to reach a
> > common shared ground. That's what
> > discussions are all about to begin with after
> > all. 
> 
> Agreed.
> 
> [799]

I'm glad that we're on good terms again, it's been bothering me a lot since I 
made that mistake. You make a good point that it can be hard to read peoples 
intends in written communication too, with the lack of body language and voice, 
dynamic communication and such, I definitely agree. Although I could have 
written that much better by not making that mistake, so it's still my fault 
even so, I will have to learn from that experience.

I can relate with the Windows issues, I've recently become fully Linux (Qubes) 
by finally becoming fully accustomed when I ditched MS-Office for LibreOffice 
(I couldn't do that for years, but finally made it fully across), which was my 
last nail in the Microsoft coffin. But I still have friends, and the

[qubes-users] Dom0 connectivity for maintenance

Performing some modifications to dom0, but when I run apps like wget from dom0 
terminal I am unable to resolve addresses. Same if I were to try running 
firefox from dom0. Know this is because of security benefits, but how can I 
enable networking from there. Say I wanted to connect to dom0 from a vnc 
temporarily.

-- 
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/431b70dd-8c1d-4cb8-aa7e-1c62fe17b6ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Clearing qubes-dom0-cached packages