p9auth driver in Linux kernel
Preventing privilege escalation: The Plan 9 way!
Rahul Murmuria
Graduate Student, George Mason University
Related Work
- OpenSSH, qmail: A process for each activity/user
- SELinux: limits priviledges based on the user that spawned the process
- Linux Capability System: super user split into 30 different capabilities
- But what about su, login, apache and others who play with the setuid?
Preventing Privledge Escalation
- Provos, N., Friedl, M., and Honeyman, P. 2003. Preventing privilege escalation. In Proceedings of the 12th Conference on USENIX Security Symposium - Volume 12 (Washington, DC, August 04 - 08, 2003). USENIX Security Symposium. USENIX Association, Berkeley, CA, 16-16.
- Master-slave concept where only master process is priviledged
- Weakness: Onus of protecting the environment still with the application
Introducing: The p9auth driver
- Run everything as an unpriviledged user
- Host Owner's Factotum brokers keys on behalf of user
- More kernel involvement (performance?)
- Network scalable (although work in progress)
- p9cr is a Kerberos-like protocol that takes care of encripted exchange of auth information
Overview
Testing the cap device
$ id rahuluid=1000(rahul) gid=1000(rahul) groups=1000(rahul)
$ id murmuria
uid=1001(murmuria) gid=1001(murmuria) groups=1001(murmuria),10(wheel)
$ whoami
rahul
$ openssl sha1 -hmac "$RANDSTR" "1000@1001" | awk '{ print $2 '} > /dev/caphash
$ echo "1000@1001@$RANDSTR" > /dev/capuse
$ whoami
murmuria
Testing the cap device
$ id rahuluid=1000(rahul) gid=1000(rahul) groups=1000(rahul)
$ id murmuria
uid=1001(murmuria) gid=1001(murmuria) groups=1001(murmuria),10(wheel)
$ whoami
rahul
su - murmuria$ echo "1000@1001@$RANDSTR" > /dev/capuse
$ whoami
murmuria
cap_device workflow
Future Work
- Run factotum at boot: requires credentials in nvram
- Need a user agent to map string usernames to userid
- storing 1000 and 1001 in authserv is obviously not scalable!
- Faster than NFS, Kerberos and/or LDAP auth?
Thoughtful Points
Ouestions?
References:- Ganti, A. 2008. Plan 9 authentication in Linux. SIGOPS Oper. Syst. Rev. 42, 5 (Jul. 2008), 27-33.
- Provos, N., Friedl, M., and Honeyman, P. 2003. Preventing privilege escalation. In Proceedings of the 12th Conference on USENIX Security Symposium - Volume 12 (Washington, DC, August 04 - 08, 2003). USENIX Association, Berkeley, CA, 16-16.
- Cox, R., Grosse, E., Pike, R., Presotto, D. L., and Quinlan, S. 2002. Security in Plan 9. In Proceedings of the 11th USENIX Security Symposium (August 05 - 09, 2002). USENIX Association, Berkeley, CA, 3-16.
Related Reading
- E. Van Hensbergen. Glen or Glenda: Empowering Users and Applications with Private Namespaces. In proceedings of Ottawa Linux Symposium, June 2005.
- Other Plan 9 From Bell Labs related papers and resources
- 9P: network protocol developed for the Plan 9 from Bell Labs distributed operating system. It is a language agnostic 'API' having means of accessing and manipulating resources and applications transparently in a distributed environment.
- v9fs, a 9P Filesystem Protocol Implementation