Re: API to determine status of System Integrity Protection?
Re: API to determine status of System Integrity Protection?
- Subject: Re: API to determine status of System Integrity Protection?
- From: Charles Srstka <email@hidden>
- Date: Mon, 14 Sep 2015 12:58:40 -0500
> On Sep 13, 2015, at 6:33 PM, Ed Wynne <email@hidden> wrote:
>
>
> On Sep 13, 2015, at 5:47 PM, Stephane Sudre <email@hidden <mailto:email@hidden>> wrote:
>>>>> That document doesn't mention an API…
>>>> Hence, since that is the current documentation, my conclusion : “Don’t think so”.
>>> There is an API. Much like with sandboxing it just may not be public, which means it is inappropriate for discussion here. I’m not sure why Apple considers this kind of thing off limits, but that is inappropriate for discussion here as well.
>>
>> I must be missing something but why should there be an API?
>
> There are many reasons. For example, writing to the areas SIP protects typically requires authorization. Not offering the user an impossible action is a much better UX than letting them go through the trouble of authenticating only to have it fail anyway.
>
>> - determining whether SIP is on requires to check whether the running
>> OS on 10.11 or later.
>
> This check is not sufficient since SIP can be disabled.
>
>> Also it could done by parsing the output of $
>> csrutil status but this would assume the output format will not change
>> in the future.
>
> Exactly, which makes this a bad option.
>
>> - determining whether you can write to a file or folder can be done
>> with the usual BSD, Cocoa APIs, can't it?
>
> Yes and no. Not having the beta (er, GM seed) handy to check, I honestly don’t know if the R/W file system permissions are reported differently when SIP is present and enabled. Based on how sandboxing operates, I would assume they are not.
>
> But that isn’t to say some things won’t be detectably different, which was the point of my suggestion about secondary checks. They might be possible, but they are still a bad option since they usually fall into the category of undocumented side effects.
>
>> - knowing which parts of the file hierarchy are protected is covered
>> by the documentation (Interestingly I've just discovered that
>> /Applications/Utilities is a no trespassing area).
>
>
> Except they aren’t protected when SIP is disabled, which was the point of the OP’s question.
>
> -Ed
The open() API returns EPERM when you try to access something protected by SIP, but EACCES for normal permission errors. So, you could just try to write to create a file at /System/foo without root access using open(), and use the value returned by errno to determine whether SIP is enabled or not.
Whether that is more or less ugly than parsing the output of csrutil, of course, is up to the reader. They’re both pretty non-ideal.
Charles
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden