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

Attachment: 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

Reply via email to