<ixelp>
GitHub - s-expressionists/Clostrum: First Class Global Environments
pequod has joined #commonlisp
<bike>
can i ask what you want to use jailing for?
<Shinmera>
mrcom: it's called using a container
<mrcom>
I'm looking for something finer-grained. Want a secure DSL which permits arbitrary CL (or a subset) that can't subvert higher-level constraints.
grawlinson has joined #commonlisp
<Shinmera>
it is extremely hard to do something like that without making it useless or insecure.
<Shinmera>
I know this isn't what you want to hear, but I would suggest considering avenues that don't involve ACE.
cage has joined #commonlisp
<mrcom>
Probably.
Pirx has joined #commonlisp
<Shinmera>
one solution might be to provide your data via an external process that sticks around and bridges to a container that you spin up for ACE, with some user functions to use that controlled bridge.
<mrcom>
Slime, in other words.
<Shinmera>
no, slime provides a bridge for ACE itself.
<mrcom>
OK, Slynk.
<Shinmera>
no?
<Shinmera>
slynk is the same thing
<Shinmera>
I'm proposing a standard external API through some socket or whatnot that has controlled calls the user can access
<mrcom>
Well, Slynk is the ACE environment, Slime/Sly talks to it.
<bike>
some of the clostrum related stuff we're doing might work for this. but it is as of yet untested.
<Shinmera>
still no
<mrcom>
Does clostrum address control of runtime environment? Reader-level stuff is conceptually straight-forward.
<Shinmera>
the point is to remove the A from ACE and reduce the interface that needs to be secure to a set of functions that can reasonably be proven to be secure.
<Shinmera>
when you have those assumed secure function entry points in a separate process, you can then spin up a container with a connection to that API.
<bike>
clostrum provides a runtime environment. you can build an environment that has no file I/O functions or whatever, and no functions to access the host environment which could bypass that, and there you go.
<bike>
assuming you have something to actually evaluate code in those environments, which is the hard part we've been working on.
<mrcom>
That's what I was meant with Sly/Slime/Slynk--arbitrary CL code can't affect the superior enviroment (e.g. elisp).
<Shinmera>
but you're still shoving arbitrary code lines over the wire
<Shinmera>
the point is to not do that
<bike>
that's a bit different. "environment" in that sense means like, different processes.
<bike>
i meant environment in the CL sense of a set of bindings.
<bike>
and if you use sly or whatever but pass arbitrary code over the wire, that arbitrary code can do file I/O or whatever else that you'd like to prevent.
<mrcom>
That's the crux--is it actually possible to guarentee the integrity of the higher-level environment without copying values to the contained envirornment?
<mrcom>
Didn't mean Slynk literally.
<mrcom>
But basically the same thing.
<bike>
is what you want to do just prevent the arbitrary code from making changes to the host, like redefining your functions or whatever? or do you actually want to constrain things as by making functions unavailable to the code being executed
<bike>
if you spin up another lisp and have it execute arbitrary code, obviously your host isn't going to have any of its functions redefined. but the other lisp can still destroy your hard drive or whatnot
<White_Flame>
I think that doing a white-list scan of symbols & packages in the read code would probably get you far
<White_Flame>
disallow intern, eval, etc
<White_Flame>
and no #.
<mrcom>
That's what I meant by reader-level being conceptually straight-forward.
<White_Flame>
right
<beach>
Eclector can provide a lot of help on the reader level.
<White_Flame>
although technically it'd be a post-read validation scan I'm talking about
<mrcom>
The problem is, what kind of mischief is possible if you can look at arbitrary objects?
<White_Flame>
the only garbage that would be created from a no-read-eval standard read would be symbol creation
<mfiano>
Also there is a (reported by me) bug in JSCL that makes the process go unresponsive when entering something like 1d999
<mrcom>
(You'd have to change the reader--disallow reader-time eval for example)
<mrcom>
How do I prevent *read-eval* being modified in the sandbox?
attila_lendvai has joined #commonlisp
<mrcom>
Even modifying a thread-local, sandbox-only copy would be game-over.
<White_Flame>
disallow READ ;)
<White_Flame>
or don't put CL:*READ-EVAL* in the whitelist of the post-READ validation of your untrusted source
<mrcom>
And EVAL, and ... what else?
<White_Flame>
intern
<mrcom>
Yeah, INTERN too.
<White_Flame>
would have to scan through the spec to see what else. Obviously any implementation-internal package should be disallowed
<mfiano>
package blacklist for eg cffi
<Shinmera>
this is a wild goose chase and you will never run out of shit to block
<mfiano>
or finer grainer to prevent like overwriting the lisp address space
<White_Flame>
it would be interesting to see if you could determine what packages the untrusted code creates,and disallow anything else except whitelisted CL: functions
<mrcom>
Packages are a reader thing. We can shadow/control access at that level.
<mfiano>
might as well just rethink computing from the ground up
<White_Flame>
nah, I think it's possible
<White_Flame>
it's just that the untrusted code wouldn't be able to 100% of what CL can do in terms of environmental manipulation
<White_Flame>
which can leak into other useful things like intern
<Shinmera>
ok, just (loop (ignore-errors (make-array most-positive-fixnum))) and your lisp is gone
<Shinmera>
look ma, no "scary operators"
def_ident738 has joined #commonlisp
<White_Flame>
yeah, that one is not solvable
<mfiano>
or just 1d999 if your lisp sucks
<White_Flame>
without some form of memory region quota system
<White_Flame>
but it's not an access control issue, it's a non-spreading resource constraint
<mrcom>
OK, suppose I provide a shadow version of SET that carefully examines the target to ensure it's not something prohibited like the *standard-output* cell.
<Shinmera>
again, this is stupid and impossible to solve. the only thing that can get you anywhere near secure is OS-level hardening with containers and controlled container access, and a controlled API for communication.
<Shinmera>
but I can only repeat myself so many times so I will shut up now
<White_Flame>
you could launch a separate lisp process with the reader constraints to bound its memory/cpu/etc usage
<beach>
mrcom: In a Clostrum environment, you would just enter the variables and functions your code is allowed to use.
<beach>
mrcom: Or, did you discard the Clostrum option?
<mrcom>
I'm agreeing with you Shinmera, but hunting for a miracle.
<Shinmera>
there is none
<White_Flame>
it's all a balance of what you wish to protect vs black swans you would allow
<White_Flame>
I think protecting from access is doable, protecting from all crashes is not
<mrcom>
beach: One problem I see is that even safe versions of code, like my hypothetical SET shadow, must internally reference the real thing.
<beach>
That is not a problem.
<White_Flame>
also you'd have to somehow prevent (safety 0)
<beach>
bike: Perhaps we are not explaining first-class global environments very well.
<White_Flame>
as an access control mechanism
<mrcom>
Can I guarentee that sandboxed code can't grok the shadow to find the real code's atom, and call it directly?
<mfiano>
Not from a library
<mrcom>
Shinmera: Yeah, I know... no.
<beach>
mrcom: A Clostrum environment contains mappings from names to objects. You are in control of the mapping.
<mrcom>
beach: Yes, gathered that. Can a Clostrum environment make objects opaque?
<White_Flame>
objects by default are opaque if you can't see the accessors that get at its components
<beach>
mrcom: Sure. You just don't provide the functions to examine them, like DESCRIBE, INSPECT.
<beach>
mrcom: What White_Flame said.
<White_Flame>
however, if they are common object types like arrays, packages, lists, etc that you can get into, then it might leak
<mrcom>
beach: That's the whack-a-mole aspect. Why diabolical ways are there to circumvent that?
<White_Flame>
mrcom: I think (safety 0) would allow some severe access hacks
<beach>
mrcom: I don't understand. You need to enter every mapping into the environment that you want to provide.
<mrcom>
s/shy/what
<mrcom>
s/why/what. Sigh.
<beach>
mrcom: So there is no need to "circumvent" other then you yourself not providing those functions.
<beach>
mrcom: I am obviously not explaining this very well, so I'll stop now.
loke has joined #commonlisp
<mrcom>
beach: Can I use CAR to pull apart my mapped *standard-output*?
<White_Flame>
beach: for instance, if some special variable in the environment contained a hashtable value with a list containing a symbol with an underlying COMMON-LISP package, you could access anything within that
<beach>
Not if CAR is not in the environment. And you can map CAR to a function that does whatever you want.
<mrcom>
beach: Good heavens. You're talking about re-implementing everything.
<White_Flame>
right, so the protection is not just thre environment itself, but doing exactly the same sort of security engineering that was original discussed, where you have to look at the entire access surface and make tweaks
<beach>
White_Flame: Not if GETHASH is not available.
<beach>
mrcom: No, you import anything you don't need to modify, like +, =, etc.
<White_Flame>
so you can't use your own hashtables, lists, etc
<White_Flame>
because that might allow access to things deeply exposed in the firstclass environment
<mrcom>
beach: What does (+ x) return?
<White_Flame>
vs some form of foreign/bridge pointer that cannot be dereferenced
<mrcom>
Shinmera: OK, OK, I give up. It requires going down to the CL implementation level.
<beach>
mrcom: What kind of question is that? If X is a lexical variable containing a number, it returns that number.
grawlinson has quit [Quit: SIGTERM]
<beach>
White_Flame: I am not sure I understand. But, I seem unable to communicate what first-class global environments do, so I think I need to stop. Really, this time.
<mrcom>
beach: If it's a single argument, will the implementation just return X without checking it's type? What will (CAR (+ x)) do?
<beach>
mrcom: I give up. Sorry.
<White_Flame>
beach: no, I think it is a good discussion revealing the complexity of things
<White_Flame>
I beieve that exposing safe functions is generally safe
<beach>
mrcom: If you import + and CAR from the host, then it will do the same thing as in the host.
<White_Flame>
but exposing data in special variables can lead to leaking information to foreign environments
<mrcom>
The problem is that "safe function" is deceptively difficult.
grawlinson has joined #commonlisp
<beach>
mrcom: You seem to now be convinced that everything needs to be re-implemented. Not so.
<White_Flame>
mrcom: I think that evaluating all the CL: functions for which are safe is very tractable
<White_Flame>
however, the exception for (safety 0) is quite difficult
<White_Flame>
but again, if you have to rework CAR, GETHASH, etc to make sure they don't hit any external data that might be exposed in your environment, then it will still leak access liek a sieve
<beach>
White_Flame: Or, you can not make that data accessible through any special variable.
<White_Flame>
because of how fundamentally important those functions are in user lisp code
<White_Flame>
beach: I think that will prove challenging
<White_Flame>
but, I'm interested in seeing this problem tackled
<beach>
Oh, like not defining a particular special variable in the first-class global environment?
<mfiano>
I still have a hard time understanding some things about FCGEs, even after listening to beach for a long time. I don't think a complex topic is easily grasped with the explanation of a symbol mapping.
<White_Flame>
(as well as memory regions/quotas, and process-local memory, but that's a separate problem)
<White_Flame>
the topic of the environment is quite simple. the topic of access security with untrusted malicious code is not simple
<beach>
mfiano: You must be right, and I have been thinking about this for more than a decade, so I am very likely unable to get things across.
<mrcom>
beach: like not defing anything that *accesses* the protected special variables. Even indirectly.
<mfiano>
I learn better by doing and trying to break things. That could be why.
<White_Flame>
the fcge will work perfectlyw ith well behaved code
attila_lendvai has quit [Ping timeout: 264 seconds]
<beach>
mrcom: There is no such thing as a protected special variable. You just don't enter the special variable into the environment. Then it can't be accessed.
<beach>
mrcom: So any code that tries to do (print *SECRET*) will get an error saying *SECRET* is not a defined variable.
<White_Flame>
unless you can intern a variable, or grab it from some function return, or have an external macro that can wrap it around your code..
<beach>
White_Flame: Why would you allow code to do that if you want a sandbox?
<White_Flame>
again, well behaved code, vs code that's determined to needle through the wall
<White_Flame>
and you really don't know for absolute certain what all long-tail access you're allowing when you add a function/macro/variable to the environemnt
<mrcom>
beach: I provide a careful, sanitized version of WRITE-TO-STRING. It guarentees its arguments are safe.
<mrcom>
It doesn't reference *STANDARD-OUTPUT* or anything.
<beach>
mrcom: Yes, and?
<mrcom>
Unfortunately, the sandboxed code as read access to the sanitized WRITE-TO-STRING.
<mrcom>
How do I guarentee it's impossible to pull that apart and find the real WRITE-TO-STRING reference?
<mrcom>
CL is really, really good at treating code as data.
<beach>
Because in the first-class global environment, the symbol WRITE-TO-STRING is mapped to your function, and there is no trace of the standard function.
<mrcom>
What does (CAR x) return, where x has been set to the sanitized WRITE-TO-STRING?
<mfiano>
mrcom: perhaps what is confusing you, is that with first-class global environments, the implementation provides this feature. You cannot think of this in terms of library code for portable Common Lisp programs.
<beach>
mrcom: If you import CAR, then an error.
dcb has joined #commonlisp
<White_Flame>
if the sanitized WRITE-TO-STRING is a function object, then (car x) would be a type error :-P
<mrcom>
How do you know it's an error? That depends on the implementation of function objects.
<beach>
mrcom: The host CAR function is required to signal an error if given a function.
pfdietz has quit [Quit: Client closed]
<beach>
mrcom: I don't care. Both lists and function objects are host objects. I don't provide those.
<beach>
mrcom: The first-class global environments provides only the mapping.
<beach>
def_ident738 has quit [Ping timeout: 255 seconds]
<White_Flame>
mrcom: it only depends on if CAR can determine that its argument is not a list or NIL
<bike>
it is permissible for functions to be structure objects.
Gleefre has joined #commonlisp
<bike>
i don't know that they actually are in any existing implementations.
<bike>
in sicl functions will be standard objects, i think.
<beach>
Funcallable standard objects, to be precise.
<mrcom>
I don't know either. Which is the point. Can I guarentee a) I've covered all the diabolical corner cases, and b) the implementation actually cares.
<bike>
yeah.
<bike>
b is really easy. you run ansi tests and there you go.
<mrcom>
Is there really an ANSI test that checks you can't CAR, or FIRST, a function?
<beach>
mrcom: Can we guarantee that any code is correct? Not if it is a slight be complex, no.
<bike>
Yes
<beach>
mrcom: Yes, check the ANSI test suite.
<bike>
there's like, tens of thousands of tests in there.
<bike>
why is it a concern that CAR might suck this obviously?
<beach>
I had not anticipated that this would be so hard when I suggested first-class global environments.
dcb has quit [Quit: MSN Messenger 4.0.5]
<bike>
ansi tests actually has some specific tests that lists aren't usable as functions, since that's a change from CLtL.
rtypo has joined #commonlisp
<mrcom>
bike: Because I'd like to use CL as a sandboxed DSL which is obvsiously secure.
<mrcom>
Obvious, because I'm not as smart as the guy trying to break me.
<bike>
"obviously" is going to be difficult because CL is huge
<bike>
but you can set up a first class environment with only "obviously" okay bindings and then you'll only need to worry about the infinite loop stuff that was mentioned earlier. which i think i could probably block with cvm, but i haven't tried
rgherdt_ has joined #commonlisp
<mrcom>
Well, the size is tractable. We can permit a limited subset. The problem is with the basics.
<beach>
Given that I have about zero evidence that what I am trying to explain actually makes sense, I think I need to stop.
<mrcom>
Bindings are tractable, too. Beach's FCGE would take care of that, or a custom reader.
<bike>
that's what i said, yes
greaser|q has joined #commonlisp
<mrcom>
Basically, I need to prove the equivalent of (CAR x) (or FIRST, or ...) can't look at forbidden stuff, even after following an indirect chain.
igemnace has quit [Read error: Connection reset by peer]
<bike>
i don't understand this concern about basics. if your CAR doesn't signal an error given a function it's broken and your implementation is pretty terrible. none of them are actually that terrible. CL implementations are not perfect but the problems are more obscure.
<mrcom>
I can't even prove that SET can't modify.
<mrcom>
bike: (CAR function) was an example. How about FIRST?
<mrcom>
Or one of the structure functions.
<bike>
first is just as basic as car.
<bike>
i think your threat model is kind of bizarre.
rgherdt has quit [Ping timeout: 255 seconds]
<bike>
in a first class environment, there'd be a definition of SET that only modifies variables in that environment, so no problem there.
<bike>
or you could just not have SET.
<mrcom>
Seriously?
<bike>
seriously what?
<mrcom>
No SET?
<bike>
yes? who uses set? do you mean setf or setq?
<bike>
but again, if you want set it's easy to provide.
<mrcom>
Same thing.
<bike>
setf and setq would also have provided definitions that only access the environment.
<mrcom>
And there are a ton of other basics that modify an argument internally.
<mrcom>
INCF.
<bike>
there actually aren't very many operators that modify environments. there are plenty that _read from_ them implicitly, like anything with a function designator
<bike>
incf is defined in terms of setf. it's like, five lines. i've actually written a first class environment version of that myself.
def_ident738 has joined #commonlisp
<mrcom>
The basic problem is that every. single. reference. to something would need to check whether the actual, run-time thing is something forbidden.
<beach>
mrcom: I think you should consider that first-class global environments are not for you.
<bike>
no it wouldn't.
<bike>
the first class environment doesn't make any forbidden functions available. you cannot access them through bindings.
<bike>
(fdefinition 'destroy-system) tells you unbound function.
<bike>
if your environment doesn't provide functions to tear apart functions, and why would it, there's no way to access forbidden fields of a function.
bendersteed has quit [Quit: bendersteed]
<mrcom>
Let us supose we've rigourously proven that function objects are indeed safe and opaque, in all reasonable implementations.
<mrcom>
What does (rplcar *modules* foo) do?
<bike>
what is rplcar?
<bike>
oh do you mean rplaca
<bike>
well, it would change the car of *modules*, of course.
<bike>
assuming *modules* is bound in this environment.
<White_Flame>
ideally it would yell at you for accessing a deprecated variable ;)
<bike>
the first class environment could provide its own binding for *modules*, so that would be modified rather than the host *modules*.
<bike>
that too.
igemnace has joined #commonlisp
<White_Flame>
bike: only if you ensured that multiple environments didn't accidentally share cons cells in that value
<mrcom>
True. What about our opaque function running in the context of the sandbox?
<bike>
which opaque function? rplaca?
<bike>
White_Flame: i really don't think that would be hard to arrange.
<White_Flame>
right, but it is definitely a consideration that must be considered
<bike>
sure.
zxcvz has joined #commonlisp
<White_Flame>
and who knows, in some cases it might be desirable to have a shared mutable variable between environments for some reason
<mrcom>
No, our safe opaque version of EVAL, or LOAD, or ...
<White_Flame>
*shared mutable object
<bike>
CL has maybe a few dozen special variables and most of them don't contain mutable compound structures anyway.
<bike>
mrcom: I'm not sure what you're asking. What (eval '(rplaca *modules* foo)) would do? It would modify the cons of (the first class environment's) *modules* to have a car that's (the first class environment's) value of FOO.
saturn2 has quit [Ping timeout: 248 seconds]
remexre has quit [Ping timeout: 255 seconds]
<mrcom>
bike: The point is, is there anything that could be modified that would trip up our nicely safe, opaque, shadowed functions. Or common external libraries.
<White_Flame>
huh, yeah only 45 special vars, outside the REPL-specific vars
<White_Flame>
* ** etc
<mrcom>
*print-pprint-dispatch*, for example.
saturn2 has joined #commonlisp
simendsjo has quit [Ping timeout: 246 seconds]
msavoritias has joined #commonlisp
remexre has joined #commonlisp
<mrcom>
Hmm.. maybe not so bad after all.
<bike>
the only standard operator that mutates the contents of *print-pprint-dispatch* is set-pprint-dispatch, i think?
wonko-the-sane has quit [Ping timeout: 252 seconds]
<mrcom>
The IO special vars might be pretty ugly. Implementation dependent vars would be a problem.
<bike>
what would be the problem?
<White_Flame>
of course, one big question is that if you call some function from your environment that's been set externally, should that function reference your environment's special vars or its original one? But that would be part of the protocol.
<bike>
i mean, i was thinking of this as the first class environment only providing standard stuff, so implementation variables would not be accessible.
dcb has joined #commonlisp
<beach>
White_Flame: If you import a function from the host, it would have to use the Clostrum protocol in order to access the first-class global environment.
<mrcom>
White_Flame: treat similar to thread-local; use the sandbox.
<White_Flame>
yeo
<White_Flame>
yep
<mrcom>
bike: I could see not providing *standard-output* breaking a lot of 3rd party libs.
<bike>
oh, i meant the problem of implementation dependent variables. IO variables could certainly be ugly.
<White_Flame>
but SLIME already tackles that sort of things
<White_Flame>
in terms of compartmentalizing IO
<White_Flame>
it's not a new issue
<mrcom>
Yeah, but slime is a whole separate environment. Very little provided from the outside.
<beach>
mrcom: If you have defined a sandbox environment, then it is very likely that pretty much every external library will break.
<mrcom>
I'm thinking of a DSL that does things like provides secure and limited database access.
<beach>
mrcom: There is no reason to believe that a random external library would restrict itself you the particular sandbox operations you have chosen.
<mrcom>
beach: yeah.
<beach>
mrcom: So bringing up external libraries is kind of strange. Because no matter what way you use to define your sandbox, you probably wouldn't be able to load them in that environment.
<Brucio-61>
why would library code that happens to be needed in the lisp image have to use the same environment as the code generated from the DSL program?
<bike>
for something like database access i wouldn't't think you should have arbitrary code execution... but i'm not a databases person
<beach>
Brucio-61: It wouldn't.
<mrcom>
beach: Not with drastic compile-/eval-time libary-ish changes.
jmiven has quit [Quit: reboot]
wonko-the-sane has joined #commonlisp
<Brucio-61>
beach: that's what i thought but the discussion seemd to assume that everything would happen in the same (fcg) environment
<beach>
mrcom: I am beginning to think that you are deliberately changing your arguments so that no solution can be provided for you. Yet you don't accept this fact.
<beach>
Brucio-61: I fully understand.
<mrcom>
Brucio-61: beach: Yeah, it would. There's no way I could guarentee that, for example, ITER is escape-proof.
<mrcom>
beach: They all stink :) And yeah, I'm going to poke holes in everything. That's what security is about.
Pirx has quit [Ping timeout: 255 seconds]
<beach>
mrcom: Let me try just one more time. You would not import ITER to the first-class global environments. If you wanted to use an external library, then that library would be loaded into the host, and only safe operations would be provided in the first-class global environment. That library can then use ITER safely, as long as the library is not buggy of course. So ITER can be used without being available in the sandbox environment
<mrcom>
CL is just really, really good at letting the application get in and touch everything. That's why its good for so much, and why I like it.
<White_Flame>
and that's why security would be via subsetting, which means you can't just import any code into it
<White_Flame>
and as such, general execution of existing code is not a concern, only code written to that subset it
<White_Flame>
*is
<bike>
if you really want to be secure, step one would be not having ACE unless you really, actually, for real need it. and you would probably want to have a concrete idea of what you want to use the ACE for. and that might involve, indeed, "maybe we don't have to worry about what happens if we load in destroy-the-moon.asd"
<mrcom>
Macros like ITER need to execute in the sandbox.
<beach>
mrcom: Why is that?
<White_Flame>
if ITER uses anything not already in the sandbox, it wouldn't work
<White_Flame>
or, you could provide ITER as part of the sandboxed environment instead of having the user code include it
<White_Flame>
which of course requires evaluating the security surface of ITER itself
<bike>
for example i'm having a hard time imagining why you would want a sandbox to be able to load arbitrary libraries. it's possible there is a use case for that, but it's not obvious to me
<mrcom>
Don't really want to become a kitchen sink.
<beach>
mrcom: You really don't get it, do you. The first-class global environment is just a mapping. A safe function in the first-class global environment can use ITER in the host environment without ITER being present in the first-class global environment.
<bike>
i would think that generally you would only allow a fixed set of libraries that are actually needed for the applications you have in mind.
<mrcom>
beach: the idea is to let the sandboxed code use at least the common libraries. It would be the sandboxed code that included stuff like "(iter ...)".
<bike>
trying to do analysis of security without a threat model is kind of silly.
<bike>
beach: i think mrcom means actually evaluating (iter ...) forms in the sandbox environment.
<bike>
maybe. i am not sure.
<mrcom>
Yes, exactly.
<bike>
in which case you would obviously need to evaluate ITER's security, which is really not a very environment related question.
<beach>
mrcom: You can't have it both ways. You can't both allow ITER in the sandbox, and not be able to verify what ITER does.
<mrcom>
No, I can't have it both ways :(
<White_Flame>
if iter is provided in the host system, supports iterating over packages, and can take a string package designator, that'd could be a leak
<bike>
it actually wouldn't be in a sandbox, since merely having the name of a dangerous function isn't sufficient to get the dangerous function
<mrcom>
White_Flame: Well, the idea is that the equivalent code directly in the sandbox code would be impossible to escape, so therefore iter would too.
<bike>
if ITER only uses standard operators (which i don't think is actually true, oh well) and you had sandboxed versions of those operators you'd be okay loading ITER into the sandbox.
<bike>
like it doesn't matter if iter forms expand into (fdefinition ...), since fdefinition doesn't access outside the box.
<mrcom>
Iter has reader macros, too. Which is a whole 'nother issue :)
yottabyte has joined #commonlisp
* White_Flame
is terrible at retaining valid grammar over his chat edits, oh well
<mrcom>
If the sandbox could guarentee that arbitrary sandboxed code can't escape, then there's no need to examine 3rd-party libraries. At worst they'd break.
<bike>
i mean, that's the point, yeah. if the FCGE doesn't have a definition of (SETF FDEFINITION) or (SETF SYMBOL-FUNCTION) (and DEFUN, etc) that affect the host environment, you're not gonna be able to redefine host functions, because 3rd party libraries would have no way to do so
<bike>
there's the question of whether the designer of the FCGE has actually tracked down every operator that can modify function bindings, but there are only so many operators to check.
<mrcom>
You'd need some kind of sandboxed versions of all of those. They are reasonable things for application code to use.
<mrcom>
Yeahhh........ And it would be OK to drop the really rare stuff.
<White_Flame>
and of course the sandboxed version must present itself as the standard CL:foo in all access methods
<bike>
i only haven't defined (setf fdefinition) because i don't need them yet.
<mrcom>
The FCGE would take care of CL:foo.
<mrcom>
Ooooh... (COERCE funcobj 'foo)
markb1 has quit [Ping timeout: 258 seconds]
<bike>
yeah, you would probably need your own coerce, if only for the sake of (coerce foo 'function) which does evaluation.
<mrcom>
"In that case, the function will be defined in the global environment, not the environment where the call to COERCE occurs."
<bike>
that's mostly referring to lexical environments. like (let ((x 4)) (coerce '(lambda () x) 'function))
<beach>
Coerce does not define anything in any environment at all.
<mrcom>
Really suspicious of anything that takes a lambda.
<bike>
there are very few operators that accept lambda expressions.
<beach>
mrcom: COERCE does not access or modify the environment. It just converts objects.
<bike>
there are many that accept _function names_, including stuff you might not think about like REMOVE-DUPLICATES, so those would all need work
<mrcom>
beach: I think its saying that COERCE could reach out and get the unshadowed function.
<White_Flame>
beach: doesn't the result-type specifier access the environment?
<bike>
mrcom: what unshadowed function?
<beach>
White_Flame: Fair enough.
<bike>
your FCGE's coerce is not required to call the host coerce, of course, since you wrote it
<mrcom>
Hmm.. what would (THE funcobj 'structurefoo) do?
<bike>
return 'structurefoo.
<bike>
THE does not do any conversions.
<beach>
mrcom: An environment is a mapping from names to objects. COERCE does not define anything in any environment.
<mrcom>
No, but it might be a way of getting around opaqueness.
<bike>
if "funcobj" is a function type, it has undefined behavior.
<bike>
since the THE is incorrect
<mrcom>
Even if the funcobj is implemented as a structure?
<bike>
i don't understand what "the funcobj" is.
<bike>
the syntax of the is (the type form)
<bike>
so funcobj is, presumably, a type?
<mrcom>
Sorry, (THE 'structure funcobj)
<mrcom>
Only no quote...
<bike>
it's also not evaluated. (the structure-object funcobj), i guess you mean.
<bike>
if funcobj is a structure object, no problem. if funcobj is not a structure object, undefined behavior. my evaluator is really dumb so it will just ignore the THE and return funcobj regardless, which is conforming.
<bike>
for a secure evaluator you would presumably define the undefined behavior to do something secure, which i suppose i have technically done.
<mrcom>
bike: Yeah, but now we're into "write a CL implementation", even if just an interpreter. Which is an idea...
<bike>
i did that. that's what i've been linking.
<bike>
SICL is also that.
<mrcom>
Yeah, I was just thinking about compiling. I guess could sacrifice some performance.
<bike>
i wrote a compiler too. though it doesn't do much optimization.
<bike>
cleavir does more optimizations and works with first class global environments.
pfdietz has joined #commonlisp
<mrcom>
Hmmm.
<White_Flame>
if I were to write a CL compiler, it'd be the slowest, largest footprint compiler in the universe
<bike>
maybe a better example of what you were getting at is (typep funcobj 'structure-object)
<bike>
which could, conformingly, be either NIL or T
<bike>
but i don't think that gives you any routes to escape, just tells you a bit about what choices the implementation made
<mrcom>
No, the idea is to fool the higher environment into doing things we don't want with a function.
<White_Flame>
in mine, any time you redefined a function, it would take 10 minutes to analyze the entire image and rethink the universe
<bike>
(assuming TYPEP accesses the type in the correct environment, as white flame mentioned)
<bike>
say functions are implemented as structure objects. structure accesses into those objects are not available from any standard functions, obviously. if the FCGE doesn't make those nonstandard accessors available, there's still no escape.
<bike>
if functions are standard objects, you might want to make sure the secure FCGE doesn't include unrestricted standard-instance-access.
<bike>
but that's probably a good idea anyway, s-i-a can do all kinds of things.
<mrcom>
Evil code could just happen to (DEFSTRUCT definitely-not-a-function ...) that mirrors actual implementation. coerce to it, and then use normal struct accessors.
markb1 has joined #commonlisp
<bike>
coerce isn't defined to let you coerce to structure types.
<bike>
you'd just get a type-error.
<mrcom>
THE?
<bike>
please look up how these operators are defined before you speculate about using them maliciously.
<bike>
CL does not have some kind of shitty C type punning.
<mrcom>
I know, with safety 0, many implementations do minimal type checking. And yeah, you do get in effect type punning and wierd run-time errors.
<bike>
securing code with safety 0 is hopeless.
<bike>
again with my evaluator as an example, safety declarations and THE are both ignored. so you can't do anything goofy like that.
<bike>
in any remotely securable implementation or sandbox, you would need THE to do something sensible
<bike>
you could, for example, in your FCGE have (defmacro the (type form) (declare (ignore type)) `(progn ,form))
def_ident738 is now known as def_ident737
<mrcom>
Yeahhhhhh.... Oh.... dear.
<bike>
(defining special operators as macros is also conforming, and that definition would give you conforming THE behavior)
<mrcom>
Would have to implement a code walker for defmacro. Can't have evil code emitting (THE ...).
<bike>
what? no. you can just have a THE that doesn't do dangerous things.
eddof13 has joined #commonlisp
<mrcom>
Oh, right, macro ouput is re-processed.
<bike>
you would probably need your own evaluator for ACE regardless, if you're expecting DoS attacks, since there's about a million ways to do (eval '(loop forever)) and they obviously can't all be located ahead of time
<mrcom>
Not worried about DoS. Would execute in it's own process. (Which would include the outer environment, not a separate process just for the untrusted code.)
<bike>
okay. another case for knowing your threat model.
thonkpod has quit [Ping timeout: 258 seconds]
<mrcom>
Alright, thanks everybody. Lots of food for thought.
thonkpod has joined #commonlisp
chomwitt has joined #commonlisp
Algernon69 has joined #commonlisp
pequod has quit [Quit: Connection closed]
loke has quit [Ping timeout: 272 seconds]
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<bike>
you are welcome.
rgherdt_ has quit [Ping timeout: 248 seconds]
yitzi has quit [Ping timeout: 260 seconds]
Cymew has quit [Ping timeout: 255 seconds]
Algernon69 has quit [Ping timeout: 264 seconds]
overclucker has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
eddof13 has joined #commonlisp
def_ident737 has quit [Ping timeout: 255 seconds]
triffid has joined #commonlisp
overclucker has joined #commonlisp
yitzi has joined #commonlisp
overclucker has quit [Client Quit]
overclucker has joined #commonlisp
overclucker has quit [Client Quit]
pfdietz has quit [Quit: Client closed]
seok66 has quit [Quit: Client closed]
seok66 has joined #commonlisp
rgherdt has joined #commonlisp
pfdietz has joined #commonlisp
overclucker has joined #commonlisp
mgl has quit [Ping timeout: 264 seconds]
zxcvz has quit [Quit: zxcvz]
loke has joined #commonlisp
zxcvz has joined #commonlisp
zxcvz has quit [Client Quit]
dino_tutter has quit [Ping timeout: 260 seconds]
jonatack has quit [Ping timeout: 258 seconds]
mathrick has quit [Ping timeout: 255 seconds]
msavoritias has quit [Read error: Connection reset by peer]
simendsjo has joined #commonlisp
seok66 has quit [Quit: Client closed]
def_ident737 has joined #commonlisp
msavoritias has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
phadthai has quit [Ping timeout: 255 seconds]
simendsjo has quit [Remote host closed the connection]
tyson2 has joined #commonlisp
pequod has joined #commonlisp
mathrick has joined #commonlisp
def_ident737 has quit [Ping timeout: 255 seconds]
Pixel_Outlaw has joined #commonlisp
mathrick has quit [Ping timeout: 248 seconds]
mdaadoun has quit [Remote host closed the connection]
phadthai has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
azimut has joined #commonlisp
Algernon69 has joined #commonlisp
Algernon69 has quit [Read error: No route to host]
Algernon69 has joined #commonlisp
random-nick has joined #commonlisp
Algernon69 has quit [Ping timeout: 255 seconds]
dino_tutter has joined #commonlisp
iska`` has quit [Remote host closed the connection]
waleee has joined #commonlisp
attila_lendvai has joined #commonlisp
wonko-the-sane has quit [Ping timeout: 252 seconds]
amb007 has quit [Ping timeout: 255 seconds]
amb007 has joined #commonlisp
msavoritias has quit [Remote host closed the connection]
anticrisis has joined #commonlisp
anticomputer has quit [Ping timeout: 252 seconds]
anticomputer has joined #commonlisp
triffid has quit [Ping timeout: 252 seconds]
jonatack has joined #commonlisp
triffid has joined #commonlisp
rgherdt has quit [Ping timeout: 258 seconds]
cage has joined #commonlisp
attila_lendvai has quit [Remote host closed the connection]
amb007 has quit [Ping timeout: 260 seconds]
attila_lendvai has joined #commonlisp
rogersm has joined #commonlisp
waleee has quit [Ping timeout: 264 seconds]
amb007 has joined #commonlisp
waleee has joined #commonlisp
shka has quit [Ping timeout: 255 seconds]
<jcowan>
bike: wouldn't making (the structure-object 5) immediately branch to Fishkill be more in the spirit of UB? Or if not immediately, when you add something to it.
overclucker has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
overclucker has joined #commonlisp
tyson2 has joined #commonlisp
overclucker has quit [Client Quit]
mgl has joined #commonlisp
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
waleee has quit [Ping timeout: 240 seconds]
waleee has joined #commonlisp
eddof13 has joined #commonlisp
cage has quit [Remote host closed the connection]
jobhdez has joined #commonlisp
jobhdez has quit [Client Quit]
overclucker has joined #commonlisp
overclucker has quit [Client Quit]
jonatack has quit [Ping timeout: 255 seconds]
overclucker has joined #commonlisp
overclucker has quit [Ping timeout: 272 seconds]
tyson2 has quit [Remote host closed the connection]
overclucker has joined #commonlisp
overclucker has quit [Client Quit]
overclucker has joined #commonlisp
jmdaemon has joined #commonlisp
overclucker has quit [Client Quit]
overclucker has joined #commonlisp
zxcvz has joined #commonlisp
zxcvz has quit [Client Quit]
attila_lendvai has quit [Ping timeout: 248 seconds]
gxt_ has quit [Ping timeout: 252 seconds]
gxt_ has joined #commonlisp
pve has quit [Quit: leaving]
mathrick has joined #commonlisp
chomwitt has quit [Ping timeout: 264 seconds]
pequod has quit [Ping timeout: 248 seconds]
notzmv has quit [Ping timeout: 272 seconds]
pranavats has joined #commonlisp
amb007 has quit [Ping timeout: 258 seconds]
overclucker has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
overclucker has joined #commonlisp
jcowan has quit []
jcowan has joined #commonlisp
jcowan has quit [Client Quit]
jcowan has joined #commonlisp
overclucker has quit [Client Quit]
overclucker has joined #commonlisp
overclucker has quit [Client Quit]
overclucker has joined #commonlisp
jeffrey has joined #commonlisp
amb007 has joined #commonlisp
son0p has quit [Quit: Bye]
random-nick has quit [Ping timeout: 255 seconds]
son0p has joined #commonlisp
jmdaemon has quit [Ping timeout: 240 seconds]
robin has quit [Remote host closed the connection]
robin has joined #commonlisp
habamax has joined #commonlisp
gxt_ has quit [Remote host closed the connection]
karlosz has quit [Quit: karlosz]
gxt_ has joined #commonlisp
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sgithens_>
outside of blog posts and things, does anyone know if there is more of a 'manual' for quicklisp outside the front page and faq, which a bit more meat about switching the active dist, updating things, and stuff like that? I've not had great luck searching...