well I know this is way to general. But I'd like nevertheless get some pointers. AFAIKG is Seaside the "first" Web framework for Smalltalk, I've just downloaded AIDA/Web and am playing around it a bit.
But let me as this question nevertheless. What alternatives are there for a "pure" Smalltalk Web presence? Currently my systems are mixture of Apache for static stuff and some other web servers to which Apache proxies (please bear with me that it's Ruby based ;-).
Now I'd like to have the following things:
1) normal pages 2) forum software 3) bug software 4) shop pages 5) a wiki and blog would be nice 6) support for RCS systems
I know that the later may be quite weak for Smalltalks, but well the world does not always talk Smalltalk ;-
Any hints and impressions and expressions would be very welcome
With best regards Friedrich
On Sun, 23 Nov 2008 08:28:18 +0100, Friedrich wrote:
well I know this is way to general. But I'd like nevertheless get some pointers. AFAIKG is Seaside the "first" Web framework for Smalltalk, I've just downloaded AIDA/Web and am playing around it a bit.
But let me as this question nevertheless. What alternatives are there for a "pure" Smalltalk Web presence? Currently my systems are mixture of Apache for static stuff and some other web servers to which Apache proxies (please bear with me that it's Ruby based ;-).
Now I'd like to have the following things:
- normal pages
- forum software
- bug software
- shop pages
- a wiki and blog would be nice
- support for RCS systems
Many/most of these things have been done for
- http://www.cmsbox.com/en/system/features
which is written in Smalltalk and powered by Seaside+script.aculo.us.
I know that the later may be quite weak for Smalltalks, but well the world does not always talk Smalltalk ;-
Any hints and impressions and expressions would be very welcome
With best regards Friedrich
Hi Frieadrich,
Friedrich wrote:
well I know this is way to general. But I'd like nevertheless get some pointers. AFAIKG is Seaside the "first" Web framework for Smalltalk, I've just downloaded AIDA/Web and am playing around it a bit.
But let me as this question nevertheless. What alternatives are there for a "pure" Smalltalk Web presence? Currently my systems are mixture of Apache for static stuff and some other web servers to which Apache proxies (please bear with me that it's Ruby based ;-).
AIDA/Web apps/websites are running as pure Smalltalk web presence, from dynamic to static content, movies included. No Apache needed, Swazoo as integral part of Aida is there to serve directly to the web.
From your list below we are covering out of the box now all except webshop. Maybe not yet perfectly but we are on the way there. See SPM (Squeak Project Manager) for instance, this is Trac like portal for your project, covering from Wiki, bug/issue tracking to code repository access. See for example the SPM for Aida/Scribo CMS http://scribo.aidaweb.si
Best regards Janko
Now I'd like to have the following things:
- normal pages
- forum software
- bug software
- shop pages
- a wiki and blog would be nice
- support for RCS systems
I know that the later may be quite weak for Smalltalks, but well the world does not always talk Smalltalk ;-
Any hints and impressions and expressions would be very welcome
With best regards Friedrich
Janko Mivšek wrote:
Hi Frieadrich,
Ops, sorry Friedrich to had made a mistake writing your name :)
Janko
2008/11/23 Janko Mivšek janko.mivsek@eranova.si:
Hi Frieadrich,
Friedrich wrote:
well I know this is way to general. But I'd like nevertheless get some pointers. AFAIKG is Seaside the "first" Web framework for Smalltalk, I've just downloaded AIDA/Web and am playing around it a bit.
But let me as this question nevertheless. What alternatives are there for a "pure" Smalltalk Web presence? Currently my systems are mixture of Apache for static stuff and some other web servers to which Apache proxies (please bear with me that it's Ruby based ;-).
AIDA/Web apps/websites are running as pure Smalltalk web presence, from dynamic to static content, movies included. No Apache needed, Swazoo as integral part of Aida is there to serve directly to the web.
How do you bind port 80?
Cheers Philipppe
Philippe Marschall wrote:
But let me as this question nevertheless. What alternatives are there for a "pure" Smalltalk Web presence? Currently my systems are mixture of Apache for static stuff and some other web servers to which Apache proxies (please bear with me that it's Ruby based ;-).
AIDA/Web apps/websites are running as pure Smalltalk web presence, from dynamic to static content, movies included. No Apache needed, Swazoo as integral part of Aida is there to serve directly to the web.
How do you bind port 80?
Running as a root. Danger for hackers to break into? Well, in Smalltalk hardly :)
Janko
2008/11/23 Janko Mivšek janko.mivsek@eranova.si:
Philippe Marschall wrote:
But let me as this question nevertheless. What alternatives are there for a "pure" Smalltalk Web presence? Currently my systems are mixture of Apache for static stuff and some other web servers to which Apache proxies (please bear with me that it's Ruby based ;-).
AIDA/Web apps/websites are running as pure Smalltalk web presence, from dynamic to static content, movies included. No Apache needed, Swazoo as integral part of Aida is there to serve directly to the web.
How do you bind port 80?
Running as a root. Danger for hackers to break into? Well, in Smalltalk hardly :)
Sorry but that's just not serious.
Cheers Philippe
Philippe Marschall wrote:
AIDA/Web apps/websites are running as pure Smalltalk web presence, from dynamic to static content, movies included. No Apache needed, Swazoo as integral part of Aida is there to serve directly to the web.
How do you bind port 80?
Running as a root. Danger for hackers to break into? Well, in Smalltalk hardly :)
Sorry but that's just not serious.
Definition of what is serious is very broad. Following blindly some "best practices" is not serious for me as well. Having a right feeling for a balance between many aspects of security, that's what I regard as a mature seriousness.
Best regards Janko
2008/11/23 Janko Mivšek janko.mivsek@eranova.si:
Philippe Marschall wrote:
AIDA/Web apps/websites are running as pure Smalltalk web presence, from dynamic to static content, movies included. No Apache needed, Swazoo as integral part of Aida is there to serve directly to the web.
How do you bind port 80?
Running as a root. Danger for hackers to break into? Well, in Smalltalk hardly :)
Sorry but that's just not serious.
Definition of what is serious is very broad. Following blindly some "best practices" is not serious for me as well. Having a right feeling for a balance between many aspects of security, that's what I regard as a mature seriousness.
I have seen aritrary remote code execution vulnerabilities in Squeak in there is no telling of how many there are left.
Cheers Philippe
Philippe Marschall wrote:
AIDA/Web apps/websites are running as pure Smalltalk web presence, from dynamic to static content, movies included. No Apache needed, Swazoo as integral part of Aida is there to serve directly to the web.
How do you bind port 80?
Running as a root. Danger for hackers to break into? Well, in Smalltalk hardly :)
Sorry but that's just not serious.
Definition of what is serious is very broad. Following blindly some "best practices" is not serious for me as well. Having a right feeling for a balance between many aspects of security, that's what I regard as a mature seriousness.
I have seen aritrary remote code execution vulnerabilities in Squeak in there is no telling of how many there are left.
Surely I'm not the only one who like to hear more concretely about those vulnerabilities and how you can exploit them through the web.
Janko
2008/11/23 Janko Mivšek janko.mivsek@eranova.si:
Philippe Marschall wrote:
> AIDA/Web apps/websites are running as pure Smalltalk web presence, > from > dynamic to static content, movies included. No Apache needed, Swazoo > as > integral part of Aida is there to serve directly to the web.
How do you bind port 80?
Running as a root. Danger for hackers to break into? Well, in Smalltalk hardly :)
Sorry but that's just not serious.
Definition of what is serious is very broad. Following blindly some "best practices" is not serious for me as well. Having a right feeling for a balance between many aspects of security, that's what I regard as a mature seriousness.
I have seen aritrary remote code execution vulnerabilities in Squeak in there is no telling of how many there are left.
Surely I'm not the only one who like to hear more concretely about those vulnerabilities and how you can exploit them through the web.
Details do not matter at all for this argument. The only that matters is that it is simple to write Smalltalk (!) code that is vulnerable to remote code execution, that this is not theoretical and has been done in practice and there is no telling of how much more vulnerable code there is. That is all that matters in the argument whether it is a good idea to run a Smalltalk service as root.
Note that this does not include all the C code that runs as root as well when you run a Smalltalk service as root. Stuff that comes to my mind: - the VM - the plugins - any libraries you call like imagemagick - anything you might call over OSProcess - ... As we see Smalltalk morphing more from a programming language to a scripting language, meaning relying more and more on C instead of Smalltalk (OpenDBX, Cario, GStreamer, FreeType ...) the amount of vulerable code (C is vulnerable by definition) only increases.
This ends my argument about running anything as root.
Cheers Philippe
Philippe Marschall wrote:
I have seen aritrary remote code execution vulnerabilities in Squeak in there is no telling of how many there are left.
Surely I'm not the only one who like to hear more concretely about those vulnerabilities and how you can exploit them through the web.
Details do not matter at all for this argument. The only that matters is that it is simple to write Smalltalk (!) code that is vulnerable to remote code execution, that this is not theoretical and has been done in practice and there is no telling of how much more vulnerable code there is. That is all that matters in the argument whether it is a good idea to run a Smalltalk service as root.
Note that this does not include all the C code that runs as root as well when you run a Smalltalk service as root. Stuff that comes to my mind:
- the VM
- the plugins
- any libraries you call like imagemagick
- anything you might call over OSProcess
- ...
As we see Smalltalk morphing more from a programming language to a scripting language, meaning relying more and more on C instead of Smalltalk (OpenDBX, Cario, GStreamer, FreeType ...) the amount of vulerable code (C is vulnerable by definition) only increases.
This ends my argument about running anything as root.
All C code is "protected" by Smalltalk, because you can explore VM and plugin vulnerabilities only through Smalltalk. Of course you can intentionally or unintentionally write such Smalltalk code, but this is another story.
From web viewpoint there is another layer of protection: web server + web framework and its security. If web framework is secure enough then don't see any other way except web application itself to let allow the intruder in.
Janko
Hi Janko,
on Sun, 23 Nov 2008 14:13:16 +0100, you wrote:
Philippe Marschall wrote:
> AIDA/Web apps/websites are running as pure Smalltalk web presence, > from > dynamic to static content, movies included. No Apache needed, > Swazoo as > integral part of Aida is there to serve directly to the web. How do you bind port 80?
Running as a root. Danger for hackers to break into? Well, in Smalltalk hardly :)
Sorry but that's just not serious.
Definition of what is serious is very broad. Following blindly some "best practices" is not serious for me as well. Having a right feeling for a balance between many aspects of security, that's what I regard as a mature seriousness.
I have seen aritrary remote code execution vulnerabilities in Squeak in there is no telling of how many there are left.
Surely I'm not the only one who like to hear more concretely about those vulnerabilities
You mean by listing things like "hacker can smuggle in code" you arrive at the whole list of possible vulnerabilities? If so, why are so many new attack forms and their variants still appearing.
There's only one law related to attacks, and it is an instantiation of Murphy's law.
and how you can exploit them through the web.
That's never going to be stopped, that is for sure. And it makes more fun to get rid of running services as root than being thrown out by a customer.
I do not want to see a headline like "Smalltalk system responsible for vulnerabilities", and how about you?
/Klaus
Janko
Klaus D. Witzel wrote:
Surely I'm not the only one who like to hear more concretely about those vulnerabilities
You mean by listing things like "hacker can smuggle in code" you arrive at the whole list of possible vulnerabilities? If so, why are so many new attack forms and their variants still appearing.
There's only one law related to attacks, and it is an instantiation of Murphy's law.
and how you can exploit them through the web.
That's never going to be stopped, that is for sure. And it makes more fun to get rid of running services as root than being thrown out by a customer.
I do not want to see a headline like "Smalltalk system responsible for vulnerabilities", and how about you?
Too big care is as bad as too little care here. Your door in your house is also locked with a lock which a determined "hacker" can break-in in seconds (believe me, I saw that with my own eyes). But you don't care much, because probability for this to happen is so low that it is not worth additional security measures. Home door is a good metaphor for "just appropriate" computer security as well. Don't exaggerate with security, but also don't neglect it, this is my moto and so far it worked. For 12 years already.
Smalltalk systems are inherently more secure by design, but ok, everyone can always run behind Apache as non-root if he wish.
Janko
On Sun, 23 Nov 2008 15:45:31 +0100, Janko Mivšek wrote:
Klaus D. Witzel wrote:
Surely I'm not the only one who like to hear more concretely about those vulnerabilities
You mean by listing things like "hacker can smuggle in code" you arrive at the whole list of possible vulnerabilities? If so, why are so many new attack forms and their variants still appearing. There's only one law related to attacks, and it is an instantiation of Murphy's law.
and how you can exploit them through the web.
That's never going to be stopped, that is for sure. And it makes more fun to get rid of running services as root than being thrown out by a customer. I do not want to see a headline like "Smalltalk system responsible for vulnerabilities", and how about you?
Too big care is as bad as too little care here. Your door in your house is also locked with a lock which a determined "hacker" can break-in in seconds (believe me, I saw that with my own eyes). But you don't care much, because probability for this to happen is so low that it is not worth additional security measures. Home door is a good metaphor for "just appropriate" computer security as well.
This only tells me that you do not really consider the many perspectives when you define "secure". The easiest attacks (preparations unnoticed by Janko) are made from within the house, and it's *you* who is keen to bring them in.
Example: someone puts #evaluate: into Integer>>#readfrom: and you upgrade the web framework to the next release which now has the troyan behind the wall. Abandon all hope once you enter that house.
More elaborate example: someone does no change like in the previous example but studies realeases and finds wholes in the code as is.
Don't exaggerate with security,
Running services as root is not related to exaggeration, it's a mistake.
but also don't neglect it, this is my moto and so far it worked. For 12 years already.
I'm doing secure systems since 1973 but wouldn't say that my expertise is better than that of 12 years. Murphy's doesn't count the years :(
Smalltalk systems are inherently more secure by design, but ok, everyone can always run behind Apache as non-root if he wish.
Okay, that's fair, so you had the last word :)
Janko
How do you bind port 80?
Running as a root. Danger for hackers to break into? Well, in Smalltalk hardly :)
I think security should be taken seriously, and better early that latter... here my two cents to the problem, not that I think this is a real solution, but it'll calm down those who care about running squeak as root (IMHO, once you got non-root access to a system, it's just a matter of time until you escalate to root, and again IMHO, Squeak and its applicacionts, present a big risk, if only, at least, because it has never been developed with security in mind).
On windows, you don't need administrative privs to bind to port 80, at least until a few versions ago (not sure in Vista). So, no need to run as 'root' on windows.
On Unix, you only need root privs to bind to port 80, so, of course, two options come to mind:
Use an external program to bind to port 80, and pass the connectio to Squeak (for example, Apach/lighttpd, maybe with fastCgi, what I find a VERY interesting option). Or some other small standalone program, that the executes Squeak passing the bound socket to the child squeavm process, where Squeak takes it from and uses it). This external program should drop privs before calling squeak.
Another, probably more integrated idea, whould be to drop privs from squeak after binding to port 80... and probably chrooting to another place. How? Here I'm attached a quick (5 minutes) interface to libc that'll let you do it. I tested it on Linux, and had to play tricks with libc.so so squeak finds it (I symlinked libs.so.6 (actually libc-2.7.so) to /usr/lib/squeak/3.9-8/libc.so [sudo ln -s /lib/libc-2.7.so /usr/lib/squeak/3.9-8/libc.so]).
Then, after importing the attached class, you can start playing with things like:
libc := Libc new. libc chroot: '/tmp' " disable changes file logging before doing it " libc setruid: 1000 euid: 1000 suid: 1000. self setrgid: 1000 egid: 1000 sgid: 1000.
with that, you are clear on this front. Again, I don't think this is the solution, the 'evaluate:' example Klaus sent earlier is for me the most clear danger, more than binary bugs in external libraries (although those are also problems)
anyway, adding 2 cents to the pot richie
Isn't there simple utils in unixes, which can simply redirect one port to another? You binding your app to port which doesn't requires root priviliges, but it works as 80 port. In particular, i don't see how apache is more secure than squeam vm. Security more depends on what you running as front end (framework in smalltalk , module in apache) not the basement.
2008/11/23 Gerardo Richarte gera@corest.com:
How do you bind port 80?
Running as a root. Danger for hackers to break into? Well, in Smalltalk hardly :)
I think security should be taken seriously, and better early that latter... here my two cents to the problem, not that I think this is a real solution, but it'll calm down those who care about running squeak as root (IMHO, once you got non-root access to a system, it's just a matter of time until you escalate to root, and again IMHO, Squeak and its applicacionts, present a big risk, if only, at least, because it has never been developed with security in mind).
On windows, you don't need administrative privs to bind to port 80, at least until a few versions ago (not sure in Vista). So, no need to run as 'root' on windows.
On Unix, you only need root privs to bind to port 80, so, of course, two options come to mind:
Use an external program to bind to port 80, and pass the connectio to Squeak (for example, Apach/lighttpd, maybe with fastCgi, what I find a VERY interesting option). Or some other small standalone program, that the executes Squeak passing the bound socket to the child squeavm process, where Squeak takes it from and uses it). This external program should drop privs before calling squeak.
Another, probably more integrated idea, whould be to drop privs from squeak after binding to port 80... and probably chrooting to another place. How? Here I'm attached a quick (5 minutes) interface to libc that'll let you do it. I tested it on Linux, and had to play tricks with libc.so so squeak finds it (I symlinked libs.so.6 (actually libc-2.7.so) to /usr/lib/squeak/3.9-8/libc.so [sudo ln -s /lib/libc-2.7.so /usr/lib/squeak/3.9-8/libc.so]).
Then, after importing the attached class, you can start playing with things like:
libc := Libc new. libc chroot: '/tmp' " disable changes file logging before doing it " libc setruid: 1000 euid: 1000 suid: 1000. self setrgid: 1000 egid: 1000 sgid: 1000.
with that, you are clear on this front. Again, I don't think this is the solution, the 'evaluate:' example Klaus sent earlier is for me the most clear danger, more than binary bugs in external libraries (although those are also problems)
anyway, adding 2 cents to the pot richie
On Sun, Nov 23, 2008 at 19:53, Igor Stasenko siguctua@gmail.com wrote:
Isn't there simple utils in unixes, which can simply redirect one port to another?
netcat (http://netcat.sourceforge.net) works like a charm for this. At my previous company we ran netcat from xinetd, to re-direct port 443 to 8443.
The correct way (which we did in production) is to have an iptables rule.
In particular, i don't see how apache is more secure than squeak vm.
True. Except that 50% of the web runs Apache. Its a bit more battle tested, I would say.
PS 50.43% this month. I expected 60%! http://news.netcraft.com/archives/2008/11/19/november_2008_web_server_survey...
Igor Stasenko wrote:
Isn't there simple utils in unixes, which can simply redirect one port to another?
Yes, that's an option that I thought of too, in fact, iptables will do the trick on Linux. However, you have to be careful here, because if the weapp thinks it's base URL is http://something:8000/ and it's public address is actually http://something/ there may be some desintelligences. Not that it can't be solved.
In particular, i don't see how apache is more secure than squeam vm. Security more depends on what you running as front end (framework in smalltalk , module in apache) not the basement.
well... it just is :) years of auditing, security in the mind of most developers in the team, dozens of bugs found and fixed, weak points in squeak (I'm not really talking of the VM, I'm putting the emphasis first in vulnerable Smalltalk code, and only then in native code (vm, plugins, external libraries, etc).
richie
Gerardo Richarte wrote:
Another, probably more integrated idea, whould be to drop privs fromsqueak after binding to port 80... and probably chrooting to another place. How? Here I'm attached a quick (5 minutes) interface to libc that'll let you do it. I tested it on Linux, and had to play tricks with libc.so so squeak finds it (I symlinked libs.so.6 (actually libc-2.7.so) to /usr/lib/squeak/3.9-8/libc.so [sudo ln -s /lib/libc-2.7.so /usr/lib/squeak/3.9-8/libc.so]).
Then, after importing the attached class, you can start playing withthings like:
libc := Libc new. libc chroot: '/tmp' " disable changes file logging before doing it " libc setruid: 1000 euid: 1000 suid: 1000. self setrgid: 1000 egid: 1000 sgid: 1000.
with that, you are clear on this front. Again, I don't think this is the solution, the 'evaluate:' example Klaus sent earlier is for me the most clear danger, more than binary bugs in external libraries (although those are also problems)
This is a solution I just contemplated during past hours and it is used by Apache as well, AFAIK. Very elegant one and from your code seems simple enough. Let me try by myself ..
Janko
Hi Richie,
I tried your code and it works nicely, thanks a lot! All I need now is to prepare an automatic procedure for Swazoo to start its HTTP servers on ports below 1024 then immediately drop the root privilege.
Only unsolved question remains how to add a server on a new IP or port, without restarting the whole image as root? I need to temporary login the image as root then logout. Can I do that through libc too?
Janko
Janko Mivšek wrote:
Gerardo Richarte wrote:
Another, probably more integrated idea, whould be to drop privs fromsqueak after binding to port 80... and probably chrooting to another place. How? Here I'm attached a quick (5 minutes) interface to libc that'll let you do it. I tested it on Linux, and had to play tricks with libc.so so squeak finds it (I symlinked libs.so.6 (actually libc-2.7.so) to /usr/lib/squeak/3.9-8/libc.so [sudo ln -s /lib/libc-2.7.so /usr/lib/squeak/3.9-8/libc.so]).
Then, after importing the attached class, you can start playing withthings like:
libc := Libc new. libc chroot: '/tmp' " disable changes file logging before doing it " libc setruid: 1000 euid: 1000 suid: 1000. self setrgid: 1000 egid: 1000 sgid: 1000.
with that, you are clear on this front. Again, I don't think this is the solution, the 'evaluate:' example Klaus sent earlier is for me the most clear danger, more than binary bugs in external libraries (although those are also problems)
This is a solution I just contemplated during past hours and it is used by Apache as well, AFAIK. Very elegant one and from your code seems simple enough. Let me try by myself ..
Janko
Janko Mivšek wrote:
Only unsolved question remains how to add a server on a new IP or port, without restarting the whole image as root? I need to temporary login the image as root then logout. Can I do that through libc too?
well... if after you dropped privs it was possible to regain them for you, it would be possible to regain them for an attacker with code executiong :) so, if we are doing things right, no, there's no way to become root after you dropped privs.
Now, if you are careful with your base URL, another option is, as Igor suggested, to use, for example, iptables to redirect port 80 to a higher port, and make squeak listen on a high port. For this you'll need an external helper program (setuid root), that lets you change in runtime the firewall rules from squeak.
Another option is to use a different external helper program, running as root, that will open the sockets for your non-root process, and then pass them around to the other process. In most OSes there's a way to pass FDs from one process to the other, as far as I remember, in Unix that's through a unix socket.
If you are interested in any of this two options, let me know, I'll try to find out the right magic.
richie
I have run squeak behind apache using a redirect in a .htaccess file, and it has worked very well. I am not sure how secure that is, ut it was easy, and it worked :) David Zmick /dz0004455\ http://dz0004455.googlepages.com http://dz0004455.blogspot.com
On Sun, Nov 23, 2008 at 5:51 PM, Gerardo Richarte gera@corest.com wrote:
richie
Philippe Marschall wrote:
AIDA/Web apps/websites are running as pure Smalltalk web presence, from dynamic to static content, movies included. No Apache needed, Swazoo as integral part of Aida is there to serve directly to the web.
How do you bind port 80?
You can use iptables to redirect the incoming port to one > 1024:
iptables -A PREROUTING -d 12.34.56.78 -p tcp --dport 80 -j DNAT --to-destination 12.34.56.78:8888
Cheers, - Andreas
Andreas Raab andreas.raab@gmx.de writes:
Philippe Marschall wrote:
AIDA/Web apps/websites are running as pure Smalltalk web presence, from dynamic to static content, movies included. No Apache needed, Swazoo as integral part of Aida is there to serve directly to the web.
How do you bind port 80?
You can use iptables to redirect the incoming port to one > 1024:
iptables -A PREROUTING -d 12.34.56.78 -p tcp --dport 80 -j DNAT --to-destination 12.34.56.78:8888
I'm really happy that my question has such an interesting run. Thank to all for that. I was very reluctant to just run something as root. I've not done it in the past and I won't surly not have a WebServer run as root. It's like a door besides you've hanged the keys.....
Regards Friedrich
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Danie Roux -
David Zmick -
Friedrich -
Gerardo Richarte -
Igor Stasenko -
Janko Mivšek -
Klaus D. Witzel -
Philippe Marschall