On 09/24/10 01:44 AM, 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? :-)
Certainly. You could drop all privileges except file_dac_read and then
switch to a different uid.
Or, since the file you want to read is owned by root (and presumably
readable by owner), you could set your Permitted privilege set to
"basic" and continue running as uid 0, but without special privileges.
Scott
--
Scott Rotondo
Senior Principal Engineer, Solaris Core OS Engineering
President, Trusted Computing Group
Phone: +1 408 276 6987 (Internal x66987)
_______________________________________________
security-discuss mailing list
[email protected]
