[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Getting tickets for boot scripts

On Tue, Dec 14, 2004 at 10:13:40PM -0700, Sean Brown wrote:
> OK I'm looking at this again, and let me see if I have it straight
> I have a pgsql service key postgres/host.example.com@EXAMPLE.COM
> a user pgsnorter@EXAMPLE.COM
> I export into the keytab, among other things like ssh principles, the postgres 
> principle. That keytab goes to every server since its used for all of those 
> services. Then I create another one with kutil that has pgsnorter@EXAMPLE.COM 
> and I distribute that to my snort sensors. Then I start snort with 
> kinit --cache /path/to/somewhere --keytab=[path to keytab with pgsnorter in 
> it] pgsnorter@EXAMPLE.COM /etc/rc.d/snort.sh
> Or did I read something wrong. Should I just have the one keytab that has 
> everything and distribute that everywhere, or create some that don't have the 
> pgsnorter principal in it and then create another that has pgsnorter and 
> distribute that to just the snort sensors? I don't want to have systems that 
> don't need access to the database to have it.

Each service preferably runs under it's own UID. Each service then gets
it's own keytab with permissions such that /only they can read it/.

So, assuming that postgres is similar to other services I've worked
with, on your DB box you'd configure postgres to point to a keytab
containing only postgres/host.example.com@EXAMPLE.COM and lock that file
down with permissions so that only the UID postgres runs as can read
it.  Sure, maybe you offer kshd ton that host oo ... but that uses
/etc/krb5.keytab and the host/host.example.com@EXAMPLE.COM principal.

If you have a script that needs remote access to the database, ideally
you'd create a special user for it and then create a keytab containing
only pgsnorter@EXAMPLE.COM that only your special user can read. You
could then use kinit as you described to obtain tickets and work with
the database service. Your script should probably kdestroy those tickets
after use.

Naturally, this doesn't protect you against root. Nothing does, so it's
generally not a problem.

It also means you need to consider your backup and network file access
strategies a little mroe careful. Recovering a keytab from a backup or
from a careless NFS export is the same thing as discovering a password.

Individual users, aside from virtual users like "pgsnorter" uses for
scripts, are almost never in any keytab. Instead of a keytab, they rely
on the users password.


"Like someone who falls into a river, people will clutch at anything to
 stay afloat. The truth is, you can swim."
    -- Robert Allen