[Twisted-Python] tap security problem
tap uid/gid data allows privilege separation. As uid/gid are part of the Application, a compromised application can write a shutdown.tap with different uid/gids. in a typical setting the new shutdown.tap will be read on the next startup, to enjoy persistence. i think the seperation between config options that are handled by mktap, and those handled by twistd needs to be refined. paul
On Sat, 5 Oct 2002 14:48:22 +0200, Paul Boehm <typo@soniq.net> wrote:
As uid/gid are part of the Application, a compromised application can write a shutdown.tap with different uid/gids.
Why, in a security-conscious environment, are you allowing the uid/gid that the server is running as to even _read_ the .tap? In any event, the .tap is effectively an SUID binary, and should be writable only by root. The whole notion of this automatic persistence is somewhat at odds with that of security - .tap persistence is very explicitly designed to have no security constraints whatsoever, but to be very convenient. If you need both persistence and security, then you have to design your persistence mechanism to constrain what can be persisted. Pickle effectively allows literal code to be stored and executed. -- | <`'> | Glyph Lefkowitz: Traveling Sorcerer | | < _/ > | Lead Developer, the Twisted project | | < ___/ > | http://www.twistedmatrix.com |
On Sat, Oct 05, 2002 at 01:53:05PM -0500, Glyph Lefkowitz wrote:
On Sat, 5 Oct 2002 14:48:22 +0200, Paul Boehm <typo@soniq.net> wrote:
As uid/gid are part of the Application, a compromised application can write a shutdown.tap with different uid/gids.
Why, in a security-conscious environment, are you allowing the uid/gid that the server is running as to even _read_ the .tap? In any event, the .tap is effectively an SUID binary, and should be writable only by root.
why wouldn't i allow the uid/gid that the server is running at, to read the tap? after all the the tap is nothing but a snapshot of the running application? if twistd did setuid() etc. calls before loading the tap, this would yield a definite improvement in security. e.g. chroot already is defined by twistd, presumably because it too requires root privileges to be used.
The whole notion of this automatic persistence is somewhat at odds with that of security - .tap persistence is very explicitly designed to have no security constraints whatsoever, but to be very convenient. If you need both persistence and security, then you have to design your persistence mechanism to constrain what can be persisted. Pickle effectively allows literal code to be stored and executed.
the persisted tap shouldn't allow me to do anything i couldn't do with a hijacked application running at some uid. i don't see why i shouldn't be able to load a tap and run it with less privileges. as i see it, tap r/w access shouldn't be any different from application code access in terms of severity. paul
On Thu, 10 Oct 2002 03:44:45 +0200 Paul Boehm <typo@soniq.net> wrote:
as i see it, tap r/w access shouldn't be any different from application code access in terms of severity.
Sure - allow reads but *NOT*!!! writes. Because if you let var-www write to python code that's going to be imported by a suid root app you're in a bad situation. If your tap is run by root it should not be writable by non-root users. -- Itamar Shtull-Trauring http://itamarst.org/ Available for Python, Twisted, Zope and Java consulting
participants (3)
-
Glyph Lefkowitz -
Itamar Shtull-Trauring -
Paul Boehm