appspace pollution :)

[Chris Pressey]

On Mon, 11 Nov 2002 13:00:23 -0000
Sean Hinde <Sean.Hinde@REDACTED> wrote:

> Hi,
> 
> > - if there is an inherent flaw in all common web servers it 
> > is that they
> > serve objects from the filesystem - the same place the important stuff
> > (OS, programs, data, etc) is.  The use of chroot should be 
> > investigated
> > for having OpenFlax serve files.  The practice of serving 
> > objects from a
> > database (like the wikie) should be investigated.  The webserver code
> > would then never access the filesystem directly, but instead rely on a
> > database package (such as mnesia).  The drawback would be the 
> > extra effort
> > required to import the objects you wish to serve, into the database.
> 
> This what we do with all our O&M related inets content - it is stored as
> binaries (or templates with the static parts as binaries) in mnesia. We
> don't find the updating overhead too great given the existence of to_erl
> - esp:store("page.html").  or esp:store_all("/Directory/../"). do all
> the work.

Mnesia, or even ets, ought to work really well for lots of small files and
templates/data.  But serving from the filesystem is probably the best bet
for large files, is my feeling - unless you 'link' to them from the
database (or unless mnesia got a lot better at storing huge binaries
lately while I wasn't looking....)  The question is kind of academic,
though, seeing as you can just install both modules even if it introduces
administration messiness.

> > - security can always be improved by deleting modules.
> 
> Up to a point (os could probably go), but dangerous ones will remain
> (file!).

I guess I thought it was too obvious to mention also that functionality
can always be reduced by deleting modules  :)

> This is a big concern as Erlang creeps ever closer to living on the
> internet(Joe punching holes through his home firewall..) Is anyone aware
> of any detailed security analysis done on Erlang/OTP? For example there
> were vulnerabilities in zlib some time ago (fixed in R9B?).
> 
> Also various people have proposed things to lock down erlang
> distribution:
> 
> * Hacking net_kernel to implement a security policy (but it apears that
> quite a bit of stuff bypasses net_kernel anyway)
> 
> * Using the included ssl for distribution (nice between known hosts but
> still allows full access to all services once in)

I think encrypting the distribution communications is the best bet for
using Erlang on public networks.  What are the reasons for using SSL for
this purpose (besides its increasing ubiquitousness) when we already have
a system of cookies and a crypto module?  It strikes me as simpler to just
use the cookie for the encryption/decryption key.

> * Various works at SERC - mainly about non trusted code execution though
> some nice stuff about secured gen_servers
> 
> * Joe's recent :) statement that "We have done all the work but just
> haven't put it in yet"
> 
> It would be fantastically powerful to have a locked down distribution
> mechanism which looked like normal erlang message passing but only
> allowed access to specified services, processes, modules, functions,
> ports, code loading etc.

It would.  Things like being able to find out which process *actually*
sent you a given message (instead of trusting it to put it's own pid in
some element of a tuple) would be nice.

> > - {active, true} sockets should probably never be used on a public
> > network.  As nicely as they map to the Erlang programming 
> > paradigm, they
> > present too great a risk of flooding the Erlang runtime with 
> > messages. 
> > The only times my webserver has actually 'hard' crashed (as opposed to
> > processes 'soft' crashing) have been because of message overflow.
> 
> Check out {active, once}.

<troll>No!  Using undocumented functions is evil and wrong!</troll>

Actually, I'm just surprised that it hasn't found its way into the inet
man page yet.

{active, once} is pretty cool, but (speaking of "looking like Erlang
message passing") not quite as cool as sending back a synchronization
message to the port would be.  Although, it's probably not too hard to
write a wrapper process that provides that, I should try it sometime.

-Chris