Subject: Erlounge Schaumburg, XML vs UBF - msg#00108

Previous Message by Date: click to view message preview

Re: More restricted execution silly ideas

erlang@xxxxxxxxxxxxxxxxxxxx wrote: > > I think this is kind of the direction I had been suggesting earlier. > [snip bit about defining trusted module directory] > > When a module is loaded, if it comes from a "trusted" directory, > > the code server loads it as is. > > How about if we just allow OTP contents, and then cherrypick from those > which actual calls we will permit? I thought about that one, but then you are constrainted to providing only some features of OTP which are considered safe, and what do you do with the rest? Ignore it? What if I chose to offer most of mnesia (the user functions, mnesia:transaction, mnesia:match_object), but not the dets or ets module? I thought about this case last night while grilling dinner, and realized that a .erl + parse_transform -> safe_.beam is the only way to go and still save performance. The "administrator" can define what modules and functions are trusted to be called from untrusted code, what should go through a security_manager module (as I've described), and what should be flagged as illegal operations at compile time, preventing compile from occuring. > > If the module is from an untrusted directory, the code server > > rips apart the .beam file and begins to "verify" it: > [snip approval algorithm] > > Basically we allow 'system' code to run without penalty, and allow user > > 'unsafe' code to run with minimal penalty, basically anytime they want > > to access external resources. Basic calls to stdlib such as lists, > > sets, dict are all allowed as-is. Its ets, file, code, message sending, > > modifying the process dictionary, etc that are slower. By putting all > > calls through a security_manager module, the security_manager can > > decide how a call should react, and can either emulate the real call, > > or check access (based on arguments, etc) and forward or exit/1 as > > necessary. > > This seems a bit overhead-rich. The idea (to me, at least) is that if > one can simply define a standard subset of standard functions which can > be permitted (typically, aside from message passing and spawn/3, anything > which has particular side-effects with reference to machine state), then > this subset can be permitted without any interference at runtime, which is > good for things like realtime behaviour. Ultimately, the execution becomes > more functional, in the sense of isolation from side effects, until the > program hands back the answers in the form of messages. I think the end result allows overhead only where necessary. What if I want/need to offer the ability to read/write files in directory A, but disallow all access in any other directory? There must be a runtime check, and adding that check to file:open and dets:open through a dynamic security_manager module would be the way to do it. But the rest of the dets: routines could be allowed to stay exactly as-is. There is a concern that dynamic module calls have to always go through the security manager, and this will slow down the call. Is M:F(A,B) today faster than apply(M, F, [A,B])? Because if so, I was going to have the security_manager module implement something like: call(M,F) -> M:F(). call(M,F,A) -> M:F(A). call(M,F,A,B) -> M:F(A,B). call(M,F,A,B,C) -> M:F(A,B,C). call(M,F,A,B,C,D) -> M:F(A,B,C,D). callv(M,F,ArgList) -> apply(M, F, ArgList). So its not as ugly. I contend you won't get safe execution without losing some performance in some areas of the application, but you can still have the security_manager provide a soft-realtime bound on the overhead it adds. > In addition, I'm unsure why analysis of .beam files would be really preferable > to analysis of .erl files ... The only advantage of a .beam file is I can receive code from over the network which I did not compile locally. But given that Erlang/OTP is usually only sent in source form between parties, doing analysis of .erl files is acceptable. > If one were to simply slurp through standard erlang/OTP source code, and > ruthlessly mutilate anything with outside references beyond, say, messages, > then one could pretty much guarantee that what happens inside the virtual > machine is the concern of that program and its spawn only (load on available > resources notwithstanding). I'd rather not get into rebuilding OTP to be safe. OTP is big, and most likely we'll never be able to keep up with the entire erlang kernel, stdlib, plus OTP and all standard applications. Not to mention that gutting them may remove critical functionality. What if I need to use ets tables for performance, as they are used only as lookup tables by my "untrusted" code, while other code which is trusted can send messages to the ets table owner to update the table? -- Shawn. Nondeterminism means never having to say you are wrong.

Next Message by Date: click to view message preview

The reason WHY OO sucks

Dear Joe, dear Erlangers, let me return once more to the "Eppur si sugat" thread. A number of things have recently moved me to sum up a few of my thoughts about OO vs. FP, which I would like to share with you. What do you think about this? ** In OO, it is often pretty difficult to decide where to attach a method which is not tied to an object by logical necessity; and when there is a pyramid of objects always appearing together, shall we attach a method to the higher components (wool = shepherd.shear( shepherd.sheep[ n ] )) or to the lower ones (wool = shepherd.sheep[ n ].shear(), or rather wool = shepherd.sheep[ n ].get_shorn())? Does the shaving method logically belong to the sheep (get_shorn) or to the shepherd (shear)? For example, the proper placement of a ``dice'' wrapper function built around the system random generator is a matter of creed. From outsourcing it into a different module to implementing it separately in every object type, all things are possible and equally justificable. The textbook example for OO programming -- a presentation or graphics program where a ``redraw yourself now'' message is sent to all the objects in memory upon receippt of a window event (for graphical_object in object_list: graphical_object.redraw()) -- emphasizes the advantages of the latter, but it is of fallacious simplicity. Actions which affect one shred of data only, like the redraw message, are not that frequent; most things happening inside a program establish some kind of relation between previously unconnected items of data. Moreover, most real-life agglomerates of data are less clearly discriminable than a simple list or array of graphical objects. Apart from the problem with shear, does it make sense to place the sheep array directly in shepherd, or is it preferable to create an intermediate level shepherd.flock? Are there any attributes, modofications or accidentia which belong to the flock as a whole without affecting the individual sheep? In the Middle Ages, half a millenium of philosophical debates was wasted on this question, and the solution agreed upon in the end (Abaelard's) bears all the hallmarks of a silly compromise. Human thinking is based upon the concept of an action flowing from a subject to an object; ever since Kant's times, the phrase ``The sun warms the stone'' has been used as the favourite example for this, and it was Schopenhauer who traced this back to the dependence of human thinking on causal connections: Observation 1 -- the sun shines upon the stone; observation 2 -- the stone gets warmer; causal connection -- the stone gets warmer because tthe sun shines upon it; (re)construction of an action -- the sun warms the stone. This notion is therefore so dominant that even statements where no action is described are formed by projecting the content upon auxiliary verbs such as ``to have'' or ``to be'': Remus erat vir fortissimus, Remus was a hero -- the Latin version shows that a ``nominative object'' is needed for this projection. Still the ``active'' nature of the stattement is there, and the thing may even be put into the passive voice, odd though that appears -- the normal Sanskrit form for expressing the past is by means of a passive participle: Ramena bhuto virah, literally ``By Ramah [was] performed the hero-being''. OO programming, however, does not fully acknowledge this. In OO, the basic structure is reflexive, as in graphical_object.redraw(). It is the subject of the action whose state may be changed by the invocation of a method, not the optional object which may be passed as a parameter to the method! Thus, the common x.y(z) formula does not mean ``x does y to z'' but ``x is modified by y'ing z''. This must be kept in mind when dealing with OO. Personally, I prefer a structure which emphasizes the predicate, such as wool = map( shear, shepherd.sheep ) and thus keeps apart things and actions. (Haskell type declarations were chosen to represent currying, but they also indicate the logical direction, even though Haskell rejects the concept of action: shear::Animal->Product and tend::[Animal]->(Animal->Product)->[Product].) Using this approach, shear may be passed as a functional parameter without the need for a subject. Who cares about the shepherd? Let him go to the pub as long as somebody will shear his flock for him. His state is not altered by the action (as he probably won't shear himself), so there is no need for him to be involved. It's the wool we are interested in. In general, data should be considered as an attachment to code, not vice versa. Though being an OO language, Python partly takes this into account by ``defining'' variables only by assignment. In this respect, it is very different from -- and superior to -- C++ and Java. ** Maybe this will be good as a bit of "selling ammunition", or at least to stimulate a few discussions... Lookign forward to hearing from you, Ruediger Marcus Flaig Am Dienstag, 3. Juni 2003 23:19 schrieben Sie: > Hi Ruediger, > > Nice mail, I like the bit about orks ... :-) > > My latin/Italian is non-existent - I wanted > to say "and yet it still sucketh" ... > > I entirely agree re: java C++. IMHO the *important* thing is > total isolation between "things" and "pure message passing" - hence Erlang. > > The language for sequential computations is irrelevant. > > I build systems from "communicating black boxes". COPL etc *is* the point > only achieved in languages like Erlang/Oz/Occam/PLITS > > cheers > > /Joe > > On Thu, 29 May 2003, Dr.Dr.Ruediger M.Flaig wrote: > > Hi all, > > > > from my bit of Italian, I think it ought to be "Eppur suga" -- the Latin > > -t is dropped in the 3rd person singular AFAIK, and it is certainly not > > reflexive... it does not suck itself, that were recursion. ;-))) > > > > Now for something more serious... I think the basic sentiment we all > > share is that Java sucks, and that C++ sucks. They do, and very badly > > too, and it is annoying to see that they have become a kind of de facto > > standard. > > > > I have used both (more than Erlang, I am afraid -- as a molecular > > biologist, I have to deal with megabyte arrays, and that is not quite > > what Erlang was designed for -- sinner repent -- well Ocaml is quite nice > > too ;-) ), and I am equally fed up with the cobolesque boilerplate of > > "private final static paralyzed karl.otto.gustav emil = > > (karl.otto.gustav) ((egon.kasimir) foo.bar().blah[anything])" and the > > orkish scrawls of > > "#define n<m>(x,i,j) {*++(*x)->y %= (i>j)?&i--:--&j}", not to mention > > memory leaks and, and, and... Maybe OO itself does not suck but a concept > > without implementation is void. > > > > But I think we are missing the point. The important thing is not that OO > > is an inferior concept but that FP (or COPL, if you please) is a superior > > one. Erlang were still great even Stroustrup and Gosling had never come > > near a computer -- because it enables you to be productive, to write > > clear and concise code, to cope with errors and, last but not least, > > because it allows reasoning. > > > > This latest thing is what I have really been missing. Erlang is a > > functional language, so it should be possible to employ automatic theorem > > provers and all that kind of stuff. Cummings wrote about ML: "We are not > > trying to develop 'safer' programs by testing, but developing SAFE > > programs by reasoning." This is a very philosophical matter. Let me say > > that Java and C++ rely on induction, Erlang allows deduction, and Sir > > Karl Popper has said the rest about that, decades ago. So are there any > > theorem prover > > s for Erlang, as there are for Lisp and ML? Can we prove a program's > correctness by reasoning? If not, let's do that! > > > The other point is that the power of Erlang's concurrency is often > > underestimated by folks who are not interested in parallelism itself. I > > am a complete layman to that field but I think that neuronal networks > > would be a great thing do with Erlang. Has anybody tried this before? Are > > there any projects in similar fields? Personally, I was attracted to > > Erlang because I felt that simulation of complex biological processes > > would be easy to implement. Imagine you have a microbe with some 4000 > > genes, each with > > a state of activity and each influencing a couple of others. In Erlang, > this would be straightforward... I met a guy who did the like and spend a > year on that programming the basic mechanism in Java! So I think we could > get away from that "Erlang? Oh, that's for telephones only" image. > > > Has anybody worked on this yet? > > > > > > SkÃÂl, > > Ruediger Marcus Flaig > > > > > > > > > > Dr. Dr. Ruediger Marcus Flaig Institute for Immunology University of Heidelberg Im Neuenheimer Feld 305 D-69120 Heidelberg <flaig@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> Tel. +49-172-7652946 | +49-6221-56-5402 | +49-6221-432963 _____________________________________________________________ Free eMail .... the way it should be.... http://www.hablas.com _____________________________________________________________ Select your own custom email address for FREE! Get you@xxxxxxxxxxxxxx, No Ads, 6MB, IMAP, POP, SMTP & more! http://www.everyone.net/selectmail?campaign=tag

Previous Message by Thread: click to view message preview

More restricted execution silly ideas

I had another thought on implementing a restricted execution environment for untrusted erlang code: How about, instead of trying to lock down an erlang virtual machine, instead putting the erlang code presented through a cleanser which pulls out any functions which are regarded as unsafe? Code which doesn't refer to anything unwanted passes through and is executed without a murmur. The rest is hacked up, probably won't even compile, and is left to bleed, or returned without running? Or simply specify a limited set of functionality, and inspect incoming code for violations? I suspect this might be easier than hacking up OTP and erlang.

Next Message by Thread: click to view message preview

Re: Erlounge Schaumburg, XML vs UBF

Hal Snyder <hal@xxxxxxxxxxx> writes: > UBF Disadvantages > > 2. Unproven. Surely at least UBF(A) _is_ proven, since it's just term_to_binary in disguise (and term_to_binary is wonderful!) > 4. S-expression closing tag problem. What's that? Cheers, Luke