ticket steal possibility

Edgecombe, Jason jwedgeco at uncc.edu
Tue Mar 27 08:15:15 EDT 2007


I assume that all priviledged users have non-priviledged accounts as
well. Is that correct?
 

Jason Edgecombe
Solaris & Linux Administrator
Mosaic Computing Group, College of Engineering
UNC-Charlotte
Phone: (704) 687-3514
 

-----Original Message-----
From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On
Behalf Of Jeffrey Hutzelman
Sent: Monday, March 26, 2007 5:59 PM
To: Nikolai Tenev; kerberos at mit.edu
Cc: Jeffrey Hutzelman
Subject: Re: ticket steal possibility



On Wednesday, March 21, 2007 01:25:26 PM +0200 Nikolai Tenev 
<ntenev at orbitel.bg> wrote:

> On server one (server1) in krb5.conf I have a record:
>
>  auth_to_local = {
>    RULE:[2:$2](support)s/^.*$/root/
>  }
>
> On server two (server2) in krb5.conf I have a record:
>
>  auth_to_local = {
>    RULE:[2:$2](support)s/^.*$/root/
>    RULE:[2:$2](developer)s/^.*$/root/
>  }

Doing authorization this way is dangerous, because it effectively grants

privileges based on the mere existance of a principal, and assumes that
no 
principal will ever be created that should not have these privileges.  A

better approach is to distribute lists of authorized developers and
support 
staff which can be used in constructing a .k5login file for root.


> When client1 is logged in from his workstation1 as root on server2,
the
> ticket  of client1 is forwarded

If you don't trust the machine you're connecting to, including all the 
people who have privileged access to it, then don't do that.  Whenever
you 
type a password on a machine, or forward credentials, agent connections,
or 
X11 connections, you are granting that machine, and whoever controls it,

the power to act as you.  Giving your credentials to an untrusted
machine 
is inherently unsafe; there are no tricks to get around that fact.

Most ssh clients can be configured to forward credentials, agent 
connections, and X11 connections only to specific hosts.  Your support 
staff should forward these only to trusted machines; that is, only to 
machines where only trusted staff have privileged access.  They should
also 
only ever type passwords at such machines, and never at an untrusted 
machine where some other person has root access.

In our facility we go a step further; privileged users are not allowed
to 
type passwords on or forward credentials to any machine where an
untrusted 
person has any access, privileged or not.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

________________________________________________
Kerberos mailing list           Kerberos at mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos




More information about the Kerberos mailing list