Sudo w/Ticket Support

[John Washington]

* Christopher D. Clausen <cclausen at acm.org> [2009-05-07 16:43]:
> petesea at bigfoot.com wrote:
> > Main reason for not setting NOPASSWD is because I don't have control
> > over the sudoers file on most of the systems I have access to.  And
> > the SA's are very reluctant to use "NOPASSWD".
> 
> Do you know about the ksu command?
> 
> Or using a ~root/.k5login and ssh -o "GssapiAuthentication yes" 
> root@`hostname` ?
> 
> > I believe they just want that extra layer of protection in case a
> > workstation is left unattended.
> 
> 
> People who leave workstations unattended should not have sudo access. 
> Also, if unattended and the tickets are still valid, someone can still 
> use them.
> 
> > I do see what you mean though.  From a security standpoint, if sudo
> > was capable of using an existing TGT, that doesn't seem like it would
> > be too much different then using NOPASSWD in the sudoers file.
> 
> Yes, exactly.  Except it will stop working once the tickets expire, so 
> there is some trivial level of safety.

My primary comment would be that there are additional concerns with sudo
access.  I cannot speak to the exact setup, but I will envision a
hypothetical scenario like the following:

  I acquire credentials locally and then ssh with gssapi to
my account elsewhere.  I then do some work.  I notice that a package is
missing/misconfigured, so I elevate my privileges with sudo and make a
change.

In this case the potential concerns are:

1. The credentials are stale.  Sudo enforces a short cache time while
Kerberos credentials are valid for an extended period.  This is a
defense mechanism to help ensure that an accidentally unlocked
workstation (your boss stops by with an important question and you
forget to lock your screen).

2. There is potentially additional reasons to require the sudo such as
two factor authentication or a different password for root access.  I
will admit that it doesn't seem like it from the description.

I would describe the solution tree like this:

If this is local, I would consider the following:

1.  Does this happen often?  Once a day isn't a problem, but if you need
to sudo every 1/2 hour then there should be some better way to tune the
sudoers file to whitelist activity.

2.  You could (functionally) achieve the same results by extending the
timeout on sudo, while retaining the need for real authentication.

If this is remote:

1.  Why not use a .k5login to get to root directly?