Bite My Shiny Metal Ass

[richmond62]

https://forums.livecode.com/viewtopic.php?f=5&t=39329
-

BMSMA.jpeg (7.53 KiB) Viewed 6573 times

[richmond62]

However, in the light of some people, arguably, over-exaggerating risks, doing the 'disable' thing may not be the "wave of the future" re OXT.

[tperry2x]

Yeah, I just read all that.
While 'Security' is there for a reason, it's also perfectly easy to make a signed application completely run malicious software too. Like the TPM chip requirement in Windows 11, there's ulterior motives for companies pushing these narratives. It comes down to hardware / software sales or subscription sign ups. Money.

To use 'signed' applications as some kind of magic bullet or panacea that fixes everything is also complete nonsense.
Particularly when you can just chuck money at the problem to get yourself signed, then consequently deploy what you want. Once it's run, it's too late for Apple to do much about it, as even if they revoked the signing certificate from their end, the damage is already done and meanwhile the thing is spreading.

[richmond62]

Many years ago (20), I built a MacOS standalone with RunRev 2 that would, on opening, delete files on a Mac.

This was done on a spare Mac at my work: and the standalone successfully hosed the system.

Needless to say, the Mac was blanked and reformatted and no backup of my 'virus' was kept.

As far as I remember the thing took about 45 minutes work.

[tperry2x]

Yes, and imagine what kinds of fresh hell you could cause with access to a terminal shell running transparently on every platform.
Just make a malicious stack and open it with a signed version of Livecode community. (no, don't actually do that!) But my point is, you've then created a malicious tool which is signed. Negating all this pseudo 'security'.

This is why I'm always wary of stacks coming in, and code contributions, and always ask people 'what is it you've changed' and do a dif compare on everything. How am I to know I won't inadvertently pass on something terrible otherwise. (That's not a snarky remark on anyone by the way, before I get shot down for typing this) - it's just you do have to be careful in this day and age. But 'signing' doesn't prevent any of that.

[richmond62]

That person who was 'having a go at me' 'over there' strikes me:

1. A true believer in whatever Apple decides to dish out.

2. Naive.

[tperry2x]

Well, either way - for the people who think codesigning is the ultimate solution to a security problem, not being codesigned is enough to put them off running OXT Lite. I mean, it is (or should be) with an ad-hoc certificate, but even this ad-hoc certificate puts up warnings about being "self-signed by an unknown developer" - that's enough to scare those of a nervous disposition off using it.
(possibly altogether).

Particularly as Apple are making those warnings look more and more scary. Which of course is in their own interests.

It's a shame, but we may have to just give in to Apple's codesigning demands and throw money at the problem to get a proper certificate? (There's no "over a barrel" emoji, but perhaps there should be).

[OpenXTalkPaul]

Yes, and imagine what kinds of fresh hell you could cause with access to a terminal shell running transparently on every platform.
Just make a malicious stack and open it with a signed version of Livecode community. (no, don't actually do that!) But my point is, you've then created a malicious tool which is signed. Negating all this pseudo 'security'.

Exactly, it's a false sense of security they're selling.
Security is really about trusting sources. Code-signing/Notarizing/security certificates may just be the optimal way to monetize 'trust'.

I posted a stack earlier that loads a bytecode extension module into memory and then uses it, that is basically 'code injectiion'...hell, all 'scripting' is basically 'code injection', so if anyone is making standalone apps that generate code and execute it, that's probably enough to get your app rejected by certain AppStore, that's basically why you don't see ANY IDEs running on iPadOS (not to go too far off topic, but that IS why I'm so interested in an xTalk IDE that can run in a web browsers).

But I'd agree with Stam in that you should only disable things like Security Access Permissions (spctl) or System Integrity Protection (SIP) when you really need to, and then don't forget to re-enable it when you're done.

There's some things that simply cannot be done with SIP turned on though.
A quick Googling:
Loading untrusted kernel extensions.
Getting task-ports for Apple-signed processes.
Modifying NVRAM variables.
Allowing kernel debugging.
Those are the sorts of things you may need to do if you're modifying the OS, like if you wanted to remove unwanted software that was pre-installed by Apple, or if you're developing a new Driver / Kernel Extension (.kext), or installing an unsigned kext (probably when building a Hackintosh or building unofficial support for old Macs like OCLP) or for reverse engineering someone else's software.

I believe 'spctl' only effects 'GateKeeper', disabling the 'trusted sources' for installing new apps, which is not the same as SIP that tries to protect the operating system from being tampered with (the macOS 'System' basically similar to firmware on a flash-rom now).

[tperry2x]

There's some things that simply cannot be done with SIP turned on though.

Yes, even changing the image behind the lock screen in MacOS (before you choose a user account if you have multiple users).
The simplest of functions you'd think, but doing so requires sudo access to a certain area which system integrity protection will prevent as default. It's headed more in the iOS direction unfortunately.

[OpenXTalkPaul]

There's some things that simply cannot be done with SIP turned on though.

Yes, even changing the image behind the lock screen in MacOS (before you choose a user account if you have multiple users).
The simplest of functions you'd think, but doing so requires sudo access to a certain area which system integrity protection will prevent as default. It's headed more in the iOS direction unfortunately.

Right but you would normally not want anything mucking around in the operating system files.

Unlike iOS (for now) on macOS you CAN disable SIP easily enough but it requires rebooting.

To disable SIP:
Restart your computer in Recovery mode.
Launch Terminal from the Utilities menu.
Run the command 'csrutil disable' (or 'csrutil enable' to turn it back on)'.
Restart your computer.

[OpenXTalkPaul]

I don't know about Sonoma or newer, but in the past GateKeeper (File Quarantine) has been fairly easy mechanism to side step ( I've done this myself in the past in a situation where I had no machine privileges to install an app). There's been several exploits found to get around it.

The first exploit like that, that I remember reading about anyway, involved simply embedding the unsigned executable into an .RTFD Doc (Apple's 'bundle' folder version of RichText Documents), like inside a readme doc. Another exploit involved simply adding a 'shebang' (#!) without following it with a shell script interpreter. The point is it's not infallible protection.

Here's a really good site for reading about macOS security (there's also related software utilities on this site), that's been tracking the gradual security hardening of macOS for many years now: https://eclecticlight.co/2020/06/25/big ... rotection/

[tperry2x]

Right but you would normally not want anything mucking around in the operating system files.

Yes, not normally. However - in a school (or a corporate setting) where the login background has to be branded with the school's logo (before a username is clicked), this requires modification of those privileged and protected areas of the system.

We did find a way, as there's a few paid commercial offerings that will sidestep Apple's 'security' and allow this to be set. (Setting this appearance is something that has always been possible in Windows and Linux). If a way hadn't been reached to set this, the macs would have been moved to staff-facing / office-only use ones and taken away from the students doing DTP. (They would have probably been given Windows machines as replacements).

^ none of the above would have been my decision though.

What's that got to do with anything? - well it comes back to the point of over-reaching control by Apple. Just like they tried (and failed) with the now broken T2 security chip (which all it managed to do is to prevent repairs) - that was also supposed to be vaunted as "the ultimate in security" if I recall

If Apple wanted to make (more) money, rather than shoehorning everyone into their App Store (which itself has been shown to contain malware - SIGNED malware (1) (2) (3) (4)), - instead, perhaps they should have bought shares in Nvidia

But to frame it as 'Security' is plain misleading. Let's just call it what it is - a drive for profit by directing traffic to it's app stores. It's no coincidence that the app store also has direct shortcuts to Applecare and to purchase additional iCloud storage - it's all part of the subscription model & cash is king. Developers can also get signed directly upon submission to the App store, by Apple, when apple approves the submission (and of course takes their cut with this factored in). Forcing developers, (especially open source ones with no funding), to have to buy developer certificates through scare tactics is just plain wrong.
Could we even get one, or are we classed as a "fictitious business" - we certainly don't have a "D-U-N-S number".

Also worth pointing out, that when we finally come to building an arm version (one day), it's GOT to be signed. Apple won't allow unsigned NATIVE arm apps to even run, although we are supposed to feel thankful that they will allow an arm-universal app to forcefully be opened without signing, by jumping through even more extra hoops.

Quite frankly, the code signing in MacOS Ventura + is almost enough to make me say "to hell with it, no more mac versions".

That site also goes on to say why codesigning in Sonoma+ might be even trickier. (wait, there's more )
It's all a bit of a "hot mess" as Steve Jobs would describe it, or should that be "Toxic hellstew"

[richmond62]

The ultimate security is a pencil and paper and a computer nowhere near you.

The whole thing is a bit like jumping into a swimming pool and being surprised you get a bit wet.