Ok your solution is going in circles... and you haven't introduced any new information over my original post.
Quote:
The files created by this process are owned by the user running them. After the chroot() call is made, the user ID is changed to the user requesting the process, and runs as it normally would run... with the permissions of the user running it.
Then how are these files any different? The jailed process creates files outside of the jailed environment (why have the jail?) that fall under the original users credentials. This seems like it meets the requirements to you?
Quote:
If we are to allow users to develop and execute applciation, what is to prevent a threat agent from using that users' credentials to execute other code?
In my solution, the threat agents lack the access... in yours, nothing.
Quote:
In my solution, any application process that a user requests would be jailed, and only able to run code within that jail, if we provide the necessary permissions to do so.
Yet according to your point above these jailed environments can create object outside of their jailed environments... object that lose the jailed credentials and acquire the user's credentials.
Quote:
In your solution, user data would also be stored on a shared resource, and be readable by many different client applications, all of which may read and execute that code.
Not true at all... see in my solution I can provide process credentials and user credentials at the same time... yours does not. Not only that my credentials are more expressive allowing again for greater granularity.
The only way for you around this is to create a seperate jail for every application used by every user (so userX, userX_firefox, userX_clientapp, etc) otherwise if you have jail_firefox as an account all that data is availible to every user that uses that jail.
Quote:
With your solution, what is to prevent a virtual machine from reading binary code from a non-executable file, and then executing that code from somewhere else?
How will the code get somewhere else? Yours requires moving objects around, mine does not.
Quote:
Your original question was to find a method to prevent the execution of incoming data.
No it wasn't... this is the second time you have clearly misread my original question.
"How can I restrict any number of client applications on a large-scale system, so that incoming data cannot be executed nor can it read or written to beyond the application’s sandbox?"
"executed... read or written "
"beyond the application's sandbox "
I think if you take the time to review my question fully you will see that I addressed and dismissed your solution because it doesn't work. It doesn't matter if you use a jail, an emulator or any other subsystem... they all result in the same problems.
Quote:
Now when you speak of a lack of lateral sharing... my solution is specifically designed to prohibit lateral sharing, as this becomes, as I said eariler in this post, an attack vector by which malicious code can spread from one application to another, and has privacy concerns as well.
Lateral sharing isn't an issue as objects move across they will inhierit new rights and privacy isn't an issue since they are only laterally shared across a single user.
Quote:
If any code can be executed, malicious code can be executed.
Hence the wish to sandbox it.
Quote:
Specifically, how would you allow users the ability to generate and execute code, extend application functionality with executable code, yet deny the same execution to malicious code? How would you allow lateral sharing, yet avoid associated privacy risks?
Who said anything about denying malicious code? I merely wish to keep code that originated from the sandbox to remain in the sandbox and code that originated outside the sandbox to be useable nearly anywhere (the specifics of where and those security concerns are beyond the scope of this conversation... so nearly anywhere will have to do).
Privacy issues do no occur because users still own the processes and are still bound their their access controls... additionally they are bound to the process' restrainsts. Since everything occurs under the same uid... no privacy issues are introduced.
cheers,
catch