
I think this is crucial to understand going forward.

These examples show that authorization is a self-restrictive model, which means that our standard POSIX processes won’t have more privileges when obtaining a right but they can limit themselves to perform specific actions and tie it to an authorization right. Prior to executing Task A, it will try to obtain the authorization Right X, and if successful it will do the task. This example can also be done in another way. If it can’t obtain the right Process B will deny the request. How can it still perform Task A? It can ask Process B, which runs as root, to perform Task A with showing the authorization Right X, which will be verified by Process B.

It still runs as the standard user, which has no write access to that location. Now, after obtaining Right X, will our process be able to perform Task A? The answer is: ~NO~. Let’s also assume that in order to perform Task A a process has to run as root, because it needs to write to a location where only root has access. Let’s say Process A runs as a regular user and asks for the Right X, which is required to perform Task A.

Let’s discuss first why it’s not true, as I think this is the more confusing part. Based on this it might sound that an authorization could give extra rights to our process, which is both true and false at the same time. There is an authorization database on the system, with various rights, that can be asked for, and if the requirement are satisfied, authorization will be granted and the asked right will be given. I think the concepts are best described at Apple’s Authorization Concepts documentation. There is also a kernel authorization framework, kauth, but this post is not about that. When I talk about authorization here, I mean the user mode authorization on macOS, which is handled by the authdprocess. Also some of the items are very confusing and it took me some time to clear things in my head as not everything is obvious or intuitive. All of these information I try catch here in one post, are known, but spread all over the place in various blog posts and articles, and I never found a good, central location with all the details. Honestly, partially for selfish reasons so I will have a goto summary when I need to lookup something later instead of browsing through 8-10 different articles. The goal of the post is to cover many aspects of authorization, which I found interesting from security perspective.

I finally kicked my ass, sat down, and wrote it. This is a blog post I wanted to write for a while now, but somehow never got the time for it, and I also knew that it will require lots of time, so I kept delaying it.
