Any real advantage to upgrading from Mojave to Catalina now?

[jaymonkey]

Do you know if some elements of SIP can be turned on/off for a specific executable?

@exquirentibus,

The SIP level for MacOS must be set prior to booting the OS and once set the current level of SIP is global.
Once MacOS is booted the level of SIP can not be changed without rebooting.

On a genuine Mac you need to boot into Recovery and run the "CSRUTIL" command in Terminal which will set the protected system variable "csr-active-config" in NVRAM.

We don't need to do that on a Hackintosh as you can dynamically experiment with SIP using Clover's "Options" Menu :-

Each SIP element is a Bit Mask value, in the above config we add the Bit Mask values together :-

1 + 2 + 4 + 32 + 64 = 103 which we then convert to Hex = 0x67

You can premaritally configure the level of SIP on a Hackintosh by setting the parameter "CsrActiveConfig" in the "RtVariables" section of Clover's config.plist :-

    <key>RtVariables</key>
    <dict>
        <key>BooterConfig</key>
        <string>0x28</string>
        <key>CsrActiveConfig</key>
        <string>0x67</string>
    </dict>

The current SIP levels have been derived by examining the MacOS source code :-

xnu/bsd/sys/csr.h at master · opensource-apple/xnu

The Darwin Kernel (mirror). Contribute to opensource-apple/xnu development by creating an account on GitHub.

github.com

The important section of code is :-

#define CSR_VALID_FLAGS (CSR_ALLOW_UNTRUSTED_KEXTS | \
                         CSR_ALLOW_UNRESTRICTED_FS | \
                         CSR_ALLOW_TASK_FOR_PID | \
                         CSR_ALLOW_KERNEL_DEBUGGER | \
                         CSR_ALLOW_APPLE_INTERNAL | \
                         CSR_ALLOW_UNRESTRICTED_DTRACE | \
                         CSR_ALLOW_UNRESTRICTED_NVRAM | \
                         CSR_ALLOW_DEVICE_CONFIGURATION | \
                         CSR_ALLOW_ANY_RECOVERY_OS | \
                         CSR_ALLOW_UNAPPROVED_KEXTS)

Most guides recommend setting "CsrActiveConfig" to 0x67 and "BooterConfig" to 0x28 which works for most users.

If you search the forums you'll find many posts discussing the pros and cons of disabling SIP and to what level. A lot of users believe (incorrectly) that setting "CsrActiveConfig" to 0x67 completely disables SIP but as you can see from the above Clover screen shot and source code that it is not the case.

I expect that if/when notarization becomes mandatory a new SIP bit mask value will be added to disable it.
"csr-active-config" is stored as a 64 bit word in NVRAM so there are plenty of Bit Mask levels left to use.

Cheers
Jay

 

[pastrychef]

There's no need to disable SIP for unsigned and/or unnotarized apps. Just right-click and select Open.

Look at what happened to Chrome users who had SIP disabled...


Source:https://arstechnica.com/information...it-was-chrome-that-stopped-macs-from-booting/

 

[ydeng]

Excellent detailed explanation! Do you know if some elements of SIP can be turned on/off for a specific executable?

I'm going to start using Xamarin to develop an IOS/Android app for a client. As a by-product, I can use C# to create a MacOS app. If SIP has an API with fine-grained control, I might be able to create something of use?

Possibly creating a task that runs an executable with certain SIP privileges that would revoke them when the task terminated?

But at the moment, I know almost nothing about SIP or any API's that might allow controlling it's behavior. I currently just code on the Windows platform.

Xcode adds com.apple.security.get-task-allow entitlement so the other processes(debuggers) can attach. Full listing of flags are in the xnu source http://82.196.10.231/xnu-4903.221.2/html/xnu-4903.221.2/bsd/sys/csr.h.html . Note CSR_ALLOW_EXECUTABLE_POLICY_OVERRIDE is new.

 

[exquirentibus]

Hmmm. Shout me down if you like, but I suspect that level of fine-grain should be a no-no. Isn't that a nice little doorway for a virus or malware?

Although developers need to be able to disable SIP as @jaymonkey says, that is a conscious decision to make. If it became on a per-app basis that could get confusing for the average user and, dare I say it, very Windows-like.

I would respectfully disagree. In my limited understand of MacOS, you can only turn SIP on or off.

Being able to limit a single executable (rather than all) so that it can modify certain directories or features on a very fine-grain level is very desirable, and one of the nice features of Windows. There are a massive # of permissions that an IOS/iPadOS user must specifically grant - which no doubt can be a bit confusing.

An app like I'm suggesting, would give an executable certain specific permissions - and then take them away after it's finished - and would shield the user from a lot of decisions, hopefully - if designed properly, making it less confusing to be 'more secure' or at least give the illusion of more security.

Malware is really coming on strong for the Apple platforms. There's a firmware bug in I think iPhone 10 and below that can never be patched that will allow hackers to take over any iPhone (in their possession) and examine previously hidden system code in detail. Things are going to get very interesting this next year!

You might be familiar with this Apple mag: Apple Insider reports massive uptick in Mac malware ? There are other security focused magazines that are more specific. Security is going to be a major problem on Macs - and we should be prepared, or be prepared to lose control of our Macs and Hackintoshes.

You might even be surprised with what mainstream programs install and how they 'phone home'?

This is a useful open source tool that runs on MacOS that takes a snapshot before and after installing an executable and reports on all the changes. I've worked with the developer on fixing some bugs as more features are added. Rather useful tool!

Microsoft Attack Surface Analyzer

I'm no Mac security expert, and don't want to debate security as my knowledge is limited on the Mac platform, but ... even an outsider can see that security is going to become more an more important - and a lack of security more unforgiving for Windows and also Mac users.

 

[jaymonkey]

In my limited understand of MacOS, you can only turn SIP on or off.

@exquirentibus,

Not true if you read my post above you will see that there are many levels of SIP that can enabled/disabled.

An app like I'm suggesting, would give an executable certain specific permissions - and then take them away after it's finished - and would shield the user from a lot of decisions, hopefully - if designed properly, making it less confusing to be 'more secure' or at least give the illusion of more security.

I very much doubt that will ever be possible on MacOS due to the high risk of infection via Malware/Trojan, this is the major issue with Windows that allows apps to run with elevated privileges and does not ask the user for admin rights if UAC is turned completely off.

MacOS will always request the Admin Password when an installer or App needs to access/modify system files or folders.

Apple recently introduced the protected (read Only) System partition in Catalina to act as another level of protection against system file modification even if certain elements of SIP are disabled, which was a smart move on Apples part IMO.

Cheers
Jay

 

[UtterDisbelief]

It's a shitshow, just random folks saying they updated ketxts successfully, no Tonymac official tools, downloads section is completely outdated, 3rd part solutions basically mean you throw everything you know from here out the window.

I regret moving from Mojave to Catalina without an updated Unibeast and Multibeast release

It's good to know you appreciate the Tonymacx86 tools . Rest assured they are being worked on. First to appear is the new EFI Mounter v3.1.

Updating the whole macOS is something that people often dive into without thinking - and agreed, that can cause problems. Experienced hands usually wait until the 3rd or 4th iteration of any new macOS before moving.

Having said that, I personally didn't wait that long and was there at 10.15.1 AND running OpenCore for the first time.

Catalina presents a whole new set of challenges. Some don't seem like much but they are indicators of what is to come as Apple tightens up on everything and where things are allowed to be installed. This makes coding new versions of the UniBeast and MultiBeast tools a bigger job than it was previously.

I also think it is important to understand the distinction between UniBeast and MultiBeast, and Clover. Clover is being phased out and the devs are moving to OpenCore. That is another big challenge. A whole new way of doing things.

I've made that move too and can confirm it is quite a learning-curve. But it is still beta so perhaps not ready for general adoption just yet.

I find it hard to agree with your first sentence. Folk are trying their best to help others - for free. What's more even a Catalina build with OpenCore does not have to be messy. In fact I would suggest it is a lot cleaner than previously.

And remember, no-one has written the instruction-book for the Hackintosh world. We all just try and help each other get their systems running smoothly.

 

[TurbineSeaplane]

I mainly upgraded so I can upgrade to a 5700 GPU at some point.

It's been flawless for me..

 

[Nodarkthings]

Hi all!
I'm a "multi MacOS partitions on the same disk" user: 10.11 on my main SSD, together with a — still experimental — 10.13 ; 2 x 10.11 + 1 x 10.9 on my HD for respectively testing purposes, clone and incompatible software.
Is this still possible with Mojave and Catalina or do they impose constraints?
First of all, I suppose that if I still want to use 10.11 and 10.9 I'd better keep them on a different drive to avoid issues? — though currently my SSD is formatted in HFS with the second partition as the APFS container and all goes well...
I wonder if Catalina, with its new partitions scheme, allows for an other version of MacOS on the same drive? And what happens to the Boot Camp partition, if there is one? It seems obvious they can't be contained in the APFS container, of course.