On Fri, Sep 24, 2010 at 09:44:21AM +0100, Chris Ridd wrote: > Hi, > > We've got some long-lived server processes (ldap, smtp, imap, xmpp) that > support clients authenticating using SASL and GSS-API. AIUI, the servers call > (through a maze of twisty libraries and plugins and callbacks) > gss_acquire_cred() on demand when they start to talk to a client, and that > call tends to involve opening /etc/krb5/krb5.keytab to retrieve some secret > info for the process/host. > > That works OK as long as the server stays running as root, because the keytab > file is only readable by root:root. > > But we don't *want* to stay running as root. Normally what we try to do is > drop to a less privileged uid after listening on privileged ports etc, but > that will simply cause the next call to gss_acquire_cred() to fail with > permissions problems. > > What's the best practice here? Are there any well-defined process privileges > that we can use which only allow access to the keytab, or do we have to just > rely on filesystem permissions/ACLs? Or something else I haven't thought of? > :-)
Beyond what others have responded with I suggest you read: http://developers.sun.com/solaris/articles/program_privileges.html Using Solaris privileges and roles/RBAC properly you can grant a server app the privilege to open a restricted network port without having to run as root (see PRIV_NET_PRIVADDR in the privileges.5 man page). -- Will Fiveash Oracle http://opensolaris.org/os/project/kerberos/ Sent using mutt, a sweet text based e-mail app: http://www.mutt.org/ _______________________________________________ security-discuss mailing list [email protected]
