date:20170311

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

--
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/a9f0d538-cf8e-8941-2ba8-fe12a45fc73d%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Tip: Adding arbitrary apps to DispVM Applications menu

2017-03-11 Thread Ted Brenner

When searching Google or Duck Duck Go, the docs come up on top. So I think
putting things in the docs is a good idea. The list is nice as a fall back
but then you have to sift through a whole chain and piece together the
answer. Much better to have the final "this is how you do X" in the docs.

On Sat, Mar 11, 2017 at 5:15 PM, Unman  wrote:

> On Sat, Mar 11, 2017 at 01:34:19PM -0800, Andrew David Wong wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > On 2017-03-11 09:31, Grzesiek Chodzicki wrote:
> > > How to add custom applications to DispVM appmenu:
> > >
> > > 1. Install the required app in the TemplateVM upon which your DispVM
> depends (fedora-23/24 by default)
> > > 2. Shutdown the TemplateVM
> > > 3. In Dom0 run qvm-create-default-dvm 
> > > 4. At this point your app can be launched in DispVM, to confirm launch
> Xterm in DispVM and start your app from there. Now we are going to add an
> entry for it in the Applications menu
> > > 5. Go to /usr/local/share/applications
> > > 6. Create a new .desktop file for your app using following (example)
> syntax:
> > >
> > > [Desktop Entry]
> > > Version=1.0
> > > Type=Application
> > > Exec=sh -c 'echo  | /usr/lib/qubes/qfile-daemon-dvm
> qubes.VMShell dom0 DEFAULT red'
> > > Icon=dispvm-red
> > > Terminal=false
> > > Name=DispVM: 
> > > GenericName=DispVM: 
> > > StartupNotify=false
> > > Categories=Network;X-Qubes-VM;
> > >
> > > 7. go to /etc/xdg/menus/applications-merged
> > > 8. Edit the qubes-dispvm.menu using any editor
> > > 9. Under  add another line containing the name of your
> .desktop file (so it looks like this):
> > >
> > > 
> > > qubes-dispvm-firefox.desktop
> > > qubes-dispvm-xterm.desktop
> > > yourdesktopfilehere
> > > 
> > >
> > > 10. Your custom menu entry should appear on the Applications list now
> > >
> > > Andrew - Frankly, this should be available within the GUI, should I
> add that to Documentation and/or create a ticket?
> > >
> >
> > Please feel free to do so.
> >
> > - --
> > Andrew David Wong (Axon)
>
> It would be useful to extend it to kde users, since that is also
> currently supported.
>
> I'm not sure that this should be added to the GUI: for those who use
> multiple DVMTemplates now, (and that's coming in 4), you will have to
> customise the menu on a per DVMTemplate basis. I think there's a good
> deal to be considered first.
>
> Is this to be a tip for the docs? I think there's a danger that they are
> becoming difficult to navigate as is, despite Andrew's efforts.
> I meant to chip in on the other thread, but I would prefer to see them
> remain in the lists - the format of this one is excellent.
>
> Of course, one has to weigh up where puzzled users will look - do you
> think they search the documentation, look through the lists (we could
> link to search results with "Tip:", search the lists or just ask
> straight off.
> I don't have any feeling as to which is most likely to be found. Andrew?
>
> unman
>
>
> --
> 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/20170311231524.GB25808%40thirdeyesecurity.org.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Sent from my Desktop

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

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

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.

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

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

On Saturday, March 11, 2017 at 8:48:27 PM UTC-5, Chris Laprise wrote:
> On 03/11/2017 10:50 AM, cooloutac wrote:
> > I have always felt any level of security is useful no matter how trivial to 
> > bypass.
> >
> > But I think the decision here for passwordless sudo is not cause privilege 
> > escalation or non root persistence is trivial.  Its because people like my 
> > mother are not gonna constantly type their password in dozens of vms, or to 
> > update half a dozen templates, all for a layer of security thats considered 
> > meaningless to Qubes threat model.  In qubes usability is more a factor.
> >
> > Maybe password for sudo should be an option for people who want it.
> 
> Passwords are not required for sudo authentication:
> 
> https://www.qubes-os.org/doc/vm-sudo/
> 
> This works like file-copying between VMs... you get a Yes/No prompt in 
> dom0. And you can have it default to either Yes or No. Anyone could use 
> it and I suggest you give it a try!
> 
> -- 
> 
> Chris Laprise, tas...@openmailbox.org
> https://twitter.com/ttaskett

oh ok,I'm just a noob so I thought the opposite of a "passwordless sudo"  was 
one with a password lol

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

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.

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.

-- 
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/5800ef8d-b303-481c-afa5-4b9c6d496a66%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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


On 03/11/2017 10:50 AM, cooloutac wrote:

I have always felt any level of security is useful no matter how trivial to 
bypass.

But I think the decision here for passwordless sudo is not cause privilege 
escalation or non root persistence is trivial.  Its because people like my 
mother are not gonna constantly type their password in dozens of vms, or to 
update half a dozen templates, all for a layer of security thats considered 
meaningless to Qubes threat model.  In qubes usability is more a factor.

Maybe password for sudo should be an option for people who want it.


Passwords are not required for sudo authentication:

https://www.qubes-os.org/doc/vm-sudo/

This works like file-copying between VMs... you get a Yes/No prompt in 
dom0. And you can have it default to either Yes or No. Anyone could use 
it and I suggest you give it a try!


--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett

--
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/e431e3eb-d890-0d13-16da-2af3797937c9%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

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

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.

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett

--
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/f2e5863e-b25c-0b12-843b-d9a20fb1710c%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

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

On 03/11/2017 12:15 PM, Unman wrote:

The answer to this is encouraging users to make good use of isolation,
qube use and Qubes features. That isnt irresponsible. It's a way of
dealing with the problem. I think you would need to develop a much more
detailed argument to convince me that the answer to malware infections
is putting a password on root access.

I didn't purport to provide "the answer"... strawman argument.

What it comes down to is a matter of degrees and costs.

There was no straw man argument here - you raised the issue of "malware
zoos" in the context of a discussion of passwordless sudo - it's
natural to think that you see it as an answer. I cant see it plays any
role.

Your language had portrayed it as a binary choice about which practice
provides "THE answer". That misrepresents the argument being made.

And the zoo analogy holds up pretty well if you accept that zoos are
places where animals are kept under less-than ideal circumstances, but
nevertheless indefinitely.

This is particularly so given your suggestion that the root access
"remembers auth for a certain amount of time" - decent targeted
attacks would have a stub firing to check if sudo was enabled every
few minutes, and would hit the target of opportunity you have opened
for them.

Its not a "suggestion". Its the way sudo works if you change a few
settings according to the vm-sudo doc. :)

The timeout default can be changed easily enough (can be made zero).

A separate shell process would have to get authorization separately, so
the attack you imagine probably wouldn't work there. To be in the same
shell, the attacker would first have to alter a bash startup file, but
these can be easily protected.

Remember, many people pick distros based on the default security and how
smoothly they work with security enhancements. This holds as much for
shell configuration as for other factors. The idea behind this is to use
the security settings that come with the OS, whether that be Debian,
Fedora, Ubuntu or Arch, etc. That makes a better starting point as we
explore options like apparmor and grsecurity (features normally
available in the above distros).

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett

--
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/bc8128a1-dfab-f91f-ce3c-87179eecfe47%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] The qubes-core.service and qubes-qmemman.service only works in fedora-23?

2017-03-11 Thread 'Temporary Madness' via qubes-users

It does not matter if I download the fedora-24 template from qubes-dom0-update 
or if I upgrade it manually (or upgrade to fedora-25). I still get the same 
result. The qubes-core.service and qubes-qmemman.service are not to be loaded 
nor to be found. 

Is this an error or is it designed this way? Both services where found and 
running in the fedora-23 template. (The output from systemctl fedora-23 are at 
the bottom of the post)

I got a tip from a fellow at the IRC channel to enable the 
qubes-vm-r3.2-current-testing repository and do an update. And it installed the 
latest rpm:s including qubes-core-vm, which I assume are related to 
qubes-core?. I restarted the newly updated fedora-24 template and nothing had 
changed, the two services where still dead.
I have not noticed any changes in performance or functionality, but this still 
bugs me.  

I cloned the fedora 23 template again and enabled the current-testing 
repository before updating a second time, but still the same result.

[user@fedora-24-1 ~]$ sudo systemctl -all | grep qubes
  usr-lib-modules-4.4.38\x2d11.pvops.qubes.x86_64.mount   
loadedactive mounted   /usr/lib/modules/4.4.38-11.pvops.qubes.x86_64
● qubes-core.service  
not-found inactive   dead  qubes-core.service
  qubes-db.service
loadedactive running   Qubes DB agent
  qubes-dvm.service   
loadedinactive   dead  Prepare Qubes DispVM Template
  qubes-early-vm-config.service   
loadedactive exitedEarly Qubes VM settings
  qubes-firewall.service  
loadedinactive   dead  Qubes firewall updater
  qubes-gui-agent.service 
loadedactive running   Qubes GUI Agent
  qubes-iptables.service  
loadedactive exitedQubes base firewall settings
  qubes-meminfo-writer-dom0.service   
loadedinactive   dead  Qubes memory information reporter
  qubes-meminfo-writer.service
loadedactive running   Qubes memory information reporter
  qubes-misc-post.service 
loadedactive exitedQubes misc post-boot actions
  qubes-mount-dirs.service
loadedactive exitedInitialize and mount /rw and /home
  qubes-netwatcher.service
loadedinactive   dead  Qubes network monitor
  qubes-network.service   
loadedinactive   dead  Qubes network forwarding setup
● qubes-qmemman.service   
not-found inactive   dead  qubes-qmemman.service
  qubes-qrexec-agent.service  
loadedactive running   Qubes remote exec agent
  qubes-sysinit.service   
loadedactive exitedInit Qubes Services settings
  qubes-update-check.service  
loadedinactive   dead  Qubes check for VM updates and notify dom0
  qubes-updates-proxy.service 
loadedinactive   dead  Qubes updates proxy (tinyproxy)
  qubes-update-check.timer
loadedactive waiting   Periodically check for updates
[user@fedora-24-1 ~]$ sudo systemctl status qubes-core.service 
● qubes-core.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)
[user@fedora-24-1 ~]$ sudo systemctl status qubes-qmemman.service 
● qubes-qmemman.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

I've manage to see some errors during the update which where related to the 
system not having the right charsets (something about UTF-8, can't find it in 
the log files right now, sorry) available when installing the qubes-core-vm 
package. And I found this in the dnf.rpm.log file(or is it totally unrelated?):
INFO Installed: glibc-all-langpacks-2.23.1-11.fc24.x86_64
ERROR Non-fatal  scriptlet failure in rpm package glibc
ERROR Non-fatal  scriptlet failure in rpm package glibc

So my suspicions where focused on that the system did not contained all the 
charsets needed(?). I installed glibc-locale-source and started to prepare for 
a fedora-25 update. To see if the qubes-core and qubes-qmemman got loaded after 
the install. There where no errors on glibc-all-langpacks while upgrading.
So I guess the source package fi

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

On Sat, Mar 11, 2017 at 01:10:32PM -0800, Daniel Moerner wrote:
> On Friday, March 10, 2017 at 9:55:08 PM UTC-5, Unman wrote:
> > So yes, in a very real sense, it doesn't matter
> > to me if the qube where I collect mail, (which isn't the qube where I
> > read it) is compromised in some way.
> 
> Hi Unman,
> 
> Could you explain your setup for collecting mail in one Qube and reading it 
> in another? I currently use Qubes for each mail account, running mutt and 
> offlineimap, and opening links in disposable VMs. But collecting mail in one 
> Qube and reading it in another is interesting to me.
> 
> Daniel
> 

Hello Daniel

It was interesting to see someone else in the thread refer to a
similar setup. (Look at 7v5w7go9ub0o earlier.) They use a disposableVM to
process the mail.

I use a number of different mail servers: like you I use mutt and
offlineimap,(and rsync and notmuch). 
I use mini templates in different flavours, mailcaps to open files in
disposableVMs. (Lots of people will hate everything about this.) I use
more than one TorVM.

I have multiple dispVMTemplates, some online and some not. A mail
archive is not network connected and is based on a mini template.
Like 7v5w7go9ub0o I use simple scripting - fire up disposableVM, run
rsync/offlineimap, qvm-move mailfile in to reader. Process mail, with any
attachments opened in disposableVM, as you do, using Split GPG.
Outgoing mail is copied to a mailqueue in another qube, and sent from
there.

As far as use is concerned, it just feels like any other mutt
session. Everything is scripted, (and tied together with bits of
string) but it works. The only difference from what you are doing is that
your mutt qube is network connected. and mine isn't.

Of course, in other cases I'll ssh to a box and use mail from there -
or use some webmail - that's straight forward 

I'm sure there are many users doing something similar.

unman

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

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

On Saturday, March 11, 2017 at 11:46:24 AM UTC-5, Unman wrote:
> On Sat, Mar 11, 2017 at 08:00:33AM -0800, cooloutac wrote:
> > On Saturday, March 11, 2017 at 10:37:18 AM UTC-5, evo wrote:
> > > Hey,
> > > 
> > > how can i change the template VM (from fedora to debian) in terminal of
> > > dom0?
> > 
> > in the qubes-manager you can right lick a vm and select vm settings.
> > 
> 
> In TERMINAL:
> qvm-prefs  template -s 
> 
> qvm-prefs is very useful.
oh sorry didn't realize you said terminal.

-- 
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/7dd37e04-3033-43f6-b8e7-a3b149370444%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Tip: Adding arbitrary apps to DispVM Applications menu

On Sat, Mar 11, 2017 at 01:34:19PM -0800, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 2017-03-11 09:31, Grzesiek Chodzicki wrote:
> > How to add custom applications to DispVM appmenu:
> > 
> > 1. Install the required app in the TemplateVM upon which your DispVM 
> > depends (fedora-23/24 by default)
> > 2. Shutdown the TemplateVM
> > 3. In Dom0 run qvm-create-default-dvm 
> > 4. At this point your app can be launched in DispVM, to confirm launch 
> > Xterm in DispVM and start your app from there. Now we are going to add an 
> > entry for it in the Applications menu
> > 5. Go to /usr/local/share/applications
> > 6. Create a new .desktop file for your app using following (example) syntax:
> > 
> > [Desktop Entry]
> > Version=1.0
> > Type=Application
> > Exec=sh -c 'echo  | /usr/lib/qubes/qfile-daemon-dvm 
> > qubes.VMShell dom0 DEFAULT red'
> > Icon=dispvm-red
> > Terminal=false
> > Name=DispVM: 
> > GenericName=DispVM: 
> > StartupNotify=false
> > Categories=Network;X-Qubes-VM;
> > 
> > 7. go to /etc/xdg/menus/applications-merged
> > 8. Edit the qubes-dispvm.menu using any editor
> > 9. Under  add another line containing the name of your .desktop 
> > file (so it looks like this):
> > 
> > 
> > qubes-dispvm-firefox.desktop
> > qubes-dispvm-xterm.desktop
> > yourdesktopfilehere
> > 
> > 
> > 10. Your custom menu entry should appear on the Applications list now
> > 
> > Andrew - Frankly, this should be available within the GUI, should I add 
> > that to Documentation and/or create a ticket?
> > 
> 
> Please feel free to do so.
> 
> - -- 
> Andrew David Wong (Axon)

It would be useful to extend it to kde users, since that is also
currently supported.

I'm not sure that this should be added to the GUI: for those who use
multiple DVMTemplates now, (and that's coming in 4), you will have to
customise the menu on a per DVMTemplate basis. I think there's a good
deal to be considered first.

Is this to be a tip for the docs? I think there's a danger that they are
becoming difficult to navigate as is, despite Andrew's efforts.
I meant to chip in on the other thread, but I would prefer to see them
remain in the lists - the format of this one is excellent.

Of course, one has to weigh up where puzzled users will look - do you
think they search the documentation, look through the lists (we could
link to search results with "Tip:", search the lists or just ask
straight off.
I don't have any feeling as to which is most likely to be found. Andrew?

unman


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

Re: [qubes-users] DNS

On Sat, Mar 11, 2017 at 10:05:50PM +0100, 'Antoine' via qubes-users wrote:
> On Thu, Mar 09, 2017 at 12:30:21AM +, Unman wrote:
> > > > > > >> https://github.com/QubesOS/qubes-issues/issues/2674
> > > > > I have the same problem with Fedora 23, Debian 8 and Debian 9:
> > > > > 
> > > > > = Fedora 23 =
> > > > > [user@work ~]$ grep PRETTY /etc/os-release 
> > > > > PRETTY_NAME="Fedora 23 (Workstation Edition)"
> > > > > [user@work ~]$ cat /etc/resolv.conf 
> > > > > nameserver 10.137.2.1
> > > > > nameserver 10.137.2.254
> > > > > [user@work ~]$ dig +short gov.uk @10.137.2.1
> > > > > 23.235.33.144
> > > > > 23.235.37.144
> > > > > [user@work ~]$ dig +short gov.uk @10.137.2.254
> > > > > ;; connection timed out; no servers could be reached
> > > I have understood why I have this problem.
> > > 
> > > On my LAN, the DNS recursive server (unbound) has a blacklist: it
> > > refuses to answer queries for tracking/ad domains. The problem is that
> > > when a program receives a "REFUSED" packet from its DNS query, it tries
> > > to solve the same host on the second DNS server in resolv.conf.
> > > 
> > > I can see the pattern clearly using tcpdump: Query -> fast answer
> > > REFUSED -> Query on the second DNS server -> no answer.
> > > 
> > > On the DNS resolver:
> > > # grep facebook unbound-blacklist.conf 
> > > local-zone: "facebook.com" refuse
> > > 
> > > on any Qubes VM:
> > > $ host facebook.com 10.137.2.1
> > > Using domain server:
> > > Name: 10.137.2.1
> > > Address: 10.137.2.1#53
> > > Aliases: 
> > > 
> > > Host facebook.com not found: 5(REFUSED)
> > > $ host facebook.com 10.137.2.254
> > > [... 10s ...]
> > > ;; connection timed out; no servers could be reached
> > > $ host facebook.com
> > > Host facebook.com not found: 5(REFUSED)
> > > $ ping facebook.com
> > > [... 10s ...]
> > > ping: facebook.com: Temporary failure in name resolution
> > > 
> > > I do not understand why this second DNS server is populated in all Qubes
> > > VM. Is there a simple way to configure only 1 DNS server?
> > > 
> > > Antoine
> > > 
> > 
> > If you had two servers on your network, or your DHCP server gave out two
> > addresses both would be used, I think.
> 
> The issue is that my DHCP server is only giving 1 DNS server. I do not
> understand why Qubes thinks I have 2.
> 
> Antoine
> 

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?

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

Re: [qubes-users] Tip: Adding arbitrary apps to DispVM Applications menu

2017-03-11 Thread Grzesiek Chodzicki

W dniu sobota, 11 marca 2017 22:34:34 UTC+1 użytkownik Andrew David Wong 
napisał:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 2017-03-11 09:31, Grzesiek Chodzicki wrote:
> > How to add custom applications to DispVM appmenu:
> > 
> > 1. Install the required app in the TemplateVM upon which your DispVM 
> > depends (fedora-23/24 by default)
> > 2. Shutdown the TemplateVM
> > 3. In Dom0 run qvm-create-default-dvm 
> > 4. At this point your app can be launched in DispVM, to confirm launch 
> > Xterm in DispVM and start your app from there. Now we are going to add an 
> > entry for it in the Applications menu
> > 5. Go to /usr/local/share/applications
> > 6. Create a new .desktop file for your app using following (example) syntax:
> > 
> > [Desktop Entry]
> > Version=1.0
> > Type=Application
> > Exec=sh -c 'echo  | /usr/lib/qubes/qfile-daemon-dvm 
> > qubes.VMShell dom0 DEFAULT red'
> > Icon=dispvm-red
> > Terminal=false
> > Name=DispVM: 
> > GenericName=DispVM: 
> > StartupNotify=false
> > Categories=Network;X-Qubes-VM;
> > 
> > 7. go to /etc/xdg/menus/applications-merged
> > 8. Edit the qubes-dispvm.menu using any editor
> > 9. Under  add another line containing the name of your .desktop 
> > file (so it looks like this):
> > 
> > 
> > qubes-dispvm-firefox.desktop
> > qubes-dispvm-xterm.desktop
> > yourdesktopfilehere
> > 
> > 
> > 10. Your custom menu entry should appear on the Applications list now
> > 
> > Andrew - Frankly, this should be available within the GUI, should I add 
> > that to Documentation and/or create a ticket?
> > 
> 
> Please feel free to do so.
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> -BEGIN PGP SIGNATURE-
> 
> iQIcBAEBCgAGBQJYxG1XAAoJENtN07w5UDAwXPQP/2hvs1va6LTLVTKWqQwlCmZd
> BHjO59rE/0ENlsK+diT1ANpggPODWTTckw6+o/rsKhGvQXv/1PZfPJCzY3FV9w66
> CndadAoQZunyGp1otJolGJHiS5ppqNXqm8+pzCNtkZ1YkYUj4QwjAAjZ67VU1y8H
> C6yb774opL+CYiOzMOy3jTnnc/yWeJfFxGKNoB8YLRBqXrk8wG+vMVZYphoYo9xg
> XIUu4xGZtCAdVvkcWT/RgBsHsdKoJ+CSij2B3bAx9vZPmmnndpB5HiXdzSZXLGhi
> Dh/Xnc9+veqLKZ9rk1DpJ0CxLnaqAz3VEqzjha7cYL+yulZvH15LO46nIfyrFOQl
> eUXK65hPj/C/+qFs2c1yBU0wFB3YcMe6fxdyUId5pKSQBU34hlDLDKhWsLVKNJ1t
> gAxEtszRecgyi4px4sI0POHhsxbDauGpSBYYcNedFIKPNnERW+mNNA2d7n7xlwHj
> 2cNt7MzUFXIxq8UwS1A5pds9KMdA5cZXGIDujMGnuKvCDCtXyOcYQyJqbupJ6/c5
> gS8JZ16RHi/oBMzmfenz2GVUjf3afATDN/oxAVJSoYtX/xZeoHQi3x2qePyfJ7hs
> q+9PxBX5RbwQs27B0M+fwF1/1Myi1J9DC2mzBfc6lgb29WwKJxdIb/RXkoaUmFA2
> 7uzEP5ORYkQQgpwlIu7i
> =0o7g
> -END PGP SIGNATURE-

PR sent and issue created
https://github.com/QubesOS/qubes-issues/issues/2694.

-- 
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/8007c1ad-5a18-4d79-9e9a-6518b1c7e590%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Tip: Adding arbitrary apps to DispVM Applications menu

2017-03-11 Thread Andrew David Wong

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-03-11 09:31, Grzesiek Chodzicki wrote:
> How to add custom applications to DispVM appmenu:
> 
> 1. Install the required app in the TemplateVM upon which your DispVM depends 
> (fedora-23/24 by default)
> 2. Shutdown the TemplateVM
> 3. In Dom0 run qvm-create-default-dvm 
> 4. At this point your app can be launched in DispVM, to confirm launch Xterm 
> in DispVM and start your app from there. Now we are going to add an entry for 
> it in the Applications menu
> 5. Go to /usr/local/share/applications
> 6. Create a new .desktop file for your app using following (example) syntax:
> 
> [Desktop Entry]
> Version=1.0
> Type=Application
> Exec=sh -c 'echo  | /usr/lib/qubes/qfile-daemon-dvm 
> qubes.VMShell dom0 DEFAULT red'
> Icon=dispvm-red
> Terminal=false
> Name=DispVM: 
> GenericName=DispVM: 
> StartupNotify=false
> Categories=Network;X-Qubes-VM;
> 
> 7. go to /etc/xdg/menus/applications-merged
> 8. Edit the qubes-dispvm.menu using any editor
> 9. Under  add another line containing the name of your .desktop file 
> (so it looks like this):
> 
> 
> qubes-dispvm-firefox.desktop
> qubes-dispvm-xterm.desktop
> yourdesktopfilehere
> 
> 
> 10. Your custom menu entry should appear on the Applications list now
> 
> Andrew - Frankly, this should be available within the GUI, should I add that 
> to Documentation and/or create a ticket?
> 

Please feel free to do so.

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJYxG1XAAoJENtN07w5UDAwXPQP/2hvs1va6LTLVTKWqQwlCmZd
BHjO59rE/0ENlsK+diT1ANpggPODWTTckw6+o/rsKhGvQXv/1PZfPJCzY3FV9w66
CndadAoQZunyGp1otJolGJHiS5ppqNXqm8+pzCNtkZ1YkYUj4QwjAAjZ67VU1y8H
C6yb774opL+CYiOzMOy3jTnnc/yWeJfFxGKNoB8YLRBqXrk8wG+vMVZYphoYo9xg
XIUu4xGZtCAdVvkcWT/RgBsHsdKoJ+CSij2B3bAx9vZPmmnndpB5HiXdzSZXLGhi
Dh/Xnc9+veqLKZ9rk1DpJ0CxLnaqAz3VEqzjha7cYL+yulZvH15LO46nIfyrFOQl
eUXK65hPj/C/+qFs2c1yBU0wFB3YcMe6fxdyUId5pKSQBU34hlDLDKhWsLVKNJ1t
gAxEtszRecgyi4px4sI0POHhsxbDauGpSBYYcNedFIKPNnERW+mNNA2d7n7xlwHj
2cNt7MzUFXIxq8UwS1A5pds9KMdA5cZXGIDujMGnuKvCDCtXyOcYQyJqbupJ6/c5
gS8JZ16RHi/oBMzmfenz2GVUjf3afATDN/oxAVJSoYtX/xZeoHQi3x2qePyfJ7hs
q+9PxBX5RbwQs27B0M+fwF1/1Myi1J9DC2mzBfc6lgb29WwKJxdIb/RXkoaUmFA2
7uzEP5ORYkQQgpwlIu7i
=0o7g
-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/d6420b95-e8e5-9992-ab30-5a6e2dee7942%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

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

2017-03-11 Thread Daniel Moerner

On Friday, March 10, 2017 at 9:55:08 PM UTC-5, Unman wrote:
> So yes, in a very real sense, it doesn't matter
> to me if the qube where I collect mail, (which isn't the qube where I
> read it) is compromised in some way.

Hi Unman,

Could you explain your setup for collecting mail in one Qube and reading it in 
another? I currently use Qubes for each mail account, running mutt and 
offlineimap, and opening links in disposable VMs. But collecting mail in one 
Qube and reading it in another is interesting to me.

Daniel

-- 
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/21ad2eab-051e-43b2-afd6-5c3c0edcc34a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS

2017-03-11 Thread 'Antoine' via qubes-users

On Thu, Mar 09, 2017 at 12:30:21AM +, Unman wrote:
> > > > > >> https://github.com/QubesOS/qubes-issues/issues/2674
> > > > I have the same problem with Fedora 23, Debian 8 and Debian 9:
> > > > 
> > > > = Fedora 23 =
> > > > [user@work ~]$ grep PRETTY /etc/os-release 
> > > > PRETTY_NAME="Fedora 23 (Workstation Edition)"
> > > > [user@work ~]$ cat /etc/resolv.conf 
> > > > nameserver 10.137.2.1
> > > > nameserver 10.137.2.254
> > > > [user@work ~]$ dig +short gov.uk @10.137.2.1
> > > > 23.235.33.144
> > > > 23.235.37.144
> > > > [user@work ~]$ dig +short gov.uk @10.137.2.254
> > > > ;; connection timed out; no servers could be reached
> > I have understood why I have this problem.
> > 
> > On my LAN, the DNS recursive server (unbound) has a blacklist: it
> > refuses to answer queries for tracking/ad domains. The problem is that
> > when a program receives a "REFUSED" packet from its DNS query, it tries
> > to solve the same host on the second DNS server in resolv.conf.
> > 
> > I can see the pattern clearly using tcpdump: Query -> fast answer
> > REFUSED -> Query on the second DNS server -> no answer.
> > 
> > On the DNS resolver:
> > # grep facebook unbound-blacklist.conf 
> > local-zone: "facebook.com" refuse
> > 
> > on any Qubes VM:
> > $ host facebook.com 10.137.2.1
> > Using domain server:
> > Name: 10.137.2.1
> > Address: 10.137.2.1#53
> > Aliases: 
> > 
> > Host facebook.com not found: 5(REFUSED)
> > $ host facebook.com 10.137.2.254
> > [... 10s ...]
> > ;; connection timed out; no servers could be reached
> > $ host facebook.com
> > Host facebook.com not found: 5(REFUSED)
> > $ ping facebook.com
> > [... 10s ...]
> > ping: facebook.com: Temporary failure in name resolution
> > 
> > I do not understand why this second DNS server is populated in all Qubes
> > VM. Is there a simple way to configure only 1 DNS server?
> > 
> > Antoine
> > 
> 
> If you had two servers on your network, or your DHCP server gave out two
> addresses both would be used, I think.

The issue is that my DHCP server is only giving 1 DNS server. I do not
understand why Qubes thinks I have 2.

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/20170311210550.uzoxnnr6dnglhteq%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

I usually just assume I'm protecting against randoms, not some super persistent 
personal target I can't defend against anyways.  So you always have to weigh 
the efforts.

I hate to use the phrase threat model cause when it pertains to attackers there 
is no such thing. Everything is in it so the phrase is used wrong.  But when it 
pertains to usability it makes sense to think about it.  Especially if Qubes 
wants more adoption then besides arrogant computer experts lol.

-- 
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/23cd3590-fa16-48ae-8998-19d7b6ce6807%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: RAM for Qubes OS

2017-03-11 Thread jeanpierrefr22

Le samedi 11 mars 2017 11:11:41 UTC+1, Vít Šesták a écrit :
> My quick guess is that you need 2GiB more RAM with Qubes0S than with, say, 
> Ubuntu. Reasoning:
> 
> a. Experience: 6GiB with Ubuntu was somewhat usable, but I had to close all 
> apps I was not using at the time and even with this, I got some swapping 
> times. With 8GiB, it was much better. With QubesOS, I got similar experience 
> for 8GiB (swapping times) and 10GiB (good experience). But please note that 
> my experience with 10GiB RAM is quite short: I have used it few days because 
> of a faulty RAM module. (10GiB was actually a temporary downgrade from 16GiB.)
> 
> b. Calculation: By default, dom0 takes at least 1GiB RAM. Both sys-net and 
> sys-firewall and sys-usb can be configured for 200 or 300 MiB. Plus some 
> overhead.
> 
> Note that Qubes 4 will probably add about 50MiB overhead for each VM except 
> HVMs (the overhead is alreasy there) and dom0 (no need for stubdom). 
> 
> On the other hand, you can make some further modifications that same some RAM.
> 
> * If you don't need USB for anything but keyboard and mouse (or touchpad or 
> something similar), you can get rid of sys-usb.
> * You might merge sys-net and sys-firewall in one VM. Yes, some will note 
> that this is generally a bad idea. While I agree it reduces some benefits of 
> Qubes, merging sys-net with sys-firewall should not make it worse than 
> conventional distributions.
> * You might try MirageOS-based firewall to reduce its footprint. But please 
> note that this is experimental today.
> 
> Also note that QubesOS is not designed for swapping. All AppVMs have 1GiB 
> swap and you can theoretically add more, but memory balancing does not work 
> well if swap is used heavily.
> 
> I would say that you will be able to run Qubes with 4GiB RAM if your 
> requirements are pretty low. It might be worth trying. But I would not 
> recommend any laptop with non-upgradable 4GiB RAM as a new hardware for 
> QubesOS.
> 
> Regards,
> Vít Šesták 'v6ak'

Thank for your answer, it's a shame there no ultrabooks allowing RAM upgrade :( 

-- 
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/ac503066-fcd7-45d0-83bc-93b4ca2f686b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Tip: Adding arbitrary apps to DispVM Applications menu

2017-03-11 Thread Grzesiek Chodzicki

How to add custom applications to DispVM appmenu:

1. Install the required app in the TemplateVM upon which your DispVM depends
(fedora-23/24 by default)
2. Shutdown the TemplateVM
3. In Dom0 run qvm-create-default-dvm
4. At this point your app can be launched in DispVM, to confirm launch Xterm in
DispVM and start your app from there. Now we are going to add an entry for it
in the Applications menu
5. Go to /usr/local/share/applications
6. Create a new .desktop file for your app using following (example) syntax:

[Desktop Entry]
Version=1.0
Type=Application
Exec=sh -c 'echo | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell
dom0 DEFAULT red'
Icon=dispvm-red
Terminal=false
Name=DispVM:
GenericName=DispVM:
StartupNotify=false
Categories=Network;X-Qubes-VM;

7. go to /etc/xdg/menus/applications-merged
8. Edit the qubes-dispvm.menu using any editor
9. Under add another line containing the name of your .desktop file
(so it looks like this):

qubes-dispvm-firefox.desktop
qubes-dispvm-xterm.desktop
yourdesktopfilehere

10. Your custom menu entry should appear on the Applications list now

Andrew - Frankly, this should be available within the GUI, should I add that to
Documentation and/or create a ticket?

--
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/b15f32cd-caaa-4146-b63f-5d0021554da3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

On Sat, Mar 11, 2017 at 08:49:10AM -0500, Chris Laprise wrote:
> On 03/11/2017 08:10 AM, Unman wrote:
> 
> >
> >Anyway, it's a argument that could go on. I dont agree that "the
> >chance for improved security comes for free". It's absolutely clear that
> >Qubes aims to balance security with usability - some of the compromises
> >that have been made seem wrong to me, this isnt one of them. I take
> >steps to mitigate changes I dont like - you should do the same if you
> >want a password on root access.
> >But for most users (particulary new users) there is a cost to
> >introducing passwrd access, and it's convenience.
> 
> Its not based on passwords. Its the same Yes/No dom0 auth dialog that
> controls qvm-copy. Except it remembers auth for a certain amount of time the
> way sudo normally does.
> 
> Notice the detractors haven't tried it and think it means assigning
> passwords to VMs.
> 
> 
> >Joanna refers to this
> >in the explanation. It's clear from the forums that many users struggle
> >with the Qubes ideas anyway - I cant see that this change would make
> >things easier for them. (Presumably you would need to have different
> >password across different templates.)
> 
> Most are already used to UAC Yes/No prompt on Windows. This is pretty
> similar.
> 
> 
> >>
> >>>There is another, much bigger issue: We don't want our systems to
> >>>become a zoo of infected VMs with malware thrashing about in them
> >>>(and on our networks!) with us as zookeepers. That would be
> >>>irresponsible.
> >
> >The answer to this is encouraging users to make good use of isolation,
> >qube use and Qubes features. That isnt irresponsible. It's a way of
> >dealing with the problem. I think you would need to develop a much more
> >detailed argument to convince me that the answer to malware infections
> >is putting a password on root access.
> 
> I didn't purport to provide "the answer"... strawman argument.
> 
> What it comes down to is a matter of degrees and costs.
> 
> 
> >
> >As far as I can see most people, particularly new users with some linux
> >background, just dont like the idea of passwordless root. That's fine.
> >That's why there's a page devoted to it, and a solution.
> 
> Well, its still passwordless with the vm-sudo auth.
> 
> You should try it. :)
> 
> 
> 
> >There's no real security
> >advantage in enabling it but if you want to you can.
> 
> I think its a mistake to deny that guest OS permissions can contribute some
> additional margin of security.
> 
> If it means a less attractive environment for script kiddies to raise
> hell--- chewing up resources, attacking other computers, creating footholds
> for more advanced threats--- then I can invest 3 min. to enable it.
>

Chris

There was no straw man argument here - you raised the issue of "malware
zoos" in the context of a discussion of passwordless sudo - it's
natural to think that you see it as an answer. I cant see it plays any
role.

This is particularly so given your suggestion that the root access
"remembers auth for a certain amount of time" - decent targeted
attacks would have a stub firing to check if sudo was enabled every
few minutes, and would hit the target of opportunity you have opened
for them. This really isnt a solution. (I see the same with people who
think they are immune from viruses because they only connect to the
internet for brief periods.)

There are many things I havent tried, and I think this is going to be
one of them. If Qubes policy were to change, then I would consider
following it depending on what the reason was for the change, but that's
a choice I would make. I still cant see that anyone has provided a
reason why " guest OS permissions can contribute some additional margin
of security". You think this is a mistake on my part.

cheers

unman


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

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

On Sat, Mar 11, 2017 at 04:43:41PM +, sm8ax1 wrote:
> 7v5w7go9ub0o:
> > 
> > 
> > On 03/11/2017 12:10 PM, Alex wrote:
> >> On 03/11/2017 12:14 PM, Chris Laprise wrote:
> >>> On 03/11/2017 04:20 AM, Alex wrote:
>  the only really read-write directories (their changes are 
>  actually persisted) are /home and /usr/local.
> >>> That is enough to be able to persist.
> >> Yes, and that doesn't even need root :) So, both having root or 
> >> not, there is some degree of persistence attainable.
> >> 
> >> Installing via DNF or any other package manager is an easy route
> >> to put files in the relevant "system" directories, but since these
> >> are not persisted, it's actually more convenient, from a malware
> >> point of view, to just place them in the home of the user and set
> >> up some kind of autostart (eg bashrc, or systemd user units, or
> >> gnome autostarts).
> > 
> > 
> > 
> > 
> > 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.

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

Re: [qubes-users] network connection has been disconeccted

On Sat, Mar 11, 2017 at 07:42:23AM -0800, Rainer Hörbe wrote:
> I installed Qubes R3.2 on a Gigabyte Brix and it worked nicely for a couple 
> of weeks. Recently id started displaying the notification "Disconnected - the 
> network connection has been disconnected" after login. And in fact no IP was 
> acquired from the DHCP server.
> 
> When I boot from CentOS etc. there is no problem to connect via ethernet. I 
> reinstalled Qubes, but the problem remains. I can, however, attache to Wifi.
> 
> I looked into various VMs, but the networking concept is quite different to 
> plain vanilla linux and I did not find a doc page to troubleshoot the problem.
> 
> - Rainer
> 

The network connection is controlled in sys-net (assuming that you have
kept the default install).
If you open a terminal there you will find it's just vanilla linux as
far as networking goes. You dont say what the wifi card is,but it's
possible that you need to update your drivers or set a specific
configuration.
Remember to do this in the template that sys-net uses.

Also, it's very simple to switch the template and see if you have more
success in maintaining a connection using a Debian template. You can
make this change from the Qubes manager, by looking at and changing
qube settings. (You will need to reboot sys-net to start suing the new
Template.)

Hope this helps

unman

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

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

On Sat, Mar 11, 2017 at 08:00:33AM -0800, cooloutac wrote:
> On Saturday, March 11, 2017 at 10:37:18 AM UTC-5, evo wrote:
> > Hey,
> > 
> > how can i change the template VM (from fedora to debian) in terminal of
> > dom0?
> 
> in the qubes-manager you can right lick a vm and select vm settings.
> 

In TERMINAL:
qvm-prefs  template -s 

qvm-prefs is very useful.

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

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

2017-03-11 Thread sm8ax1

7v5w7go9ub0o:
> 
> 
> On 03/11/2017 12:10 PM, Alex wrote:
>> On 03/11/2017 12:14 PM, Chris Laprise wrote:
>>> On 03/11/2017 04:20 AM, Alex wrote:
 the only really read-write directories (their changes are 
 actually persisted) are /home and /usr/local.
>>> That is enough to be able to persist.
>> Yes, and that doesn't even need root :) So, both having root or 
>> not, there is some degree of persistence attainable.
>> 
>> Installing via DNF or any other package manager is an easy route
>> to put files in the relevant "system" directories, but since these
>> are not persisted, it's actually more convenient, from a malware
>> point of view, to just place them in the home of the user and set
>> up some kind of autostart (eg bashrc, or systemd user units, or
>> gnome autostarts).
> 
> 
> 
> 
> 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?

-

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

-- 
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/1b2ed6d3-0866-c0b4-a470-b82c2d724a6d%40vfemail.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Mount different folders on same partition to different AppVMs?

2017-03-11 Thread Andres MRM

Thanks, Unman! It's an interesting idea! I'll see what fits better for my
case.

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

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

On Saturday, March 11, 2017 at 10:37:18 AM UTC-5, evo wrote:
> Hey,
> 
> how can i change the template VM (from fedora to debian) in terminal of
> dom0?

in the qubes-manager you can right lick a vm and select vm settings.

-- 
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/faec128c-f26f-4e22-92a2-c317129177de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

On Saturday, March 11, 2017 at 8:51:05 AM UTC-5, Chris Laprise wrote:
> On 03/11/2017 08:10 AM, Unman wrote:
> 
> If it means a less attractive environment for script kiddies to raise 
> hell--- chewing up resources, attacking other computers, creating 
> footholds for more advanced threats--- then I can invest 3 min. to 
> enable it.
> 
> 
> -- 
> 
> Chris Laprise, tas...@openmailbox.org
> https://twitter.com/ttaskett

why not just use a dispvm or compartmentalize more? I feel that is the purpose 
of Qubes,  To address problem of many trivial security protections.

-- 
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/6c90e5d9-6f92-438a-93a3-a8fbb421c9a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2017-03-11 Thread sm8ax1

hib0...@gmail.com:
> This part of the file system is not rewritten on every boot. Are you 
> constantly somehow verifying your VM every boot, every 5 minutes, every web 
> page load?  Or are you restoring from a backup every boot or worse rebuilding 
> the entire VM from a template every time you need it? Do you just not care 
> that this VM could be under nefarious control and let the perpetrator read 
> your email etc?

Actually, I think it is, but I could be wrong.

I'm no expert so I hope someone jumps in and corrects me, but as I
understand it, /rw and /home are the only persistent directories, and
they are local to the VM.

Everything else is mounted as a temporary snapshot of a file owned by
the template (meaning the named TemplateVM can make persistent changes
to it), except for tmpfs filesystems like /run and /tmp.

So, malware could make itself persistent by infecting ~/.bashrc for
example, but `dnf install` or /usr/bin/audacious would go back to its
original state after a reboot.

If it were up to me (and I had the necessary time and skills), I would
harden all the things. Dom0 and DomUs alike. SELinux, AppArmor, Grsec,
musl, even OpenBSD where possible, and of course restricted root access.
Let the user incrementally disable security features if their favorite
apps don't work.

Xen is nice, but it's no panacea. I think about two years ago Xen got
hit pretty hard with a raft of critical security vulns and it caused bit
of controversy in the community.

Nevertheless I realize all this isn't easy and I appreciate the amount
of effort the developers have gone to in order to give us the Qubes we
have today. Qubes could be better, but there's a reason all of us left
our previous OSes after all, isn't there?


-

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

-- 
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/c69fde54-0a47-6b85-0a33-a5596364e955%40vfemail.net.
For more options, visit https://groups.google.com/d/optout.

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

I have always felt any level of security is useful no matter how trivial to 
bypass.

But I think the decision here for passwordless sudo is not cause privilege 
escalation or non root persistence is trivial.  Its because people like my 
mother are not gonna constantly type their password in dozens of vms, or to 
update half a dozen templates, all for a layer of security thats considered 
meaningless to Qubes threat model.  In qubes usability is more a factor.

Maybe password for sudo should be an option for people who want 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/7f41fb78-ec14-49c0-9602-124fc4dff1ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] network connection has been disconeccted

2017-03-11 Thread Rainer Hörbe

I installed Qubes R3.2 on a Gigabyte Brix and it worked nicely for a couple of 
weeks. Recently id started displaying the notification "Disconnected - the 
network connection has been disconnected" after login. And in fact no IP was 
acquired from the DHCP server.

When I boot from CentOS etc. there is no problem to connect via ethernet. I 
reinstalled Qubes, but the problem remains. I can, however, attache to Wifi.

I looked into various VMs, but the networking concept is quite different to 
plain vanilla linux and I did not find a doc page to troubleshoot the problem.

- Rainer

-- 
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/a8b7f6d3-7c29-4676-900d-b33087d3a098%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

Hey,

how can i change the template VM (from fedora to debian) in terminal of
dom0?

-- 
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/e4f8e573-06bc-218e-e3ef-6e4f612a598f%40aliaks.de.
For more options, visit https://groups.google.com/d/optout.

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

2017-03-11 Thread 7v5w7go9ub0o



On 03/11/2017 12:10 PM, Alex wrote:
> On 03/11/2017 12:14 PM, Chris Laprise wrote:
>> On 03/11/2017 04:20 AM, Alex wrote:
>>> the only really read-write directories (their changes are actually
>>> persisted) are /home and /usr/local.
>> That is enough to be able to persist.
> Yes, and that doesn't even need root :) So, both having root or not,
> there is some degree of persistence attainable.
>
> Installing via DNF or any other package manager is an easy route to put
> files in the relevant "system" directories, but since these are not
> persisted, it's actually more convenient, from a malware point of view,
> to just place them in the home of the user and set up some kind of
> autostart (eg bashrc, or systemd user units, or gnome autostarts).




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

Don't retain potentially infect-able user files; stop, flush, and 
restart frequently.

Paranoids accessing dangerous mail servers can run multiple mail clients 
in multiple dispvms so that if one is compromised, only that 
correspondence is lost - one could also run Samhain to monitor unusual 
behavior.






>
>>> As the others already stated there could be problems for the
>>> actually running session, i.e. the rogue command could siphon all
>>> your data to a remote location, but it would be only able to access
>>> data in that AppVM and not the others. This action would not need
>>> any root access, because all data is from the very same user that
>>> downloaded/started the rogue program in the first place, so it
>>> already has access.
>>>
>>> The only advantage that root access would give could arguably be
>>> persistance (i.e. installation, as you suggested with DNF), but
>>> that advantage is fake and will vanish on AppVM reboot.
>> Disagree there. Root access would bestow greater ability to launch
>> attacks against VM isolation. That would be rare in of itself, but
>> the chance for improved security comes for free.
> And that's the point where I agree with you, I overlooked the
> exploitability of Xen virtual devices in my original answer. Software
> running as root has easier access to the Xen para-vm communication
> devices, and that may lead to crossing the VM isolation.
>
>
>> There is another, much bigger issue: We don't want our systems to
>> become a zoo of infected VMs with malware thrashing about in them
>> (and on our networks!) with us as zookeepers. That would be
>> irresponsible.
>>
>> Qubes' abilities should not be framed in a way that would encourage
>> that. Even if isolation works 100% of the time, we should view that
>> as the opportunity to remove and prevent malware---preferably with
>> some help from the guest OS.
>>
>> Put another way: If VMs were teeth, would you prefer to have one
>> cavity this year, or seven?
> That's a gross oversimplification of the situation. In Qubes there are
> several AppVM that are "all created equal", but to the user there MUST
> be some difference, and he is advised to make use of the colored labels
> to emphasize and remind these differences.
>
> While I don't certainly want to have all red-labeled VMs (i.e. the
> malware zoo situation you propose), I'm pretty sure I will not trust
> some VMs because they are used with dangerous websites/software. I will
> consider them dangerous even with passwordless sudo disbled, because
> there may be some 0-day that has been exploited for a local privilege
> escalation that makes sudo a non-problem.
>
> I make sure to periodically purge those VMs (which I named dump-0,
> dump-1, etc to even remember that they are not to be trusted and because
> when I forget why they are here (hence, the cryptic name) they can be
> safely deleted), and because of the periodic update restart cycles all
> other AppVMs are not always on, so malware cannot rely on system level
> persistence there. In those "safer" appVMs, I don't open suspicious
> e-mails nor visit doubtful websites; activities that I try to perform in
> the unsafe AppVMs.
>
> TL;DR: there's no malware disadvantage if there is no passwordless sudo
> in Qubes (it can persist as the user, and can still see all the files of
> that user), and there's very little advantage (temporary persistence in
> "system" directories) that may even become a decoy of some sort with
> passwordless sudo being enabled.
>
> In my humble opinion, this absence of actual advantages or disadvantages
> makes the whole situation irrelevant from a security standpoint. There
> are other issues that should be taken into account for a more complete
> answer than just security as holy grail, and they can safely be
> introduced in the decision when the security outcome is the same. They
> range from "is having to remember several different root/sudo password

[qubes-users] Error: Bad return status for module build on kernel: 4.9.0-2-amd64 (x86_64)

2017-03-11 Thread faber

I'm trying to adopt the kernel image 4.9.0-2-amd64 on my Debian 9
TemplateVM.

After installing the image and its headers, I do the following command:

--
sudo dkms autoinstall -k 4.9.0-2-amd64
--

And get the following output:


-
Kernel preparation unnecessary for this kernel.  Skipping...

Building module:
cleaning build area...
make -j2 KERNELRELEASE=4.9.0-2-amd64 KVERSION=4.9.0-2-amd64...(bad exit
status: 2)
Error! Bad return status for module build on kernel: 4.9.0-2-amd64 (x86_64)
Consult /var/lib/dkms/digimend/6/build/make.log for more information.

Kernel preparation unnecessary for this kernel.  Skipping...

Building module:
cleaning build area...
make -j2 KERNELRELEASE=4.9.0-2-amd64 -C /lib/modules/4.9.0-2-amd64/build
M=/var/lib/dkms/u2mfn/3.2.3/build...(bad exit status: 2)
Error! Bad return status for module build on kernel: 4.9.0-2-amd64 (x86_64)
Consult /var/lib/dkms/u2mfn/3.2.3/build/make.log for more information.
-



And the output of /var/lib/dkms/u2mfn/3.2.3/build/make.log is:


-
DKMS make.log for u2mfn-3.2.3 for kernel 4.9.0-2-amd64 (x86_64)
Sat Mar 11 16:13:29 CET 2017
make: Entering directory '/usr/src/linux-headers-4.9.0-2-amd64'
  LD  /var/lib/dkms/u2mfn/3.2.3/build/built-in.o
  CC [M]  /var/lib/dkms/u2mfn/3.2.3/build/u2mfn.o
/var/lib/dkms/u2mfn/3.2.3/build/u2mfn.c: In function ‘u2mfn_ioctl’:
/var/lib/dkms/u2mfn/3.2.3/build/u2mfn.c:80:23: error: passing argument 5
of ‘get_user_pages’ from incompatible pointer type
[-Werror=incompatible-pointer-types]
   (data, 1, 1, 0, &user_page, 0);
   ^
In file included from /var/lib/dkms/u2mfn/3.2.3/build/u2mfn.c:26:0:
/usr/src/linux-headers-4.9.0-2-common/include/linux/mm.h:1302:6: note:
expected ‘struct vm_area_struct **’ but argument is of type ‘struct page **’
 long get_user_pages(unsigned long start, unsigned long nr_pages,
  ^~
/var/lib/dkms/u2mfn/3.2.3/build/u2mfn.c:79:9: error: too many arguments
to function ‘get_user_pages’
   ret = get_user_pages
 ^~
In file included from /var/lib/dkms/u2mfn/3.2.3/build/u2mfn.c:26:0:
/usr/src/linux-headers-4.9.0-2-common/include/linux/mm.h:1302:6: note:
declared here
 long get_user_pages(unsigned long start, unsigned long nr_pages,
  ^~
cc1: some warnings being treated as errors
/usr/src/linux-headers-4.9.0-2-common/scripts/Makefile.build:304: recipe
for target '/var/lib/dkms/u2mfn/3.2.3/build/u2mfn.o' failed
make[3]: *** [/var/lib/dkms/u2mfn/3.2.3/build/u2mfn.o] Error 1
/usr/src/linux-headers-4.9.0-2-common/Makefile:1507: recipe for target
'_module_/var/lib/dkms/u2mfn/3.2.3/build' failed
make[2]: *** [_module_/var/lib/dkms/u2mfn/3.2.3/build] Error 2
Makefile:150: recipe for target 'sub-make' failed
make[1]: *** [sub-make] Error 2
Makefile:8: recipe for target 'all' failed
make: *** [all] Error 2
make: Leaving directory '/usr/src/linux-headers-4.9.0-2-amd64'
-



Any idea?

Thanks in advance

-- 
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/87f6e97b-5298-9a4a-7fd4-8e9c57fbfd65%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Videostream with Qubes??



Am 03/11/2017 um 04:20 PM schrieb cooloutac:
> On Saturday, March 11, 2017 at 10:17:52 AM UTC-5, evo wrote:
>> Am 03/11/2017 um 04:16 PM schrieb cooloutac:
>>> On Saturday, March 11, 2017 at 9:54:33 AM UTC-5, evo wrote:
 Am 03/11/2017 um 02:24 AM schrieb cooloutac:
> On Friday, March 10, 2017 at 8:22:51 PM UTC-5, cooloutac wrote:
>> On Friday, March 10, 2017 at 6:17:37 PM UTC-5, evo wrote:
>>> Am 03/10/2017 um 07:18 PM schrieb cooloutac:
 On Friday, March 10, 2017 at 4:14:22 AM UTC-5, evo wrote:
> Am 03/10/2017 um 05:45 AM schrieb cooloutac:
>> On Thursday, March 9, 2017 at 11:43:37 PM UTC-5, cooloutac wrote:
>>> On Thursday, March 9, 2017 at 1:44:38 PM UTC-5, evo wrote:
 Hello!

 i have problems with the most streams on the net.
 Youtube is ok, but i suppose rather slow.

 I think, this is the thing with flash, HTML5 and openH264.
 H264 is deactivated and if i want to activate it, it seems to be 
 not
 possible.

 Is it so, that HTML5 needs H264?
 Or is it so, that i need flash for every other stream.
 I tried also some links, that should be HTML5, but they were not
 possible... maby they were not really in HTML5 or HTML5 does't 
 work good.

 Do somebody has an idea?
>>>
>>> whats the templatevm its based on fedora or debian?  If fedora you 
>>> have to enable rpmfusion and install gstreamer package to get that 
>>> format.  I forget exactly which one though man.  I think i posted 
>>> about it here once i;ll t ry tolook.
>>
>> gstreamer1-libav
>>
>> https://groups.google.com/forum/#!searchin/qubes-users/gstreamer1$20libav%7Csort:relevance/qubes-users/HzzQWXU7nzE/ZXSbhStPJwAJ
>>
>
> i run fedora 23 on it, rpm fusion is almost on... but i can not find
> gstreamer1-libav on the server... strange

 hmm... did you install both rpm fusion free and nonfree?  Im not sure 
 which one its in. 

 Also make sure you looking gstreamer1 and not gstreamer.

 Its in there somewhere and it will play the mp4 streams on firefox 
 without flash.  Maybe just search gstreamer1 and scroll through the 
 list maybe I spelled it wrong. look for the libav one.

 https://www.rpmfind.net/linux/rpm2html/search.php?query=gstreamer1-libav

>>>
>>> hmm... now i checked it again... i have gstreamer1-1.6.4-1 already
>>> installed... but firefox still do not want to play, hmmm
>>
>> weird.  you installed the gstreamer1-libav package? It doesn't have that 
>> version number, the libav package is something seperate.  You need to 
>> install that specific package it is def in rpmfusion repos.  I don't 
>> believe you need any other gstreamer package to stream mp4 but you 
>> might. maybe ffmpeg, but idoubt it.
>
> you can also try using a debian template instead and see if firefox 
> stream the mp4 by default but if not you will need the same package but 
> maybe its easier to find and install from debian repo.
>

 fedora is weird... maby because i always worked with debian.
 if i look in the software center, then i see gstreamer-extra
 installed... gstreamer-libav is listed but i can not install it there...
 is there somewhere a block for other sources?

 if i go to see the software-sources of the software center, so i see RPM
 Fusion free updates and nonfree updates

 i also deinstalled the other gstreamer

 i made a new standalone VM with debian and there i have
 gstreamer1.0-libav (this is the whole name), so the stream works with
 firefox now. How can i check, if any flash is installed?
>>>
>>> I would use the terminal in the template instead to install packages, for 
>>> example:
>>>  sudo dnf install gstreamer1-libav
>>>
>>> to remove a package for example:
>>> sudo dnf remove gstreamer1-libav
>>>
>>> to search for one
>>>
>>> sudo dnf search gstreamer
>>>
>>>
>>> strange, not sure why the template is not starting now if you uninstalled a 
>>> gstreamer package.   Did any other packages get removed along with it?
>>>
>>
>> i think not, i did it over the software center.
>> can not start any fedora VM now if i restart the running ones.
> 
> did you hustdown the template first?
> 

yes i shutdown the template, now i have still run some fedora templates,
but if i restart them, they will not start.

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

[qubes-users] Re: Videostream with Qubes??

On Saturday, March 11, 2017 at 10:22:47 AM UTC-5, evo wrote:
> Am 03/11/2017 um 04:20 PM schrieb cooloutac:
> > On Saturday, March 11, 2017 at 10:17:52 AM UTC-5, evo wrote:
> >> Am 03/11/2017 um 04:16 PM schrieb cooloutac:
> >>> On Saturday, March 11, 2017 at 9:54:33 AM UTC-5, evo wrote:
>  Am 03/11/2017 um 02:24 AM schrieb cooloutac:
> > On Friday, March 10, 2017 at 8:22:51 PM UTC-5, cooloutac wrote:
> >> On Friday, March 10, 2017 at 6:17:37 PM UTC-5, evo wrote:
> >>> Am 03/10/2017 um 07:18 PM schrieb cooloutac:
>  On Friday, March 10, 2017 at 4:14:22 AM UTC-5, evo wrote:
> > Am 03/10/2017 um 05:45 AM schrieb cooloutac:
> >> On Thursday, March 9, 2017 at 11:43:37 PM UTC-5, cooloutac wrote:
> >>> On Thursday, March 9, 2017 at 1:44:38 PM UTC-5, evo wrote:
>  Hello!
> 
>  i have problems with the most streams on the net.
>  Youtube is ok, but i suppose rather slow.
> 
>  I think, this is the thing with flash, HTML5 and openH264.
>  H264 is deactivated and if i want to activate it, it seems to be 
>  not
>  possible.
> 
>  Is it so, that HTML5 needs H264?
>  Or is it so, that i need flash for every other stream.
>  I tried also some links, that should be HTML5, but they were not
>  possible... maby they were not really in HTML5 or HTML5 does't 
>  work good.
> 
>  Do somebody has an idea?
> >>>
> >>> whats the templatevm its based on fedora or debian?  If fedora 
> >>> you have to enable rpmfusion and install gstreamer package to get 
> >>> that format.  I forget exactly which one though man.  I think i 
> >>> posted about it here once i;ll t ry tolook.
> >>
> >> gstreamer1-libav
> >>
> >> https://groups.google.com/forum/#!searchin/qubes-users/gstreamer1$20libav%7Csort:relevance/qubes-users/HzzQWXU7nzE/ZXSbhStPJwAJ
> >>
> >
> > i run fedora 23 on it, rpm fusion is almost on... but i can not find
> > gstreamer1-libav on the server... strange
> 
>  hmm... did you install both rpm fusion free and nonfree?  Im not 
>  sure which one its in. 
> 
>  Also make sure you looking gstreamer1 and not gstreamer.
> 
>  Its in there somewhere and it will play the mp4 streams on firefox 
>  without flash.  Maybe just search gstreamer1 and scroll through the 
>  list maybe I spelled it wrong. look for the libav one.
> 
>  https://www.rpmfind.net/linux/rpm2html/search.php?query=gstreamer1-libav
> 
> >>>
> >>> hmm... now i checked it again... i have gstreamer1-1.6.4-1 already
> >>> installed... but firefox still do not want to play, hmmm
> >>
> >> weird.  you installed the gstreamer1-libav package? It doesn't have 
> >> that version number, the libav package is something seperate.  You 
> >> need to install that specific package it is def in rpmfusion repos.  I 
> >> don't believe you need any other gstreamer package to stream mp4 but 
> >> you might. maybe ffmpeg, but idoubt it.
> >
> > you can also try using a debian template instead and see if firefox 
> > stream the mp4 by default but if not you will need the same package but 
> > maybe its easier to find and install from debian repo.
> >
> 
>  fedora is weird... maby because i always worked with debian.
>  if i look in the software center, then i see gstreamer-extra
>  installed... gstreamer-libav is listed but i can not install it there...
>  is there somewhere a block for other sources?
> 
>  if i go to see the software-sources of the software center, so i see RPM
>  Fusion free updates and nonfree updates
> 
>  i also deinstalled the other gstreamer
> 
>  i made a new standalone VM with debian and there i have
>  gstreamer1.0-libav (this is the whole name), so the stream works with
>  firefox now. How can i check, if any flash is installed?
> >>>
> >>> I would use the terminal in the template instead to install packages, for 
> >>> example:
> >>>  sudo dnf install gstreamer1-libav
> >>>
> >>> to remove a package for example:
> >>> sudo dnf remove gstreamer1-libav
> >>>
> >>> to search for one
> >>>
> >>> sudo dnf search gstreamer
> >>>
> >>>
> >>> strange, not sure why the template is not starting now if you uninstalled 
> >>> a gstreamer package.   Did any other packages get removed along with it?
> >>>
> >>
> >> i think not, i did it over the software center.
> >> can not start any fedora VM now if i restart the running ones.
> > 
> > did you hustdown the template first?
> > 
> 
> yes i shutdown the template, now i have still run some fedora templates,
> but if i restart them, they will not start.

not sure why

[qubes-users] Re: Videostream with Qubes??

On Saturday, March 11, 2017 at 10:16:29 AM UTC-5, cooloutac wrote:
> On Saturday, March 11, 2017 at 9:54:33 AM UTC-5, evo wrote:
> > Am 03/11/2017 um 02:24 AM schrieb cooloutac:
> > > On Friday, March 10, 2017 at 8:22:51 PM UTC-5, cooloutac wrote:
> > >> On Friday, March 10, 2017 at 6:17:37 PM UTC-5, evo wrote:
> > >>> Am 03/10/2017 um 07:18 PM schrieb cooloutac:
> >  On Friday, March 10, 2017 at 4:14:22 AM UTC-5, evo wrote:
> > > Am 03/10/2017 um 05:45 AM schrieb cooloutac:
> > >> On Thursday, March 9, 2017 at 11:43:37 PM UTC-5, cooloutac wrote:
> > >>> On Thursday, March 9, 2017 at 1:44:38 PM UTC-5, evo wrote:
> >  Hello!
> > 
> >  i have problems with the most streams on the net.
> >  Youtube is ok, but i suppose rather slow.
> > 
> >  I think, this is the thing with flash, HTML5 and openH264.
> >  H264 is deactivated and if i want to activate it, it seems to be 
> >  not
> >  possible.
> > 
> >  Is it so, that HTML5 needs H264?
> >  Or is it so, that i need flash for every other stream.
> >  I tried also some links, that should be HTML5, but they were not
> >  possible... maby they were not really in HTML5 or HTML5 does't 
> >  work good.
> > 
> >  Do somebody has an idea?
> > >>>
> > >>> whats the templatevm its based on fedora or debian?  If fedora you 
> > >>> have to enable rpmfusion and install gstreamer package to get that 
> > >>> format.  I forget exactly which one though man.  I think i posted 
> > >>> about it here once i;ll t ry tolook.
> > >>
> > >> gstreamer1-libav
> > >>
> > >> https://groups.google.com/forum/#!searchin/qubes-users/gstreamer1$20libav%7Csort:relevance/qubes-users/HzzQWXU7nzE/ZXSbhStPJwAJ
> > >>
> > >
> > > i run fedora 23 on it, rpm fusion is almost on... but i can not find
> > > gstreamer1-libav on the server... strange
> > 
> >  hmm... did you install both rpm fusion free and nonfree?  Im not sure 
> >  which one its in. 
> > 
> >  Also make sure you looking gstreamer1 and not gstreamer.
> > 
> >  Its in there somewhere and it will play the mp4 streams on firefox 
> >  without flash.  Maybe just search gstreamer1 and scroll through the 
> >  list maybe I spelled it wrong. look for the libav one.
> > 
> >  https://www.rpmfind.net/linux/rpm2html/search.php?query=gstreamer1-libav
> > 
> > >>>
> > >>> hmm... now i checked it again... i have gstreamer1-1.6.4-1 already
> > >>> installed... but firefox still do not want to play, hmmm
> > >>
> > >> weird.  you installed the gstreamer1-libav package? It doesn't have that 
> > >> version number, the libav package is something seperate.  You need to 
> > >> install that specific package it is def in rpmfusion repos.  I don't 
> > >> believe you need any other gstreamer package to stream mp4 but you 
> > >> might. maybe ffmpeg, but idoubt it.
> > > 
> > > you can also try using a debian template instead and see if firefox 
> > > stream the mp4 by default but if not you will need the same package but 
> > > maybe its easier to find and install from debian repo.
> > > 
> > 
> > fedora is weird... maby because i always worked with debian.
> > if i look in the software center, then i see gstreamer-extra
> > installed... gstreamer-libav is listed but i can not install it there...
> > is there somewhere a block for other sources?
> > 
> > if i go to see the software-sources of the software center, so i see RPM
> > Fusion free updates and nonfree updates
> > 
> > i also deinstalled the other gstreamer
> > 
> > i made a new standalone VM with debian and there i have
> > gstreamer1.0-libav (this is the whole name), so the stream works with
> > firefox now. How can i check, if any flash is installed?
> 
> I would use the terminal in the template instead to install packages, for 
> example:
>  sudo dnf install gstreamer1-libav
> 
> to remove a package for example:
> sudo dnf remove gstreamer1-libav
> 
> to search for one
> 
> sudo dnf search gstreamer
> 
> 
> strange, not sure why the template is not starting now if you uninstalled a 
> gstreamer package.   Did any other packages get removed along with it?

you can check for flash in firefox by typing about:plugins and see if shockwave 
flash islisted.

-- 
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/521df545-c567-40b7-a9e8-df5f8ccdc461%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Videostream with Qubes??

On Saturday, March 11, 2017 at 10:17:52 AM UTC-5, evo wrote:
> Am 03/11/2017 um 04:16 PM schrieb cooloutac:
> > On Saturday, March 11, 2017 at 9:54:33 AM UTC-5, evo wrote:
> >> Am 03/11/2017 um 02:24 AM schrieb cooloutac:
> >>> On Friday, March 10, 2017 at 8:22:51 PM UTC-5, cooloutac wrote:
>  On Friday, March 10, 2017 at 6:17:37 PM UTC-5, evo wrote:
> > Am 03/10/2017 um 07:18 PM schrieb cooloutac:
> >> On Friday, March 10, 2017 at 4:14:22 AM UTC-5, evo wrote:
> >>> Am 03/10/2017 um 05:45 AM schrieb cooloutac:
>  On Thursday, March 9, 2017 at 11:43:37 PM UTC-5, cooloutac wrote:
> > On Thursday, March 9, 2017 at 1:44:38 PM UTC-5, evo wrote:
> >> Hello!
> >>
> >> i have problems with the most streams on the net.
> >> Youtube is ok, but i suppose rather slow.
> >>
> >> I think, this is the thing with flash, HTML5 and openH264.
> >> H264 is deactivated and if i want to activate it, it seems to be 
> >> not
> >> possible.
> >>
> >> Is it so, that HTML5 needs H264?
> >> Or is it so, that i need flash for every other stream.
> >> I tried also some links, that should be HTML5, but they were not
> >> possible... maby they were not really in HTML5 or HTML5 does't 
> >> work good.
> >>
> >> Do somebody has an idea?
> >
> > whats the templatevm its based on fedora or debian?  If fedora you 
> > have to enable rpmfusion and install gstreamer package to get that 
> > format.  I forget exactly which one though man.  I think i posted 
> > about it here once i;ll t ry tolook.
> 
>  gstreamer1-libav
> 
>  https://groups.google.com/forum/#!searchin/qubes-users/gstreamer1$20libav%7Csort:relevance/qubes-users/HzzQWXU7nzE/ZXSbhStPJwAJ
> 
> >>>
> >>> i run fedora 23 on it, rpm fusion is almost on... but i can not find
> >>> gstreamer1-libav on the server... strange
> >>
> >> hmm... did you install both rpm fusion free and nonfree?  Im not sure 
> >> which one its in. 
> >>
> >> Also make sure you looking gstreamer1 and not gstreamer.
> >>
> >> Its in there somewhere and it will play the mp4 streams on firefox 
> >> without flash.  Maybe just search gstreamer1 and scroll through the 
> >> list maybe I spelled it wrong. look for the libav one.
> >>
> >> https://www.rpmfind.net/linux/rpm2html/search.php?query=gstreamer1-libav
> >>
> >
> > hmm... now i checked it again... i have gstreamer1-1.6.4-1 already
> > installed... but firefox still do not want to play, hmmm
> 
>  weird.  you installed the gstreamer1-libav package? It doesn't have that 
>  version number, the libav package is something seperate.  You need to 
>  install that specific package it is def in rpmfusion repos.  I don't 
>  believe you need any other gstreamer package to stream mp4 but you 
>  might. maybe ffmpeg, but idoubt it.
> >>>
> >>> you can also try using a debian template instead and see if firefox 
> >>> stream the mp4 by default but if not you will need the same package but 
> >>> maybe its easier to find and install from debian repo.
> >>>
> >>
> >> fedora is weird... maby because i always worked with debian.
> >> if i look in the software center, then i see gstreamer-extra
> >> installed... gstreamer-libav is listed but i can not install it there...
> >> is there somewhere a block for other sources?
> >>
> >> if i go to see the software-sources of the software center, so i see RPM
> >> Fusion free updates and nonfree updates
> >>
> >> i also deinstalled the other gstreamer
> >>
> >> i made a new standalone VM with debian and there i have
> >> gstreamer1.0-libav (this is the whole name), so the stream works with
> >> firefox now. How can i check, if any flash is installed?
> > 
> > I would use the terminal in the template instead to install packages, for 
> > example:
> >  sudo dnf install gstreamer1-libav
> > 
> > to remove a package for example:
> > sudo dnf remove gstreamer1-libav
> > 
> > to search for one
> > 
> > sudo dnf search gstreamer
> > 
> > 
> > strange, not sure why the template is not starting now if you uninstalled a 
> > gstreamer package.   Did any other packages get removed along with it?
> > 
> 
> i think not, i did it over the software center.
> can not start any fedora VM now if i restart the running ones.

did you hustdown the template first?

-- 
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/2791bfa0-d79a-450e-9f8a-53f2ee3e5cae%40googlegroups.com.
For more options,

[qubes-users] Re: Videostream with Qubes??



Am 03/11/2017 um 04:16 PM schrieb cooloutac:
> On Saturday, March 11, 2017 at 9:54:33 AM UTC-5, evo wrote:
>> Am 03/11/2017 um 02:24 AM schrieb cooloutac:
>>> On Friday, March 10, 2017 at 8:22:51 PM UTC-5, cooloutac wrote:
 On Friday, March 10, 2017 at 6:17:37 PM UTC-5, evo wrote:
> Am 03/10/2017 um 07:18 PM schrieb cooloutac:
>> On Friday, March 10, 2017 at 4:14:22 AM UTC-5, evo wrote:
>>> Am 03/10/2017 um 05:45 AM schrieb cooloutac:
 On Thursday, March 9, 2017 at 11:43:37 PM UTC-5, cooloutac wrote:
> On Thursday, March 9, 2017 at 1:44:38 PM UTC-5, evo wrote:
>> Hello!
>>
>> i have problems with the most streams on the net.
>> Youtube is ok, but i suppose rather slow.
>>
>> I think, this is the thing with flash, HTML5 and openH264.
>> H264 is deactivated and if i want to activate it, it seems to be not
>> possible.
>>
>> Is it so, that HTML5 needs H264?
>> Or is it so, that i need flash for every other stream.
>> I tried also some links, that should be HTML5, but they were not
>> possible... maby they were not really in HTML5 or HTML5 does't work 
>> good.
>>
>> Do somebody has an idea?
>
> whats the templatevm its based on fedora or debian?  If fedora you 
> have to enable rpmfusion and install gstreamer package to get that 
> format.  I forget exactly which one though man.  I think i posted 
> about it here once i;ll t ry tolook.

 gstreamer1-libav

 https://groups.google.com/forum/#!searchin/qubes-users/gstreamer1$20libav%7Csort:relevance/qubes-users/HzzQWXU7nzE/ZXSbhStPJwAJ

>>>
>>> i run fedora 23 on it, rpm fusion is almost on... but i can not find
>>> gstreamer1-libav on the server... strange
>>
>> hmm... did you install both rpm fusion free and nonfree?  Im not sure 
>> which one its in. 
>>
>> Also make sure you looking gstreamer1 and not gstreamer.
>>
>> Its in there somewhere and it will play the mp4 streams on firefox 
>> without flash.  Maybe just search gstreamer1 and scroll through the list 
>> maybe I spelled it wrong. look for the libav one.
>>
>> https://www.rpmfind.net/linux/rpm2html/search.php?query=gstreamer1-libav
>>
>
> hmm... now i checked it again... i have gstreamer1-1.6.4-1 already
> installed... but firefox still do not want to play, hmmm

 weird.  you installed the gstreamer1-libav package? It doesn't have that 
 version number, the libav package is something seperate.  You need to 
 install that specific package it is def in rpmfusion repos.  I don't 
 believe you need any other gstreamer package to stream mp4 but you might. 
 maybe ffmpeg, but idoubt it.
>>>
>>> you can also try using a debian template instead and see if firefox stream 
>>> the mp4 by default but if not you will need the same package but maybe its 
>>> easier to find and install from debian repo.
>>>
>>
>> fedora is weird... maby because i always worked with debian.
>> if i look in the software center, then i see gstreamer-extra
>> installed... gstreamer-libav is listed but i can not install it there...
>> is there somewhere a block for other sources?
>>
>> if i go to see the software-sources of the software center, so i see RPM
>> Fusion free updates and nonfree updates
>>
>> i also deinstalled the other gstreamer
>>
>> i made a new standalone VM with debian and there i have
>> gstreamer1.0-libav (this is the whole name), so the stream works with
>> firefox now. How can i check, if any flash is installed?
> 
> I would use the terminal in the template instead to install packages, for 
> example:
>  sudo dnf install gstreamer1-libav
> 
> to remove a package for example:
> sudo dnf remove gstreamer1-libav
> 
> to search for one
> 
> sudo dnf search gstreamer
> 
> 
> strange, not sure why the template is not starting now if you uninstalled a 
> gstreamer package.   Did any other packages get removed along with it?
> 

i think not, i did it over the software center.
can not start any fedora VM now if i restart the running ones.

-- 
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/919ed4ff-4a18-b87f-ffcf-2b4533b3aace%40aliaks.de.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Videostream with Qubes??

On Saturday, March 11, 2017 at 9:54:33 AM UTC-5, evo wrote:
> Am 03/11/2017 um 02:24 AM schrieb cooloutac:
> > On Friday, March 10, 2017 at 8:22:51 PM UTC-5, cooloutac wrote:
> >> On Friday, March 10, 2017 at 6:17:37 PM UTC-5, evo wrote:
> >>> Am 03/10/2017 um 07:18 PM schrieb cooloutac:
>  On Friday, March 10, 2017 at 4:14:22 AM UTC-5, evo wrote:
> > Am 03/10/2017 um 05:45 AM schrieb cooloutac:
> >> On Thursday, March 9, 2017 at 11:43:37 PM UTC-5, cooloutac wrote:
> >>> On Thursday, March 9, 2017 at 1:44:38 PM UTC-5, evo wrote:
>  Hello!
> 
>  i have problems with the most streams on the net.
>  Youtube is ok, but i suppose rather slow.
> 
>  I think, this is the thing with flash, HTML5 and openH264.
>  H264 is deactivated and if i want to activate it, it seems to be not
>  possible.
> 
>  Is it so, that HTML5 needs H264?
>  Or is it so, that i need flash for every other stream.
>  I tried also some links, that should be HTML5, but they were not
>  possible... maby they were not really in HTML5 or HTML5 does't work 
>  good.
> 
>  Do somebody has an idea?
> >>>
> >>> whats the templatevm its based on fedora or debian?  If fedora you 
> >>> have to enable rpmfusion and install gstreamer package to get that 
> >>> format.  I forget exactly which one though man.  I think i posted 
> >>> about it here once i;ll t ry tolook.
> >>
> >> gstreamer1-libav
> >>
> >> https://groups.google.com/forum/#!searchin/qubes-users/gstreamer1$20libav%7Csort:relevance/qubes-users/HzzQWXU7nzE/ZXSbhStPJwAJ
> >>
> >
> > i run fedora 23 on it, rpm fusion is almost on... but i can not find
> > gstreamer1-libav on the server... strange
> 
>  hmm... did you install both rpm fusion free and nonfree?  Im not sure 
>  which one its in. 
> 
>  Also make sure you looking gstreamer1 and not gstreamer.
> 
>  Its in there somewhere and it will play the mp4 streams on firefox 
>  without flash.  Maybe just search gstreamer1 and scroll through the list 
>  maybe I spelled it wrong. look for the libav one.
> 
>  https://www.rpmfind.net/linux/rpm2html/search.php?query=gstreamer1-libav
> 
> >>>
> >>> hmm... now i checked it again... i have gstreamer1-1.6.4-1 already
> >>> installed... but firefox still do not want to play, hmmm
> >>
> >> weird.  you installed the gstreamer1-libav package? It doesn't have that 
> >> version number, the libav package is something seperate.  You need to 
> >> install that specific package it is def in rpmfusion repos.  I don't 
> >> believe you need any other gstreamer package to stream mp4 but you might. 
> >> maybe ffmpeg, but idoubt it.
> > 
> > you can also try using a debian template instead and see if firefox stream 
> > the mp4 by default but if not you will need the same package but maybe its 
> > easier to find and install from debian repo.
> > 
> 
> fedora is weird... maby because i always worked with debian.
> if i look in the software center, then i see gstreamer-extra
> installed... gstreamer-libav is listed but i can not install it there...
> is there somewhere a block for other sources?
> 
> if i go to see the software-sources of the software center, so i see RPM
> Fusion free updates and nonfree updates
> 
> i also deinstalled the other gstreamer
> 
> i made a new standalone VM with debian and there i have
> gstreamer1.0-libav (this is the whole name), so the stream works with
> firefox now. How can i check, if any flash is installed?

I would use the terminal in the template instead to install packages, for 
example:
 sudo dnf install gstreamer1-libav

to remove a package for example:
sudo dnf remove gstreamer1-libav

to search for one

sudo dnf search gstreamer


strange, not sure why the template is not starting now if you uninstalled a 
gstreamer package.   Did any other packages get removed along with 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/520d2e28-aeed-430f-878c-210681300f37%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Videostream with Qubes??



Am 03/11/2017 um 02:24 AM schrieb cooloutac:
> On Friday, March 10, 2017 at 8:22:51 PM UTC-5, cooloutac wrote:
>> On Friday, March 10, 2017 at 6:17:37 PM UTC-5, evo wrote:
>>> Am 03/10/2017 um 07:18 PM schrieb cooloutac:
 On Friday, March 10, 2017 at 4:14:22 AM UTC-5, evo wrote:
> Am 03/10/2017 um 05:45 AM schrieb cooloutac:
>> On Thursday, March 9, 2017 at 11:43:37 PM UTC-5, cooloutac wrote:
>>> On Thursday, March 9, 2017 at 1:44:38 PM UTC-5, evo wrote:
 Hello!

 i have problems with the most streams on the net.
 Youtube is ok, but i suppose rather slow.

 I think, this is the thing with flash, HTML5 and openH264.
 H264 is deactivated and if i want to activate it, it seems to be not
 possible.

 Is it so, that HTML5 needs H264?
 Or is it so, that i need flash for every other stream.
 I tried also some links, that should be HTML5, but they were not
 possible... maby they were not really in HTML5 or HTML5 does't work 
 good.

 Do somebody has an idea?
>>>
>>> whats the templatevm its based on fedora or debian?  If fedora you have 
>>> to enable rpmfusion and install gstreamer package to get that format.  
>>> I forget exactly which one though man.  I think i posted about it here 
>>> once i;ll t ry tolook.
>>
>> gstreamer1-libav
>>
>> https://groups.google.com/forum/#!searchin/qubes-users/gstreamer1$20libav%7Csort:relevance/qubes-users/HzzQWXU7nzE/ZXSbhStPJwAJ
>>
>
> i run fedora 23 on it, rpm fusion is almost on... but i can not find
> gstreamer1-libav on the server... strange

 hmm... did you install both rpm fusion free and nonfree?  Im not sure 
 which one its in. 

 Also make sure you looking gstreamer1 and not gstreamer.

 Its in there somewhere and it will play the mp4 streams on firefox without 
 flash.  Maybe just search gstreamer1 and scroll through the list maybe I 
 spelled it wrong. look for the libav one.

 https://www.rpmfind.net/linux/rpm2html/search.php?query=gstreamer1-libav

>>>
>>> hmm... now i checked it again... i have gstreamer1-1.6.4-1 already
>>> installed... but firefox still do not want to play, hmmm
>>
>> weird.  you installed the gstreamer1-libav package? It doesn't have that 
>> version number, the libav package is something seperate.  You need to 
>> install that specific package it is def in rpmfusion repos.  I don't believe 
>> you need any other gstreamer package to stream mp4 but you might. maybe 
>> ffmpeg, but idoubt it.
> 
> you can also try using a debian template instead and see if firefox stream 
> the mp4 by default but if not you will need the same package but maybe its 
> easier to find and install from debian repo.
> 


after i tried to deinstall the other gstreamer on fedora template, i can
not start the template anymore... with the fail: can not start
qrexec-daemon.  WTF???

-- 
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/e56c0601-2be2-b3cf-f5e8-e181ac552eab%40aliaks.de.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Videostream with Qubes??

Am 03/11/2017 um 02:24 AM schrieb cooloutac:
> On Friday, March 10, 2017 at 8:22:51 PM UTC-5, cooloutac wrote:
>> On Friday, March 10, 2017 at 6:17:37 PM UTC-5, evo wrote:
>>> Am 03/10/2017 um 07:18 PM schrieb cooloutac:
 On Friday, March 10, 2017 at 4:14:22 AM UTC-5, evo wrote:
> Am 03/10/2017 um 05:45 AM schrieb cooloutac:
>> On Thursday, March 9, 2017 at 11:43:37 PM UTC-5, cooloutac wrote:
>>> On Thursday, March 9, 2017 at 1:44:38 PM UTC-5, evo wrote:
 Hello!

 i have problems with the most streams on the net.
 Youtube is ok, but i suppose rather slow.

 I think, this is the thing with flash, HTML5 and openH264.
 H264 is deactivated and if i want to activate it, it seems to be not
 possible.

 Is it so, that HTML5 needs H264?
 Or is it so, that i need flash for every other stream.
 I tried also some links, that should be HTML5, but they were not
 possible... maby they were not really in HTML5 or HTML5 does't work 
 good.

 Do somebody has an idea?
>>>
>>> whats the templatevm its based on fedora or debian?  If fedora you have 
>>> to enable rpmfusion and install gstreamer package to get that format.  
>>> I forget exactly which one though man.  I think i posted about it here 
>>> once i;ll t ry tolook.
>>
>> gstreamer1-libav
>>
>> https://groups.google.com/forum/#!searchin/qubes-users/gstreamer1$20libav%7Csort:relevance/qubes-users/HzzQWXU7nzE/ZXSbhStPJwAJ
>>
>
> i run fedora 23 on it, rpm fusion is almost on... but i can not find
> gstreamer1-libav on the server... strange

 hmm... did you install both rpm fusion free and nonfree?  Im not sure 
 which one its in. 

 Also make sure you looking gstreamer1 and not gstreamer.

 Its in there somewhere and it will play the mp4 streams on firefox without 
 flash.  Maybe just search gstreamer1 and scroll through the list maybe I 
 spelled it wrong. look for the libav one.

 https://www.rpmfind.net/linux/rpm2html/search.php?query=gstreamer1-libav

>>>
>>> hmm... now i checked it again... i have gstreamer1-1.6.4-1 already
>>> installed... but firefox still do not want to play, hmmm
>>
>> weird.  you installed the gstreamer1-libav package? It doesn't have that 
>> version number, the libav package is something seperate.  You need to 
>> install that specific package it is def in rpmfusion repos.  I don't believe 
>> you need any other gstreamer package to stream mp4 but you might. maybe 
>> ffmpeg, but idoubt it.
> 
> you can also try using a debian template instead and see if firefox stream 
> the mp4 by default but if not you will need the same package but maybe its 
> easier to find and install from debian repo.
> 

fedora is weird... maby because i always worked with debian.
if i look in the software center, then i see gstreamer-extra
installed... gstreamer-libav is listed but i can not install it there...
is there somewhere a block for other sources?

if i go to see the software-sources of the software center, so i see RPM
Fusion free updates and nonfree updates

i also deinstalled the other gstreamer

i made a new standalone VM with debian and there i have
gstreamer1.0-libav (this is the whole name), so the stream works with
firefox now. How can i check, if any flash is installed?

-- 
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/2074a30e-1659-f88a-4ed2-20c43e4793f8%40aliaks.de.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: problem with qubes xfce menu

2017-03-11 Thread haaber

On 03/11/2017 01:44 PM, Unman wrote:
 Hello,
 I realise with surprise that some items in the "Q"-symbol that gives 
 the
 xfce menu have disappeared: the settings menu (!), the link to a dom0
 termnal  & the link to debian-8 template.

 Is there a way to recreate these items? Bernhard
>>>
> 
> Hello Bernhard,
> 
> I should apologise for the tone of my last email to you, which was
> pretty short. It was the end of a stressful day.

I read your very detailed and patient answers on this list for a while,
and this last one is another example. Thanks! You see, you were right, I
did not search profoundly before filling up your mailboxes with my
question. Meanwhile I did, yet without success. The log-in-logout trick
does not work.

> If ALL your dom0 entries have disappeared then I suspect that the desktop
> files have been deleted from those directories, or moved.
> So, have a look in /usr//share/applications - there should be many
> .desktop files.
There is not a single one. Strange. I had a battery failure with several
unwanted hard power-offs. Maybe orphaned inodes were removed when
rebooting? At least we have localized my problem :)

> If there aren't all is not lost - you can look for them using 'find -name
> *desktop' as root - I'd look in /lib., /usr and /var.
> What you want are files that aren't prefixed "qubes", but just say (e.g
> xfce4-terminal.desktop) If you find one open it in a text editor and
> make sure that it contains a line "Exec "
no *xfce*.desktop file in /var or /lib. I have 6 such files in /usr , 3
of which contain the word "exec":

I have no sdt fedora left over, only cloned & enriched specialized
f-24-minimals.
As you said, for dom0 I only need xfce4-terminal.desktop (no copy left
apart "helpers") and xfce4-settings-manager.desktop (no copy either).

> Alternatively, reinstalling the packages you are concerned about should,
> I think, reinstate the desktop files. 
> sudo dnf reinstall 

I accumulate problems, it seems:
[me@dom0] sudo dnf reinstall xfce4-settings-qubes
Failed to synchronize cache for repo 'qubes-dom0-cached', disabling.
Installed package xfce4-settings-qubes-3.2.2-1.fc23.x86_64 (from
anaconda) not available.
Error: Nothing to do.

> Or you could write your own .desktop file, or search for one on the web.
> If you are really stuck I can send you some.
Or I follow  Raahelps comment and reinstall everything :)  In the
meanwhile  xfce4-terminal.desktop would be nice to have (could you send
it as PM, please)? I don't really need the settings menu - and in case I
should be able to run it from the command line, don't I? But I can't
live without a terminal.

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/dd466b4a-e183-e443-c78e-752e6120ebad%40web.de.
For more options, visit https://groups.google.com/d/optout.

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

On 03/11/2017 08:10 AM, Unman wrote:

Anyway, it's a argument that could go on. I dont agree that "the
chance for improved security comes for free". It's absolutely clear that
Qubes aims to balance security with usability - some of the compromises
that have been made seem wrong to me, this isnt one of them. I take
steps to mitigate changes I dont like - you should do the same if you
want a password on root access.
But for most users (particulary new users) there is a cost to
introducing passwrd access, and it's convenience.

Its not based on passwords. Its the same Yes/No dom0 auth dialog that
controls qvm-copy. Except it remembers auth for a certain amount of time
the way sudo normally does.

Notice the detractors haven't tried it and think it means assigning
passwords to VMs.

Joanna refers to this
in the explanation. It's clear from the forums that many users struggle
with the Qubes ideas anyway - I cant see that this change would make
things easier for them. (Presumably you would need to have different
password across different templates.)

Most are already used to UAC Yes/No prompt on Windows. This is pretty
similar.

There is another, much bigger issue: We don't want our systems to
become a zoo of infected VMs with malware thrashing about in them
(and on our networks!) with us as zookeepers. That would be
irresponsible.

I didn't purport to provide "the answer"... strawman argument.

What it comes down to is a matter of degrees and costs.

As far as I can see most people, particularly new users with some linux
background, just dont like the idea of passwordless root. That's fine.
That's why there's a page devoted to it, and a solution.

Well, its still passwordless with the vm-sudo auth.

You should try it. :)

There's no real security
advantage in enabling it but if you want to you can.

I think its a mistake to deny that guest OS permissions can contribute
some additional margin of security.

If it means a less attractive environment for script kiddies to raise
hell--- chewing up resources, attacking other computers, creating
footholds for more advanced threats--- then I can invest 3 min. to
enable it.

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett

--
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/8c88f706-e272-90f6-7aa3-986b20b97098%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

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

On Sat, Mar 11, 2017 at 01:10:08PM +0100, Alex wrote:
> On 03/11/2017 12:14 PM, Chris Laprise wrote:
> > On 03/11/2017 04:20 AM, Alex wrote:
> >> the only really read-write directories (their changes are actually
> >> persisted) are /home and /usr/local.
> > 
> > That is enough to be able to persist.
> Yes, and that doesn't even need root :) So, both having root or not,
> there is some degree of persistence attainable.
> 
> Installing via DNF or any other package manager is an easy route to put
> files in the relevant "system" directories, but since these are not
> persisted, it's actually more convenient, from a malware point of view,
> to just place them in the home of the user and set up some kind of
> autostart (eg bashrc, or systemd user units, or gnome autostarts).
> 
> >> 
> >> As the others already stated there could be problems for the
> >> actually running session, i.e. the rogue command could siphon all
> >> your data to a remote location, but it would be only able to access
> >> data in that AppVM and not the others. This action would not need
> >> any root access, because all data is from the very same user that
> >> downloaded/started the rogue program in the first place, so it
> >> already has access.
> >> 
> >> The only advantage that root access would give could arguably be 
> >> persistance (i.e. installation, as you suggested with DNF), but
> >> that advantage is fake and will vanish on AppVM reboot.
> > 
> > Disagree there. Root access would bestow greater ability to launch 
> > attacks against VM isolation. That would be rare in of itself, but
> > the chance for improved security comes for free.
> And that's the point where I agree with you, I overlooked the
> exploitability of Xen virtual devices in my original answer. Software
> running as root has easier access to the Xen para-vm communication
> devices, and that may lead to crossing the VM isolation.
> 

Is this actually true? I dont think that root in a qube has any "easier
access" to the Xen communication devices.Exploits may require root, but
they need not. 

Anyway, it's a argument that could go on. I dont agree that "the
chance for improved security comes for free". It's absolutely clear that
Qubes aims to balance security with usability - some of the compromises
that have been made seem wrong to me, this isnt one of them. I take
steps to mitigate changes I dont like - you should do the same if you
want a password on root access.
But for most users (particulary new users) there is a cost to
introducing passwrd access, and it's convenience. Joanna refers to this
in the explanation. It's clear from the forums that many users struggle
with the Qubes ideas anyway - I cant see that this change would make
things easier for them. (Presumably you would need to have different
password across different templates.)

> 
> > There is another, much bigger issue: We don't want our systems to
> > become a zoo of infected VMs with malware thrashing about in them
> > (and on our networks!) with us as zookeepers. That would be
> > irresponsible.

The answer to this is encouraging users to make good use of isolation,
qube use and Qubes features. That isnt irresponsible. It's a way of
dealing with the problem. I think you would need to develop a much more
detailed argument to convince me that the answer to malware infections
is putting a password on root access.

As far as I can see most people, particularly new users with some linux
background, just dont like the idea of passwordless root. That's fine.
That's why there's a page devoted to it, and a solution.

> > 
> > Qubes' abilities should not be framed in a way that would encourage 
> > that. Even if isolation works 100% of the time, we should view that
> > as the opportunity to remove and prevent malware---preferably with
> > some help from the guest OS.
> > 
> > Put another way: If VMs were teeth, would you prefer to have one
> > cavity this year, or seven?
> That's a gross oversimplification of the situation. In Qubes there are
> several AppVM that are "all created equal", but to the user there MUST
> be some difference, and he is advised to make use of the colored labels
> to emphasize and remind these differences.
> 
> While I don't certainly want to have all red-labeled VMs (i.e. the
> malware zoo situation you propose), I'm pretty sure I will not trust
> some VMs because they are used with dangerous websites/software. I will
> consider them dangerous even with passwordless sudo disbled, because
> there may be some 0-day that has been exploited for a local privilege
> escalation that makes sudo a non-problem.
> 
> I make sure to periodically purge those VMs (which I named dump-0,
> dump-1, etc to even remember that they are not to be trusted and because
> when I forget why they are here (hence, the cryptic name) they can be
> safely deleted), and because of the periodic update restart cycles all
> other AppVMs are not always on, so malware cannot rely on system level
> persistence there.

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


On 03/11/2017 07:10 AM, Alex wrote:

On 03/11/2017 12:14 PM, Chris Laprise wrote:

On 03/11/2017 04:20 AM, Alex wrote:

the only really read-write directories (their changes are actually
persisted) are /home and /usr/local.


That is enough to be able to persist.

Yes, and that doesn't even need root :) So, both having root or not,
there is some degree of persistence attainable.

Installing via DNF or any other package manager is an easy route to put
files in the relevant "system" directories, but since these are not
persisted, it's actually more convenient, from a malware point of view,
to just place them in the home of the user and set up some kind of
autostart (eg bashrc, or systemd user units, or gnome autostarts).



As the others already stated there could be problems for the
actually running session, i.e. the rogue command could siphon all
your data to a remote location, but it would be only able to access
data in that AppVM and not the others. This action would not need
any root access, because all data is from the very same user that
downloaded/started the rogue program in the first place, so it
already has access.

The only advantage that root access would give could arguably be
persistance (i.e. installation, as you suggested with DNF), but
that advantage is fake and will vanish on AppVM reboot.


Disagree there. Root access would bestow greater ability to launch
attacks against VM isolation. That would be rare in of itself, but
the chance for improved security comes for free.

And that's the point where I agree with you, I overlooked the
exploitability of Xen virtual devices in my original answer. Software
running as root has easier access to the Xen para-vm communication
devices, and that may lead to crossing the VM isolation.



There is another, much bigger issue: We don't want our systems to
become a zoo of infected VMs with malware thrashing about in them
(and on our networks!) with us as zookeepers. That would be
irresponsible.

Qubes' abilities should not be framed in a way that would encourage
that. Even if isolation works 100% of the time, we should view that
as the opportunity to remove and prevent malware---preferably with
some help from the guest OS.

Put another way: If VMs were teeth, would you prefer to have one
cavity this year, or seven?

That's a gross oversimplification of the situation. In Qubes there are
several AppVM that are "all created equal", but to the user there MUST
be some difference, and he is advised to make use of the colored labels
to emphasize and remind these differences.

While I don't certainly want to have all red-labeled VMs (i.e. the
malware zoo situation you propose), I'm pretty sure I will not trust
some VMs because they are used with dangerous websites/software. I will
consider them dangerous even with passwordless sudo disbled, because
there may be some 0-day that has been exploited for a local privilege
escalation that makes sudo a non-problem.


At those moments when malware has an opportunity to take hold or 
escalate, labels don't matter and you probably won't know. Neither you 
nor the attacker has perfect knowledge, and the attacker may find the 
anticipated vuln to be patched.


In that case, Linux has at least bought you some time.



I make sure to periodically purge those VMs (which I named dump-0,
dump-1, etc to even remember that they are not to be trusted and because
when I forget why they are here (hence, the cryptic name) they can be
safely deleted), and because of the periodic update restart cycles all
other AppVMs are not always on, so malware cannot rely on system level
persistence there. In those "safer" appVMs, I don't open suspicious
e-mails nor visit doubtful websites; activities that I try to perform in
the unsafe AppVMs.

TL;DR: there's no malware disadvantage if there is no passwordless sudo
in Qubes (it can persist as the user, and can still see all the files of
that user), and there's very little advantage (temporary persistence in
"system" directories) that may even become a decoy of some sort with
passwordless sudo being enabled.


You seem to be going in the direction where a user does not / cannot use 
storage in a normal way... everything is transient. Definitely not a 
personal computing model, which is what Qubes aims for.


To put it another way, Qubes is not TAILS.


range from "is having to remember several different root/sudo passwords
really safer?


It doesn't work that way. Auth is channeled through a dom0 Yes/No prompt 
(like copying between VMs), not a password prompt.



to
"how many root actions does the user do in an AppVM? Will this impact
his usual workflow, or will it be a corner case?"


The client OS already has experience with that issue and struck a 
balance. In the case of Debian and Fedora, the authorization persists 
for a certain amount of time during a session so you are not prompted 
often. The frequency is a bit more (due to separate VMs) but you only 
have to hit Enter.



passing through

Re: [qubes-users] Re: problem with qubes xfce menu

On Fri, Mar 10, 2017 at 09:25:23AM +0100, haaber wrote:
> On 03/10/2017 08:05 PM, cooloutac wrote:
> >> Hello,
> >> I realise with surprise that some items in the "Q"-symbol that gives 
> >> the
> >> xfce menu have disappeared: the settings menu (!), the link to a dom0
> >> termnal  & the link to debian-8 template.
> >>
> >> Is there a way to recreate these items? Bernhard
> >
> >>>
> >>> To recreate the debian-8 menu you should be able to run
> >>> qvm-sync-appmenus. (You'll need to start the template first.)
> >>> This is referred to at www.qubes-os.org/doc/managing-appvm-shortcuts
> >>>
> >>> There have been numerous threads about using and abusing the menu
> >>> system in xfce - please search and read them before posting here.
> >>
> >> main problem with xfce menu editor is it doesn't let you "abuse" it lol.  
> >> like creating or deleting new entries.  Which would be much easier then 
> >> editing some files like a developer.
> >>
> >> Would that command also help other default shortcuts like shortcut for 
> >> dom0 desktop settings?
> > 
> > Actually  I gotta say Bernhard if that happened to me I would freak the 
> > heck out and probably reinstall the whole system from another iso.  Do you 
> > know how it happened or what you were doing possibly cuased it, if I'm 
> > understanding you correctly? You are missing the settings shortcut? Were 
> > you tinkering with anything?
> 
> This is not the only 'strange' thing, and I wait the first occasion of 1
> day without anything good to do to reinstall everything. Hope this
> happens before Q4 comes out .. I already tested emergency backup of
> data, via a live-usb key break-in into my crypto-descs. Knowing that I
> am able to do that is relaxing a lot :)
> 
> So: Unman's command worked for debian menu item, but it does not work
> for dom0.
> Would be too easy! But he pointed a page to read, so I rtfm.
> 
> Thnaks a lot, guys! Bernhard
> 

Hello Berhard,

I should apologise for the tone of my last email to you, which was
pretty short. It was the end of a stressful day.

Xfce menus are (relatively) easy to understand.

There are environment variables that are important:
you can see these by running 'env|grep XDG' in dom0.
XDG_DATA_DIRS, XDG_MENU_PREFIX and XDG_CONFIG_DIRS are important in this
context.

My guess is that you have CONFIG_DIRS at /etc/xdg.
That mean that your menus are sourced from /etc/xdg/menus.
If XDG_MENU_PREFIX is xfce- then the main menu will be at
/etc/xdg/menus/xfce-applications.menu

None of the other files in that directory matter for the moment.
Menus are built by combining the contents of .desktop files, and a bit
of magic to group them together. It's the .desktop files that are
important.
These are found (among other places) in XDG_DATA_DIRS - usually
/usr/share/applications and /usr/local/share/applications

If ALL your dom0 entries have disappeared then I suspect that the desktop
files have been deleted from those directories, or moved.

So, have a look in /usr//share/applications - there should be many
.desktop files.

If there aren't all is not lost - you can look for them using 'find -name
*desktop' as root - I'd look in /lib., /usr and /var.
NB Dont get excited about any desktop files you see in xfce/helpers -
those aren't what you want.
What you want are files that aren't prefixed "qubes", but just say (e.g
xfce4-terminal.desktop) If you find one open it in a text editor and
make sure that it contains a line "Exec "

If you have a fedora template then  you could look in the
/etc/share/applications folder there, find the desktop files you want and
copy them to dom0. There isn't a simple way of doing this but there is a
guide here:
www.qubes-os.org/doc/copy-from-dom0/

Alternatively, reinstalling the packages you are concerned about should,
I think, reinstate the desktop files. 
sudo dnf reinstall 

Or you could write your own .desktop file, or search for one on the web.
If you are really stuck I can send you some.

Note that you don't need ALL the shortcuts for dom0, because you
wouldn't/shouldn't be running programs there- so you only need menu
entries for the programs that you do need - probably terminal and
Settings manager.

Once you have the .desktop files in /usr/share/applications, the menu
entries should reappear - you can force this by running "xfdesktop
--reload", or by logging out and logging back in.

I hope this is of some help. If you need further help let us know.

unman

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

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

2017-03-11 Thread Alex

On 03/11/2017 12:14 PM, Chris Laprise wrote:
> On 03/11/2017 04:20 AM, Alex wrote:
>> the only really read-write directories (their changes are actually
>> persisted) are /home and /usr/local.
> 
> That is enough to be able to persist.
Yes, and that doesn't even need root :) So, both having root or not,
there is some degree of persistence attainable.

Installing via DNF or any other package manager is an easy route to put
files in the relevant "system" directories, but since these are not
persisted, it's actually more convenient, from a malware point of view,
to just place them in the home of the user and set up some kind of
autostart (eg bashrc, or systemd user units, or gnome autostarts).

>> 
>> As the others already stated there could be problems for the
>> actually running session, i.e. the rogue command could siphon all
>> your data to a remote location, but it would be only able to access
>> data in that AppVM and not the others. This action would not need
>> any root access, because all data is from the very same user that
>> downloaded/started the rogue program in the first place, so it
>> already has access.
>> 
>> The only advantage that root access would give could arguably be 
>> persistance (i.e. installation, as you suggested with DNF), but
>> that advantage is fake and will vanish on AppVM reboot.
> 
> Disagree there. Root access would bestow greater ability to launch 
> attacks against VM isolation. That would be rare in of itself, but
> the chance for improved security comes for free.
And that's the point where I agree with you, I overlooked the
exploitability of Xen virtual devices in my original answer. Software
running as root has easier access to the Xen para-vm communication
devices, and that may lead to crossing the VM isolation.

> There is another, much bigger issue: We don't want our systems to
> become a zoo of infected VMs with malware thrashing about in them
> (and on our networks!) with us as zookeepers. That would be
> irresponsible.
> 
> Qubes' abilities should not be framed in a way that would encourage 
> that. Even if isolation works 100% of the time, we should view that
> as the opportunity to remove and prevent malware---preferably with
> some help from the guest OS.
> 
> Put another way: If VMs were teeth, would you prefer to have one
> cavity this year, or seven?
That's a gross oversimplification of the situation. In Qubes there are
several AppVM that are "all created equal", but to the user there MUST
be some difference, and he is advised to make use of the colored labels
to emphasize and remind these differences.

While I don't certainly want to have all red-labeled VMs (i.e. the
malware zoo situation you propose), I'm pretty sure I will not trust
some VMs because they are used with dangerous websites/software. I will
consider them dangerous even with passwordless sudo disbled, because
there may be some 0-day that has been exploited for a local privilege
escalation that makes sudo a non-problem.

I make sure to periodically purge those VMs (which I named dump-0,
dump-1, etc to even remember that they are not to be trusted and because
when I forget why they are here (hence, the cryptic name) they can be
safely deleted), and because of the periodic update restart cycles all
other AppVMs are not always on, so malware cannot rely on system level
persistence there. In those "safer" appVMs, I don't open suspicious
e-mails nor visit doubtful websites; activities that I try to perform in
the unsafe AppVMs.

TL;DR: there's no malware disadvantage if there is no passwordless sudo
in Qubes (it can persist as the user, and can still see all the files of
that user), and there's very little advantage (temporary persistence in
"system" directories) that may even become a decoy of some sort with
passwordless sudo being enabled.

In my humble opinion, this absence of actual advantages or disadvantages
makes the whole situation irrelevant from a security standpoint. There
are other issues that should be taken into account for a more complete
answer than just security as holy grail, and they can safely be
introduced in the decision when the security outcome is the same. They
range from "is having to remember several different root/sudo passwords
really safer? What if the user fails to use different passwords?" to
"how many root actions does the user do in an AppVM? Will this impact
his usual workflow, or will it be a corner case?" passing through "what
if the user focuses on keeping the systems updated (i.e.
excluding/fixing vulnerabilities that may contain privilege escalation
that bypasses the sudo problem) instead of relying on a complex set of
keys and permissions that may be completely bypassed by some security
exploit?"

-- 
Alex

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

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