Arc Forumnew | comments | leaders | submitlogin
An exceedingly simple trusted execution model for Arc
6 points by dfranke 6124 days ago | 6 comments
The following is an extremely simple set of primitive functions that could be added to Arc, on top of which any sort of trusted execution system could be built via macros -- anything from Perl-style taint checking to a Java-style security model or even the Decentralized Label Model.

1. All code executes as a given real and effective user. An object of any type can serve to represent a user. At the start of execution, the real and effective users are both `nil'. Nil acts as a superuser.

2. All potentially-dangerous primitive functions, such as I/O and networking, throw security exceptions unless they are called as effective user nil.

3. There are primitive functions `getuid' and `geteuid' that returns the current real and effective user ids respectively.

4. There is a primitive function `suid' that takes a function as an argument, and returns a new function identical to the input, that when called, executes its dynamic scope with the effective user as the real user who passed it through `suid'.

5. There is a primitive function `sudo' that takes a userid and a thunk, and executes the dynamic scope of the thunk as the supplied real userid. `sudo' requires that it either be invoked as effective user nil, or that the real user requested is equal to the current effective user.

And that's all there is to it. You can implement any security system you want on top of these primitives.

(EDIT: added the distinction between real and effective user so that a suid function can tell who called it)



4 points by drcode 6124 days ago | link

I think an arc execution model should have support for finegrained control over timeout and cpu load... I would love it if I could build a website in a language (such as arc) that would allow me to easily run user-supplied code with enough control in the language where I can say "your code must complete in 0.1 sec or 1000 cpu slices or it will be stopped"

-----

2 points by dfranke 6124 days ago | link

That's more the domain of a concurrency system than a security system, isn't it?

-----

2 points by mst 6124 days ago | link

I think I'd rather have an 'outer user scope'.

i.e. something like

(fn geteuid () (car user-stack)) (fn getuid () (cadr user-stack))

that way you can cons on suid and 'pop' outwards.

It's always seemed a trifle annoying to me that when you suid from within something that's already suid you lose information.

-----

1 point by dfranke 6124 days ago | link

You can implement this on top of my given axioms. My system isn't meant to be friendly; it's meant to be the simplest possible building blocks for a friendly system.

-----

1 point by cpfr 6120 days ago | link

1. How do you enforce real/effective uid? What prevents this from being overwritten?

2. What prevents a user from saving and serialzing a dangerous thunk for later use? How do you expire?

3. How do you keep which functions are dangerous? What prevents due to lack of foresight unnecessary security breaches?

4. What stops others from getting around these by dipping under Arc and these primitives?

These are hard questions and unless they are answered the security the system provides is merely a ruse.

-----

1 point by dfranke 6124 days ago | link

On second thought, real vs. effective user isn't needed. You can simulate that by encapsulating a suid function inside a non-suid function that checks the current userid and passes it as an argument to the suid function.

-----