Sanboxed Apps Reading Extended Security Information (ACL)

Question

Created 1d

Replies 1

Boosts 0

Participants 2

My custom filesystem kernel extension stores ACLs as an extended attribute, com.apple.system.Security.

Sanboxed apps such as TextEdit, Pages, etc., running as a non-privileged process, fail to save modified contents when permissive ACLs are in use.

Running them as a privileged process, does allow for file changes to be saved though.

Non-sandboxed apps, such as VSCode, and command line programs are not susceptible to this behaviour.

APFS, on the other hand, seems to handle ACLs as an ATTR_CMN_EXTENDED_SECURITY filesystem attribute, rather than as an EA. In this case, sandboxed apps have no trouble accessing the ACL data.

I implemented a minimal PoC within my custom kext to verify this. I construct an ACL in memory allowing a given user to write,append,delete file contents, and return it that via vnop_getattr. This allows the file contents to be modified and saved by sandboxed apps.

Can you please confirm if my findings are accurate and sandboxed apps fail to read the com.apple.system.Security EA by design?

Also, Is it an accurate assumption, that ACLs should be handled either as an EA, or an ATTR_CMN_EXTENDED_SECURITY, but not both?

Thanks.

Answer 1

DTS Engineer OP

Apple

7h

Can you please confirm if my findings are accurate and sandboxed apps fail to read the com.apple.system.Security EA by design?

No, I don't think that's correct. You can see the code here but I believe that xattr was set up as the "fallback" storage mechanism which the VFS system uses if the can't retrieve the data through ATTR_CMN_EXTENDED_SECURITY. As far as directly reading the xattr, the vfs layer is what blocks that, not the sandbox, through this check.

However, my bigger question here is what you mean by "read". ACL enforcement and validation happens in the kernel, not user space, so a process doesn't really "read" its ACL, whether or not it's stored in an xattr. I don't know what's going on here, but the general theory you're describing doesn't really make sense to me. Have you tried starting with a minimal test app that's sandboxed and directly access the file? I'd start with our basic app template with the sandbox enabled, then use the File Access Entitlement to hard code its access to a specific file.

Related to that point:

I construct an ACL in memory allowing a given user to write,append,delete file contents, and return it that via vnop_getattr.

Be aware that the way most document based apps interact with their documents isn't through the standard "open-> read-> write-> close" Unix "cycle". Most document based apps use some form of safe save semantics where they copy the original, modify the copy, then exchange (ideally, atomically), the original with their modified copy.

Also, Is it an accurate assumption, that ACLs should be handled either as an EA, or an ATTR_CMN_EXTENDED_SECURITY, but not both?

Well, strictly speaking, it looks you could actually "mix" them but the bigger issue is basically "why bother". If the file system is going to handle them within it's metadata, then setting com.apple.system.Security is just extra work without any value.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware