When I delete caches to the TRASH and then try to "securely delete" using PERMANENT ERASER or ONYX (Sierra), I get a message about . . .


SUIDGuardNG.kext


. . . cannot be deleted (something about incompatible?).

Anything I should be concerned about? Should this file be removed by some other method?

Any help would be appreciated.

If ONYX won't delete something, then it's something your system absolutely requires. Check out the advisories in the Help Center panel which should pop up on your Desktop when you open ONYX.

Googling the extension indicates that this is a known issue. The solution recommended is to reboot the Mac into Safe Mode with the Shift key, then open “/Library/Extensions” and look for “SUIDGuardNG.kext” and delete it. The cache will be rebuilt.

Super. Thanks for getting back so quickly.

I will do the SAFE BOOT thing and let you know if there are any further issues with this file.

That's interesting, I'll have to go look for that. (where is that file located?)

Unix filesystems have ownerships, ACLs, permissions, and flags for security. Mac OS's older HFS (a la mac os 8 and 9) used a bit for indicating a file was locked. Unix has a flag that was suitable caned UCHG. (user unchangeable) OS X used that flag for the new HFS+ system.

There is another lock flag you don't see much. In the past it's only been on ONE file on the entire computer. The kernel booter. /System/Library/CoreServices/bootx (or Boot.efi for PPC)

That file is protected by a "super lock", SCHG. (system unchangeable) Only root can add or remove it, but there's an added catch. Once the system has elevated from kernel protection level 0 to 1 (early in the boot process) SCHG cannot be removed. 0->1 is a one-way trip, so to return to level 0 requires a reboot. So to remove it, you have to boot into single user mode and remove it via terminal. This prevents a truly nasty virus from infecting the bootstrap process and making a rootkit. The firmware is very well guarded, and the kernel does signature verification on itself and all privileged binaries, but the kernel booter is protected only by some crypto and that flag. That prevents malware from easily replacing it, even if it can find a hole in the security or con the user into giving up the password. See also "(boot) chain of trust". (firmware -> booter -> kernel -> os)

I suspect a variation on this theme is being used for "rootless" mode, where not even root can mess with certain file structures. BTW, I hate that. I understand why they're doing it, but I still hate it. I hate it less knowing I can turn it off. The day I can't turn it off the hate will get much deeper. And knowing Apple, that day will come.

Aaaaanyway, that filename is reminiscent of SCHG, and the prefix "SUID" is another flag that allows an app to run under the privileges of the owner of the file, instead of the person running the file, so again that one needs to be protected well usually. SUID is often used to create back doors for apps that need helpers, so that the app can be run by an unprivileged user but do privileged things. (theres another active thread on this topic I replied to just a little while ago)

Alexandria Librarian's client installed a library reader for the school's library that had a SUID file. Wisely, apple's disk image restore process did not restore that flag, but unfortunately that required an admin password on the first launch to fix it... on every imaged computer in the library. yay.

File is (was!) located in : HD / Library / Extensions.

I deleted and securely erased it. No sign of it since.

SUIDGuardNG.kext is a third party system extension that hardens OS X against a number of exploits. It was written by a security researcher named Stefan Esser and it's available here:

https://github.com/sektioneins/SUIDGuard

It's a bit esoteric even for security geeks, and I can't imagine how it would have ended up on your system without your knowledge.

" . . . I can't imagine how it would have ended up on your system without your knowledge . . . "


----------------------------------------

I have no idea either. Didn't even know it was in the computer except for the fact that I regularly send Library cache folder/files to the trash as part of my general tidying up.

Using Onyx to "securely delete" trash a few days ago, a popup message suddenly appeared saying that Onyx could not erase the file. The "original" was located in the Library / Extensions folder and deleted using the instructions given by another poster to this thread.

Not sure if this is relevant or not : The first time I got the message was within a couple of days of installing SIERRA. (The SUID file did not show up earlier using Onyx with El Capitan.)

First, I backed up MBPro on Time Machine and then downloaded SIERRA - making a bootable drive in the process followed by a "two pass" erase of the HD. Installed SIERRA as well as ONYX's lastest version for OS X 10.12 (SIERRA). Used Migration Assistant to retrieve my files from Time Machine.

oh, correction. boot.efi is NOT SCHG. (and good holy grief, autocorrect is just fighting me tooth and nail in this thread!!) it is UCHG, just a regular finder lock. but good enough for most dumb malware.