Re: Regd. "restricted" flag value in Kext
Re: Regd. "restricted" flag value in Kext
- Subject: Re: Regd. "restricted" flag value in Kext
- From: Richard Hamilton <email@hidden>
- Date: Mon, 07 Sep 2015 12:18:49 -0400
Looking through the XNU (kernel) code for 10.10.3 (latest on
opensource.apple.com), it appears that the only thing that happens with the SF_RESTRICTED flag in Yosemite, is that if it is set on a directory, files created in that directory or renamed into that directory (or within that directory) will also have it set (automatically). Renaming a file from a directory with SF_RESTRICTED to one without SF_RESTRICTED does _not_ clear the flag. Hard-linking a file that does not have the flag set into a directory with it set does _not_ set the flag. If the flag is set automatically, it may still be cleared by root. If a file is in such a directory without the flag set (such as if hard-linked into there, or the flag cleared manually), hard-linking it to another name within that directory will _not_ set the flag.
That was determined partly by looking at the code, and partly by trying some scenarios to show that the effect was as limited as it appeared it would be.
I would suppose that in El Capitan, either the behavior is somewhat different, or additional limitations are enforced. Maybe what's in Yosemite is for backward compatibility (e.g. if files are moved +/- one version, that the flag will be preserved and minimal honoring of when it's set automatically will still apply). But that last is just a guess.
One other possibility: Macs have some not entirely kernel based security mechanisms; sandboxes, and entitlements are those I've heard of. They might also be involved, in the full implementation in El Capitan; so once El Capitan source is available, one might have to look further than the XNU source tarfile alone, to determine all of what's happening. Features may also be used in code that is not publicly released...so don't assume you can get the full picture by digging through all the released code.
In Yosemite, the chflags command and system call, stat(2) and variants, strtofflags(3) and its inverse (and therefore programs that call strtofflags(3), like ls(1) and chflags(1)) may be aware of the ST_RESTRICTED flag. copyfile(3) also seems to make some effort to preserve it if already set on the destination file, but I haven't looked at that enough to tell how or why that is done.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden