site_archiver@lists.apple.com Delivered-To: Darwin-dev@lists.apple.com The primary paper on UNIX setuid() is: Setuid Demystified Hao Chen, David Wagner, Drew Dean Proceedings of the 11th USENIX Security Symposium <www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf> - -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Sep 26, 2008, at 2:37 AM, Mario Emmenlauer wrote: Damien Sorresso wrote: The rules of setuid(2) have evolved into a vastly complex morass with subtle variations on different platforms. Entire papers have been written about this behavior. You name it. I will look for a good tutorial, though Terry's suggestion contained a nice start. The kernel interfaces are not really vastly complext; most of the complexity is in user space session setup and teardown, which you mostly do not have to care about if you write "UNIXy code". The main difference between Mac OS X and POSIX standard behaviour is that we support external group resolution for group membership above and beyond the default list of the effective group plus 15 supplementary groups (the 0th supplementary group is a synonym for the effective group, for a total of 16 in the array for getgroups()/ setgroups(); this is an historical BSD thing, permitted, per POSIX). You can initialize this using initgroups(), or you can use syscall(SYS_initgroups,...), which takes the same arguments as setgroups(), plus a uid argument as the key for looking up group membership for the groups served through DirectoryServices. A secondary difference is in per-thread credentials, which inverts the group list and uid set ordering. In per thread credentials, you initialize the group list last; this is permissible since you cannot set them except from a privileged process, and they are being used for proxy operations, usually by a file services dameon, and are not security sensitive. Since the initial privileged process that started the thread within itself (1) has a still-accessible heap and stack after the change and (2) has the rights to set grouplist - and resolver uid membership - anyway, on a process-wide basis, permitting setting this in a thread running under an assumed credential does not decrease security. In general, we do not want you to establish your own sessions, and would prefer that you use /bin/login to do session management and support the utmp/utmpx interfaces for process accounting and knowing who is logged into your system, etc.; otherwise, things get more complicated fast, in order to support those interfaces, since you have to (1) maintain privilege in order to access the files to write out the closure records on sessions started by you (login does this - it hangs around until its children go away), and (2) deal with PAM and all the other things login deals with for authenticating you to the system. This email sent to site_archiver@lists.apple.com