delegating principal creation to a web process

[Jason Edgecombe]

Simon Wilkinson wrote:
>
> 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.
>
Is this shifting the script that does the actual work from the webserver
to the KDC (or some other better trusted host)?

How would remctl verify that the request came from the trusted php page?
Perhaps the user-supplied hashed username from the HTTP request must be
passed to remctl? hmmm. Should I use the host keytab or a
service-specific keytab so that I don't have to use a suid root program.

My rules for creating the new principal are as follows:
1. The principal must not exist
2. The username must be in the /etc/passwd file (users have an entry in
/etc/passwd before their principal is created.

Thanks,
Jason