RE: [qubes-users] UEFI secureboot issue
Wim Vervoorn
I would like to use Qubes on a UEFI system with secure boot enabled.
Until now this fails with a security violation.
I assume this is because the Qubes efi application is not signed by the "microsoft-uefica" key.
We can of course make it boot by adding the hash of the loader to the UEFI "db" but we don't like to do this because we would need to do this again if a change is made. We assume you also signed the laoder with an appropriate key but I have not been able to find the certificate of the public key so I can add this to the "db" database and allow all efi binaries that are released by Qubes. Can you tell me where I can find that and share it with me?
Best Regards,
Wim Vervoorn
Eltan B.V.
Ambachtstraat 23
5481 SM Schijndel
The Netherlands
T : +31-(0)73-594 46 64
E : wver...@eltan.com
W : http://www.eltan.com
"THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664 OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES."
cooloutac
Qubes doesn't support secure boot unfortunately. I think its batshit crazy to consider a pc even reasonably secure without it.
Jean-Philippe Ouellet
> Qubes doesn't support secure boot unfortunately. I think its batshit crazy to consider a pc even reasonably secure without it.
name may suggest.
If you haven't already, I'd suggest reading Joanna's "Intel x86
considered harmful" paper [1] and checking out Trammell Hudson's Heads
project [2].
FWIW, the systems I currently believe have the most secure boot chains
do not involve UEFI at all.
Regards,
Jean-Philippe
[1]: https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf
[2]: http://osresearch.net/
wver...@eltan.com
Hello,
I do understand using secureboot is not the perfect way but it's not always possible to achieve this.
What we have is a custom bios that implements a nailed down version of secureboot where we control the secure boot databases, So that should reduce the risk of a 3rd party allowing software that we don't want to.
All that needs to be done from Qubes side to accomodate this is to make sure the efi executable are signed and the make sure the ceriticate for the public key is available. Once this is done we can add this to our database and we can leave secureboot enable when we use Qubes.
So basically my question to the Qubes maintainers is if they will be supporting this scenario at any point in time. If not we are forced to create another scenario.
Thanks in advance for your cooperation,
Wim Vervoorn
cooloutac
That sounds insane, what systems are those? Yes Joanna started saying things Richard Stallman had been saying for years. But its Still just alot of "what ifs"...
In reality, and what we know as true facts, and what is, is that secure boot stops attacks like hacking teams insyde bios exploit. Nothing else would. And yes these things can happen remotely, physical access is not required. An OS probably isn't even required. Even Richard Stallman has changed his tune and says secure boot is ok to use in its current state as a security feature. He half halfheartedly admits he was wrong by saying Microsoft failed its intended purpose. So any FSF hippie nut still preaching against secure boot is just a hater. A hater of microsoft, a hater of redhat, and someone who doesn't want to admit they were wrong.
I think its insane to call any system even reasonably secure,without secure boot.
wver...@eltan.com
Hello,
Suppose I want to create a secure boot chain in another way how do I do this for Qubes? As far as I can deduct from the security documents the packages are signed but the individual executables are not. Is this correct or am I making a mistake here?
Thanks
Tai...@gmx.com
remove the ability for commercial PC's to run non windows operating systems.
SB 1.0 specs mandate owner controlled (an option to shut it off), SB2.0
doesn't and PC's built to that spec such as the Windows 10 ARM PC's and
MS's "signature series" PC's prevent you from installing non microsoft
operating systems.
"Secure" boot is simply a marketing name for kernel code signing, you
can easily do this with coreboot and a grub payload (grub supports
kernel signing).
SB doesn't stop virii as that wasn't what it was designed to do,
preventing rootkits from modding the kernel is irrelevant as you can
simply change another critical system file of which there are
many on windows.
Kernel code signing is only useful in an AEM context with an encrypted
filesystem but unencrypted kernels.
I myself have a variety of owner controlled fully libre firmware devices
such as the KGPE-D16 and KCMA-D8 asus motherboards, those two are the
only ones that offer full libre functionality along with high
performance - they also run qubes great - having 32 cores and 128GB ram
is excellent for it.
Please note these are the only owner controlled devices that support
v4.0 (purism isn't owner controlled and their firmware isn't and can't
ever be open source)
Another neat feature is an addon user configurable CRTM TPM module (very
rare).
As always I offer free tech support for libre motherboards if you wish
to buy one.
Wim Vervoorn
Hello,
Basically I am not asking for some type of religious war on Secure Boot. All I am basically asking for is if the executables provided in the Qubes distribution are signed and if so which keys have been used.
If they are not and we should sign them ourselves (either for grub or secureboot) this is good to know as well.
Best regards,
Wim Vervoorn
cooloutac
Stopped reading past your first sentence, because reality has already proven that wrong.
cooloutac
ok I read on lol...My raspberry pi is an arm processor, its running linux.
Easy do a secureboot with coreboot he says. Ya i'm sure we can all easily do that. /sarcasm
You say preventing modifications to the kernel is irrelevant. Which means you are failing to understand that the operating system is irrelevant.
cooloutac
I have to add another thing. Its nice to say that the motherboard firmware is libre, but it makes no difference to me cause I don't have the know how to read or alter the code myself.
So you and Microsoft are no different to me because I still have to trust and rely on you because I'm just an avg noob. But IMO, it would be more naive and dangerous for me to buy a board or get tech support from some random stranger online, then it would be to use monitored support service by paid emplooyees, or a commercial product used by millions that can't be as easily altered from its factory state. (minus gov't backdoors) I hope you don't take offense.
I mean the whole argument for libre and open source is having more eyes on the code. But what people don't understand is "eyes on the code" encompasses many things. Microsoft for example has "more eyes on the code" for the simple fact its more widely used and more widely targeted by attackers. But its not a security focused os unfortunately. Also, are we talking about good eyes or evil eyes? IMO, this aint the 90s anymore and evil eyes are the wide majority now. Even linus torvalds has changed his tune past couple years.
And I have to put this out there, guys like Linus Torvalds, or Brad Spengler, would never use linux at home for their family or personal use. They use windows. I kid you not.
cooloutac
Number two, They have a respected reputation in the industry.
3. they don't seem to get involved in industry politics or get very emotional or tied to any status quos or value assumptions. They seem to care only about the code and whats practical for Qubes and nothing else seems to phase them. Almost robot like.
All that being said we don't know if they are controlled by a nefarious government or not. Joanna always gets flak for saying that herself. SO nothing can be 100% trusted. ever. But compared to the alternatives...
cooloutac
Now he has to stop calling secure boot security theater, because alot of people seem to believe it and take his word like gospel.
Is protecting the bios from rootkits its intended purpose? seems so?, it helps anyways, and it definitely was intended to protect the firmware. Its not just kernel code signing, its driver code too.
I would add also make a password on your bios obviously, and enable flash protections.
I don't even think most the ITL members use aem, it sounds complicated and buggy and I can't afford to buy new hardware if it red flags anyways.
Sven Semmler
> As always I offer free tech support for libre motherboards if you
> wish to buy one.
Latitude E6410 basically accepting that it is far from perfect. Also
since I am new to Qubes OS I will make many mistakes an learn from them.
At some point in 2018 however I wish to buy / build a high powered
laptop that runs Qubes OS 4 and is as secure as possible. Are there any
libre motherboard based laptop options or does this automatically mean
desktop?
/Sven
Tai...@gmx.com
computer that has IOMMU/SLAT
- No me/psp
- Open source init (as opposed to purisms version of "coreboot" which is
closed source)
- Reasonably fast
There are a few blobs (video, fan control) but they are replaceable if
someone is willing to do so or fund development.
qubester
Maybe I should go back to using Windows 10, if secure boot trumps
the other security aspects of Qubes.
Or, do you think your 'safer' using Qubes, if so, why ?
cooloutac
To be honest, it really doesn't matter what os you use, its all about what the user does on it. When using qubes the user still has to be careful. It doesn't matter if dom0 is compromised if a vm with sensitive info is. You really have to be strict with yourself.
You going to play online video games? might as well use windows.
Dual booting? might as well just use windows.
disabling iommu features? might as well just use windows.
Worried about government spying? Might as well not use anything.
You have to live like a monk if you really want privacy.
I have a windows machine and a qubes machine. the qubes machine is for offline documents, compartmentalizing specific website login activity, and random browsing. The windows machine is for gaming and movies.
The guy Brad Spengler already warned dom0 and vms can be compromised by bad system updates. And I believe this happened to me and led to my bank account being hacked. Also just after intel announced their patch for the hardware backdoor that existed for 8 years.
Qubes did last almost 2 years for me though(minus gaming), when barebones linux wouldn't last a day and windows wouldn't last a couple months. Simply because I refuse to give up doing the things I own a pc for. The other thing he warned about was using too much of the gpu in qubes... I foresee that coming in the future with people demanding passthrough for it.
If you do decide to go back to windows 10, hardenwindows10forsecurity.com also might interest you hardenubuntu.com (scroll down to harden ubuntu section) The user activities and security and trust of the developers become the deciding factor after a point.
I don't think any operating system does it all. Just like alot of people didn't think root privilege escalation in
vms, being trivial to bypass, was an excuse not to add that layer of protection. I think its even worse not to use secure boot.
cooloutac
also if my hardware is compromised it really doesn't matter what os I use at that point either.
yreb-qusw
it that you don't use an OS that supports it ?
Or are you saying that besides the secure boot, that Qubes or Linux IS
more "secure" , and it's a "know your adversary" thing? If I'm
understanding this correctly the main adversary re: secure boot would be
some "advanced threat" like a government with that level of "skills" ??
I'm more "newb" than you, what does a "failed" update look like ?? I
have been feeling a lot more secure using a dedicated VM to do banking
, which actually was how I started down the path to use Qubes ...
I don't know what "root privilege escalation in
of this to improve with Qubes 4.x ?
Personally, I also enjoy how well Whonix works in Qubes , and use it
for most things that don't require logins, and I like the speed or the
OS vs win10 , which nows feel clunky, esp on VPN
qubester
using windows 7 because "he plays games" , and for convenience, no
mention that it might have something to do with Secure Boot ..
So, would you feel more secure doing your banking on a Windows Box,
since you think an broken update of Qubes caused you to "be hacked" ?
just curious, not being rhetorical..... :)
Sven Semmler
on 08/18/17 19:34, you wrote:
> Lenovo G505S
"AMD A10-Series A10-5750M (2.50 GHz) 6 GB Memory 1 TB HDD AMD Radeon HD
8650G"
-> I do have an AMD based laptop and while Qubes installed, there are
issues (DispVM doesn't work, after a while it won't even boot anymore).
From the little research I've done I take it that AMD means I have to
deal with a "missing firmware" issue. While I do intent to figure this
out for educational purposes, I am not sure I want to go with AMD for
the "big one" next year. That's why I am running Qubes on the DELL right
now (it had an i7 and Intel graphics).
-> 6 GB Memory ... I have 8 GB now and would say that that's probably
the absolute minimum. I am hoping to go with at least 32 GB next year.
-> Radeon HD 8650G ... sounds like trouble too
Is that really the machine you meant?
Tai...@gmx.com
> Thank you Taiidan,
>
> on 08/18/17 19:34, you wrote:
>> Lenovo G505S
> "AMD A10-Series A10-5750M (2.50 GHz) 6 GB Memory 1 TB HDD AMD Radeon HD
> 8650G"
>
> -> I do have an AMD based laptop and while Qubes installed, there are
> issues (DispVM doesn't work, after a while it won't even boot anymore).
> From the little research I've done I take it that AMD means I have to
> deal with a "missing firmware" issue. While I do intent to figure this
> out for educational purposes, I am not sure I want to go with AMD for
> the "big one" next year. That's why I am running Qubes on the DELL right
> now (it had an i7 and Intel graphics).
with) not a hardware error.
Missing binary blobs "firmware" wouldn't cause that.
People who say "oh AMD sucks" or "oh intel sucks" have no real reason to
say so, its pepsi vs coke any issues are either software or BIOS (which
is irrelevant as you are installing coreboot)
> -> 6 GB Memory ... I have 8 GB now and would say that that's probably
> the absolute minimum. I am hoping to go with at least 32 GB next year.
around $40 or so (nothing wrong with getting used ram)
> -> Radeon HD 8650G ... sounds like trouble too
integrated graphics.
cooloutac
lol... also cause his family hates linux, and because as he has said "he just likes things to work in his old age" He use to be a linux only guy in college, then he grew out of it. He prefers to use vm's in windows for his developing. He prolly feels his project is only for servers and professionals.
I've already explained this earlier, I'll try again. It really doesn't matter what os you use, its all about the user.
A windows machine would be fine to do online banking on, as long as you are not doing much of anything else on it and not a huge target, imo. Guys like HDM use windows for banking. In his words he doesn't care at all cause its a consumer account not a business bank account so he has financial protections and doesn't care if he gets hacked. I don't look at things that way though, because being hacked would bother me regardless.
Alot of offensive hackers like him think everything is a victimless crime till it happens to them. They have to tell themselves that if they have any sort of conscious.
A hardened linux boot cd rom would also be ok to use for banking, although all the projects I know of have been abandoned, and I've never used one with secure boot before although I'm sure its possible. But I don't have the patience to compile my own live cd.
Qubes definitely fills a gap of people wanting to do a little bit of everything on their computer when its comes to browsers and offline documents. When you are doing random browsing or going to sketchy sites, or want to isolate offline files all on the same machine, isolate certain programs from rest of the system, Qubes is alot easier and more resource friendly to use then setting up your own windows or hardened linux box with vms, Plus there are more security features then the avg person could implement themselves.
Experts have problems even implementing similar features on linux system with kvm.
But Qubes still relies alot on user habits, and in fact the user learning new habits. So Qubes does require even more discipline then linux or windows, to get the full benefits of using it, imo. But I think the avg person can easily get used to it.
And like I said it took almost two years to compromise my qubes machine, doing the same tasks on a on a windows machine would take a month or two. And with linux only days. This is my personal experience since 2008, of course I have no proof. If you were to ask me during windows xp days? I would immediately say linux is more secure. But times change.
socks
> But Qubes still relies alot on user habits, and in fact the user learning new habits. So Qubes does require even more discipline then linux or windows, to get the full benefits of using it, imo. But I think the avg person can easily get used to it.
>
> And like I said it took almost two years to compromise my qubes machine, doing the same tasks on a on a windows machine would take a month or two. And with linux only days. This is my personal experience since 2008, of course I have no proof. If you were to ask me during windows xp days? I would immediately say linux is more secure. But times change.
is "HVM" ?
cooloutac
well linux mint is even worse for security then other linux boxes, like fedora or debian. Because the linux mint devs themselves say security is not their priority, and they hold back updates to ensure stability. But that means you are getting patches way later then you should. They forget to sign stuff sometimes, dont' renew their website certs, don't even use good encryption for sig files, A hacker was even putting out backdoored iso on their site last year I believe.
If you really want to use linux I would recommend debian, where you can easily encrypt all partitions and the devs take security seriously. Plus its the easiest linux to compile your own hardened kernel for.
But like i keep saying it all depends on the user and I am only giving you my personal experiences based on how I've used my own pc.
Sven Semmler
> That is a software error (which I of course would be pleased to help
> with) not a hardware error.
to have a second computer fully installed and with the latest backups
restored on standby. Because stuff usually breaks at the worst time.
Since my move to Qubes, I don't have this safety. During the last 2
weeks I learned a lot about Qubes, so maybe this time it'll go better.
If I need help, I will surely post to this list.
> People who say "oh AMD sucks"
it runs Windows. I simply had issues with a stock / not troubleshooted
version of Qubes OS 3.2 installed. I would actually prefer the AMD based
machine as primary computer due to screen size, keyboard size (it's a 17").
/Sven
Sven Semmler
Hash: SHA256
On 09/01/2017 12:16 PM, I wrote:
> On 08/24/17 17:34, Tai...@gmx.com wrote:
>> That is a software error (which I of course would be pleased to
>> help with) not a hardware error.
> I will definitely try again.
The first and most dire issue is that after installing Qubes OS
everything appears to be fine for a random amount of time and then the
screen goes black.
I have seen this behavior with this machine before using various Linux
distributions. The only stable install I was able to achieve was using
AMD fglrx. When using the newer / free AMDGPU driver I always get this
issue.
AMD fglrx only supports Xorg < 1.18 and Qubes uses 1.18.3 ... so I see
no chance to install fglrx.
lspci says the VGA compatible controller is: Advanced Micro Devices,
Inc. [AMD/ATI] Carrizo (rev c5)
The computer is called HP Pavilion Notebook /80B0, BIOS F.10 05/27/2016.
It's this one: https://www.walmart.com/ip/46429956 (I removed the HDD
and put a fast Intel SSD inside).
Attached a screenshot of dmesg | grep amdgpu. Of course, right now the
machine is running for 30+ minutes without the black screen. Other times
I only have 3-5 minutes. So I agree it's a SW bug and it likely has
something to do with the AMD/ATI drivers.
Any ideas what I could try?
/Sven
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJZsA7gAAoJENpuFnuPVB+25b4P/jxJxieMQ8pwXQSBKOX+OHXm
S3Ak/pAsspg8p5PQ6DTxrmDGI6L0B1p4tMCyBloct8NtmU+LUiHsvREQZBAIvEZ9
LDt8DHoSUhN3kFG4Bxv1EpeL9DdfmN4utbu7jDysswJ6DcLjQdVDIha1qlgxkfWF
a8IEIJrTdlsv6u3LJEQoS+R+PDhsLn6Ic6xAWvJjF8NJD5hd51ZBNhawNToYVEw7
o/vHa2oqN6AF5Qpt0bQcRaFZ2boxyLiLts20E7rYZ1qQQSp+kbKeO0UB/wxUr9zB
7p7L9wFNhsxAjkJmWVr5pNt5LSvuuvqEhe9wFC7T7PumNG20ZbzqlfUe3PNYcvrM
Oq3UNLlMSwhG7XpdvTB2Pyj0/kW6k2weqWw2gz8pwX+l3n4zNMwNLSO/aExYWIIH
zr3vnLKMk1NqjbOcroVeFKUtncM68PoF1g3qDeJQ0MZg6ken5dgPc0avaey1p9GA
ixH12rg8hsI89YRzscCr+1lGVnPTWR9HnjaTotOMTin8QXIrAmi41BobTVrzxiOs
6He4+HkcEiLnEC2LZsOM/aeIAzNiEmPBFJlNpGCDYEJQ/QjxCb7uSGiVcDKzz6CA
pMPhVyxLr6OG9bzTvBUxHjQ3DgkM2fvHMnmTc5tXDfvcDMkLZ+hDpimuRIkUUush
ZAWvDGO3p6WnzM1ir/TX
=gMC7
-----END PGP SIGNATURE-----
Tai...@gmx.com
> Any ideas what I could try?
guesswork, install ssh so you can get access then.
Sven Semmler
Hash: SHA256
* install sshd in a dedicated qube on computer 1
* follow
https://www.qubes-os.org/doc/firewall/#port-forwarding-to-a-qube-from-th
e-outside-world
to enable computer 2 to connect to sshd on computer 1
* follow
https://www.qubes-os.org/doc/firewall/#port-forwarding-to-a-qube-from-th
e-outside-world
to forward dom0 output through a VM on computer 2 to computer 1
At this point I should be able to use the keyboard on computer 2 and
see dom0 output on computer1. Then I'll just wait for the black screen
and run dmesg on computer 2 / capture output on computer 1
I'll report back when I have it. Thank you!
/Sven
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
f2qjYffu+S40gJrZyImOKi9kwGUg6RwdlsVuKrHPV+BVodurCD5C8t8YUqQRl7nI
0Hn8ZW1a2wA/gw1Zz+nON9E9YwxRcD8yNQsODZ+fIYA+Y2tHtwyNW4vp6kSPzTSa
HaPp6j5quISeInYSgSCFQfSMQulQZ6metomHlGSyd9FbUEbBzOvKon/vxOL7ezsv
z3P9un8AIhlWf8nm92ZBLGhc19A+PPdnN/9Hl210mNjIu67ytfTFby10GFITWBXp
2mHPXp0uy2zvaBE1GqONkn/Hb0KjHng5O6kn4Mnc0d3qOowPlByj89usHgBr4PmS
OrmjztKjvH2o7FUEIj7x1hUmTrx/juRrtjG0oMJ1qPx17qsZ+xMtCTKDDzrjh2kh
KPhEUuy28SXCEoH1xydtJR0uePPJIe7k+QW4lC3vnlCYmMPaVbdV3ixPN2oCfj6L
UIaTEERF+jjmfVx91VgUPC9YKFJAw3jNOSNEluTXy38O7KfFEWg0BdtaITTZuPfp
3/6RUPgsUzGWPFA5v8TuT2xWkijidB+PEDdVNpQBPeysWF4foFmslpsnTqXXs45f
T0Ef+IjYRe9Yh3mXwTDIBwpi3hMa2RsdBZc1Qz+Sol6Hp3E7rfKXzsYg1qdfTWdS
k4ECLv4HXbMtdTT2w34S
=aWvv
-----END PGP SIGNATURE-----
Tai...@gmx.com
Sven Semmler
Hash: SHA256
> Just use another distro to do it, don't go to all that effort.
loses. While it might theoretically be possible to diagnose and correct
whatever issues this computer has ... it's just not worth it.
So when the time comes to buy HW for Qubes 4.0 next year, I'll be sure
to pick an Intel processor and Intel integrated graphics. I don't need
better graphics and more than that I don't need the struggle.
Thanks for offering to help though. I understand your position that
technically an AMD would be just as good. But out of the box it won't be
.
/Sven
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
TPS6i7j6uhNdqTxCZQ58rmmIoyIW/1i4JBc8x8MJ/VTogbeqfDBZeBEvIbM1I8H3
S53TLhYxOkn5R7cq2OSyRrsScsKYUDcF5vNPbYT5nJ34ffXv5suj5GGhQshq1U8m
YH7TEbQDFdlPq3UfDb3dW0I/S61rXyd55bFHgnZwvvvQL0/ApjQtx8mEcRuEO8bX
jzaQIYSBEsnnMQ85KZaF6KjsmfipgM8exzYDcoBrMX6yiA7byxvhd+t3c/EYC4MM
63BY0Fr/1AhvITOkRVfew4LDY7TbnRNR6khian1di/27cakNVNUgGEVPvGKoRymx
VKRhrr1DTdqjEhWm+qgwUzc11H8p07mST5BGx8rfg9cHrGYfL2YQCkcwVPLERHKs
6UY/Adu6XnJUHJUeOt8/oN1NNn0FfxV68gzJ3ddd9VwTQ16rUbdwRqkO1nUqoCtN
29uR3KvS3PfZ8K7yaikRyTEoCcnNHmLF8PUR+yqz1FtvxfI5xmdDUKJmzUKw6QTE
UNmk0oNTZT1qEfSFaEGZClhGwLO+NSgxSS/SWAuXL4BlW98H0r1fjhdOEB+Rv4+a
1XAmO8s7gZ2qdeJxiQnGcKPFqn1JsNBgIfLuPcqEMpG0MSNKtqD69/nVKalNbAEl
kVVuaH7uy8R8i3lETCRZ
=cMt5
-----END PGP SIGNATURE-----
Tai...@gmx.com
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 09/06/2017 11:44 PM, Tai...@gmx.com wrote:
>> Just use another distro to do it, don't go to all that effort.
> Yeah, after 5+ hours of trying to get this to work, I'll have to cut my
> loses. While it might theoretically be possible to diagnose and correct
> whatever issues this computer has ... it's just not worth it.
>
> So when the time comes to buy HW for Qubes 4.0 next year, I'll be sure
> to pick an Intel processor and Intel integrated graphics. I don't need
> better graphics and more than that I don't need the struggle.
further developments of anti-features such as ME/PSP (and they are
generally cheap plastic crap anyways), so I recommend the following:
I would of course recommend an owner controlled Lenovo G505S (pre PSP
AMD) which does work with with qubes out of the box (it is on the HCL)
and also has open source init coreboot
But if you really are picky about this another good choice for you would
be one of the intel ivy bridge thinkpads (and install the better
previous generation t420 keyboard) such as the T430, W530, X230 etc.
they work great with linux and they support open source init coreboot -
you can also get a docking station or expanded battery for them - the
only issue is ME (although one can me-clean to the degree that
ivy/sandybridge allows more than the new intel stuff)
> technically an AMD would be just as good. But out of the box it won't be
going on.
I believe the reason it doesn't work is due to the fact that the
graphics device is quite new in linux years and hardly any experts have
one as it is pretty obscure. (btw fyi the AMD laptop you have right now
has PSP, which is AMD's ME)
Marek Marczykowski-Górecki
Hash: SHA256
> Basically I am not asking for some type of religious war on Secure Boot. All I am basically asking for is if the executables provided in the Qubes distribution are signed and if so which keys have been used.
>
> If they are not and we should sign them ourselves (either for grub or secureboot) this is good to know as well.
No, currently neither of those binaries (xen.efi, kernel, initramfs) are
signed. Only rpm packages carrying them.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
Version: GnuPG v2
/4OdRu/LmerqyxFW1jUjE19YeH0i+/Lr2VVOI07/NcZeEpH2VfoRmWZYeNExyH+x
FyxOBQIJjg+FyvihtHfPlGRHkRBtvAVrJcFCZgteUH5zN5fa/pY+05X3WjhnReNg
se9EQeMGY8VRyPHXxV4xKjfI77CUF6ezv4p5+1DwP3jbG/jPjFgskfUtfEHjP04N
aIpbbW204hAc4k6bWvRnGbEum+vXuYd318f8R7JzdEtJ1MVvv/DQt1JxQw8FPfUN
nLKv4tmHxqnQWIMktgqenT73t51eOFpdtEBcXnQvWk9XtiLfA8LQZ8b531ZogbU=
=CdQG
-----END PGP SIGNATURE-----
Wim Vervoorn
Hello Marek,
This is clear. Do you have any plans to do this in the future?
Best regards,
Wim Vervoorn
kra...@gmail.com
It's mind boggling that an OS that claims to be "secure OS" does not implement binary signing.
Unfortunately, as it is the system is not usable to me. Though it makes for a nice show with all different colors.
Any chance this will be fast tracked?
Thank you.
Wim Vervoorn
I totally agree with you but haven't seen anything.
I guess you will need to sign them yourself and add the key to the bios key database.
Best regards,
Wim Vervoorn
You received this message because you are subscribed to a topic in the Google Groups "qubes-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qubes-users/vrzdJmPNzrE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qubes-users...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/53e1084c-d3f7-45a3-9fe1-a247cad4e05b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
brenda...@gmail.com
> I totally agree with you but haven't seen anything.
>
> I guess you will need to sign them yourself and add the key to the bios key database.
In the meantime, I recommend a partial workaround.
Protect the BIOS from some forms of tampering:
1. Use a machine with a BIOS password that prevents software-based flashing when a BIOS password is set. Many "enterprise class" laptops from Lenovo/Dell enforce this. You can test it yourself. There's some interplay between this rule and the "only accept manufacturer-signed firmware" rule. Both can be worked around with hands-on access to the machine and the will to do it, though.
Protect the Drive data from some forms of tampering, including some forms on hands-on tampering:
2. Use a self-encrypting SSD (most recent Crucial/Samsung drives) with either a) ATA password protection* or b) using OPAL w/ open-source sedutil.
Belt & suspenders and all that (do you trust the drive hardware encryption manufacturer...maybe? maybe not?):
3. On top of the hardware encryption, us an OS (such as Qubes) that software encrypts the non-boot portion of the drive.
Option #2b is worth looking up, TCG Opal via sedutil is quite nice.
Let me explain #2a:
Historically ATA Password was a hack that was easy to workaround using various bits of software (for really poor implementations) or a combination of hardware/software systems that exposed the manufacturer test/programming signal lines via the jumper pin headers. Software that utilized this out-of-band interface was developed that called manufacturer routines to unlock the drive in several ways. These techniques were discovered by trail & error or leaks, and built primarily by eastern european and/or russian data recovery companies. In the end, good data recovery shops could recover data from ATA Password locked drives (not to mention good/bad governments).
TCG Opal's incorporation of ATA Password into their Self Encrypting Drive design standard changed all that.
Contemporary Opal 2 supporting drives (e.g. most consumer-level and enterprise-level Samsung or Crucial SSDs) treat ATA Password as "Security Class 0" whereas Opal is meant to be used with the feature set in "Security Class 2" (e.g. as provided via sedutil). In both Classes, the drive's user-area data is always stored encrypted with an initial factory-generated key, which is user replaceable.
If Opal's locking range support or an ATA Password is not configured (or when you disable either), the drive's user-area data is still encrypted at rest, but at power-on it automatically unlocks because: effectively you have a null password/configuration. Either the key is stored in the clear or the empty password/configuration value is passed to a secure hash function and the hash output is used to decrypt the drive's user-area key. The key is then loaded and used to decrypt the user-area data.
When an ATA Password is set, the password (or whatever the BIOS translates what you type to...) is passed to a secure hash function, the output of which is used to symmetrically encrypt the drive key, and the newly-encrypted key is then written back to the drive over the old encrypted drive key or clear key.
So, when the ATA Password is used instead of the more complex Opal configuration: on power-up the drive asks for a password, the entered password is run through a hash-based algorithm to decrypt the drive key and unlock the drive.
Importantly, these drives salso upport the ATA Sanitize/Crypto Scramble Ex function which randomizes the drive user-area key. Remember I said that the key is set at the factory. You can change it! Calling the function instantly destroys the existing user-area key and creates a new one. If you don't trust the factory key, I recommend this as a first step before putting your data on the drive. Lenovo has a utility for this for Thinkpads, Seagate's SeaChest utilities now also support this, hdparm may have added support too, I think.
Depending on the drive, you can see the result of the Crypto Scramble Ex call on non-zero'd flashed blocks. Test: write a sector with non-zeroed data you recognize, read the sector, see the ordered non-zero data, call Crypto Scrable Ex function, read same sector, see what appears to be random data.
What was stored in the flash did not change, but the key used to decrypt data from the drive is now different. Effectively, the drive is erased: the entire user-area of the drive is now random data or zeroes. Even physical flash blocks not assigned to logical flash blocks (e.g. trimmed but not yet erased; or retired due to bit errors) no longer have a key stored in the drive configuration that can recover any data from them.
Brendan
Marek Marczykowski-Górecki
Hash: SHA256
> Just curious if there is any movement on this.
>
> It's mind boggling that an OS that claims to be "secure OS" does not implement binary signing.
>
> Unfortunately, as it is the system is not usable to me. Though it makes for a nice show with all different colors.
>
> Any chance this will be fast tracked?
mostly because AEM is incompatible with UEFI, so there is no alternative
way of verifying /boot integrity boot time. In any case, you can verify
/boot files integrity using rpm database, which is derived from signed
rpm packages (see rpm -V). But that doesn't help during system boot.
Implementing this requires quite a bit of knowledge/research:
1. How to sign efi binaries (specific command), preferably in a
split-gpg compatible way (if that's using gpg at all, which AFAIK isn't
true). Preferable private key shouldn't be exposed directly to the build
environment, but in any case, it should be separate key from package
signing key.
2. Make sure kernel and initramfs also gets verified (the only binary
loaded directly is the xen.efi) - how to do that when initramfs is
dynamically generated? How other distributions do that(*)?
AFAIK xen.efi do have support for shim.efi (is that the correct name?)
for offloading signature verification, but still it isn't clear to me
how it helps here.
3. Make sure xen and kernel command line is also verified - similar
problem to initramfs. I'd strongly prefer to avoid hardcoding them at
the build time...
As you can see, meaningful implementation of this is much more than just
signing xen.efi and vmlinuz. If there is anyone who could help with any
of the above, we'd be very grateful.
(*) AFAIK in Fedora, if kernel is loaded with secure boot enabled, it
refuse to load not correctly signed kernel modules (and employ other
mitigations for modifying the kernel at runtime). But this is far from
enough, because it's still possible modify initramfs to for example
steal your disk passphrase. I don't know if there are other mitigations
against that.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
1yx6+gf9ElVMEp+52yhwTP5iQA4A1SZAJMdbKzN0InyCY7VowxcVqPKJwma7Fc1l
WKipTaMBHj0FjqYRYQc7KeDcy76oldJr6aDk5SICJu5fCfySO3viNozAEYoP0bFr
sKujRZN/Jk49khugLpFSza43Flum8t/jDJrnpkbO3qVDzG/8DF5dHKcyr9VjPiI3
tgliLDsyMxfJWA/hprtw2DZUFIuYRW0koVf78IjeOPpfHikahqYwVTg5o760Vajr
5IU11QAWJ5r+oDpcswcXRONzohz6GucKSdKCGbBpQHmIEyx+CGnOUxjFQqix3RPn
vk2yvouv58IqnvbW1YN5c0AB1rDmig==
=kY5v
-----END PGP SIGNATURE-----
cooloutac
https://ruderich.org/simon/notes/secure-boot-with-grub-and-signed-linux-and-initrd
cooloutac
> This article might help. They also talk about encrypted /boot.
>
> https://ruderich.org/simon/notes/secure-boot-with-grub-and-signed-linux-and-initrd
Seems as if people have only implemented this for debian based systems.
brenda...@gmail.com
It does not address BIOS/firmware tampering portion of AEM, though there are some mitigations in place when a BIOS password is used, depending on manufacturer.
Just FYI.
Brendan
Marek Marczykowski-Górecki
Hash: SHA256
multiboot2 protocol support in Xen. This, on the other hand is supported
only in Xen>=4.9, so Xen 4.8 in Qubes 4.0 is too old for that.
In Qubes 4.1 we plan to use Xen 4.11, so it would be possible to
implement it there.
But still, there is quite a bit of work with it. For example key
management. Since the initramfs is generated on user machine, there
needs to be a private key to sign it. This means each installation needs
to have its own key. The public part of this key needs to be embedded
into grub standalone image, which means we can't generate signed build
binary build time. This means different secure boot signing key for each
installation, so yet another key to be generated during installation,
then to be manually imported into UEFI keyring...
The script in that article is a good base for such solution, but
obviously it needs to be modified for Qubes specifics.
In the meantime I've found that newest tboot supposedly support UEFI
boot, so it could be possible to make AEM works on UEFI too. This would
handle initramfs, kernel cmdline etc verification.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
1yx0fAf+KREox86t4xIqLXU+Y+h0tG8yL+WRWGvAbQG50Lpav3dLgwZCIGNp1RzN
dmneyOXGKZzw+YdiW/dC7oqp8QJwVG7akw+/U63csHCUkGJ7t8NHA+On4A0TvewA
7Q5dZTpdmda07aFR4vQqCCokmLCeqxROrYEMRSFDr1qRpWCRp1hGIcopxcrsUVyA
rYIONpNDVbI5C3Oo1Y7NUAJuUaLZJBm+U0JjEiHF8DL7JysM1fnonkHORWOt5/jL
YX+Ozlz9BpzoDYRtCIA4MZfvzBIQ3BV4rgl1ft57Y2YvGALd6EMg+DSmPzPl82zK
zbkvDTgT3riHi8AnB8JsH6aMe8+UJg==
=KGDd
-----END PGP SIGNATURE-----
cooloutac
And I know Qubes team has prolly heard this before I always felt safer using debian. One of the reasons cause it was so much easier to make a kernel with it then fedora and only distro I could get grsec working properly with. More minimalist, etc.
Maybe Reg Tiangha can chime in. I wonder if maybe putting the script with initramfs in the kernel would actually be defeating the purpose anyways because its another security risk.
But I also understand why some people will say secure boot altogether is not worth it for these reasons cause if user space gets compromised etc and somethings are left vulnerable , but imo that goes for everything and doesn't change much. But I also understand why it might not be worth the effort or a priority for developers.
Ya TPM would be the best solution. I can probably get tpm module for my desktop but affordable laptops with the option are a little tough to find. Would love to have all of the above lol. But definitely would be great to have aem working with uefi and have signed grub.
what about encrypted /boot? :)
Tai...@gmx.com
designed to stop people from running linux"
There is nothing stopping you from installing coreboot with a grub
payload and using grubs signing features then setting the write lock bit
to prevent internal re-flashing which would be better in every way vs
closed source MS designed junk. The KGPE-D16, KCMA-D8 and the G505S are
the last and best owner controlled x86 devices with open hw init
coreboot and all work well for xen/qubes.
If you insist on using SB there is nothing stopping you from signing
things yourself and using your own SB keys...that is if your proprietary
firmware actually lets you do that.
I really can't believe that the deal-breaker is that you can't use qubes
with a proprietary UEFI kernel code signing application...
cooloutac
Sigh... Trying to sell some hardware again? Noone mentioned Microsoft. And I don't think anyone said its a deal breaker. Mind boggling you don't realize all the major linux distros already use this technology. Its for a reason.
And Xen is stopping us according to Marek. Hopefully it will be possible in Qubes 4.1 which is being developed to use a later xen version.
Tamas K Lengyel
> > Just curious if there is any movement on this.
> >
> > It's mind boggling that an OS that claims to be "secure OS" does not implement binary signing.
> >
> > Unfortunately, as it is the system is not usable to me. Though it makes for a nice show with all different colors.
> >
> > Any chance this will be fast tracked?
>
> Generally having signed xen/kernel binaries would be a good thing,
> mostly because AEM is incompatible with UEFI, so there is no alternative
> way of verifying /boot integrity boot time.
possible to enable both SecureBoot and AEM. Instruction and patches
are at https://github.com/tklengyel/xen-uefi
Cheers,
Tamas