OSDev.org

But how does the system know that the app being installed is a FutureAmp player? How can the system tell the difference between FutureAmp and a virus scanner that needs permission to delete potentially any file that's infected? And how does it tell the difference between that virus scanner, and a malicious program that will delete pretty much whatever it can? If the system relies on Joe to tell it which is which, you're back to the same problem.

There are lots of other reasons why I think VMs are a good idea, but they're drifting off the topic of this thread... and I'm at work, and need to get actual work done now.

pini wrote: ... and also to provide a strong protection against side effects like buffer overflow exploits (executable stacks, and so on).

How would you deal with this problem (buffer overflow exploits) without segmentation?

Colonel Kernel wrote: But how does the system know that the app being installed is a FutureAmp player? How can the system tell the difference between FutureAmp and a virus scanner that needs permission to delete potentially any file that's infected? And how does it tell the difference between that virus scanner, and a malicious program that will delete pretty much whatever it can? If the system relies on Joe to tell it which is which, you're back to the same problem.

There are lots of other reasons why I think VMs are a good idea, but they're drifting off the topic of this thread... and I'm at work, and need to get actual work done now.

How VM solves this problem? Joe will have to decide which operations are allowed for each program, e.g, he should be able to know that something goes wrong if FutureAmp is trying to delete system files. A secure system should deny a process any access other than those explicitly granted by users. Of course, the users can use default settings (for example, programs is allowed full access to files in its own directory) to make life easier.

well, one potential idea is to distribute "profiles" of applications. Joe wouldn't be requested to do anything if the FutureAmp identifies itself as a "Media Player" and describes compatibly with what the system expects to be a "Media Player". All joe will see is "installing 'FutureAmp' media player to the system" ...

A trojan player will not match the 'Media Player' class, e.g. because it will attempt to have "program can read text document created by Joe", which doesn't belong to the description of a 'Media Player'. The system can identify that at installation time and warn Joe that "TrojanAmp require the right to 'read text documents created by Joe'. This may disclose private information to unknown tiers. You're suggested to abort installation now. Contact local administrator or support team for additionnal advice."

Alternatively, some programs may need to have access to any kind of documents (typically mail clients) but we could arrange things such that an explicit grant is allowed from the user (for instance through the 'add attachment' box) so that the mail client doesn't automatically gain access to all the documents of the user, but only selected ones.

A virus scanner is typically a "critical" program (the shell is critical too) and 'Average' users shouldn't be allowed to install new critical programs. Indeed, it requires the full control over all the user's document. Yet the virus scanner could be made less critical by not having the right to modify documents by itself but only "tag" them as being bad (e.g. quarantine them only).

Imho, strong authentification could allow Joe's computer maintainer (even if the local computer dealer or something) to remotely allow the installation of update packages the maintainer trusts, and if Joe prefers it that way (Please think twice to the implicit commercial trust relationship between Joe and his 'maintainer' before you start flaming me for this

sturmstiger wrote: How would you deal with this problem (buffer overflow exploits) without segmentation?

Doesn't the NX bit solve that sufficiently well?

How VM solves this problem? Joe will have to decide which operations are allowed for each program, e.g, he should be able to know that something goes wrong if FutureAmp is trying to delete system files. A secure system should deny a process any access other than those explicitly granted by users. Of course, the users can use default settings (for example, programs is allowed full access to files in its own directory) to make life easier.

VMs per se don't solve this problem, but they do allow for the kind of stack-based permission check I talked about earlier. The point is that user-based permissions are insufficient, since users are able to (whether intentionally or not) run code that won't act in their own best interests. The idea is to assign permissions to code based on where it comes from, not based on what it says it is supposed to do.

Here is info on .NET's implementation of what I'm talking about:

Code Access Security.

Pype.Clicker wrote: well, one potential idea is to distribute "profiles" of applications. Joe wouldn't be requested to do anything if the FutureAmp identifies itself as a "Media Player" and describes compatibly with what the system expects to be a "Media Player". All joe will see is "installing 'FutureAmp' media player to the system" ...

A trojan player will not match the 'Media Player' class, e.g. because it will attempt to have "program can read text document created by Joe", which doesn't belong to the description of a 'Media Player'. The system can identify that at installation time and warn Joe that "TrojanAmp require the right to 'read text documents created by Joe'. This may disclose private information to unknown tiers. You're suggested to abort installation now. Contact local administrator or support team for additionnal advice."

Maybe I'm missing something here... When Joe installs something, is he specifying that he expects that something to be a Media Player? Now we're back to square #1. If programs tell the system what class they belong to, and these programs can lie, then how is the system supposed to know what class to expect during any given installation?

Colonel Kernel wrote:Example: Joe User has somehow been fooled into running some malicious code he downloaded (it happens... call Joe stupid, call him irresponsible, whatever -- you can't deny the power of social engineering and human stupidity). If this code is allowed to run as a plain old "unmanaged" app, then the only thing preventing it from accessing the file system is the identity of the user that it runs under. In this case, it was run (unwittingly) by Joe, so it's free to delete all Joe's files, much to Joe's chagrin.

This is just a flaw in the security model of current mainstream operating systems. There is no reason why each program should run with the priviledges of the user.

Some people argue that granting access on per-file basis (in for example, the mentioned email-client) is too much trouble, but in fact you can make a lot of it transparent: make the system-provided "file open" dialog double as a "grant" dialog. No UI changes are needed. Suddenly, the program can only access files that the user specifically chose.

Another nice trick is not to allow programs to be run without installing it with a system-provided "secure installer". This installer can then ask user to confirm the name of the application, and if the application name is always shown in the same place, the application can no longer fool anyone about it's identity.

There are tons of similar tweaks that don't need any real changes to how the system looks and feels to the user, but provide great security improvements.

Now, let's consider the troijan media player. It is installed, and in installer user confirms the application-suggested name "FutureAmp". From now on, "FutureAmp" is always known to be this particular program. When you want to play a media clip, you drag and drop files (which acts as a grant) or use an open dialog (which acts as a grant) or whatever. Now the media player can read the media files. It still can't read anything else.

Next, it needs to ask for a permission to access soundcard. Ok, so pop a dialog "FutureAmp wants to play sound through your soundcard." to which the user can say "ok". Playing sounds isn't very dangerous, so it can be non-dangerous looking dialog. It could be asked as part of the installation too, and it'll be remembered. FutureAmp still can't record sounds from the microphone. That's much more dangerous, and needs a warning sign in the dialog so as to alert the user that something might be wrong.

Ok, consider something went wrong anyway. Now, Joe calls a friend of his to fix his machine. His friend can now look at a list of permissions that have been granted to various applications, which is usually enough to identify which programs aren't doing what they should be doing. The permissions can then be revoked, and if necessary, the applications uninstalled. No reinstallation of the system, or tweaky cleaner applications are necessary.

Welcome to the world of security.

Colonel Kernel wrote:

sturmstiger wrote: How would you deal with this problem (buffer overflow exploits) without segmentation?

Doesn't the NX bit solve that sufficiently well?

I thought NX bit is not available on IA-32.
Anyway, I guess I'll go with segmentation to get hardware enforced, kernel-level security. Long live IA-32 (and compatible modes)!
But let me know if you believe that's a really bad idea, and I may change my mind.

The security measures mentioned by Pype.Clicker and mystran are similar to what I had in mind, but it will be a long way to go before I start to deal with these high-level stuff.

Grants, are, in my opinion, one of the best options for security.

What I think should be done (which is why I'm going to do it) is to have grants function as runnable code with normal permissions of the user that returns a Boolean, true or false for whether or not the resource can be accessed. A string's worth of metadata to point to a grantfile is all that's needed. They would have their own permission checks that in turn would have to pass before the grantfile would even run. Thus, if I have program FutureAmp, and I don't have permission to run FutureAmp/.grant then it counts as a false and I can't run FutureAmp!

Now to TrojanAmp. If TrojanAmp tries to delete my whole filesystem, and comes upon say... FutureAmp, which I (the username for me) own, than before it can delete FutureAmp it must get the OK from FutureAmp's grant, which might check the application registry for authorized deleters, or might ask for user confirmation with a dialogue message. If the grant fails because The User clicked "No." when presented with the message "Do you want to let the program TrojanAmp delete the file FutureAmp?", then TrojanAmp isn't allowed to do anything with the file.

The same sort of grant could be given to system files like the kernel, all just by adding one bit of metadata to the filesystem code, a hook from the FileOpen() function to run the grant, and permissions to check who could run and modify the grant.

sturmstiger wrote:I thought NX bit is not available on IA-32.

Not until recently. AMD introduced it last year, and Intel has recently added it to the P4 line... not sure which models. Maybe only the brand new ones with EM64T?

@mystran: I've heard about capability-based security. Is this what you're describing? Sounds interesting...

Colonel Kernel wrote: @mystran: I've heard about capability-based security. Is this what you're describing? Sounds interesting...

Indeed. Some of the UI ideas btw are not my own.. search the web and you might hit them. Can't remember where I actually got them so can't cite anything. Sorry about that.

Look through the Unununium mailing lists, they had something on that.

www.unununium.org

When Joe installs something, is he specifying that he expects that something to be a Media Player? Now we're back to square #1

No. the program being installed should identifies the profile it wishes. Seeing "Installing a new document manager TrojanAmp" instead of "Installing a new Media Player TrojanAmp" should make Joe hickup and he should click "abort".

Now that may not be enough for Mr Anykey, which *should* have told the computer he doesn't want to be asked anything technical, the system will instead tell "Document Manager TrojanAmp identified as a critical application. Installation of critical applications should only be performed by system technician. Please contact your local guru."

Crazed123 wrote: Now to TrojanAmp. If TrojanAmp tries to delete my whole filesystem, and comes upon say... FutureAmp, which I (the username for me) own, than before it can delete FutureAmp it must get the OK from FutureAmp's grant, which might check the application registry for authorized deleters

I was thinking at something even higher than this. There are user-owned files (pictures, texts, spreadsheets, ...) and program-owned files (preferences, working temporary files, logs, etc). An 'ordinary' program only has the ability to delete its own files. It cannot delete user's file even if ran by the user, and it certainly doesn't have the ability to delete programs (which even the user himself may not be entitled to do!).

Only system programs (like the shell, or a documents manager of some sort) are entitled to delete files, which makes them critical programs. The only way for TrojanAmp to have the ability to delete files is to identify itself as a critical program at installation time. The "grants" file of applications are unreachable for both applications and users. Only the system (application installer) can alter these files.