Re: [qubes-users] QSB #46: APT update mechanism vulnerability

[Ilpo Järvinen]

On Tue, 29 Jan 2019, Alexandre Belgrand wrote:

> Le mardi 29 janvier 2019 à 00:59 +0200, Ilpo Järvinen a écrit :
> > There are many technical reasons raising from plain
> > physics/electronics 
> > which make an attack chip of that size with the described
> > capabilities to 
> > seem quite utopistic (and the article therefore bogus). ...But of
> > course 
> > you can choose to believe what you want.
> 
> The Chinese chip has been found and exists, no doubt about it. It was
> found on thousands of servers, so I believe it is being analyzed.

Yeah yeah, the only modification was that chip as claimed in the article? 
Magically all the necessary signal pins were routed to its location
but nothing else was changed (and you cannot have that many pins in 
that sized chip anyway which will seriously limit the possible functionality 
and processing speed). ...But it must all be true and present in thousands
of servers because a sensational article so claims (funny though that the 
so claimed victims of the attack consistently denied presence of such a 
chip in their servers but I guess you'll anyway think they must be lying 
for the benefit of the Chinese, damage control, because of the 
"investigation", or whatever reason).

-- 
 i.

-- 
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/alpine.DEB.2.20.1901290940250.13141%40whs-18.cs.helsinki.fi.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] QSB #46: APT update mechanism vulnerability

[Alexandre Belgrand]

Le mardi 29 janvier 2019 à 00:59 +0200, Ilpo Järvinen a écrit :
> There are many technical reasons raising from plain
> physics/electronics 
> which make an attack chip of that size with the described
> capabilities to 
> seem quite utopistic (and the article therefore bogus). ...But of
> course 
> you can choose to believe what you want.

The Chinese chip has been found and exists, no doubt about it. It was
found on thousands of servers, so I believe it is being analyzed.

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

Re: [qubes-users] QSB #46: APT update mechanism vulnerability

[Ilpo Järvinen]

On Mon, 28 Jan 2019, Alexandre Belgrand wrote:

> Le lundi 28 janvier 2019 à 13:08 -0800, goldsm...@riseup.net a écrit :
> > I'm intrigued how you know can catagorically state "CAs and GNU/Linux
> > distributions are #1 targets for national
> 
> China:
> https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies
> 
> China uses a tiny chip to intercept data. Read Bloomberg article.
> 
> "A chip can also steal encryption keys for secure communications, block
> security updates that would neutralize the attack, and open up new
> pathways to the internet."

There are many technical reasons raising from plain physics/electronics 
which make an attack chip of that size with the described capabilities to 
seem quite utopistic (and the article therefore bogus). ...But of course 
you can choose to believe what you want.


-- 
 i.

-- 
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/alpine.DEB.2.20.1901290037280.13141%40whs-18.cs.helsinki.fi.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Cannot add new user to Thunderbird address book

[John Goold]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 1/25/19 2:52 PM, John Goold wrote:
> There is only one issue in my complete transition to a Qubes
> system. This is the first.
> 
> When I attempt to add a "New Contact" to Thunderbird's address
> book, the "OK" button will change to show it is selected, but does
> not do anything. The same happens when I attempt to update an
> existing contact.
> 
> Qubes 4.0.1; Thunderbird 60.4.0 (64-bit)
> 
> Note: My migration involved copying
> ~/.thunderbird//abook.mab from my laptop and replacing the
> one in my "personal" qube. I checked its permissions and it is
> writable.
> 
> All my existing contacts show up and are usable. I am at a bit of a
> loss .
> 
> 

After wasting too much time trying to work out where the problem was
(it does not seem to make any sense), I installed the "Card Book"
add-on. It seems to work flawlessly (I have only been using it for a
couple of days) and has a bit nicer user interface.

John
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEe8Wcf7Po7bts2Rl4jWN9/rQYsRwFAlxPgVIACgkQjWN9/rQY
sRw47ggAoruyMwG+qkS1rPbhKMjk/E3TutF3XLF88mfC3nrWlljvyaiIstNGKF8A
V0qp9KI/eOuAB6DdGhIKZAekp6AWHM/sECaGPJ7FF3irIoyOdYyFBEbCxmn4ktJT
nODuvpTl5XciX8EwKy08nbsFS+6DIh/oZ/xbZfBLP4kiulaQJQKsqNTlNYNTElI5
UZcgjJY9G8fDjdVU3cHEJBtN0YIwuEjN/8nymZyK93RVJvA08txiyZEkSr71t/6C
GmwokVdgs9LnV/asfvmBnS/8tHb2n5b/YzWU1djPfcE0/rbhw63JSbGZcWLuKouh
MaTS7QcrWu7G9jAySWTkUaKL0j27lA==
=xPKj
-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/5ae5ae8e-0ffc-f5e0-a45f-f5a94ff8adfc%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] QSB #46: APT update mechanism vulnerability

[Alexandre Belgrand]

Le lundi 28 janvier 2019 à 13:08 -0800, goldsm...@riseup.net a écrit :
> I'm intrigued how you know can catagorically state "CAs and GNU/Linux
> distributions are #1 targets for national

China:
https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies

China uses a tiny chip to intercept data. Read Bloomberg article.

"A chip can also steal encryption keys for secure communications, block
security updates that would neutralize the attack, and open up new
pathways to the internet."


US:
https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-Hack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel-Management-Engine.pdf

The US are using Intel ME backdoor to take complete control of a
computer using a built-in VNC server and shadow connections.

"Has built-in full-fledged web and VNC servers" (page 20)

So my assumption was that all these backdoors were made for the primary
targets of stealing secret keys.

Game-over. Once the private keys have been stolen, "mirage Internet".
At the state of technology, I don't want Qubes users to believe that
Qubes is secure. Qubes is INsecure.

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

Re: [qubes-users] QSB #46: APT update mechanism vulnerability

[Alexandre Belgrand]

Le lundi 28 janvier 2019 à 13:08 -0800, goldsm...@riseup.net a écrit :
> To Alexandre Belgrand   
> 
> I'm intrigued how you know can catagorically state "CAs and GNU/Linux
> distributions are #1 targets for national
> intelligence agencies". This is classified information and therefore
> only available to a "Spook". Otherwise, it's entered the public
> domain
> via say a whistle blower like Ed Snowden. If that's how you came upon
> it, please state the source and location. 

I am not a whistle blower, but I believe that all CAs and GNU/Linux
distributions are primary targets for Intelligence agencies. This is
not secret, this is why I am writing it, sitting behind my real IP. 

You will find this information on Internet. Look for the recent
problems with China for example.

Stealing root certificates allow Intelligence agencies to set-up mirage
Internet : i.e. decrypt SSL/crypted content and present modified
content to the user and make man-in-the-middle attack.

Think about Debian private keys. The keys are stored on a server in a
datacenter, not even on smartcards. What can stop a remote attacker
with a remote console (either directly or using Intel ME) from stealing
the keys and then breaking password using a keylogger in Intel ME.
Answer : nothing can stop a local government from doing so.

Think about SSL X509 certificates. To deliver encrypted content, the
private key has to be on the server. You only need serial console
access to steal the private key. 

The only solution is to compile the same bytecode and verifying hashes
online, but Debian is lagging behind important patches, because they
don't understand what already happened.



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

Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?

[goldsmith]

On 2019-01-28 19:46, billol...@gmail.com wrote:
> On Monday, January 28, 2019 at 10:27:32 AM UTC-5, gold...@riseup.net wrote:
>> On 2019-01-27 19:15, billol...@gmail.com wrote:
>> > On Sunday, January 27, 2019 at 12:22:03 PM UTC-5, unman wrote:
>> >>[snip]
>> >> Qubes provides a framework for using software - it doesn't take away the
>> >> onus on users to use that software properly, and to ensure they are aware
>> >> of good practice.  (As an aside I'm always baffled by people querying
>> >> how they can use Facebook under Tor or Whonix. What are they thinking?)
>> >> I regularly audit templates with tripwire, running from an
>> >> offline openBSD qube, and do standards checks with debsums. I do good
>> >> deal of my work offline in openBSD and then transfer encrypted in to
>> >> other qubes for transmission. That seems like overkill, and isn't for
>> >> everyone: it might be for you.
>> >>
>> >> unman
>> >
>> > I think this is the most important thing you wrote. I used to do
>> > network security for a small scientific government network back in the
>> > 1990s, and I constantly ran into the problem that there is an inverse
>> > relationship between security and usability.  The scientists on my
>> > network were constantly finding ways of going around whatever security
>> > measures I put in place precisely because they didn't want to deal
>> > with the "hassle."
>> >
>> > But I'm no different, really.  Not too many years ago, I routinely
>> > disabled SELinux when I installed a new OS simply because I considered
>> > it too much of a hassle to learn how to use it effectively.  It made
>> > it difficult for me to do stuff.  Everybody yelled at me, but it just
>> > wasn't worth the effort to me. Now, I've learned it a bit and it's not
>> > such a hassle.
>> >
>> > There's this balance between the inconvenience/damage associated with
>> > an intrusion versus the inconvenience associated with the security
>> > configuration.  For me on the computer I'm using as I write this, it
>> > wouldn't be the end of the world if *everything* on my computer were
>> > owned by someone else.  It would be a hassle, but not fatal -- I have
>> > insurance, etc. for the financial information I have here, and I don't
>> > really care if someone sees the email conversations I have on this
>> > machine.
>> >
>> > So, considering the financial stuff, for instance.  There's a hassle
>> > with someone getting my credit card information.  It's happened
>> > (though not because of a computer glitch).  My card gets frozen, I
>> > can't use it for a week or two, I have to make a bunch of phone calls,
>> > etc.  But I'm financially protected and eventually I'll be fine.  The
>> > problem is the hassle factor, not financial ruin. My biggest security
>> > concern is someone using up all my bandwidth; I live in a rural area
>> > and have metered service.  Someone using up 5 gigs of bandwith is more
>> > concerning to me than them owning 5 gigs of data from my machine. So,
>> > I have to ask myself, which is more hassle -- dealing with the
>> > intrusion, or dealing with the security hassle?
>> >
>> > It's my responsibility to determine where that balance is, and nobody
>> > else's.  And it's likely different for everybody.  For instance, I
>> > used to have a blog, but I'm a litigation consultant and I started
>> > seeing my blog posts turning up in court.  So I don't blog any more. I
>> > can't be on Facebook, or LinkedIn, or Doximity, or ResearchGate.
>> > That's not a problem for me, but it would drive my wife crazy.  I use
>> > one laptop for some stuff, and I use a different laptop, differently
>> > configured, for other stuff.
>> >
>> > And, the higher up the food chain you go with respect to people
>> > interested in surveilling you, the less chance you have of keeping
>> > them out.  I'm out of the business now, but back in the day I
>> > occasionally did some classified work. I remember some years ago, I
>> > called a friend of mine who worked for the government.  I called him
>> > using the work phone of an acquaintance to ask him a technical
>> > question.  He picked up the phone and immediately said "Hey, Bill, how
>> > you doing?"
>> >
>> > I was stunned. I asked him how the hell he knew it was me.  He said
>> > "Bill, I'm with the .  We always know where you
>> > are."
>> >
>> > I have another friend who spent his early career working for a
>> > government contractor.  His job was to break into people's houses at
>> > night and install keyloggers on their computers. With a subpoena, of
>> > course.  All the security software in the world won't help you with
>> > that.
>> >
>> > The key, for me, is to achieve the maximum security that I can achieve
>> > and stay below my maximum hassle tolerance.  Qubes is nice because it
>> > adds a big uptick in transparent security with only a small uptick in
>> > hassle -- at least for someone who is fairly conversant with sysadmin
>> > stuff.  So for me it's a big win. But it's not all 

Re: [qubes-users] QSB #46: APT update mechanism vulnerability

[Alexandre Belgrand]

Le lundi 28 janvier 2019 à 16:47 +0100, qubes-...@tutanota.com a
écrit :
> What do you yourself use?
Hope I can answer too. 

I use an X230 with Intel ME disabled from BIOS. It costs about 160€ on
the second hand market and it has pretty decent hardware. Lenovo claims
that Intel ME can be disabled, but Intel ME is still running and may
accept remote shadow connections given a signed certificate from Intel.

This is why I am only reading the mailing list and not using Qubes. At
present, I consider Qubes as an interesting development, but not
reaching its goals because dom0 can be penetrated using Intel ME.

I am quite amused by tails sending an update command on each boot. You
can be sure to light red light in a control center and be penetrated
within seconds if need be. Remember that governments have control of
most outgoing nodes. So neither do I use Tor.

You just can't simply store valuable documents on a computer when
connected to a network. Companies that care about security should have
a complete process to manage workstations and internal networks,
without access to the Internet. We are back to ancien times.

Kind regards,
Alexandre Belgrand

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

Re: [qubes-users] QSB #46: APT update mechanism vulnerability

[goldsmith]

On 2019-01-27 14:33, Alexandre Belgrand wrote:
> Le dimanche 27 janvier 2019 à 13:11 +, Holger Levsen a écrit :
>> I *believe* they probably misunderstood evil32.com and it's fallout.
> 
> CAs and GNU/Linux distributions are #1 targets for national
> intelligence agencies.
> 
> Debian developers are not using smartcards to store their GPG keys,
> including the master key signing code. It is very likely that Debian
> master key has been stolen. I would be very surprised if it had not
> been stolen.
> 
> One reason why nobody wants to use SSL, including OpenBSD, is that
> there is a wide belief that SSL private keys have been stolen.
> Therefore there is no need to use SSL, as it does not offer a real
> protection.
> 
> This is simply GAME OVER (part 1 of the game).
> 
> One reason why I am not using Qubes, is that it does not offer a real
> protection compared to Debian, as both systems are IMHO compromised.
> 
> At present, any government with a valid certificate from Intel can use
> Intel ME backdoor to access all resources from a computer, including
> keyboard and screen and there is no way to secure an X86 computer.
> 
> If Qubes was making a wide use of Smartcards with a separate pinpad
> reader and was using a hardened operating system like OpenBSD or even a
> hardened GNU/Linux, I would have a closer look at it.

To Alexandre Belgrand   


I'm intrigued how you know can catagorically state "CAs and GNU/Linux
distributions are #1 targets for national
intelligence agencies". This is classified information and therefore
only available to a "Spook". Otherwise, it's entered the public domain
via say a whistle blower like Ed Snowden. If that's how you came upon
it, please state the source and location. 

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

Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?

[billollib]

On Monday, January 28, 2019 at 10:27:32 AM UTC-5, gold...@riseup.net wrote:
> On 2019-01-27 19:15, billol...@gmail.com wrote:
> > On Sunday, January 27, 2019 at 12:22:03 PM UTC-5, unman wrote:
> >>[snip]
> >> Qubes provides a framework for using software - it doesn't take away the
> >> onus on users to use that software properly, and to ensure they are aware
> >> of good practice.  (As an aside I'm always baffled by people querying
> >> how they can use Facebook under Tor or Whonix. What are they thinking?)
> >> I regularly audit templates with tripwire, running from an
> >> offline openBSD qube, and do standards checks with debsums. I do good
> >> deal of my work offline in openBSD and then transfer encrypted in to
> >> other qubes for transmission. That seems like overkill, and isn't for
> >> everyone: it might be for you.
> >>
> >> unman
> > 
> > I think this is the most important thing you wrote. I used to do
> > network security for a small scientific government network back in the
> > 1990s, and I constantly ran into the problem that there is an inverse
> > relationship between security and usability.  The scientists on my
> > network were constantly finding ways of going around whatever security
> > measures I put in place precisely because they didn't want to deal
> > with the "hassle."
> > 
> > But I'm no different, really.  Not too many years ago, I routinely
> > disabled SELinux when I installed a new OS simply because I considered
> > it too much of a hassle to learn how to use it effectively.  It made
> > it difficult for me to do stuff.  Everybody yelled at me, but it just
> > wasn't worth the effort to me. Now, I've learned it a bit and it's not
> > such a hassle.
> > 
> > There's this balance between the inconvenience/damage associated with
> > an intrusion versus the inconvenience associated with the security
> > configuration.  For me on the computer I'm using as I write this, it
> > wouldn't be the end of the world if *everything* on my computer were
> > owned by someone else.  It would be a hassle, but not fatal -- I have
> > insurance, etc. for the financial information I have here, and I don't
> > really care if someone sees the email conversations I have on this
> > machine.
> > 
> > So, considering the financial stuff, for instance.  There's a hassle
> > with someone getting my credit card information.  It's happened
> > (though not because of a computer glitch).  My card gets frozen, I
> > can't use it for a week or two, I have to make a bunch of phone calls,
> > etc.  But I'm financially protected and eventually I'll be fine.  The
> > problem is the hassle factor, not financial ruin. My biggest security
> > concern is someone using up all my bandwidth; I live in a rural area
> > and have metered service.  Someone using up 5 gigs of bandwith is more
> > concerning to me than them owning 5 gigs of data from my machine. So,
> > I have to ask myself, which is more hassle -- dealing with the
> > intrusion, or dealing with the security hassle?
> > 
> > It's my responsibility to determine where that balance is, and nobody
> > else's.  And it's likely different for everybody.  For instance, I
> > used to have a blog, but I'm a litigation consultant and I started
> > seeing my blog posts turning up in court.  So I don't blog any more. I
> > can't be on Facebook, or LinkedIn, or Doximity, or ResearchGate. 
> > That's not a problem for me, but it would drive my wife crazy.  I use
> > one laptop for some stuff, and I use a different laptop, differently
> > configured, for other stuff.
> > 
> > And, the higher up the food chain you go with respect to people
> > interested in surveilling you, the less chance you have of keeping
> > them out.  I'm out of the business now, but back in the day I
> > occasionally did some classified work. I remember some years ago, I
> > called a friend of mine who worked for the government.  I called him
> > using the work phone of an acquaintance to ask him a technical
> > question.  He picked up the phone and immediately said "Hey, Bill, how
> > you doing?"
> > 
> > I was stunned. I asked him how the hell he knew it was me.  He said
> > "Bill, I'm with the .  We always know where you
> > are."
> > 
> > I have another friend who spent his early career working for a
> > government contractor.  His job was to break into people's houses at
> > night and install keyloggers on their computers. With a subpoena, of
> > course.  All the security software in the world won't help you with
> > that.
> > 
> > The key, for me, is to achieve the maximum security that I can achieve
> > and stay below my maximum hassle tolerance.  Qubes is nice because it
> > adds a big uptick in transparent security with only a small uptick in
> > hassle -- at least for someone who is fairly conversant with sysadmin
> > stuff.  So for me it's a big win. But it's not all there is.
> > 
> > There's no such thing as perfect security.  There's only finding the
> > balance between one's perceived 

[qubes-users] Upgrades for dom0-Qubes 4; on system reboot skips plymouth, usb kb dies, can't enter decrypt pw

[qubert]

First visible error on screen:
[FAILED] Failed to start Setup Virtual Console
Second vis error:
[FAILED] Failed to start Show Plymouth Boot Screen.

No problem, eh? Because a few lines later, it prompts me for the passphrase for 
the encrypted disk. Awesome.

But every time, as soon as it gets there, my keyboard light goes dead, and I of 
course can't type anything in.

I have tried four different keyboards. All keyboards are USB, three are wired, 
one wireless. Have also tried multiple different usb ports, some usb 2.0 and 
some usb 3.
Have been using the system just like this for many months with two different 
usb keyboards. Nothing changed except running the dom0 upgrade (from qubes 
manager right-click), and I rebooted immediately after.

When I edit the boot options by eliminating "quiet" I get exactly the same 
prompt for the luks decrypt password, except it adds this as the final logging 
line (this line also overwrites the area in which I should be entering the 
decrypt pw):
[ 3.407261] clocksource: Switched to clocksource tsc

Removing 'rhgb' in addition to quiet eliminates the plymouth boot error, but I 
still get dumped out onto the terminal password entry line and as soon as that 
line comes up the keyboard light goes off every time!

Obviously without a keyboard, I can't even get tty, much less enter the unlock 
passphrase.

I'm effectively locked out, and before I start messing with it and changing 
things, thought I would ask to see if anyone out there knows what might be 
wrong

Thanks!

-- 
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/7d22a295-57d5-45df-a5ad-8aedd18c90b6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

getting rid of ME on modern CPUs (Re: [qubes-users] QSB #46: APT update mechanism vulnerability)

[Holger Levsen]

On Mon, Jan 28, 2019 at 11:46:55AM -0600, Stuart Perkins wrote:
> Up to a certain manufacture, you can go to coreboot and lose the ME entirely. 
>  After that point, setting the HAP bit may be your best option.  We need 
> someone to to reverse engineer the ME and implement enough of it in coreboot 
> to take over so the newer ones will run.

thats not enough. on modern intel cpus there's boot-guard which will
prevent booting with coreboot unless it's signed with a secret intel
key.


-- 
tschüß,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

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


signature.asc
Description: PGP signature

Re: [qubes-users] QSB #46: APT update mechanism vulnerability

[Stuart Perkins]

On Mon, 28 Jan 2019 16:47:08 +0100 (CET)
 wrote:

>Jan 27, 2019, 5:04 PM by alexandre.belgr...@mailbox.org:
>
>> Le dimanche 27 janvier 2019 à 16:47 +, unman a écrit :
>>  
>>> I'd be interested to know what system has been graced with your
>>> approval.
>>> If you believe all this, then what makes you think that national
>>> intelligence agencies haven't infiltrated *bsd, coreboot and any
>>> other
>>> system you can name. 
>>> imo Qubes does a reasonable job of providing a more secure system
>>> that's usable by ordinary users.
>>>  
>>
>> Simply no x86 system is reasonably secure.
>>  
>>> Spreading unfounded allegations is a disservice to the community.
>>>  
>
>Most of the serious users are very well aware of the IME/AMT vulnerability and 
>are addressing it continuously and publicly. See Joanna Rutkowska and her 
>talks. You are looking for a 100% solution. Big surprise is a 100% solution is 
>not existing and will never be. 
>You can of course use a libre X200 without IME and without real virtualization 
>too, having again to deal with issues of a monolythic system. 
>Tradeoff can be the X230 with more-less disabled IME with proper 
>virtualization.
>
>What do you yourself use?
>
>
>> Qubes is interesting because it is trying to answer security needs and
>> the design is nice. 
>>
>> But think about Intel ME backdoor. Imagine that any officer with a
>> signed certificate of Intel can penetrate dom0 in your computer within
>> seconds and then view your screen, move your mouse and type on your
>> keyboard. This is reality and Qubes cannot change it.
>>  
>Qubes doesn't even claim to change it. You need to address Intel same way as 
>Qubes ppl do and ask them to close the backdoor. 
>
>Are you aware that spreading of the false claims *can be* an intelligence 
>operation to undermine user's support and appreciation of the codes like 
>Debian and Qubes? From leaked materials is known that the US IAs named for 
>example Tails based on Debian as a total apocalypse for intelligence 
>collection for them, if spread. 
>
>Keep in mind, nothing is perfect. But if you have an option for a better set 
>and setting, put it up.
>
>
>
>> -- 
>> 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/65d4efc1f6cc5203a5fc0802e2cdff2e9fc992f7.ca...@mailbox.org
>>  
>> >
>>  .
>> For more options, visit > https://groups.google.com/d/optout 
>> > .
>>  
>

Up to a certain manufacture, you can go to coreboot and lose the ME entirely.  
After that point, setting the HAP bit may be your best option.  We need someone 
to to reverse engineer the ME and implement enough of it in coreboot to take 
over so the newer ones will run.

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

[qubes-users] HCL - System76 Oryx Pro

[Shahin]

  
  

  




-- 
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/1f94e8ca-744e-1985-6e30-6e7cf94e8212%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-System76-Oryx_Pro-20190128-114149.yml
Description: application/yaml

[qubes-users] Reversing dom0 testing repo installation

[qubes-fan]

hi, I accidentaly downloaded and installed the dom0 update from the testing 
repo. Is there any way to reverse the action and keep only the stable version?

I already disabled the testing repo in the /etc/yum.repos.d/qubes-dom0.repo

Thank you

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

Re: [qubes-users] QSB #46: APT update mechanism vulnerability

[qubes-fan]

Jan 27, 2019, 5:04 PM by alexandre.belgr...@mailbox.org:

> Le dimanche 27 janvier 2019 à 16:47 +, unman a écrit :
>
>> I'd be interested to know what system has been graced with your
>> approval.
>> If you believe all this, then what makes you think that national
>> intelligence agencies haven't infiltrated *bsd, coreboot and any
>> other
>> system you can name. 
>> imo Qubes does a reasonable job of providing a more secure system
>> that's usable by ordinary users.
>>
>
> Simply no x86 system is reasonably secure.
>
>> Spreading unfounded allegations is a disservice to the community.
>>

Most of the serious users are very well aware of the IME/AMT vulnerability and 
are addressing it continuously and publicly. See Joanna Rutkowska and her 
talks. You are looking for a 100% solution. Big surprise is a 100% solution is 
not existing and will never be. 
You can of course use a libre X200 without IME and without real virtualization 
too, having again to deal with issues of a monolythic system. 
Tradeoff can be the X230 with more-less disabled IME with proper virtualization.

What do you yourself use?


> Qubes is interesting because it is trying to answer security needs and
> the design is nice. 
>
> But think about Intel ME backdoor. Imagine that any officer with a
> signed certificate of Intel can penetrate dom0 in your computer within
> seconds and then view your screen, move your mouse and type on your
> keyboard. This is reality and Qubes cannot change it.
>
Qubes doesn't even claim to change it. You need to address Intel same way as 
Qubes ppl do and ask them to close the backdoor. 

Are you aware that spreading of the false claims *can be* an intelligence 
operation to undermine user's support and appreciation of the codes like Debian 
and Qubes? From leaked materials is known that the US IAs named for example 
Tails based on Debian as a total apocalypse for intelligence collection for 
them, if spread. 

Keep in mind, nothing is perfect. But if you have an option for a better set 
and setting, put it up.



> -- 
> 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/65d4efc1f6cc5203a5fc0802e2cdff2e9fc992f7.ca...@mailbox.org
>  
> >
>  .
> For more options, visit > https://groups.google.com/d/optout 
> > .
>

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

Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?

[goldsmith]

On 2019-01-27 19:15, billol...@gmail.com wrote:
> On Sunday, January 27, 2019 at 12:22:03 PM UTC-5, unman wrote:
>>[snip]
>> Qubes provides a framework for using software - it doesn't take away the
>> onus on users to use that software properly, and to ensure they are aware
>> of good practice.  (As an aside I'm always baffled by people querying
>> how they can use Facebook under Tor or Whonix. What are they thinking?)
>> I regularly audit templates with tripwire, running from an
>> offline openBSD qube, and do standards checks with debsums. I do good
>> deal of my work offline in openBSD and then transfer encrypted in to
>> other qubes for transmission. That seems like overkill, and isn't for
>> everyone: it might be for you.
>>
>> unman
> 
> I think this is the most important thing you wrote. I used to do
> network security for a small scientific government network back in the
> 1990s, and I constantly ran into the problem that there is an inverse
> relationship between security and usability.  The scientists on my
> network were constantly finding ways of going around whatever security
> measures I put in place precisely because they didn't want to deal
> with the "hassle."
> 
> But I'm no different, really.  Not too many years ago, I routinely
> disabled SELinux when I installed a new OS simply because I considered
> it too much of a hassle to learn how to use it effectively.  It made
> it difficult for me to do stuff.  Everybody yelled at me, but it just
> wasn't worth the effort to me. Now, I've learned it a bit and it's not
> such a hassle.
> 
> There's this balance between the inconvenience/damage associated with
> an intrusion versus the inconvenience associated with the security
> configuration.  For me on the computer I'm using as I write this, it
> wouldn't be the end of the world if *everything* on my computer were
> owned by someone else.  It would be a hassle, but not fatal -- I have
> insurance, etc. for the financial information I have here, and I don't
> really care if someone sees the email conversations I have on this
> machine.
> 
> So, considering the financial stuff, for instance.  There's a hassle
> with someone getting my credit card information.  It's happened
> (though not because of a computer glitch).  My card gets frozen, I
> can't use it for a week or two, I have to make a bunch of phone calls,
> etc.  But I'm financially protected and eventually I'll be fine.  The
> problem is the hassle factor, not financial ruin. My biggest security
> concern is someone using up all my bandwidth; I live in a rural area
> and have metered service.  Someone using up 5 gigs of bandwith is more
> concerning to me than them owning 5 gigs of data from my machine. So,
> I have to ask myself, which is more hassle -- dealing with the
> intrusion, or dealing with the security hassle?
> 
> It's my responsibility to determine where that balance is, and nobody
> else's.  And it's likely different for everybody.  For instance, I
> used to have a blog, but I'm a litigation consultant and I started
> seeing my blog posts turning up in court.  So I don't blog any more. I
> can't be on Facebook, or LinkedIn, or Doximity, or ResearchGate. 
> That's not a problem for me, but it would drive my wife crazy.  I use
> one laptop for some stuff, and I use a different laptop, differently
> configured, for other stuff.
> 
> And, the higher up the food chain you go with respect to people
> interested in surveilling you, the less chance you have of keeping
> them out.  I'm out of the business now, but back in the day I
> occasionally did some classified work. I remember some years ago, I
> called a friend of mine who worked for the government.  I called him
> using the work phone of an acquaintance to ask him a technical
> question.  He picked up the phone and immediately said "Hey, Bill, how
> you doing?"
> 
> I was stunned. I asked him how the hell he knew it was me.  He said
> "Bill, I'm with the .  We always know where you
> are."
> 
> I have another friend who spent his early career working for a
> government contractor.  His job was to break into people's houses at
> night and install keyloggers on their computers. With a subpoena, of
> course.  All the security software in the world won't help you with
> that.
> 
> The key, for me, is to achieve the maximum security that I can achieve
> and stay below my maximum hassle tolerance.  Qubes is nice because it
> adds a big uptick in transparent security with only a small uptick in
> hassle -- at least for someone who is fairly conversant with sysadmin
> stuff.  So for me it's a big win. But it's not all there is.
> 
> There's no such thing as perfect security.  There's only finding the
> balance between one's perceived risk, one's actual vulnerability, and
> one's tolerance for hassle.  And any security configuration is
> self-defeating if:
> 
> 1) People take it for granted and think that it's all they have to
> think about, and/or
> 2) It's enough of a hassle that 

Re: [qubes-users] Backup stops when the backup file reaches 3Gb

[Mike Keehan]

On Fri, 25 Jan 2019 13:52:55 +
Mike Keehan  wrote:

> On Thu, 24 Jan 2019 11:29:50 +
> unman  wrote:
> 
> > On Thu, Jan 24, 2019 at 01:00:15AM -0500, Chris Laprise wrote:  
> > > On 01/23/2019 08:15 PM, js...@bitmessage.ch wrote:
> > > > Mike Keehan:
> > > > > Hi,
> > > > > 
> > > > > I'm using Qubes Backup to save some of my qubes into another
> > > > > VM. The backup VM has 18 Gb of storage available, but
> > > > > whenever the backup file reaches 3Gb, the backup process just
> > > > > hangs.
> > > > > 
> > > > > No CPU usage, no error messages, just stops.  The backup
> > > > > window shows 40% complete, but never moves any further
> > > > > (different % for different combinations of qubes in the
> > > > > backup list).
> > > > > 
> > > > > After waiting a considerable time (well, 5-10 minutes),
> > > > > hitting Cancel in the backup window does cancel it.  The rest
> > > > > of the system is continuing to work without problem.  Happens
> > > > > every time I try to use Qubes backup.
> > > > > 
> > > > > The Qubes Disk Space widget shows less than 50% disk used
> > > > > overall, the backupVM shows only 18% disk used when the 3Gb
> > > > > file has been saved.
> > > > > 
> > > > > I'm stumped.
> > > > > 
> > > > > Mike.
> > > > 
> > > > Hi,
> > > > 
> > > > You may have to wait longer than 5-10 minutes. I experience
> > > > something similar when doing a full backup, except it's worse
> > > > because i'm backing up like 2.5TB. It appears to hang for
> > > > several hours at a time (and this happens more than once), but
> > > > it does eventually make visible progress again. The whole
> > > > process takes over 24 hours. This is why i do full backups very
> > > > infrequently.
> > > > 
> > > > For you it shouldn't take nearly as long because it's a lot less
> > > > data, but the progress appearing to hang for a while seems to be
> > > > normal.
> > > > 
> > > > I'm using 3.2 tho, and i know they made changes to the backup
> > > > mechanism under the hood in 4.0, so i'm not sure if this issue
> > > > still applies in 4.0.
> > > 
> > > Marek,
> > > 
> > > Isn't this the null bytes bug in GNU tar?
> > > 
> > > https://groups.google.com/d/msgid/qubes-users/f4d997d5-7191-06d0-e7bb-ef42745a7db5%40posteo.net
> > > 
> > > It would be a good idea to update this in dom0. My own backup tool
> > > uses GNU tar as well.
> > > 
> > > -- 
> > > 
> > > Chris Laprise, tas...@posteo.net
> > > https://github.com/tasket
> > > https://twitter.com/ttaskett
> > > PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886
> > 
> > It seems a little early to judge.
> > 
> > Mike - it looks from your comment as if you have been trying with
> > subsets of the qubes? Can you confirm if these are running or
> > stopped.
> > 
> > Like jsnow, I'm regularly able to backup far more than 3G without
> > issue, so it looks as if there's something particular about this
> > scenario. It would be helpful if you could confirm the issue when
> > all qubes you are backing up are stopped.
> > Then try bisecting the qubes backup group - keep bisecting if you
> > hit the problem again until you either find the problematic qubes
> > or have backed them all up.
> >   
> 
> OK, progress:)
> 
> I can backup a list of stopped qubes, running out to a 10Gb file
> without any issues.  They all verify OK too.  However, backing up
> running qubes exhibits the problem.  
> 
> Starting up one of these qubes and trying to backup causes the
> progress indicator to stop at some point, BUT, the data is still
> being backed up to disk, and continues flowing for some time.  When
> the data flow stops, then I have to cancel the backup operation.
> However, verifying the backup works OK - file size reported is
> correct, and the verify process finishes successfully.  I haven't
> tried to actually restore one of these yet.
> 
> I tried recording the process status of both dom0 and the backup vm
> during the backups, but could not see any particular process dying
> when the progress updater stopped moving.  The tar processes stopped
> in dom0 but I guess that was because they had finished creating the
> private.img files.
> 
> So it looks like backing up a live VM causes the backup process to
> fail at some point, but not before the data is actually backed up.  
> 
> It doesn't look like a tar null issue as the data does get to disk OK.
> It's just the control of the backup process getting out of step
> somewhere.
> 
> Mike.
> 

I'm trying to debug the backup halting part way when backing up
a running VM.  (I have restored one of these backups successfully!)

The backup.py script shows a debug log can be produced, but I can't
find it - do I have to turn it on somehow?

Mike.

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

Re: [qubes-users] Qube Window Manager; unable to list all open windows

[Franz]

On Sun, Jan 27, 2019 at 1:16 PM Chris Laprise  wrote:

> On 01/27/2019 09:32 AM, Franz wrote:
> > Command `wmctrl -l` gives the following error
> >
> > |Cannot get client list properties. (_NET_CLIENT_LIST or
> _WIN_CLIENT_LIST)|
>
> This works for me with KDE.
>
>
> >
> > But when I use |wmctrl| to display info about the window manager, Qubes
> > is indeed found:
> > [user@personal ~]$ wmctrl -m
> > Name: Qubes
> > Class: N/A
> > PID: N/A
> > Window manager's "showing the desktop" mode: N/A
> >
> > What I am trying to do is to gracefully close firefox, but I get the
> > same error:
> >
> > [user@personal ~]$ wmctrl -c firefox
> > Cannot get client list properties.
> > (_NET_CLIENT_LIST or _WIN_CLIENT_LIST)
>
> You could try using 'xdotool' instead:
> xdotool search --name Firefox
>
> See my 'halt-vm-by-window' script from 'Qubes-scripts' project for
> examples. You could go through the list of matching windows, find the VM
> name with 'xprop', then issue a command like "qvm-run $vmname 'pkill
> firefox'" which should send a normal TERM signal to Firefox. Its best to
> wait about 5 seconds before trying to shut down the VM so the browser
> state has time to be written to disk.
>
>
thanks Chris
xdotool does not seem to work either

I tried to use the script posted here
https://superuser.com/questions/583246/can-i-close-firefox-browser-tab-or-firefox-browser-from-ubuntu-terminal

but it give this error:
Defaulting to search window name, class, and classname
Your windowmanager claims not to support _NET_ACTIVE_WINDOW, so the attempt
to activate the window was aborted.
xdo_activate_window on window:18874384 reported an error

It may be a xfce problem since you wrote it works with KDE
Best

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

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

[qubes-users] Qubes 4 crashes

[aaq via qubes-users]

Hello!

I have experienced a couple of times now that my Qubes 4 installation crashes 
at different times.

I do not expect this to be an issue with Qubes, but it would be nice if I could 
debug this some how. I have no idea where to look for the necessary logs though.

Some details:
The crash itself comes in different forms, but the outcome is always the same; 
total system freeze where a hard shutdown is required.

Often it crashes with some kind of graphical glitch where the GUI is skewed. 
I.e. colours look weird and it is obvious that the screen glitched.
Yesterday I experienced that it crashed without glitching though, so it took me 
some time to realise that it was actually crashed.

It usually happens when my laptop is running on battery. I have never 
experienced it when it is plugged into the charger.

I have a Thinkpad X270, i7 processor, 8 GB RAM.

I am personally suspecting a lack of RAM maybe, but I need to have it confirmed 
by others or get another opinion.

Thank you very much!

-- 
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/0b22d136-b883-4e59-a5fe-2d5bcf816ade%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.