Some further reading material about operating in a security model where you accept that things are already compromised:
* CISecurity did a good job on the Kerberos benchmark that was written: http://benchmarks.cisecurity.org/downloads/show-single/index.cfm?file=mitkerberos110.100 * Two Factor should be employed on any system you consider critical: As far as Identities go, The Password is Dead... YubiKey is a pretty good, low overhead starting point, http://wiki.yubico.com/wiki/index.php/Main_Page * Long Live POSIX, the owner,group,everyone model has been broken for quite sometime. I suggest checking out Capsicum in addition to any further reading about trusted computing or SElinux, etc. http://www.cl.cam.ac.uk/research/security/capsicum/ https://github.com/google/capsicum-linux On Feb 28, 2014, at 9:27 AM, Nordgren, Bryce L -FS <bnordg...@fs.fed.us> wrote: > >>> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
