Hello, I am looking for a way to start Zope (2.7.2) with root privileges *without* droping them later. I tried to set: effective-user root in the configuration file but it produced the same error... By now i have edited the source code fragment responsible for this check to override it. I was wondering if it can be [somehow] configured without tampering with zope source. Thanks.
On Tue, 27 Jul 2004 16:51:02 +0300 Vangelis Mihalopoulos <mihalop@VTrip.NET> wrote:
Hello,
I am looking for a way to start Zope (2.7.2) with root privileges *without* droping them later. I tried to set: effective-user root
Hi, wouldn't be more wise just setuid (chmdo -s) some external method['s], doing inside it[them] you root 'necessities' ;o)? best regards, Rod Senra
Rodrigo Dias Arruda Senra wrote:
Hi, wouldn't be more wise just setuid (chmdo -s) some external method['s], doing inside it[them] you root 'necessities' ;o)?
thanks for your answer Rod, nice thinking, but i am not sure it would work... external methods are called in the same thread serving the request... so, how would a suid affect anything? It could only be useful if i "executed" suid python scripts from an external method, and thus creating a new process... i have to test it to be sure.
I hate it when people "nanny" me about doing things that are possible but outside of the scope of normal usage, so I hesitate to warn you about this. But I still feel compelled to warn you that running Zope as root is not advisable; while there have been no known remote exploits of Zope that allow an intruder any form of filesystem access, obviously it's possible, so running as root is potentially quite dangerous. On Tue, 2004-07-27 at 11:37, Vangelis Mihalopoulos wrote:
Rodrigo Dias Arruda Senra wrote:
Hi, wouldn't be more wise just setuid (chmdo -s) some external method['s], doing inside it[them] you root 'necessities' ;o)?
thanks for your answer Rod,
nice thinking, but i am not sure it would work... external methods are called in the same thread serving the request... so, how would a suid affect anything? It could only be useful if i "executed" suid python scripts from an external method, and thus creating a new process... i have to test it to be sure.
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Chris McDonough wrote:
I hate it when people "nanny" me about doing things that are possible but outside of the scope of normal usage, so I hesitate to warn you about this. But I still feel compelled to warn you that running Zope as root is not advisable; while there have been no known remote exploits of Zope that allow an intruder any form of filesystem access, obviously it's possible, so running as root is potentially quite dangerous.
Well, i agree with you. But, still, using suid python scripts for half of my app is a problem... believe me, it will be much easier for someone to find a security flaw in my app than is Zope... :)
On Tuesday 27 July 2004 12:22, Vangelis Mihalopoulos wrote:
Well, i agree with you. But, still, using suid python scripts for half of my app is a problem... believe me, it will be much easier for someone to find a security flaw in my app than is Zope... :)
Another idea... don't know how worthy it is, feel free to shoot it down... (but I'd appreciate knowing what's wrong with it for my own education :-)). What if you encapsulated your code that must run as root in some kind of daemon that listens locally only? Either network, and protected by a file, or maybe use a Unix domain socket or similar mechanism. Either use a proprietary protocol, or maybe have it serve up XML-RPC. Force all interaction between Zope and this code to use a defined interface. It would give you a place to do sanity checking on the commands being fed to the privileged code, and I would think it would provide some protection of the root code from a Zope compromise. To exploit your code, an attacker must first compromise Zope, and then figure out how to get your code to misbehave. Just my $0.02 -Michael
Michael Ekstrand wrote:
On Tuesday 27 July 2004 12:22, Vangelis Mihalopoulos wrote:
Well, i agree with you. But, still, using suid python scripts for half of my app is a problem... believe me, it will be much easier for someone to find a security flaw in my app than is Zope... :)
Another idea... don't know how worthy it is, feel free to shoot it down... (but I'd appreciate knowing what's wrong with it for my own education :-)).
What if you encapsulated your code that must run as root in some kind of daemon that listens locally only? Either network, and protected by a file, or maybe use a Unix domain socket or similar mechanism. Either use a proprietary protocol, or maybe have it serve up XML-RPC. Force all interaction between Zope and this code to use a defined interface. It would give you a place to do sanity checking on the commands being fed to the privileged code, and I would think it would provide some protection of the root code from a Zope compromise. To exploit your code, an attacker must first compromise Zope, and then figure out how to get your code to misbehave.
well, my code doesn't have to "misbehave" to cause damage... if zope security is compromised, then the whole system is compromised, so i don't think your idea is applicable on my case. nevertheless, what you propose is a nice architecture which could be used in other cases. For example, a "file manager" with root privileges doesn't have to be compromised. If one bypasses zope security, he can do all the damage he wants :)
Vangelis Mihalopoulos <mihalop@VTrip.NET> writes:
Well, i agree with you. But, still, using suid python scripts for half of my app is a problem... believe me, it will be much easier for someone to find a security flaw in my app than is Zope... :)
That's key, though. Your application is going to be a less attractive target for attacks than zope to the degree that it is a less prevalent application than zope. This doesn't mean that you shouldn't be careful to make your application secure - but it does mean that you have a lot more lattitude than zope, the application, to provide for your special local-host security concerns. Someone later in the thread suggested separating the code that needs to run as root as a separate service. I think that's heading in the right direction. You don't have to get very fancy to convey things between the separate processes, and you can arrange things so that it takes local-host access to deliver things to the root processing. If you can wait for batch processing, you could have an arrangement where the root processes run periodically (down to every minute) from cron, to look for files in a particular directory for handling. The zope side would just situate the files. You could restrict the file processing dir to the userid of the zope process, to regulate local access. The processor could even use http, xmlrpc, webdav, ZEO, etc to call back into zope to deliver the results of the processing. If you need more immediate call/response, you could have a long running process listening and talking on unix domain pipes. (Despite the name, i think windows systems have those, as well.) It isn't trivial to interact with interacting with pipes (you'll get acquainted with select, read buffering policies, etc), but it's valuable knowledge that serves you in ways beyond the specific problem. The essential principle, here, is that you want to make as narrow as you possibly can the ways which root processing is exposed across the network. Most network daemons that run as root have years of testing and many thousands of eyes - and still, holes are discovered and exploited daily. Zope tries to minimize that kind of exposure by refusing to run as root in the first place - it makes for a more manageable problem when abusive access is discovered. Ken Manheimer klm@zope.com
On 28 Jul 2004, Ken Manheimer wrote:
That's key, though. Your application is going to be a less attractive target for attacks than zope to the degree that it is a less prevalent application than zope. This doesn't mean that you shouldn't be careful to make your application secure - but it does mean that you have a lot more lattitude than zope, the application, to provide for your special local-host security concerns.
I agree with you. But what if i am implementing a file manager? With capabilities like upload/downloading any file in all filesystems? Even if i implement a privileged XML-RPC server which only listens requests from the local host (from Zope that is), i don't think security is tighter. If someone breaks into [the non-privileged] Zope, he can still use the privileged server to do as much harm as he pleases. I believe it comes down to what exactly are the privileged actions. If it is simply a very specific task that would not compromise the whole system security, that model is a "must". But if the privileged actions are more generic, with abilities to harm the whole system, then running Zope as root is of no importance. Thanks for your answer, Vangelis
Hi, I need to feed a Zope instance with data coming from UDP datagrams. I figured out the following approaches: 1) Make the Zope instance a ZEO client, and use another ZEO client (probably a Twisted app) to feed the data to the same ZODB storage. 2) Use Zope inner services (http, https, webdav, ftp) as model to build my embeeded UDP listener 3) Forget all about UDP and adapt the data source (a win32app) to use XMLRPC instead. But this is a last resort, because I think xml-rpc packets bring to much overhead to my scenario. Did I miss any other alternatives ? Is 1) obviously the best ? I would appreciate any comment. best regards, Rod Senra rodsenra at gpr.com.br
On Wed, May 26, 2004, Rodrigo Dias Arruda Senra wrote:
On Tue, 27 Jul 2004 16:51:02 +0300 Vangelis Mihalopoulos <mihalop@VTrip.NET> wrote:
Hello,
I am looking for a way to start Zope (2.7.2) with root privileges *without* droping them later. I tried to set: effective-user root
Hi, wouldn't be more wise just setuid (chmdo -s) some external method['s], doing inside it[them] you root 'necessities' ;o)?
Other alternatives might be using ``sudo'' from the external method or perhaps XMLRPC calls to a server running as root. Bill -- INTERNET: bill@Celestial.COM Bill Campbell; Celestial Software LLC UUCP: camco!bill PO Box 820; 6641 E. Mercer Way FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 URL: http://www.celestial.com/ ``the purpose of government is to reign in the rights of the people'' -Bill Clinton during an interview on MTV in 1993
On Tue, 2004-07-27 at 09:51, Vangelis Mihalopoulos wrote:
I tried to set: effective-user root in the configuration file but it produced the same error... By now i have edited the source code fragment responsible for this check to override it. I was wondering if it can be [somehow] configured without tampering with zope source.
That is the "right" thing to do; there is no other way to have Zope run as root for its lifetime. - C
participants (6)
-
Bill Campbell -
Chris McDonough -
Ken Manheimer -
Michael Ekstrand -
Rodrigo Dias Arruda Senra -
Vangelis Mihalopoulos