[27593] in Kerberos
RE: ticket steal possibility
daemon@ATHENA.MIT.EDU (Edgecombe, Jason)
Tue Mar 27 08:16:05 2007
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 27 Mar 2007 08:15:15 -0400
Message-ID: <A01ABA2A211C644596549C5FF91C50E41346F58E@EXEVS02.its.uncc.edu>
In-Reply-To: <DB7122C65220B136BC5B645A@sirius.fac.cs.cmu.edu>
From: "Edgecombe, Jason" <jwedgeco@uncc.edu>
To: "Jeffrey Hutzelman" <jhutz@cmu.edu>, "Nikolai Tenev" <ntenev@orbitel.bg>,
<kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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@mit.edu [mailto:kerberos-bounces@mit.edu] On
Behalf Of Jeffrey Hutzelman
Sent: Monday, March 26, 2007 5:59 PM
To: Nikolai Tenev; kerberos@mit.edu
Cc: Jeffrey Hutzelman
Subject: Re: ticket steal possibility
On Wednesday, March 21, 2007 01:25:26 PM +0200 Nikolai Tenev
<ntenev@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+@cmu.edu>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
