[29556] in Kerberos
Re: delegating principal creation to a web process
daemon@ATHENA.MIT.EDU (Simon Wilkinson)
Fri Mar 21 05:20:26 2008
In-Reply-To: <47E31132.5020701@rampaginggeek.com>
Mime-Version: 1.0 (Apple Message framework v753)
Message-Id: <0C4B7618-C348-4FB0-A8E3-9DA11677C15F@sxw.org.uk>
From: Simon Wilkinson <simon@sxw.org.uk>
Date: Fri, 21 Mar 2008 09:19:08 +0000
To: Jason Edgecombe <jason@rampaginggeek.com>
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On 21 Mar 2008, at 01:36, Jason Edgecombe wrote:
>>
> The script will check that the user is in the /etc/password file. The
> keytab will only have privileges to add accounts, so existing accounts
> like admin/root are safe.
Bear in mind that if you wildcards anywhere in your ACLs, you don't
just care about existing accounts, but also about creating new
accounts that may match existing wildcards.
> How would remctl give me more security in this arrangement?
It lets you protect the access to your kadmind better, by allowing
you to do all of the sanity checking at the point of privilege
escalation.
In your current model, anyone who has access to the keytab on your
web server machine (which probably means anyone who can execute
scripts on your web server), can bypass the sanity checking that your
script performs. If you use remctl, then the web server machine
purely has a keytab that lets it talk to remctl, which then performs
sanity checking before passing the request on to the kadmind. In that
way, you can guarantee that any request _must_ have been sanity
checked in order to reach kadmind.
Simon.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
