[squeak-dev] smalltalk and Web stuff

> 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

>
> 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
>
>
>

>>>>>> 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.

> 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

> 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.

>> 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 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.

>
>>>
>>> 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
>
>
>
>

>     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)