Imagine I have a type of "virtual OS" framework in Unity which runs C# code that represent third-party apps the user can later launch. Would there be any way to secure that third-party code to not, say, read or write files to the local storage? A kind of sandboxed security model (maybe via each third-party app being a DLL which is given certain rights or so)?
If impossible to achieve programmatically, is there a way a project could be securely checked via a custom parser to disallow all file-access keywords ("may never include string 'IO'", with one being ok for false positives to be checked manually), or is that impossible to achieve too? Thanks!
Related
I have several C# assembly libraries, which are not strongly named (signed). I would like to make a SxS COM-wrapper over those components using the tlbexp.exe to consume in native programs. Is it necessary to sign them or is there another way to do it?
Thanks
There are strong misconceptions in this question, it confuzzles the roles of two programmers. You are the author of the library, somebody else uses your library and probably works for another company and has no idea who you are. The client programmer. You in turn have no idea how the client programmer uses your library, how many programs he wrote and what he does to deploy your library on his users' machines. You run Tlbexp.exe only to help him write his code.
This is a recipe for trouble, like it is no matter what language or tooling you use when you create libraries. That trouble starts when you make a change in the library and the client programmer has to rebuild and redeploy his programs that use your library.
There is extra trouble in a COM library because by default registration is machine-wide. Which is pretty nice if the change you made is a bug-fix, all of the client programs that use your library automatically get the fix. But it is not nice if the change is breaking and causes the old client program to fail. The standard disaster is that the client programmer rebuilds some of this programs but forgets or ignores some old ones he no longer maintains. The end-user is often the real victim, he's got a program that crashes but two programmers that don't think it is their problem to fix.
What is necessary is that programs that the client programmer does not update keep using the old version of your library so it is unaffected by the change. In other words, there need to be multiple copies of your DLL on the users machine and a program automagically needs to pick the right one.
Thankfully that is easy to do for a [ComVisible] .NET assembly. Either the client programmer, his user or an installer you provide for him can put the assembly in the GAC. Which allows multiple copies of an assembly to exist side-by-side and the CLR can automatically find the correct one. That has two requirements. You need to bump the [AssemblyVersion] of your library, that's standard. And the assembly needs to have a strong name so it can be put in the GAC. That is trivial to do by you, using Project > Properties > Signing and ticking the "Sign the assembly" checkbox. This has no security implications so the key doesn't matter and a password is entirely unnecessary. It is not easy to do by the client programmer so this is something that you must do. Always.
The client programmer also has the option to use isolated COM with a manifest (aka "regfree COM"), probably what you meant with "SxS COM-wrapper". With the benefit that each program he writes has its own copy of the DLL, the way it works by default in .NET. Bug-fixes need to be deployed manually but a change in your library can't break an unmaintained client program. But this is entirely his choice, there is nothing that you can do to ensure that this is done. You must assume that he doesn't use it, and he almost certainly won't at first, so you can't bypass the need to strong-name.
When an assembly is strongly named, its types can only be used from other strongly named assemblies. Since your assemblies are not strongly named, there's no need to sign your COM wrapper.
Signing an assembly makes it possible to place it in the Global Assembly Cache (GAC). This has the benefit of keeping multiple versions side by side, without breaking existing clients.
The alternative is to use the Windows registry via regasm's /codebase switch. Much in the same way as classic COM components are set up, this option registers your COM-visible assembly on a system wide basis.
Since you wish to deploy your COM wrapper via SxS / Registration-Free activation, thereby bypassing the registry and GAC altogether, there's really no need sign it.
Is There any way to do following in C#.NET or JAVA,
Get list of files from specific directory of Another pc having solaris OS and transfer file using SCP to another pc which have also solaris OS.
Actually i am thinking about creating front-end in asp.net to transfer backup from Live to backup server and get information about backup.
I even this is possible or not, but I wan't to clear my confusion on this.
Please give me your suggestion.
C# or any other .NET language is specific for Windows and won't run on anything but Windows. So forget about .NET languages. For this type of task I would definitely use Java if you insist on using a programming language at that level.
From Java you can use JSch library. It can do SCP from within Java. Here's is one example.
However I must say that most people that are familiar with Unix/Linux would probably simply do this task from within a scripting environment. Heck it can be done from Bash if you like.
Regardless of your choice of tool/prg.language you'll also have to decide if your doing PUSH or PULL. It seems from your posting that you are most keen on doing a PULL. There's no right or wrong answer on PUSH vs PULL.
I'm writing a kind of a generic contester system for ACM solutions (like TopCoder, Timus and others). When user sends his solution using web-service, i need to run/compile it. And i want to set restrictions to it in order to run them safe (no access to outer files, no ability to get system time, cannot change working directory etc)
There're two kinds of user solutions:
solutions, that can be compiled (aka c/c++/pascal), also jit-ed and bytecode solution (c#, java)
interpreted solutions (lisp/ruby/python/php)
Contester system is written in C# for .NET 3.5. Contester can run in Linux on Mono and in Windows on .NET.
What's the best way to do it? If there's ability to restrict compiled solutions (using PermissionAttributes), but i have no idea how to restrict interpreted solutions.
Easiest (seeing you probably need full trust) is to run under a very limited user account. IIRC the guest account cannot be used for this.
Edit:
A clean VM might ideal.
I am working on a .NET app that will also run on iphone via monotouch and osx/linux via mono. The app will hold profiles for various users and the profile used for a particular session will be selected on startup, kind of like Skype.
To store per-user settings, I am considering using the Application Settings system that's part of .NET. However, this system seems to rely on reflection, which is not available on iphone. I am also not sure if this system will function on platforms other than Windows.
I could also use the app's sqlite database that stores the application data to store settings, and simply roll my own settings classes that would be serialized/deserialized to the sqlite database like all the other application data.
Finally I could roll my own file-based solution.
What are the tradeoffs for these approaches? Why does .NET have dedicated support for user settings? It seems like a quite simple thing that coders should do on their own, and the existence of dedicated support within the .NET framework makes me suspect that I'm missing some point of complexity.
Thanks!
First thought - don't use configuration settings, use the sqlite database as that is on the iPhone and the best approach to take. Remember MonoTouch just transliterates the .NET code to the Objective C equivalent code and compiled to native binary, and you may run into snags if you use Windows/Mono specific code that may not be present on the iPhone.
Avoid pinvokes like the plague if you want your code to work across all platforms.
.Net has support for user settings because Microsoft designed them that way.
Hope this helps,
Best regards,
Tom.
what is the best way to deploy a winforms app if you know you are going to be doing frequent releases
Click Once is your best bet.
Click Once is great if you know the customer base will always have access to an internet connection and they only ever need a single version installed. This is probably true for the majority of apps.
But if that is not the case then I recommend you ensure that people can install different versions of your application side-by-side. Do not place your assemblies in the GAC or have them share a common resource. This way the customer can have multiple versions installed and they all continue to work. Xcopy deployment would be even better but hard to achieve in practice for non-trivial apps.
I recommend an NANT build script, using NSIS for your setup script. Both are freely available and allow you to have a one-click build process that is fully expandable.
In a corporate network I do the following:
create a strong name key
have all machines 'full trust' any assembly with that key - this can be automated with group policy.
sign the app with the strong name key
put the application on a network share and push shortcuts to the user’s desktops via a script or group policy.
Note: It's given that you've already pushed out the .NET framework. This also can be automated. If you've other resources that need to installed on the client the something like Click once is going to be needed.