On Sun, Aug 31, 2008 at 11:19:45AM +0200, Peter Palfrader wrote: > On Sat, 30 Aug 2008, Steve Langasek wrote: > > Well, the underlying premise here is, of course, that certain routinely > > useful capabilities need to be taken out of the hands of the users because > > they won't use them responsibly[1]. > > > But we're already talking > > about hard policy changes to stop users from doing things they shouldn't do > > in the first place (== using passwords when logging in to Debian servers > > from their systems), so I don't think you should underestimate the capacity > > of developers to be cleverly stupid when security is concerned. > > I don't think that using the password per se on debian hosts is an evil > thing to do. I have to do it dozens of time almost every day for sudo. > And I don't think nopasswd entries in the sudoers file would be all that > much better. Or we could start shipping a pam pwdfile table for use > with sudo. Maybe we should do that anyway, regardless of what comes > from this discussion. > > Also I agree, if somebody willfully compromises security there's nothing > we, or anyone, can do.
It doesn't necessarily have to be willfully.
Security is mostly a social problem, not a technical one; you have to
keep that in mind at all times. Even though the average Debian Developer
is stronger on a technical level than the average computer user, that
doesn't mean there aren't any bad apples; and it certainly doesn't mean
all Debian Developers understand all the intricacies of security
problems.
What is sure, however, is that as you create more hoops you for people
to jump through, people will try to find more and more workarounds for
these hoops; and, therefore, that in many cases implementing a measure
meant to increase security may, in fact, lower the security of your
system as a whole rather than increase it, simply because people have
other tradeoffs to make than you as a security-aware system
administrator. While it may sound attractive to say "You're only allowed
to access Debian.org from your home system after sending a GPG-encrypted
mail to a particular system and waiting for a one-time-password that you
will receive through an automated phone system"[1], it's clear that
people will try to work around that system, because they don't know any
better, or because there's an emergency, or whatnot.
I personally do not share the belief that outlawing password-based login
is going to improve security. If we're afraid of keyloggers, then we
should also be afraid of using software that intercepts Kerberos TGTs,
SSH keys, etc; if we're afraid of weak passwords, then we should also be
afraid of weak SSL/SSH/... keys. On the other hand, outlawing
password-based logins may initially make people who want to SSH debian
systems from work jump through their home system in order to access
their SSH key; but I suspect they'll eventually create an SSH key on
their work machine, not realizing that their dark evil system
administrator has access to their hard disk, allowing them to
brute-force it. Additionally, you don't necessarily know what the state
of the link between their work system and their home system is; the SSH
daemon on the home system may be compromised, or may be limited to a
weak encryption, or whatever. Allowing password-based deals with all
these issues, because you only need to take care that what you are
running is safe, and that _your own_ encryption is strong enough, as
opposed to the encryption between the host you're talking to and the
host the user is actually physically using. That does require you to
enforce a "safe passwords only" policy, but this can be done through the
likes of cracklib.
I believe that beyond implementing checks at reasonable places,
enforcing that only secure protocols are used (with 'secure' being
defined as 'does not send important security credentials over the wire
in such a way that they could be re-used for other services by an
eavesdropper'), and, especially, educating users on things to do vs
things not to do, there isn't much you can do. Speaking of secure
protocols: someone should _really_ update db.debian.org so that slapd
does /not/ accept password-based authentication over non-encrypted
links[2].
This education could be done in two steps: first, create a policy and
link to it from debian-devel-announce; second, make this required
reading for the NM procedure (similar to the 'DMUP' and 'SC/DFSG'
questions that NMs need to agree to in a signed mail). In the case of
Debian, I think it's fair to assume people do not want security
breaches, which may or may not be the case for other organizations.
> > Having your inter-host file transfers sandboxed, such that you have to log
> > in to the host on each end in order to get the files copied to the place you
> > want them, would be a serious nuisance, and in particular, it would not
> > allow for good use of rsync as a time- and bandwidth- saving technique.
> > Having to start a separate ssh agent for Debian systems would also not be
> > user-friendly.
>
> How often do you do that, seriously? I can't think off-hand of the last
> time I had to rsync large amounts of data as weasel between debian
> hosts. I don't rule out that it happens, I would just like to know if
> it's a daily routine.
Personally, I'd be a bit wary of statements like the above. "How often
does <foo> happen" on a host that may be used by over 1000 people isn't
easy to answer.
> > Kerberized ssh with ticket forwarding is one of the better ones in this
> > regard, because it doesn't require typing a password across the wire and the
> > delegated credentials have a limited lifetime.
>
> I fail to see how this is better than ssh agent forwarding. This might
> be because I never really did much with ticket forwarding but I always
> thougt the idea was to forward a TGT, so it again would give you access
> to all hosts, for much longer than you are logged in probably.
That is one option, but not necessarily the only one; it is possible to
instruct the KDC that it must not issue forwardable tickets, meaning,
you wouldn't be able to forward a TGT _in any case_. If the KDC would
still allow proxiable tickets, then this could be used to get one
particular service to issue requests in name of another principal (e.g.,
you could use HTTP/[EMAIL PROTECTED] tickets to get a postgres/
ticket to authenticate to the postgres service on the same host for as
long as the HTTP connection has access to the client to request it using
the client's TGT, but you couldn't get a new TGT valid for
foo.debian.org).
By setting the "GSSAPICleanupCredentials" option in sshd_config, the
credentials cache is destroyed upon logout (this can also be done
through the session component of libpam_krb5.so). I'm not entirely sure
whether destroying a credentials cache means the KDC is also instructed
to revoke the TGT and cannot check currently, but I believe this is the
case.
Additionally, Kerberos tickets have a limited lifetime (10 hours by
default, but this can be changed, and probably should be if we ever were
to use Kerberos in Debian); if an attacker gets hold of a Kerberos TGT,
they can only use it for as long as the TGT does not expire (they may be
able to renew the ticket, but that too can be disabled, and if not it
cannot be done beyond a particular timelimit that is counted from the
initial issuance of the TGT). It's even possible to postdate a ticket,
so that you could, e.g., get a ticket now for the at(1) job that will
run at midnight tonight. It will then not be usable before the time
given. SSH keys do not have any of these time-limiting features; if an
attacker gets hold of your private SSH RSA key, you lose.
[...]
> > RSA auth forwarding is also good by this standard, because the credentials
> > are only available while the user's initial connection is active and there
> > are methods for requiring user confirmation for each instance of
> > authentication forwarding.
>
> Agree on the available only temporary. I don't think many people use
> the confirmation of each instance of agent use (not forwarded use, I
> don't think that's possible, is it?). I did that a while ago but it got
> so annoying since I ssh to hosts hundreds of times a day.
That's another reason why time-limited credentials such as provided by
Kerberos are a better option.
> > Anything that involves sending your password across the wire, or
> > storing RSA keys on the Debian host, is pretty obviously not good.
>
> Anything that involves sending a password over the wire that can be
> used to access shells on other machines should be avoided, agreed.
I'm not sure on this. Really, an SSH key is also a password -- it's just
much longer.
> > > 1. And more likely the user will fetch a full TGT on the source host
> > > when they want to copy stuff to another host since the default mode of
> > > login will probably stay ssh keys.
> >
> > Well, a way around that is to not give users kinit on the Debian hosts,
> > and/or implement ACLs on the KDC that prohibit issuing TGTs to Debian hosts.
>
> Not sure how feasable that would be, and what it would help if you can
> just forward a TGT to a debian host.
The TGT is encrypted to the KDC, not to the principal. It is therefore
impossible to forward a TGT without the knowledge of the KDC.
If your ACLs disallow TGTs on Debian hosts, then there will be no TGTs
on Debian hosts, period.
HTH,
[1] Yes, this is deliberately over the top. You got the point, didn't
you?
[2] Yes, I did change my password immediately after I realized that I'd
accidentally sent it over the wire in the clear.
--
<Lo-lan-do> Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22
signature.asc
Description: Digital signature
