Value of Open Core's SecureBootModel for hackintoshes

[deeveedee]

I have been challenged here regarding my belief that Open Core's SecureBootModel has value for hackintoshes.  You can see my response here. I'll admit that my initial investigation of the Open Core SecureBootModel here was only a cursory read and I can't possibly understand the full macOS SecureBoot process, but all will need to forgive me if I doubt my critic's claim as being biased with judgement clouded by hatred for Open Core and Acidanthera.

 

I am going to research this further and will report my findings here.  I don't have a strong loyalty to Open Core or CLOVER, so my judgment won't be clouded.

 

I am currently doing my research with the EliteDesk 800 G5 Mini (documented here) running with Open Core 0.9.9, SecureBootModel=j174 (MacMini8,1 as per this document).  I am going to consider the use of Open Core vaulting and ApECID during my research.

 

My current understanding of macOS SecureBoot on a hackintosh (without T2) is illustrated by the following (from here) :

 

I don't consider verification of kernelcache and of the OS snapshot to be "useless."  My research will be slow and my updates here will be infrequent, so I welcome posts in this thread from others.  Hopefully the posts will remain constructive and fact-based.

[miliuco]

Apple Secure Boot is the technology used in Macs to verify the integrity of the operating system at boot: boot loader > kernel > system volume snapshot. If this check fails, macOS won't boot.

Apple Secure Boot only works during the boot process, once macOS is running it no longer performs any function.

 

Apple defines 3 Secure Boot modes:

• Full Security: Only allows to boot the installed operating system or another signed version of macOS in which Apple currently trusts. It also checks the integrity of the installed version. If the check fails, the system offers to reinstall macOS or boot from a different disk.
• Medium Security: Checks that the installed version of macOS is legitimate but not the integrity of the system. Lets you boot any signed version of macOS in which Apple has ever trusted.
• No Security: other systems or versions different from those mentioned in the secure options are allowed. There are no requirements on the boot operating system.

Apple Secure Boot state on Intel-based Macs can be obtained from NVRAM:

nvram 94b73556-2197-4702-82a8-3e1337dafbfb:AppleSecureBootPolicy

If the variable is found, it can be one of the following:

• %02 - Full Security Mode
• %01 - Medium Security Mode
• %00 - No Security Mode

If the variable is not found, Apple Secure Boot is not supported.

 

SecureBootModel with other value than Disabled gives Medium Security, for Full Security you must use ApECID.

 

SecureBootModel and ApECID:

• with SecureBootModel=Disabled>> no security (%00)
• with SecureBootModel=x86legacy or any of the valid values >> medium security (%01)
• with SecureBootModel= any of the T2 values plus ApECID non zero >> full security (%02).

Notice that since OpenCore 0.7.2:                                                                                                                           

• x86legacy is designed for machines without T2 chip with Big Sur and Monterey
• j137 doesn't work on Monterey
• j137 is the recommended value for macOS 10.13.2 through 10.15.x            
• systems older than macOS 10.13.2 must set SecureBootModel=Disabled
• users who don't want to have Apple Secure Boot for any reason can set SecureBootModel=Disabled, even in Big Sur and Monterey.

In summary, these are muy opinions:

• I appreciate the interest that the Opencore developers have had in making our Hacks as similar as possible to a real Mac, including Apple Secure Boot. I know that it is impossible for everything to be exactly the same, but they have managed to give OpenCore features that very often make me forget that I am using a Hack and not a real Mac
• SecureBootModel=Disabled does not appear to lower the Hack's security below a required level, at least for personal PCs. SecureBootModel only acts at boot time to check the legitimacy/integrity of the booting system. Another thing is in multi-user environments (business...) where a malicious user can access the Hack to boot it from a device with manipulated macOS.

I don't agree 100% with @Slice. There are Macs without T2 that have Apple Secure Boot medium security, for example iMac19,1 with macOS 10.14 or newer.

But I do agree with him that having SecureBootModel enabled or disabled has no/little importance in Hacks.
Without forgetting that Clover lacks this property and many thousands of users have used it and are using it to full satisfaction.

 

Edited March 28 by miliuco

[deeveedee]

9 minutes ago, miliuco said:

But I do agree with him that having SecureBootModel enabled or disabled has no/little importance in Hacks.
Without forgetting that Clover lacks this property and many thousands of users have used it and are using it to full satisfaction.

 

Are you saying that when OC's SecureBoot = "medium" is used with hacks, this verification does not happen?

 

If so, then why does SecureBootModel need to be Disabled on hacks that use OCLP post-install patches?

Edited March 28 by deeveedee

[miliuco]

@deeveedee

Medium Security: Checks that the installed version of macOS is legitimate but not the integrity of the system. Lets you boot any signed version of macOS in which Apple has ever trusted.

Dortania schema es also valid for me, difference between medium or full is the verification of the integrity, not just the legitimacy, of the booting system.

 

Edited March 28 by miliuco

[deeveedee]

22 minutes ago, miliuco said:

@deeveedee

Medium Security: Checks that the installed version of macOS is legitimate but not the integrity of the system. Lets you boot any signed version of macOS in which Apple has ever trusted.

Dortania schema es also valid for me, difference between medium or full is the verification of the integrity, not just the legitimacy, of the booting system.

 

I know the definitions... So you're saying that verification of the kernelcache and OS snapshot have little value in hacks?  I'm trying to understand your comment that "SecureBootModel enabled or disabled has no/little importance in Hacks."

 

EDIT: In other words, even if the only thing that SecureBootModel does for us is make sure we're booting an Apple-signed macOS with an Apple-sealed APFS volume, is that of "little value in hacks?"

 

EDIT2: @miliuco I am familiar with your well-written post here.  It doesn't seem to me that Acidanthera added SecureBootModel purely for use with real Macs.  I'd love to hear an opinion from someone on the Acidanthera team.

Edited March 28 by deeveedee

[miliuco]

@deeveedee

Yes, in single user use on a home PC I believe that disabling SecureBootModel has little influence on security. It may be that in multi-user or business use it may be more important.

Verification of the kernelcache and OS snapshot is important, of course, but you have to accept that there are users who can operate differently without being worried about it and that is something we have to accept.

I assume that we are using a boot loader (OpenCore or Clover doesn't matter here) developed by people we don't know (but we trust) to install macOS in an environment for which it is not specifically designed. I can say the same about kexts.

If strict security (or as high as possible) were one of the guidelines of my activity with computers, it is likely that I would not have Hacks or Windows. But for me mainly it is a very great hobby.

I don't underestimate security at all, but I think that what macOS gives me in the Hack is enough for me even with SecureBootModel=Disabled or OCLP. Actually, I have SecureBootModel=x86legacy on all systems except for one Sonoma disk where I am interested in keeping in touch with the evolution of OCLP and the patch for Broadcom Wi-Fi.

I think we're getting off the topic of this thread and linking to other posts about security in macOS. If the topic is SecureBootModel and its usefulness in Hacks, I contribute what I know so far about it.

 

Edited March 28 by miliuco

[deeveedee]

11 minutes ago, miliuco said:

@deeveedee

Yes, in single user use on a home PC I believe that disabling SecureBootModel has little influence on security. It may be that in multi-user or business use it may be more important.

Verification of the kernelcache and OS snapshot is important, of course, but you have to accept that there are users who can operate differently without being worried about it and that is something we have to accept.

I think we're getting off the topic of this thread and linking to other posts about security in macOS. If the topic is SecureBootModel and its usefulness in Hacks, I contribute what I know so far about it.

 

 

I agree that the value of OpenCore's SecureBootModel depends on the use cases.  That has always been my point with security.  If I disconnect my Mac from all networks and turn it off, then it is completely safe for use as a paper weight.

 

We're not off-topic in this thread.  i think it's important for people to be able to see what OpenCore's SecureBootModel does and then for them to make their own determination.  My challenge is with blanket statements like "useless," "nonsense" and "has no/little importance in Hacks" when no context has been provided.  Statements like this lead users to believe that they don't need to consider their use cases.

[mhaeuser]

@deeveedee For context, I implemented OC Secure Boot. Your observations are all correct from what I can tell. You are also correct that non-T2 Macs *do* use Apple Secure Boot Medium Security starting with the verification of the kernel (efiboot is not verified). I guess Apple's work is also "nonsense", maybe they need some better experts for consultancy. ;)

 

@miliuco's distinctions of Full and Medium Security as well as evaluation of security are lacking. Full Security works a bit like iOS, where the Image4 manifests are personalized for the machine (based on ApECID), which prevents booting unexpected installs (i.e., ideally such not explicitly installed on this machine). Of course, the iOS model is more sophisticated with downgrade protection and all. The advantage of this is questionable for various reasons, but I think of it as an intermediate step towards the more iOS-like model we got with Apple Silicon. I'm not sure whether Apple has any protection whatsoever against just re-using the same ApECID on another machine to forge supposedly trusted installs with T2.

 

Regarding whether this is needed for personal use, well, why not? Every consumer device nowadays uses Secure Boot - Desktops, Laptops, Tablets, Phones, Watches. Windows requires it to be supported, macOS enables internal checks by default, and even many Linux distros are capable by default and ship with the necessary infrastructure. Booting an external device is not the main or only attack vector, any malicious modification of the boot chain suffices (which can be done in software with admin permissions and with incorrectly configured systems even with plain user permissions, also privilege escalation exploits could suddenly be made much more persistent). I advise against making up supposed "primary threat vectors" and to instead trust the leading engineers who do this for a living.

 

Regarding T2, well, it is not even involved in what is classically called "Secure Boot". T2 Macs have the additional efiboot verification done by Mac EFI (which OC does for us, but introduces the new issue that OC must be trusted too), which serves the same purpose as UEFI Secure Boot. In fact, when you sign OpenCore for usage with UEFI Secure Boot and configure Apple Secure Boot correctly, you have a fully end-to-end Secure Boot chain. There are no compromises or "half-bakedness" due to missing T2 here.

 

However, T2 is involved in two related technologies, called "Trusted Boot" and "Measured Boot". The former verifies the integrity of UEFI itself. Without it, you could maliciously modify the firmware and then disable Secure Boot that way. However, if you use a device with Intel Boot Guard or similar, it is not disrupted by using UEFI SB-ready OpenCore and Apple Secure Boot - you again have a perfectly valid end-to-end Trusted Boot + Secure Boot chain.

 

The latter "measures" various platform properties (configuration, loaded software, ...) and then applies security policies to them. For Windows and BitLocker, TPM may not release the decryption key if the measurement yields unexpected results. For Apple T2, I am actually not sure, it is not well documented or explored which policies they apply. You cannot easily replicated this in software, but it is not even clear what exactly you lose.

 

TL;dr, T2 hardly matters here. I advise to ignore @Slice for such topics, as he primarily drops uneducated one-liners, ignores corrections, and decides to remain both ignorant and yet confident in obviously incorrect claims.

[deeveedee]

@mhaeuser Thank you for contributing to this thread.  My intent wasn't to bash anyone or any boot loader and I certainly do not want to mandate my security preferences.  Just trying to raise awareness.

[RobertX]

2 hours ago, mhaeuser said:

I advise to ignore @Slice for such topics, as he primarily drops uneducated one-liners, ignores corrections, and decides to remain both ignorant and yet confident in obviously incorrect claims.

...statements like this explain why @Slice has issues with the "other" folks, an otherwise informative post turns into an insult so easily...does not clover now implement much of open core? ...and as to security, aren't we all here running machines "hacked" to one degree or another, so where does security start?

Please do continue the discussion, but if you drop the personal attacks...we might all learn something

[deeveedee]

@RobertX Agreed.  The personal attacks take two to tango.  You missed your opportunity to provide the same comment on Slice's original volley that started this discussion.  Let's keep the conversation friendly, informative and professional and recognize that there's plenty of blame to share.

Edited March 29 by deeveedee

[deeveedee]

Does OCAT facilitate generation of a new Open Core EFI with vaulting and ApECID?  Making minor changes to an OC EFI with vaulting is painful (at least for me).  Having OCAT automate SecureBootModel configuration with vaulting and ApECID might just convince me to use an Open Core configurator.

[miliuco]

@mhaeuser

Thank you for your post. Always useful. Always learning from people like you.

And yes, why not? as you say. 

[miliuco]

@deeveedee

I don't see this feature in OCAT.

You are right: ApECID + vaulting is a hard task. If you want to add UEFI Secure Boot, even more difficult.

[mhaeuser]

Re Slice and tango: Well, you can call it an insult if you want to, I won’t argue. However, after more years of reading and technically commenting on the same kind of one-liners than most have been into Hackintoshing, way back into the Ozmosis days, I am too tired to not just state the obvious. If this was about some dubious news outlet that sells ignorant opinion pieces as news stories, I think people would tend to agree. Just don’t trust unreliable sources.

 

Re security, there is nothing about OC etc. that inherently screws security. Of course, some things increase the attack surface and things are not perfect. But “this is hacky anyway” or “you compromise on one thing, might as well throw everything in the trash” are very short-sighted. All critical things in Acidanthera have been designed with best-effort security in mind and stuff like Vault actually exceeds typical solutions.

[Max.1974]

Hello @mhaeuser 

 

Thanking you for the information, I would like to ask, as an average user, in the case of Clover in relation to security, would it be possible to implement something different from SIP or similar to SecureBootModel?

I ask not with the intention of causing more controversy, but rather out of necessity. I use some programs in the Cloud that involve confidential information, especially from my work as a public agent, and I have always trusted Opencore a lot and now I am resuming the use of Clover as it seems less conflicting with the installations. And all due respect to the OC team, which is dedicated and I did and still use it on my machines, and all thanks to the other Clover developers, regardless of the differences, Hackintosh would be a perfect world, if there weren't so many conflicts between the creator from Clover and the OC developers.

 

The question I ask is whether we can safely use Clover or Opencore without OCLP and whether we can implement something different that would serve the same purpose.

 

I know this may be up to the Clover development team, but honestly, today I see that we should come together more, on this threshold of the dark days of Hackintosh, instead of distancing ourselves.

 

I ask because access to other developers is rare, with the exception of some wonderful souls who step up and help us like @chris1111 .

 

Thanks a lot, and  if you can answer and help, thanks again!!  

 

 

[deeveedee]

@Max.1974 Bless your well-intended heart.  I think you can answer that question yourself, but I eagerly await the responses.

[mhaeuser]

@Max.1974 Regarding Clover and security, there are no conceptual blockers. The technical ideas of Clover and OC are not so different and not implementing sound SB support really is just a dev decision. And I son’t think they are going to reconsider.

 

The rest I can only address by a history lesson. In 2013 or so, I started submitting changes to Clover - a bit shoddy at first, but it got better quickly. In 2014, I started RE’ing Apple-proprietary EFI extensions. Some time in 2015 or so, I started proposing integrating some into Clover, starting with the boot hotkeys. I got a response akin “Hack cannot support hotkeys because it’s no Mac” at the time, despite providing RE’d headers and implementations. The same year I started talking to The HermitCrabs Lab, so I decided “well, ok, give it to Ozmosis then”. Contributing to both Clover and Oz, I proposed collaborating more and got meddled up in their beef with Slice, who dropped the same ridiculous comments about Oz then as he does now about OC. There were claims Oz stole a lot of stuff from Clover, but once I got access to the repos much later, I could validate first-hand most rather happened vice-versa.

 

Anyway, Oz kept expanding with my RE results, including the bless support that now makes OC support for macOS installers and such seamless. When Vitaly re-appeared in 2017, we tried to get FV2 working with Clover and were faced with serious technical issues from Clover’s side. Around the same time, Clover v3 got proposed and I - yet again - tried to push for a collaboration. Alas, the project leadership was a mess and nothing ever happened.

 

At the same time yet, HermitCrabs wanted to re-do Ozmosis - basically OC v0. Tired of the technical issues with Clover v2, Vitaly acquired the thing and we started bringing the pieces together. And - yet again - we tried to collaborate, basically suggesting to make this Clover v3. At some point, there were talks that Slice may contribute the GUI to OC. What we got instead were no contributions whatsoever and instead the snarky comments about Oz became snarky comments about OC.

 

So when Clover started leveraging OC libraries in 202x, I - yet again - suggested to collaborate. After all, we know our code best. So I made remarks about stuff like how they used our symbol patcher and I was basically told I’m just here to hate on their efforts. Two weeks later, they hit the very issue I warned them of and applied the fix I told them to ahead of time.

 

So, everyone chiming wisdoms about “but there’s always two parties” and “drop the beef”, sorry that I will not try a fifth(!) time to turn this nonsense into something constructive. I think I got more burnout from Team Clover politics than from all OC work to date.

[Max.1974]

@mhaeuser 

 

Thank you for responding so candidly. I'm sorry for everything that happened, what a shame that I have no or almost no knowledge to help you with your perspectives. From what I understand, and I understand it well, the whole situation has become a huge burden. What a shame my brother, such brilliant people like you and many I met here, if united as a real team, would make Apple itself jealous. I understand perfectly, and if in any way I can collaborate or contribute, please let us know how we can help.
I've been here for so many years, following everything, but as I'm in the legal field, I'm always in the box, always admiring the machine languages and always imagining everyone's unity. Unfortunately, the reality is sad, especially as I imagine the life of Coders, as it is quite hard work and lonely. God bless you all, and forgiveness for the inconvenience. Thanks for the answers. If there is hope, it will certainly come from noble hearts. Thanks for answering. From my heart this is important to me, as I have been using hacks since 1999. Thank you!!

 

 

4 hours ago, deeveedee said:

@Max.1974 Bless your well-intended heart.  I think you can answer that question yourself, but I eagerly await the responses.

 

Thank you my dear ! You are great person!! 😍 

Edited March 30 by Max.1974

[Slice]

Security against hackers? Who we are?

boot.efi checks kernelcache? For a what? We patch it! We inject hackers kext inside.

[Slice]

Don't confuse the concepts, FileVault2 is working with Clover in Sonoma. It has no relation to SecureBootModel=disable.

[mhaeuser]

@Slice You are a broken record, please stop embarrassing this community and yourself.

 

PS: For those who don’t know, AuxKC is a concept Apple introduced exactly so that they can authenticate BootKC and SysKC even when third-party drivers are installed. Injected kexts for us are authenticated via OC Vault, so no loophole there. Linux has its whole own infrastructure to similarly authenticate such things with MOK. All concepts are sound, end-to end, and industry-standard. Ignore this ignorant bar gossip.

[deeveedee]

7 hours ago, mhaeuser said:

Injected kexts for us are authenticated via OC Vault

 

I'm fairly certain Slice was stating that we're trusting the kexts.  OC Vault isn't guaranteeing the kexts to be harmless - just that they haven't been tampered with after we copied them to our OC EFI.  While you can be certain of the safety of Acidanthera kexts, many OC users are pulling kexts from various sources and injecting them via OC.  Nothing OC vault can do about that (not that you suggested it can).

 

What we don't want to do here is imply that security is in any way guaranteed by the additional OC measures discussed here.  At least, that has not been my intent for starting this thread.

Edited March 30 by deeveedee

[mhaeuser]

@deeveedee Yes, but it’s the same for any authentication chain. That’s one of the reasons Linux folks have been (rightfully) complaining about the Shim situation, which effectively requires trusting the Microsoft 3rd party certificate and thus everything else it signs.

 

Also no, that is not what he was saying. This is yet another false dichotomy of full security and “but we mod/hack things anyway, so it’s all nonsense”. If he meant that we are trusting them (and the injection code itself), it would make all the more sense to make things tamper-resistant to preserve said trust (which is exactly what OC does).

[deeveedee]

@mhaeuser I'm inclined to give him the benefit of the doubt and avoid misinterpretation.  I didn't read his comment the same way.