> > Offline password caching is also optional and a different method.
> > In this case the actual password is maintained in the kernel keyring
> > in locked memory until the machine goes online and can acquire a TGT.
> > On success it is deleted.
> > however it doesn't really matter from an evil-root scenario, because
> > evil-root will have already snatched the password from the PAM stack
> > at authentication time.
Ah. My evil root scenario was that my AS exchange happened on my trusted
machine and I used SSO to sign in to Evil root's machine. No password in Evil's
pam stack. Evil can log into an Evil-compromised machine all he wants. Can't
steal a password from yourself.
Please shoot holes in this design for me: :)
A domain uses Kerberos for authentication. The domain does not allow LDAP or
other forms of authentication.
A domain has trusted, domain-administrated machines for initial sign on. Users
are not given root access on these machines. Alternatively, users who have been
given root access to a machine can initiate an AS exchange from machines they
control, but others cannot and/or are strongly discouraged from doing so.
Hence, a user can be granted control over their own workstation/laptop.
Users are given permissions on machines as needed to configure whatever it is
that they need to do. Say there is some sort of project with specialized
requirements which affects ~10-50 participants or so. Someone in the project
stands up a machine to address the project's needs, but this person is not part
of the Organization, so he could be Evil.
Users would be expected to perform their initial sign on using their own
workstation/terminal, then connect to the project resource. Ideally, the
project resource is a website of some type, so only a Kerberos service ticket
is needed. In the case that project members need command line access, but no
access to domain-wide services (like NFS server), they can just get a service
ticket for host/evil.example....@example.org.
So far, Evil is boxed in. Evil has not been given credentials which allow him
to impersonate another user to the domain. Evil's box is a black hole.
Identities go in, but they can't get out.
A problem occurs when users need to access domain-wide services from Evil's
machine. The user (Innocent) can forward their TGT to Evil's machine, giving
Evil full use of Innocent's identity, or Innocent can use their own, trusted
workstation to individually request proxy tickets for the services Innocent
intends to access.
Evil can now impersonate Innocent. In the case where Evil received proxy
tickets, it can only impersonate Innocent to specific services on specific
hosts. In the case where Evil received a TGT, Evil can impersonate innocent at
will to any domain service.
This suggests that it should be a security requirement for
non-organization-wide projects to provide their own services. This permits
encouraging/mandating the use of service tickets with project resources. For
instance, if the project needs file storage, they should provide file storage.
Alternatively, if the organization wishes to provide storage, they may want to
allocate servers (and Kerberos principals) individually for each project.
This seems to me to be a way to compartmentalize groups of cooperating users in
a way that tends to prevent Evil in one group from spreading to another group,
while allowing users to leverage the organization's identity store...It seems
to me that this is even more effective at stopping the spread of Evil than
establishing hierarchical cross-realm trusts underneath the main organization...
Am I overlooking something, or is this likely to be an effective means of
delegating small project support while sideboarding potential Evil?
This electronic message contains information generated by the USDA solely for
the intended recipients. Any unauthorized interception of this message or the
use or disclosure of the information it contains may violate the law and
subject the violator to civil or criminal penalties. If you believe you have
received this message in error, please notify the sender and delete the email
Freeipa-users mailing list