[qubes-users] !!!! Greetings !!!!

[kong khemara]

Hello,
I am Barr Kong Khemara, I humbly ask if you are related to my client who died 
couple of
years ago in a car accident here in my country Cambodia. I wish to also inquire 
if
it is possible to have different families with the same last name as yours by 
coincidence
who do not share the same common roots? Kindly get back to me if your email is 
still
Valid to enable me give you the details of my message or make headway in my 
search.
Regards,
Kong Khemara

-- 
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/SINPR03MB2192A018C20625F0EE5E28E0A4370%40SINPR03MB2192.apcprd03.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?

[Jean-Philippe Ouellet]

On Thu, Mar 30, 2017 at 6:21 PM, Shane Optima  wrote:
> Maybe if you (or someone) could write a Firefox extension to modify all 
> browser page titles to be a concatenation of the page title and a short token 
> of characters generated from a salted hash of the URL (so that I don't have 
> to deal with any more hyperbole out of people like M. Ouelette), I could 
> write the Dom0 bash bit. Or vice versa. Couldn't promise delivery on a tight 
> deadline, though.

If you're going to write an extension then there's no reason to use
window titles since you could communicate over another channel which
is not under full attacker control by default, and wouldn't have
negative UX side-effects of abusing window titles as a communication
mechanism.

Furthermore, it's not hyperbole. Here's a super simple (but likely
quite effective!) exploit which took me a about two minutes to write:

(function() {
  var attack_target = 'Sign in to GitHub · GitHub';
  var saved_title = '';
  var pw = document.querySelector('#password');
  pw.addEventListener('focus', function() {
  saved_title = document.title;
  if (Math.random() < 0.2)
document.title = attack_target;
  });
  pw.addEventListener('blur', function() {
document.title = saved_title;
  });
})();

What you are proposing is simply too dangerous and easy to exploit.
For most threat models, passwords would honestly be safer if saved in
the browser. For the safety of yourself and others, please don't
implement this using window titles as proposed.

Don't get me wrong, your fundamental concept is a good idea, but only
if the password manager authenticates the requesting site in a secure
way. Window titles are absolutely not the way to do that, not even for
an initial version.

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

Re: [qubes-users] Re: Qubes OS 3.1 reaches EOL on 2017-03-29

[Unman]

On Wed, Mar 29, 2017 at 12:22:57AM -0700, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 2017-03-01 01:01, Andrew David Wong wrote:
> > Dear Qubes community,
> > 
> > Qubes OS releases are normally supported for six months after each 
> > subsequent
> > major or minor release (see [Supported Versions] and [Version Scheme]). In
> > accordance with this policy, Qubes 3.1, which was released on 2016-03-09, is
> > scheduled to reach end-of-life (EOL) on 2017-03-29 --- six months after 
> > Qubes
> > 3.2 was released on 2016-09-29. We strongly urge all current Qubes 3.1 
> > users to
> > upgrade to Qubes 3.2 or newer before 2017-03-29. As always, newer releases 
> > are
> > available on the [downloads] page.
> > 
> > You can view this announcement on the Web at:
> > https://www.qubes-os.org/news/2017/03/01/qubes-os-3-1-eol-on-2017-03-29/
> > 
> > [Supported Versions]: https://www.qubes-os.org/doc/supported-versions/
> > [Version Scheme]: https://www.qubes-os.org/doc/version-scheme/
> > [downloads]: https://www.qubes-os.org/downloads/
> > 
> 
> This is a reminder that Qubes 3.1 has now reached EOL as of 2017-03-29.
> Please upgrade to Qubes 3.2 immediately if you have not done so already.
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org

Should we have a concerted effort to assess remaining 3.1 bugs to either
close or relabel as 3.2?

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

Re: [qubes-users] Re: dnf over VPN with qubes-updates-proxy

[Unman]

On Wed, Mar 29, 2017 at 06:02:17AM -0700, Nemo wrote:
> > 
> > You can add the rule like this:
> > 'sudo iptables -I INPUT -p tcp --dport 8082 -j ACCEPT'
> > 
> > '-I INPUT' Inserts the rule at the top of the INPUT chain (You can
> > specify a number here, like '-I INPUT 2' to specify position.)
> > 
> > -p tcp = specifies Protocol is tcp
> > --dport = Destination PORT
> > 
> > Try that and see if it works for you.
> > If this is the solution, (and I think it is), the you can add this line
> > in /rw/config/qubes-user-firewall-script - look at the docs on the Qubes
> > firewall to help here.
> > 
> > This is a known issue in proxyVMS - in fact I've fixed it and that code
> > is merged but, I guess, you havent yet got it.
> > 
> > Make sure you clean up any other changes you may have made getting to
> > this point.
> > 
> > unman
> 
> Thank you! This did fix it.
> 
> Is the proxyVMS update included in the updated qubes-core-vm and 
> qubes-core-vm-systemd packages? If not, how can I make sure I get updates 
> like this in the future?
> 

Yes, that update will find its way in to the stable updates, after it's been
through testing. If you make sure you keep your system updated you will
get that fix.

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

Re: [qubes-users] Upgraded to 3.2, lockscreen accepts ANY password

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-03-30 04:06, to...@vmail.me wrote:
> Both the xscreensaver and the i3lock accept any password. I have
> not manually changed the files in /etc/pam.d/ but note some have 
> the "nullok" option.
> 
> I've run tail -f against /var/log/* and /var/log/*/* but no
> changes occur after locking and unlocking the screen.
> 
> Expected behaviour: the user login password should be required
> before the screen unlocks.
> 
> (this install was upgraded to 3.2 from 3.1 which was upgraded from
> 3.0).
> 
> window manager = i3
> 

Thanks for the report. Tracking the issue here:

https://github.com/QubesOS/qubes-issues/issues/2734

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

iQIcBAEBCgAGBQJY3ZBxAAoJENtN07w5UDAwaVgP/17sFFKc2A5DQgPlqLUC/3Jg
HE1fux9QqM5Lm5s5DjqW3N87GNsbZhq4aVKDEhInggkaeebI3CjvpFGAz2wY/Gta
ZiLpTvObMmak5bJzhtcdKCijU5ulC0oExCh5HbRZDWBNTqpQ0SctZb+hCW4TrwQD
YiioFL0D6Wz6A8KER9cHs2Il744jofLLqzH+YzZnqNXmme0pCtkzfKBrzqQAnbg4
3Qo8vTDqubWOrLrj+dXTGa2UQGTQG2gMpwIib9YxMfgJqRMBFblFFq5383SiQYMN
7l8NTncjVKwckgsG7E1YlPIDUl1ramCxjDKtknnzoLqpfrbG7TG5pnV86MG7yHiK
QSs9rAoUFw4ew2/8ZhHW422y3mkN6d0Gv0rNfbR9mFxiqZGrg9U6TJ3DPHuSPIg/
rIBQqdF+r+dF7/ryA2ygDF0Gmlb3Lek5Oo0S5M6QHkWuo7j1jfENtEPqyTock3yJ
xs+EeA6OVv7xqByLtzHmv38tLOQqQz1XuhXrMO5SpTtKYe2fn2ireJkgPYI2BL/D
pmkKMcbQDxZXT9qgLwBOOPbhPIGqhqmRXBhR6MNPZkG9yI8frUeX9AcDJ5q/Chlf
kGRY1T3uUO0/OvanGTrFVF9un50vT9sxFLE0kr0X+Kd44qDVFHh2ldJuwbIcdTQS
a5+uqoVH5LgaGZeeI/Ag
=8lHC
-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/0ce6450f-0647-4aab-a9c0-8e7ef261fdfc%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Maybe a silly question

[J. Eppler]

> As Qubes works by means of the principle of security by isolation and every 
> part of the hardware is running in a virtual machine. Does it make any sense 
> to use Kaspersky Security for virtualization over the xen hypervisor  to 
> improve security and antihacker security?

The KasperskyOS uses a hosted hypervisor (type-2 hypervisor). The KasperskyOS 
is based on a reliable proprietary microkernel. They use device emulation or 
where possible paravirtualization. KasperskyOS is able to use hardware 
virtualization extensions, but does not require them [1]. I assume they use an 
mixed approach of binary translation and kernel based virtualization. However, 
everything is proprietary. This is the reason what makes a technical and 
security comparison between KasperksyOS and QubesOS impossible.

However, it is easy to argue why Xen is a good choice as hypervisor for 
security projects such as QubesOS:

- Xen is open source, which means everybody can audit and anylze it
- Xen is used by several large companies in their cloud data center (Amazon 
AWS, Netflix etc.) -> Industrial proven
- Xen was developed and maintained for over a decade and has proven to be 
reasonable secure and flexible.
- Xen itself has a very small code base, which means less code running higher 
privileged CPU modes (Intel VT + AMD-V ring -1, ARM "HYP" mode).

> Is going KasperskyOS to suppose a big concurrency to Qubes?

No, QubesOS has a very high security standard driven by excellent research from 
Invsible Things labs. Furthermore, QubesOS is open source, which means people 
can extend QubesOS for their own use cases. Larger community projects which 
extend QubesOS are Whonix, the Archlinux-Template, the Mirage-Firewall 
Unikernel. In addition there are a couple of smaller projects.

By the way, KasperskyOS is not the only solution. Bromium vSentry for example 
is another endpoint virtualization solution.

[1] 
https://os.kaspersky.com/wp-content/uploads/sites/11/2017/02/Kaspersky-Secure-Hypervisor-En.pdf

-- 
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/f798d2d8-6d04-4433-a4ce-0704b8e45b5e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?

[Shane Optima]

On Thursday, March 30, 2017 at 5:27:12 PM UTC-4, Chris Laprise wrote:
> I get the feeling when you talk about people contributing, you mean 
> /other/ people. That's fine, but in my estimation what you're proposing 
> would take under 30 lines of bash code.

I think I've already covered this exact as comprehensively as can be done 
without writing you an actual autobiographical novel

What the hell, I'll try again anyway. Yes, I could do it. Yes, it would in the 
end be a very small project (that's the entire point of suggesting it.)  Yes, 
it would be interesting and useful. It would also be useful for me to figure 
out why Thunderbird is derping out again, learn Javascript, migrate all of my 
boxes to COW filesystems (which entails researching and choosing between ZFS, 
btrfs or bcachefs), and also do several thousand things that *aren't* 
computer-related, many of which either involve my son or attempting to make 
money doing non-IT things. 

To the extent that I am talking about this specific issue and not "ZOMG systemd 
sucks, why haven't you built Alpine Templates that can do 3d gaming, XFCE sucks 
why not use ObscureWM Deluxe, etc.",  I was trying to be considerate and 
constructive. I even mentioned semi-seriously how this could (down the road) be 
part of a monetization scheme for Qubes, but despite all of that you still 
managed to play the lazy, self-absorbed noob card.  Congratulations.

If you can send me a package of free time, I would be more than happy to give 
it a shot right away. As it is now, if it really is that so amazingly simple as 
to hardly be worth mentioning and yet no one has done it, then I submit that I 
have already made a "contribution" and it is to point out that this thing 
*should be done*:

***

Chris: "The schoolhouse is on fire!"

Volunteer Fireman: "Have you ever hooked a firehose up to a hydrant before?"

Chris: "No, uh, but I mean it's on fire *right now* and..."

Volunteer Fireman: "Look, it's really quite simple. And this would be a great 
opportunity for you learn something. Nothing beats hands-on experience."


***

Chris: "If you had enough time to write *all of that*..."

Me: "Then perhaps you'd do me the courtesy of reading it instead of attempting 
to use it (with no trace of irony) as a evidence of my sloth?"

Maybe if you (or someone) could write a Firefox extension to modify all browser 
page titles to be a concatenation of the page title and a short token of 
characters generated from a salted hash of the URL (so that I don't have to 
deal with any more hyperbole out of people like M. Ouelette), I could write the 
Dom0 bash bit. Or vice versa. Couldn't promise delivery on a tight deadline, 
though.

-- 
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/f8850253-8170-4bca-8fd4-b873d0a1aa60%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] [Debian 8] Audio problem after upgrading

[J. Eppler]

Hello,

I upgraded my Debian 8 "Jessie" template from Debian Qubes r3.1 to Qubes r3.2. 
Now, I have problems with the audio output. When I try to play audio files I do 
not hear anything and music player - web or deskotp - skip through songs very 
fast without playing them.

I tried to play something with clementine, this is the error message I got:

~~~
user@personal-music:~$ clementine
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
AL lib: (WW) alc_initconfig: Failed to initialize backend "pulse"
AL lib: (EE) alsa_open_playback: Could not open playback device 'default': No 
such file or directory
16:17:22.874 WARN  unknown  QTimeLine::start: already 
running 
~~~

Anybody, any ideas what the issue could be?



-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2875d7bb-8da9-4e0b-8426-cb05a2b9de81%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?

[Chris Laprise]

I get the feeling when you talk about people contributing, you mean 
/other/ people. That's fine, but in my estimation what you're proposing 
would take under 30 lines of bash code.


You should write it yourself as a way to learn about Linux and Qubes.

--

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

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3b1563c3-e9e9-6f46-029d-6d9ab3ac80d2%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?

[Shane Optima]

>Yeah, it could be dangerous, but still might be worth writing for oneself if 
>the threat model seems appropriate. I wouldn't suggest this as a Qubes feature.

As an out of the box official Qubes feature, no, but it seems like an excellent 
stopgap and stepping stone given the ease of implementation and the 
infeasibility of exploits.  I personally think such a project would be 
acceptable and desirable as a beta or experimental thing that the user needs to 
opt-in for, or failing that an unofficial project. 

>Sure, you could be super careful, but you're still pointing the gun at your 
>foot.

Better my foot than my face.

Can you at least recognize that this would be an entirely opt-in tool?  There 
would be no risk to anyone who doesn't use the tool even if it's enabled, and 
(barring the use of additional spoofing exploits) there's no risk from a 
specific site unless you use it with that specific site. This is all inherently 
granular. If you don't trust one specific site, just use the browser password 
manager or a long term cookie.  The two can be used in tandem.

I'm not going to memorize fifty different twenty character passwords, manual 
copy-pasting for everything is too cumbersome, and I've discovered the hard way 
that passwords cannot under any circumstances be shared, even among seemingly 
reputable sites, so the real question is what you think we should all be doing 
in the meantime. 

Exploits that target browser password storage or cookie exploits?  They already 
exist, regular usage will not spot them, and a compromise of a browser means 
the immediate compromise of all your passwords. Given the potential for using 
DispVMs on a regular basis[1], this latter point is particularly important 
because *all* compromises on a DispVM are temporary ones, so if you can limit a 
single breach to only compromising one or two logins that's a huge win.

Exploits that could target this Qubes-specific password tool? Ludicrously 
obscure[2], cannot work against an attentive user, cannot be done stealthily-- 
attentive users can release warnings for the less attentive users to heed, 
can't be used to snag a password from another VM, etc.  

A successful attack is quite implausible. And once the ball gets rolling, 
someone else can add features to it to make it much more secure. By the time 
anyone cares enough to even try the attack, it will almost certainly be guarded 
against.

Your primary concern can be mostly addressed with simple, straightforward hack: 
a browser extension that overrides the page title in some fashion.  This could 
be done in a manual whitelisting fashion, or ideally you could append a token 
computed from a hash of the URL (salted with a random per-VM value that isn't 
known to the attacker.) This would not only protect vs. spoofing, but if you 
modified the password manager to use only the token it would also prevent page 
title changes from breaking the tool. 

And then a third person could come along and make it sexier by automatically 
pasting it in the password field for you, and a fourth person could add 
username + password support, and a fifth person could add a keyboard shortcut 
to make it easier to create new stored logins on Dom0... and suddenly you have 
a full featured, easy to use, fairly secure tool that everyone starts using.  

And then a sixth person proposes rewriting the whole thing to use on something 
much better than window titles and copy-pasting (perhaps using the split VM 
scheme you described), and at this point it hopefully becomes an official Qubes 
tool, one that can be proudly touted on the box: "Password manager runs on a 
secure offline VM!"  And at that stage, perhaps Qubes could even offer start 
offering subscription cloud services to keep your precious passwords available 
and backed-up (with a master passphrase that decrypts locally, of course), with 
maybe an eye for offering more truly *secure* cloud services down the line. 

Or at least that how it goes if everything unfolds as an ideal UNIX-philosophy 
bazaar. But I'd rather risk that pipe dream stalling along the way than wait 
around for five years with nothing but a "go roll your own." None of that is a 
regression.

>You don't even need to rely on the window title for the security aspect

That did occur to me; I was jsut pointing out that even simple string parsing 
of the window title should be sufficient on its own (provided you're 
intercepting it before the Dom0 WM appends the VM name.) 

>xdotool also lets you inject keystrokes into windows. 

That, I did not know.

>Automatically injecting the keystrokes removes the "just watch the
window title and don't paste if it changed" mitigation

'Automatically', yes.  But even if you're not doing it automatically, xdotool 
might be better to utilize than the clipboard so that neither the hyperboard 
nor the VM clipboard contents get clobbered. 

> With a shortcut-key assignment this can be easily scripted by the user (you 
> said this 

Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?

[Chris Laprise]

On 03/30/2017 10:34 AM, Jean-Philippe Ouellet wrote:

On Thu, Mar 30, 2017 at 5:31 AM, Chris Laprise  wrote:

xdotool also lets you inject keystrokes into windows.

With a shortcut-key assignment this can be easily scripted by the user (you
said this was for power users).


Automatically injecting the keystrokes removes the "just watch the
window title and don't paste if it changed" mitigation which Shane
claimed as sufficient to make this attack preventable rather than just
detectable.


Agreed.



Overall I think this concept is simply too dangerous because you are
ignoring the actual origin of the browser and authenticating based
entirely on fully attacker-controlled information. Sure, you could be
super careful, but you're still pointing the gun at your foot.


Yeah, it could be dangerous, but still might be worth writing for 
oneself if the threat model seems appropriate. I wouldn't suggest this 
as a Qubes feature.


--

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

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8ef6bde4-8675-89e7-53d2-c3813a190625%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?

[Jean-Philippe Ouellet]

On Thu, Mar 30, 2017 at 5:31 AM, Chris Laprise  wrote:
> xdotool also lets you inject keystrokes into windows.
>
> With a shortcut-key assignment this can be easily scripted by the user (you
> said this was for power users).

Automatically injecting the keystrokes removes the "just watch the
window title and don't paste if it changed" mitigation which Shane
claimed as sufficient to make this attack preventable rather than just
detectable.

Overall I think this concept is simply too dangerous because you are
ignoring the actual origin of the browser and authenticating based
entirely on fully attacker-controlled information. Sure, you could be
super careful, but you're still pointing the gun at your foot.

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

Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?

[Jean-Philippe Ouellet]

On Thu, Mar 30, 2017 at 5:31 AM, Chris Laprise  wrote:
> You don't even need to rely on the window title for the security aspect: The
> _QUBES_VMNAME window property will tell you. For example:
>
> $ CUR_WINDOW=`xdotool getwindowfocus`
> $ VMNAME=`xprop _QUBES_VMNAME -id $CUR_WINDOW | cut -d \= -f2 | tr -d '"'`

The issue I raise is not pasting into the wrong VM, I think that's
easy enough to avoid already.

The concern is pasting the wrong password into an expected site in the
expected VM because that site spoofed its window title (which is under
full javascript control) while dom0 observed it to choose which
password to deliver.

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

Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?

[cooloutac]

On Monday, March 27, 2017 at 1:16:10 AM UTC-4, Shane Optima wrote:
> >which may or may not be *detected* by a sharply observant user, but could 
> >still not be *prevented* by one
> 
> Um, that is incorrect.  I'm not sure you understand at all what I'm talking 
> about here so let's go over it step by step:
> 
> A. User visits a site associated with a pre-stored password and presses a 
> special key combination.
> B.  Dom0 polls the active window title repeatedly over let's say one full 
> second. Attentive users may at this point glance briefly at the window title 
> to make sure it matches what the website is.  (This isn't *really* necessary 
> given how infeasible an attack would be, but a single glance at the title 
> during the polling period is all you need. You don't need to stare at it. I 
> often glance at the HTTPS when I visit sites, don't you? Why not glance at 
> the window title?)
> C. At the end of the polling period, Dom0 copies your password to the 
> clipboard of the VM associated with the active window.
> D. If the window title did something odd, DON'T PASTE YOUR PASSWORD IN THE 
> PASSWORD FIELD.  And definitely don't paste your password in the password 
> field and then hit submit. 
> 
> It's as simple as that. 
> 
> Since we're talking about non-compromised VMs only here, the attacker will be 
> unable to retrieve the clipboard and your password will thus be safe.
> 
> You might do something like write a browser extension to automatically paste 
> the password in the password field as browser password managers typically do. 
> Such an extension could and should, of course, take additional measures to 
> ensure the password is the correct one intended (I can think of a couple 
> mechanisms offhand.) This is preferable, and it's also something that would 
> take more effort.  
> 
> >Your argument appears to reduce to "This may be theoretically
> exploitable, but the ease of implementation and additional convenience
> is more important to me"
> 
> Uh, yes.  That's Joanna's philosophy, too. Everything is a tradeoff. I'm not 
> claiming that she would agree with me that this tradeoff is a good idea, but 
> the perfectionist stance you appear to be taking, as embodied by this 
> statement, is antithetical to everything I've seen in the Qubes philosophy.  
> 
> Qubes is about reasonable security (citation: the Qubes motto / tag line) 
> with reasonable usability. If security always trumped usability, surely there 
> wouldn't be a GUI at all.  (If I'm not mistaken, that's pretty much the 
> approach the OpenBSD people used to justify their superlative claims.)
> 
> >hold, passwordless sudo is *not* a theoretical weakness
> 
> What rubbish. Yes it is.  
> 
> >The key difference between this and the passwordless sudo argument you bring 
> >up is that the qubes security model explicitly assumes that user->root 
> >privilege escalation within a VM is possible
> 
> The 'Qubes security model' depends on user behavior to support it.  It 
> actually puts a far greater burden on the user to not be stupid (e.g. use 
> banking VM for all kinds of other stuff) than this password tool would.  If 
> you insist there's no theoretical security loss with passwordless sudo, then 
> there surely is no theoretical security loss with a password tool such as 
> this.
> 
> Heck, we don't even need to consider remote attacks to see how usage entirely 
> determines the security implications of a passwordless sudo: a person walking 
> by can compromise your un-screenlocked machine. And this is already a threat 
> model that Qubes takes seriously, as demonstrated by their anti-evil maid 
> packages. Obviously, a passwordless sudo in Dom0 or the VMs is a major 
> vulnerability whenever physical security cannot be guaranteed. You are not 
> just relying on the user to properly use screen lockers, but you are also 
> relying on the screen locker software to not fail. 
> 
> An uncompromisingly strict obedience to the security in depth principle, with 
> no regard for user convenience, would surely frown on such a single point of 
> failure, no?
> 
> But I repeat, I mostly agree that the convenience of passwordless sudo 
> outweighs the risks, and even I would go a step further and say that this 
> could be an example of an inverse of the password post-it note effect: when a 
> secure tool (such as Qubes) becomes significantly easier to use with a very 
> small additional risks incurred, it results in a REAL WORLD SECURITY GAIN, at 
> the cost of some additional minor theoretical security risks.
> 
> This is exactly as it is with a password manager such as I describe, except 
> the risk is even more negligible because the attack would have to be 
> conducted completely blind and could be easily spotted and foiled by an aware 
> user. Such a tradeoff should be acceptable for the first iteration of a 
> password manager. Later iterations could use browser extensions or multiple 
> VMs doing fancy tricks or whatever long term 

Re: [qubes-users] How much important is TPM?

[Steve Coleman]

Without a TPM you will be limited as to what you can do with any TCG 
Opal compliant self encrypting drives (SED), and for a laptop this is a 
very interesting feature to loose. Most all SSD's I know are Opal 
compliant and many laptop spinning drives are as well. Take a look at 
the rpm package sedutil to see the tool description, which under Qubes 
would for now only work in Dom0 due to no TPM's, nor Virtual TPMs 
(vTPM), being available to the user VM's domains. Just be aware that 
sedutil has a steep learning curve, but it is worth it once you get your 
brain wrapped around how it works.


I have done many interesting things with these drives that you might not 
even think are possible, but with Qubes the best feature I could 
envision is having a read-only boot partition where the system 
configuration is first measured by the tamper-proof read-only protected 
bootstrap kernel via the hardware TPM before the invisible Qubes-OS 
partition is even mounted and launched. An AEM on steroids, because you 
can not even physically write to the drive, and you can't even inspect 
the actual encrypted OS that will boot if everything is 
cryptographically matched. I'm working on a similar bootstrap project 
configuration in my spare time which one day I would hope to extend to 
my Qubes desktop.


Once Xen is launched it should be possible to launch virtual TPM's for 
the user domains so that kernel or application keys can be securely 
managed to create VLAN's, sign documents, etc. Having a vTPM might even 
allow sedutil to be used for storing and locking data or even for 
running user VM's (e.g. Offline storage for Tor Network VM's) on Opal 
SSD drives, if the commands can pass-through the virtual sata emulation. 
I don't know if that will work or not. If it does there are many, many 
cool uses to try if I ever have the time to play with that technology 
with Qubes. The problem being I only have my one desktop and can't 
afford to pull the rug out from under myself here at work where I don't 
have the tasking to play with this at the moment.


Anybody out there have any success installing Virtual TPM's under Xen? 
If so please ping me offline.


Steve

On 03/28/2017 02:40 AM, Vít Šesták wrote:

AFAIU, TPM is useful mostly for AEM. But AEM requires Intel TXT (which is 
missing even on some high-end CPUs). But TXT has various vulnerabilities. How 
much real protection can it offer? Is it worth the hassle (finding a laptop 
with both TPM and TXT and installing and using AEM)?

To be honest, I don't know much about TPM/AEM/TXT.

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



--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/fdee9a29-03c2-0ee8-6500-8f578329fca2%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Upgraded to 3.2, lockscreen accepts ANY password

[tom . b]

Both the xscreensaver and the i3lock accept any password.
I have not manually changed the files in /etc/pam.d/ but note some have 
the "nullok" option.


I've run tail -f against /var/log/* and /var/log/*/* but no changes 
occur after locking and unlocking the screen.


Expected behaviour: the user login password should be required before 
the screen unlocks.


(this install was upgraded to 3.2 from 3.1 which was upgraded from 3.0).

window manager = i3

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