> > 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?

Bryce




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 
immediately.


_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to