Using ksu/sudo with Kerberos
Brian Candler
environment?
So far I can see the following options:
(1) create separate principals for each user who should have root access,
e.g.
cand...@FOO.EXAMPLE.COM
candlerb/ad...@FOO.EXAMPLE.COM
Then map */admin to the root account using auth_to_local, and people
can use ksu to switch.
(I'm not sure I like the idea of burying "/admin" inside a principal's name;
that seems to be mixing authentication and authorization. And that would
apply a single authorization policy across all systems)
(2) Use sudo with NOPASSWD for users who are members of a particular group
(3) Use sudo with pam_krb5, so user has to enter their password again.
Kerberos is then just acting as a password oracle (ick).
Are there any others I should be considering?
Thanks,
Brian.
Russ Allbery
> (1) create separate principals for each user who should have root access,
> e.g.
> cand...@FOO.EXAMPLE.COM
> candlerb/ad...@FOO.EXAMPLE.COM
> Then map */admin to the root account using auth_to_local, and people
> can use ksu to switch.
We do this, except we use .k5login with a specific list of principals that
should have access to root. I wouldn't use auth_to_local for...
> (I'm not sure I like the idea of burying "/admin" inside a principal's name;
> that seems to be mixing authentication and authorization. And that would
> apply a single authorization policy across all systems)
...exactly that reason.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Christopher D. Clausen
> Brian Candler <B.Ca...@pobox.com> writes:
>
>> (1) create separate principals for each user who should have root access,
>> e.g.
>> cand...@FOO.EXAMPLE.COM
>> candlerb/ad...@FOO.EXAMPLE.COM
>
>> Then map */admin to the root account using auth_to_local, and people
>> can use ksu to switch.
>
> We do this, except we use .k5login with a specific list of principals that
> should have access to root. I wouldn't use auth_to_local for...
Note that depending upon your SSH setup, adding user principals to root's
.k5login (or auth_to_local rules) might allow one to login directly as root
on the system via SSH. In general, that is exactly what I prefer to do:
ssh root@machine gets me in as root but logs that cclausen (or
cclausen/admin) made the connection. Of course it doesn't log every
individual action, but IIRC neither does ksu.
I have PermitRootLogin set to without-password in sshd_config so that
Kerberos is allowed but not password based auth for the root user.
<<CDC
Russ Allbery
> Russ Allbery <r...@stanford.edu> wrote:
>> We do this, except we use .k5login with a specific list of principals that
>> should have access to root. I wouldn't use auth_to_local for...
> Note that depending upon your SSH setup, adding user principals to root's
> .k5login (or auth_to_local rules) might allow one to login directly as root
> on the system via SSH. In general, that is exactly what I prefer to do:
> ssh root@machine gets me in as root but logs that cclausen (or
> cclausen/admin) made the connection. Of course it doesn't log every
> individual action, but IIRC neither does ksu.
Same here. I prefer that to ksu since it doesn't expose the password on
the local system.
> I have PermitRootLogin set to without-password in sshd_config so that
> Kerberos is allowed but not password based auth for the root user.
Yup. You may want to also disable public key authentication.
Ken Dreyer
>
> Yup. You may want to also disable public key authentication.
We're enabling kerberos for several services at my organization, and
we were just having this same discussion. Can you elaborate on why you
would disable pubkey?
- Ken
Russ Allbery
It's totally up to you, of course, and we do leave it enabled on some
systems because in some cases it's easier than using GSSAPI authentication
with ssh. But once you have Kerberos, public keys constitute a second
parallel authentication system which isn't tied in with Kerberos, which is
a potential vulnerability. You may disable a Kerberos account but not
forget to remove their authorized_keys entries, for example. ssh keys are
also difficult to centrally manage, which is usually one of the whole
points of a Kerberos infrastructure.
There unfortunately isn't any way that I know of to allow GSSAPI and
public key authentication via ssh for regular users but require GSSAPI
alone for root authentication, so we usually just turn public key off
entirely. (I suppose you could enforce an empty authorized_keys file, but
that requires some sort of configuration management infrastructure running
on each system to ensure that.)
Abe Singer
In my previous job, we modified sudo (relatively simple patch, I'll
have to dig it up) to use kerberos authentication with a principal
of the format <user>/sudo@<REALM>. (sudo supports kerberos auth, but
using the user's login principal, which AFAIC is a horrible mistake
security-wise).
I'm old school -- where allowing direct root login is verboten,
allowing direct login to root just makes me twitch. Having logging
of who logged in helps, but I prefer requiring users to login as themselves
and the su/sudo to get root access. I can't make the strongest argument for
it, but I like having tohe user have to have an account on the target host
*and* have a separate credential for privilege access, *and* have permission
in sudoers for that host. If nothing else, maybe it reduces the risk of
accidentally allowing open root login to the machine, or accidentally
giving someone privileged access to a host they're not supposed to have
it on.
-- Abe
On Mon, Oct 04, 2010 at 03:47:00PM -0500, Christopher D. Clausen wrote:
>
> Russ Allbery <r...@stanford.edu> wrote:
> > Brian Candler <B.Ca...@pobox.com> writes:
> >
> >> (1) create separate principals for each user who should have root access,
> >> e.g.
> >> cand...@FOO.EXAMPLE.COM
> >> candlerb/ad...@FOO.EXAMPLE.COM
> >
> >> Then map */admin to the root account using auth_to_local, and people
> >> can use ksu to switch.
> >
> > We do this, except we use .k5login with a specific list of principals that
> > should have access to root. I wouldn't use auth_to_local for...
>
> Note that depending upon your SSH setup, adding user principals to root's
> .k5login (or auth_to_local rules) might allow one to login directly as root
> on the system via SSH. In general, that is exactly what I prefer to do:
>
> ssh root@machine gets me in as root but logs that cclausen (or
> cclausen/admin) made the connection. Of course it doesn't log every
> individual action, but IIRC neither does ksu.
>
> I have PermitRootLogin set to without-password in sshd_config so that
> Kerberos is allowed but not password based auth for the root user.
>
> <<CDC
>
> ________________________________________________
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
Brian Candler
> Note that depending upon your SSH setup, adding user principals to
> root's .k5login (or auth_to_local rules) might allow one to login
> directly as root on the system via SSH.
ISTM that leaves a bit of an administrative headache in updating .k5login
files on all the machines. I don't suppose there's a way to get kerberos or
openssh to query LDAP for this instead? I see the question asked in 2007
but only some private patches mentioned:
http://mailman.mit.edu/pipermail/kerberos/2007-October/012353.html
At worst, I guess I could write a script which does an LDAP query every hour
and writes the results to root's .k5login
sudo's testing for group membership seems a lot more attractive in that
regard.
Regards,
Brian.
Guillaume Rousse
> Ken Dreyer <ktdr...@ktdreyer.com> writes:
>> On Mon, Oct 4, 2010 at 3:38 PM, Russ Allbery <r...@stanford.edu> wrote:
>
>>> Yup. You may want to also disable public key authentication.
>
>> We're enabling kerberos for several services at my organization, and
>> we were just having this same discussion. Can you elaborate on why you
>> would disable pubkey?
>
> It's totally up to you, of course, and we do leave it enabled on some
> systems because in some cases it's easier than using GSSAPI authentication
> with ssh. But once you have Kerberos, public keys constitute a second
> parallel authentication system which isn't tied in with Kerberos, which is
> a potential vulnerability. You may disable a Kerberos account but not
> forget to remove their authorized_keys entries, for example. ssh keys are
> also difficult to centrally manage, which is usually one of the whole
> points of a Kerberos infrastructure.
account for instance, and configure OpenSSH to use PAM, you don't really
care about the exact authentication method used.
And they are methods to manage public keys centraly, such as storing
them in a LDAP directory or in a version control system, regulary synced
on machines through some kind of configuration management engine.
> There unfortunately isn't any way that I know of to allow GSSAPI and
> public key authentication via ssh for regular users but require GSSAPI
> alone for root authentication, so we usually just turn public key off
> entirely. (I suppose you could enforce an empty authorized_keys file, but
> that requires some sort of configuration management infrastructure running
> on each system to ensure that.)
What about this (untested) ?
Match User root
PubkeyAuthentication no
--
BOFH excuse #394:
Jupiter is aligned with Mars.
Russ Allbery
Ah, yes, the Match stuff is relatively new and will probably now do the
right thing. Thank you!
jul...@vgai.de
> sudo's testing for group membership seems a lot more attractive in that
> regard.
Can it test this using LDAP, too?
-- Julian
Brian Candler
Sure: using nss_ldap then you ldap uid, gid and supplementary groups via
LDAP. Then in /etc/sudoers you just check for membership of a particular
group.