. Re: API to determine status of System Integrity Protection?

[Stephane Madrau]

2015-09-14 21:00 GMT+02:00 :

>
> 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.
>

What's wrong with using csr_check() and csr_get_active_config(). That's
nothing else than what csrutil uses... Are these functions considered as
SPI ? They are in the kernel sources...
And using SPI shouldn be worse than parsing a shell tool output...

If these are ok, then this code should do it
https://github.com/Piker-Alpha/csrstat/blob/master/csrstat.c

-- 
Stéphane
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: . Re: API to determine status of System Integrity Protection?

[Charles Srstka]

> On Sep 15, 2015, at 1:37 AM, Stephane Madrau  wrote:
> 
> What's wrong with using csr_check() and csr_get_active_config(). That's
> nothing else than what csrutil uses... Are these functions considered as
> SPI ? They are in the kernel sources...
> And using SPI shouldn be worse than parsing a shell tool output...
> 
> If these are ok, then this code should do it
> https://github.com/Piker-Alpha/csrstat/blob/master/csrstat.c 
> 
> 
> -- 
> Stéphane

Using private APIs is probably the worst possible way to go about doing this 
(and those are private APIs; if they’re not in the system headers, they’re not 
guaranteed not to change in the future, even if they’re currently in the 
source).

Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: API to determine status of System Integrity Protection?

[Jean-Daniel Dupas]

> Le 14 sept. 2015 à 01:33, Ed Wynne  a écrit :
> 
> 
> On Sep 13, 2015, at 5:47 PM, Stephane Sudre  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.

No trying to write in a protected area in the first place is even better. You 
don’t need to check, just don’t do it.

> 
>> - 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
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: API to determine status of System Integrity Protection?

[Ed Wynne]

On Sep 14, 2015, at 7:05 AM, Jean-Daniel Dupas  wrote:

>> Le 14 sept. 2015 à 01:33, Ed Wynne  a écrit :
>> On Sep 13, 2015, at 5:47 PM, Stephane Sudre  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.
> 
> No trying to write in a protected area in the first place is even better. You 
> don’t need to check, just don’t do it.

For the most part, this is true… and even more true as time goes by and Apple 
gives us better alternatives.

The problem is that OS X is a complex mature ecosystem that already has 
advanced and potentially non-app/user oriented software that needs to do stuff 
like this. The non-negotiable mandate of “don’t do that” isn’t always as simple 
to deal with as you might expect.

-Ed

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: API to determine status of System Integrity Protection?

[Charles Srstka]

> On Sep 13, 2015, at 6:33 PM, Ed Wynne  wrote:
> 
> 
> On Sep 13, 2015, at 5:47 PM, Stephane Sudre  > 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 (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: API to determine status of System Integrity Protection?

[Stephane Sudre]

On Sat, Sep 12, 2015 at 9:53 PM, Ed Wynne  wrote:
>
> On Sep 12, 2015, at 1:45 PM, sqwarqDev  wrote:
>
>>
>>> On 13 Sep 2015, at 00:43, SevenBits  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?

- determining whether SIP is on requires to check whether the running
OS on 10.11 or later. Also it could done by parsing the output of $
csrutil status but this would assume the output format will not change
in the future.
- determining whether you can write to a file or folder can be done
with the usual BSD, Cocoa APIs, can't it?
- 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).

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: API to determine status of System Integrity Protection?

[Ed Wynne]

On Sep 13, 2015, at 5:47 PM, Stephane Sudre  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

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: API to determine status of System Integrity Protection?

[sqwarqDev]

> On 13 Sep 2015, at 00:43, SevenBits  wrote:
> 
> That document doesn't mention an API…
> 

Hence, since that is the current documentation, my conclusion : “Don’t think 
so”.





___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: API to determine status of System Integrity Protection?

[Ed Wynne]

On Sep 12, 2015, at 1:45 PM, sqwarqDev  wrote:

> 
>> On 13 Sep 2015, at 00:43, SevenBits  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.

However, there are secondary ways to detect SIP. For instance, using the “ls 
-lO” command will show the restrict flag on certain files. I believe that flag 
is present when SIP is on, and isn’t when it isn’t. I’m not positive on that 
specific thing, but the idea holds. Certain things will be different that you 
can test.

Yes, performing secondary checks sucks… but until Apple gives us an API. 
Whatcha gonna do?

-Ed


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: API to determine status of System Integrity Protection?

[sqwarqDev]

> On 9 Sep 2015, at 02:06, James Bucanek  wrote:
> 
> I'll assume by the raging silence that there is no such API.

Don’t think so. The current documentation is here:

https://developer.apple.com/library/prerelease/ios/documentation/Security/Conceptual/System_Integrity_Protection_Guide/System_Integrity_Protection_Guide.pdf



Best

Phil



Get DetectX - The free troubleshooting tool for your mac. More info on 
http://sqwarq.com/detectx
http://applehelpwriter.com
http://sqwarq.com - apps for OS X & iOS




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: API to determine status of System Integrity Protection?

[SevenBits]

That document doesn't mention an API...

On Saturday, September 12, 2015, sqwarqDev  wrote:

> > On 9 Sep 2015, at 02:06, James Bucanek  > wrote:
> >
> > I'll assume by the raging silence that there is no such API.
>
> Don’t think so. The current documentation is here:
>
>
> https://developer.apple.com/library/prerelease/ios/documentation/Security/Conceptual/System_Integrity_Protection_Guide/System_Integrity_Protection_Guide.pdf
>
>
>
> Best
>
> Phil
>
>
>
> Get DetectX - The free troubleshooting tool for your mac. More info on
> http://sqwarq.com/detectx
> http://applehelpwriter.com
> http://sqwarq.com - apps for OS X & iOS
>
>
>
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com )
>
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/sevenbitstech%40gmail.com
>
> This email sent to sevenbitst...@gmail.com 
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com