Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Greg A. Woods; Planix, Inc. (woodsplanix.ca)
Date: Wed Aug 20 2008 - 11:44:32 CDT
On 19-Aug-08, at 9:07 PM, David Holland wrote:
> Nonsense. The application process needs to be able to communicate with
> the bsdauth process anyway; there's nothing inherent that prevents
> such communication from including Kerberos tickets.
Indeed -- however the action of setting the credentials for the
process (i.e. in the process context) is, by necessity, a privileged
operation. The naive "one big ball of wax or whatever" solution is to
start the process as root, authenticate the user, set the credentials
in the process context, then call setuid() to give up superuser
privileges and authorize the authenticated user to run.
> Whether bsdauth as it currently exists is actually capable of doing
> this properly is another question; but it's also not entirely clear
> that PAM as it exists can do this properly either.
Not quite -- as I outlined in 2003 I think another system call, or
pair of system calls, is the most elegant solution. These would allow
a privileged child process to set the credentials of the parent
process. I haven't done a formal analysis of this model, though I
have done a lot of critical thinking about it, and so far as I can see
it can be made secure and robust.
Greg A. Woods; Planix, Inc.