Custom Query (1145 matches)

Reported by jdreed, 13 years ago.

I know upstream decided not to, but upstream's priorities are "Machines should boot in 0.1ms" and our priorities are "Machines should be functional."

Reported by jdreed, 13 years ago.

... because LibreOffice? is too stupid/cool to ship /usr/bin/loffice.

I'm really only interested on this on -cluster, and I'm not suggesting we preserve functionality, I'm suggesting it whine at the user via zenity (in case it's started from a .desktop file) or stderr and tell them what to go type.

Reported by geofft, 11 years ago.

Given the concerns in #1384, delegating Kerberos credentials is currently somewhat unsafe -- an attacker who can intercept DNS requests can redirect you to their own server pretending to be athena.dialup. Meanwhile, since athena.dialup doesn't accept non-delegated Kerberos login, users will probably end up in the habit of running ssh -K to get there.

Alex Dehnert pointed out that the security model of SSH's known_hosts file does not involve DNS canonicalization (all the dialups share a single SSH host key), and proposed disabling GSSAPIKeyExchange as a mitigation for #1384 so that, if an attacker tries to spoof athena.dialup, host key exchange will fail. I don't think disabling it globally is quite warranted, but I could see an argument for disabling it just for athena.dialup, given the delegation risk (and maybe Linerva too, while we're at it).

Of course, that would now make users see a host key prompt for athena.dialup. We could skip that by shipping an /etc/ssh/ssh_known_hosts file with an entry for athena.dialup.mit.edu, so the initial trust prompt is skipped and there's a fully trusted path via the Debathena package. Then we could add something like

Host athena.dialup.mit.edu athena.dialup
    HostName athena.dialup.mit.edu
    GSSAPIKeyExchange no

to /etc/ssh/ssh_config, and the UX would remain the same. (We could also then safely turn on GSSAPIDelegateCredentials yes, in the unlikely event we decided to rethink #205).

There would be a slight amount of update pain if athena.dialup ever rekeys, but, I'm sure that will be a massive pain anyway (to update users' .ssh/known_hosts files everywhere) so I think that's okay.

There's not a particular need to do this for any of the individual athena.dialup servers, I think, and they'd be annoying to manage because the list of servers changes. But we could, if we wanted.