[Freeipa-users] local root can su to any IPA user

[JR Aquino]

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 <bnordgren at 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.org at 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140228/ad7720f4/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140228/ad7720f4/attachment.sig>