ravynsoft
Security Features like macOS?
I'm interested in whether ravynOS plans to implement security features similar to macOS.
Like: macOS Security Features:
- System Integrity Protection (SIP)
- Gatekeeper
- XProtect
- FileVault
- App Sandboxing
- Code Signing
Note: I'm not deeply familiar with all these security aspects, but Terry Lambert (former Apple and FreeBSD developer) discussed these security differences between Darwin and FreeBSD in his Quora response:
He provided detailed insights about FreeBSD's security issues, particularly regarding VNOP operations, signal handling, mount systems, and credential handling. He also mentioned that Darwin's security model (especially for user/kernel boundary crossing credential enforcement) is superior in several aspects, though these improvements could potentially be ported to ravynOS.
- Kernel Level:
- VNOP operations:
- Race condition fixes for create/rename (non-atomic operations)
- Directory entry slot identification and usage improvements
- Thread reentrant support for UFS/FFS
- Temporary reservation state storage fixes
- Signal stack handling:
- Prevention of ring 3 to ring 0 transitions
- Arbitrary code execution prevention
- Saved stack handling improvements
- Memory protection:
- W+X protection completeness
- TLB entry NX bit handling
- Page boundary protection
- Cache line handling
- File System:
- Mount system:
- VFSOP separation for mount operations
- Generic mount code improvements
- Consistent checking implementation
- NFS security:
- Mount code vulnerability fixes
- Prevention of arbitrary kernel memory writes
- Credential tampering protection
- Complete ACL implementation:
- Credential handling integration
- Group processing improvements
- Exclusion group handling
- Security Boundaries:
- User/kernel boundary:
- Enhanced protection mechanisms
- Cross-boundary authentication enforcement
- Process isolation improvements
- Credential system:
- POSIX Saved ID handling fixes
- Supplementary group processing
- Privilege escalation prevention
- System Management:
- sysctl improvements:
- Kernel memory access control
- Binary compatibility constraints
- Accessor/mutator pattern implementation
- Process management:
- procfs/linprocfs security balancing
- Information exposure control
- Unnecessary feature removal
- Runtime Protection:
- Stack protection:
- SEGVGUARD limitations resolution
- Memory overcommit handling
- Physical RAM requirements optimization
- Code execution:
- PIE/ASLR implementation improvements
- Secondary mapping prevention
- JIT/JVM compatibility improvements
- Static PIR handling
It's pretty likely we will develop some of those, at least enough to support apps that use them. Not really on my radar yet - it's too far out.
Capsicum was designed to support a better version of the macOS sandboxing model and it would be great to integrate this with AppKit. I did a prototype on GNUstep ages ago but have no idea where I put the code. The core things:
- Added an NSString subclass that owned a (reference to a refcounted) file descriptor.
- Make the path manipulation methods act as relative to this base.
- Extended the various methods that open files based on strings to handle these special strings differently.
- Make the standard open and save dialogs talk to another process that runs outside of Capsicum mode and hands file descriptors back. This needed some fun for bundles and saving (it needed to create the directory and then hand a descriptor for the new directory back). Supporting the atomic updates was also fun, I think you needed to create two files and unlink one then renameat could work.
- Extend the app launcher to set up the right RTLD capsicum paths and pass in file descriptors for the common locations (temp, read-only descriptors for some other directories).
- Extend NSFileManager to return these file descriptors for common operations.
- Extend the scorer APIs to request a socket from casperd.
With this, you run apps with least privilege automatically.
custodial comments
Just parsing some of the details (to help myself and other get around this topic)
In context to "Darwin's superior security model is open source and could be copied to BSD"
The current (Sequoia) xnu sources are extremely difficult to navigate,compared to, for example, the Leopard sources.
You are looking for this file:
xnu/bsd/kern/kern_credential.c at xnu-11215.41.3 · apple-oss-distributions/xnu
In the function kauth_cred_proc_update() starting at line 3925.
The cr_groups shuffle is much easier to understand in the Leopard sources, as I said.
There is a lot of gratuitous use of c99 explicit structure element initializers in the code these days, which was not there in Leopard (or Lion, or even shortly thereafter, for that matter).
I think it makes the code less clear, and it certainly makes the code less portable to CPU targets where the C compiler doesn’t actually support it.
code mentioned:
https://github.com/apple-oss-distributions/xnu/blob/33de042d024d46de5ff4e89f2471de6608e37fa4/bsd/kern/kern_credential.c#L3924-L3980
Regarding sandboxing:
-
- The entitlements is handled through gatekeeper as part of code-signing/checking
- The container stores for sandboxing could be approximated with the
Library/Containersinfrastructure but are not discussed in the context of sandboxing by apple (as far as I know, but I may have missed somthing :shrug:)
-
my own (and very old) sandbox jail creation blog for darwin
- demonstrates the manual proccess that would need to be automatic to create true sandboxes
- docker provides containers that are similar security solutions to BSD-style sandboxes
- sandboxing bundles and apps would involve links (in some transparent way) to the frameworks needed, and probably the whole objc runtime, which may make proper OBJC message passing more complex to support.
-
(oversimplifying a bit) this topic should be discussed more in the context of policy too, sandboxing apps is used by apple to keep (usually third-party) apps from system level (root) access in their "rootless" design by default, and gatekeeper is supposed to be used to promote code-signed apps (e.g. to let apps out of the sandbox).
ROOTLESS kernel (Apple's System Integrity Protection)
-
why hardware is required to use SSV + SIP + iBoot securely
- (IMHO) While this is a MAJOR security point for XNU/darwin it is likely one of the unspoken hardware limitations. To enforce this mode it must be part of the boot-loader, and Apple typically requires access to the Hardware Secure Enclave to check the kernel is signed at boot and presumably they only sign code that checks if it can boot in typical BSD/Unix mode with a true root privileged mode or if it boots in the SIP enabled (rootless) mode. The issue with not having a hardware secure enclave is that it leaves the whole mechanism reliant on the writable (and often un-encrypted) root-of-trust data (which in this case, isn't even from a well known company like apple, but from the project); This makes the support of SIP less valuable to ravynOS ... :thinking: but since this project is already crazy enough, we could still try, and leverage T2 and M1 M2 hardware when present :shrug: (just can't claim the same assurance as apple hardware does by default)
-
TL;DR; - more than you ever wanted to know about booting securely like your mac does every day:
-
TL;DR; - And why all the trouble: security (and its arm-race)
-
EFI is insecure - think evil maid scenario
XProtect
Xprotect is basically Apple's tool to virus scanning for Known viruses in the wild.
- XProtect is very simple but the general idea of a built-in virus scanner is not a bad idea
FileVault
- FileVault2 means APFS drivers for APFS encryption at the disk level
- Filevault 1 like solution (the old slow version) should be possible (given enough interest) with clever partitioning and decryption at mount-time and encryption at write-time in the short-term, could use a strong hash of a user secret (e.g. password) with some hardware UUID seed to provide a boot-time behavior similar to FileVault :shrug:
- more than you wanted to know about Filevault
- history of FailVault
- PEFS is a similar solution already available for FreeBSD
- PEFS GitHub
Another point to discuss is the FileProvider API in things like Objective-C IO and extended attributes and ACL support (APFS is still young by FS standards) E.g., if doing FileVault, or APFS it makes sense to attempt both.
Hopefully this helps with organizing this topic and related discussions a little for moving forward on the ideas
