Enabling SIP on 3rd-party apps

Hi,


We're working on an app that manages a lot of critically sensitive data (namely, a password manager), and we're trying to get the most security we can out of macOS. One obvious vulnerability is that a malicious user can always use lldb or a similar tool to dump the memory at a time when a password is there.


SIP offers protection against these types of attacks. I wanted to know if we could protect our app by using the SIP mechanism.


Is any of the following solutions possible:


  • Add an entitlement to the app to make it rootless
  • Configure SIP settings in the user's home directory to add the app to the rootless apps list
  • Request that the app be added to the list in a future macOS release
Up vote post of chrales Down vote post of chrales
1.2k views
Posted by
chrales
Reply
Add a Comment

Accepted Reply

The current SIP protections are based on how the code is signed, which isn’t something you can change. It seems reasonable to file an enhancement request for a way to opt into that protection. Please post your bug number, just for the record.

Keep in mind that the user can, at their option, disable SIP on the system as a whole, which limits the utility of this for your purposes. I guess you could set your app up not to work if SIP is disabled, although:

  • there’s no public API for detecting that (another enhancement request opportunity!)

  • you’re likely to really annoy some customers, who run with SIP disabled for other reasons

In the meantime, one thing you can do right now is call 

PT_DENY_ATTACH
on yourself; see the 
ptrace
man page for details. This won’t stop a determined attacker (ask me how I know!) but there are very few downsides.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware 

let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Post marked as solved
Add a Comment

Replies

The current SIP protections are based on how the code is signed, which isn’t something you can change. It seems reasonable to file an enhancement request for a way to opt into that protection. Please post your bug number, just for the record.

Keep in mind that the user can, at their option, disable SIP on the system as a whole, which limits the utility of this for your purposes. I guess you could set your app up not to work if SIP is disabled, although:

  • there’s no public API for detecting that (another enhancement request opportunity!)

  • you’re likely to really annoy some customers, who run with SIP disabled for other reasons

In the meantime, one thing you can do right now is call 

PT_DENY_ATTACH
on yourself; see the 
ptrace
man page for details. This won’t stop a determined attacker (ask me how I know!) but there are very few downsides.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware 

let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Post marked as solved
Add a Comment

Thanks Quinn. This pretty much covers the subject.


The current SIP protections are based on how the code is signed, which isn’t something you can change.


Is this anything like the Kernel Extension codesigning keys? Should we just request a "new" type of key?


This won’t stop a determined attacker (ask me how I know!)


How do you know? And what are the risks, and the steps an attacker could take to bypass this?

Posted by
chrales
Up vote reply of chrales Down vote reply of chrales
Add a Comment

Is this anything like the Kernel Extension codesigning keys?

No. Last I checked, SIP only kicks in for Apple code that comes built in to the OS.

How do you know?

Well, I was being facetious but, sure I can answer that: a while back I built my own tool to nobble 

PT_DENY_ATTACH
so that I could debug various plug-ins that get loaded in system components that set 
PT_DENY_ATTACH
. And no, I won’t share (-:

And what are the risks, and the steps an attacker could take to bypass this?

What’s your threat model? Are you trying to protect yourself from the user themselves (like a DRM scheme)? Or trying to protect yourself from code that the user has unwittingly run?

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware 

let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment

I dropped a couple of enhancement requests as per your suggestion:


rdar://28650702

rdar://28650719

Posted by
chrales
Up vote reply of chrales Down vote reply of chrales
Add a Comment

"I guess you could set your app up not to work if SIP is disabled"


Not quite. You cannot trust the system to tell you the trust if SIP has been disabled, because the protection is not active anymore and the API could be made to return true when the real answer is false.

Posted by
Security Engineer
Up vote reply of Security Engineer Down vote reply of Security Engineer
Add a Comment