[2302] in athena10
Re: [Debathena] #205: ssh changes behavior from Athena 9,
daemon@ATHENA.MIT.EDU (Debathena Trac)
Wed Apr 15 21:01:36 2009
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
From: "Debathena Trac" <debathena@MIT.EDU>
Cc: debathena@mit.edu
To: jmorzins@mit.edu, andersk@mit.edu, jdreed@mit.edu
Date: Thu, 16 Apr 2009 01:01:17 -0000
Reply-To:
Message-ID: <054.a6e88a92ce923101203dcdfb04dafbfe@mit.edu>
In-Reply-To: <045.dc406a80e7544701121648e9f5b55df5@mit.edu>
Content-Transfer-Encoding: 8bit
#205: ssh changes behavior from Athena 9, does not delegate tickets by default-------------------------+--------------------------------------------------
Reporter: jmorzins | Owner:
Type: defect | Status: new
Priority: major | Component: --
Keywords: ssh kerberos |
-------------------------+--------------------------------------------------
Comment(by andersk):
Replying to [comment:3 jdreed]:
> Kerberos Extras does this for you on Mac OS X too.
Really? That seems extremely poor, especially since I don’t see any
documentation for that change, at least on their website. I agree we
should get macdev to comment on this.
> Should we go that route, users who take their security seriously enough
can always have a ~/.ssh/config that overrides the system defaults.
Users shouldn’t have to change how they do things unrelated to Debathena
in order to remain secure after installing Debathena.
> Can't these services be configured to reject delegated credentials,
rather than using it as a rationale for a widespread user behavior change?
Not without sshd code changes. Furthermore, that doesn’t solve the
problem, because even if the service was normally configured to reject
delegation, an attacker who compromises the service could change that
configuration. A secure distributed computing infrastructure cannot be
built upon hosts with a “gentleman’s agreement” not to attack each other.
> If we decide to stick with the current configuration, I think we
definitely need to do this, ideally for debathena-login and higher. The
warning should also, as succinctly as possible, inform users of the
consequences of this (ie: no dotfiles, no homedir access, no running
locker software, no zephyr, etc). Perhaps the right thing to do is to
say "Warning: you have no Kerberos tickets or AFS tokens. For more
information, see http://whatever"
That seems reasonable. Obviously, there are some details we’d want to
think about: the message should go to stderr, only for nonlocal accounts,
possibly only for interactive logins, and possibly only if your
{.bashrc,.cshrc} isn’t otherwise readable without tokens (since otherwise
you probably took some explicit action to make this work); such
restrictions don’t seem like they would diminish the message’s usefulness
to its target audience.
> Given that the dialups will be Athena 9 for quite a while, if enabling
this is not possible, I'd really like to configure -cluster and
-workstation to at least delegate credentials to the Athena dialups. If
those are compromised, we're pretty doomed anyway, so I think it's
reasonable to trust them.
For -cluster and -workstation, I would be open to considering this, but I
worry that the inconsistency (between -standard and -cluster, as well as
between athena.dialup and other hosts) may be just as confusing as the
difference from Athena 9 in the first place.
-- Ticket URL: <http://debathena.mit.edu/trac/ticket/205#comment:4>Debathena <http://debathena.mit.edu/>MIT Debathena Project
