Security enhancement proposal

Submitted by Ben Bucksch on Sat, 11/04/2006 - 17:14.

Here's a proposal to make security on JNode better than on current OSes (Win, Linux, Mac). It inherently requires breaking the Java API in a few cases.

Current state

There's a fundamental security problem with current OSes: apps are not walled off against each other, the only sec context is the user account. Every app can read and write every file, and execute all other apps with the same permissions.

There is memory protection between apps, but more for reliability than security, because the real user data can still be accessed.

Signed jars don't help here, because I (as user) can only accept/deny. If I deny, I can't use the app at all. If I accept, I give its author all my data. That is exactly the root problem. Same problem with app-specified permissions, apps will just request it, and users will grant it. There is lots of data that users will just accept whatever is demanded, just to see dancing hamsters.

Luckily, there are only very limited access methods (I am not currently aware of any other mechanism for spyware):

  • File access

    The root problem for most spyware etc. is that any application can read every file from disk, as long as the user has access.

    So, the linux root/user separation doesn't actually help all that much, because the spyware I start as "ben" will be able to read all my files, and send them over the net.

  • Shared UI resources

    The other root problem is that shared UI resources like keyboard, screen / Window system messaging and copy&paste are freely accessible. that's what makes keyloggers possible, and I think that's the reason of the annoying Admin dialogs in Windows Vista.

Proposed solution

Cut these 2 short, and you'll have a *much* safer system.

Here's the proposal:

  • File access

    my suggestion for filesystem is: every application has 2 namespaces/folders:

    • install dir
      Systemwide, readonly (writable only by root), where it keeps resources, icons, system prefs etc.

    • user pref dir
      where the app keeps user data, caches etc.. This is writable by the app, and every app will have a different one. what's important is that these are the *only* 2 dirs where the app can open files.

    • Dialog
      There's one special exception: The app can open java.io.File in a special way, so that the user gets a File Open/Save dialog to specify a file name. the app cannot see or influence the dialog.
      It's very simple: basically File|Open and File|Save in traditional apps don't give the app-specific dialog, but the system dialog. and that will be the only way for the app to access arbitrary files.
  • UI resources
    • Message injection (java.awt.Robot)
      You are only allowed to insert messages into the message queue influencing your own app, not others. this is critical. the fact that windows allows that is a *security hole* and probably the reason for the extremely annoying Admin dialogs in Windows Vista.

    • Screen capture and similar
      same as message injection

    • Copy&Paste
      can only be triggered by system libraries (e.g. Swing), when executed by the user. Take care that it's not triggered by a message injection. This prevents spyware from stealing the passworts I paste into the browser etc..
‹ question RTSJ ›

why not implement through smarter SecurityManager

Submitted by sourcerror on Sun, 11/19/2006 - 21:31.

Ben,

This is my first post here... go easy on me. First of all, we loved dancing hamsters and look forward to running the first JNode dancing hamsters application when we see it. Eye-wink

One of your early justifications was:
Signed jars don't help here, because I (as user) can only accept/deny

But I still think there is hope with the right security manager and dialog/wizard with presets that help people modify their permission files during install or invoking the app the first time. The default could be hardly any permissions and asking the user for specific permissions as the application tries to access resources. This could be sort of like the WindowsXP dialog box that tells you a program is trying to open up a port to accept connections and would you like to allow it. Of course WindowsXP doesn't give many choices, JNode could provide more protective defaults and when you allow unblocking it could provide more options ranging from unblock this time, unblock for some time window, etc.

If the SecurityManager was done in a nice modular way we could evolve multiple custom ways of doing this and not affect the rest of the JNode application install/launch architecture. You could even do exotic things like delegate the accept/deny questions from a novice user's machine to a more security competent user for approval.

The advantage of using the security manager is that there are other things that can be addressed. You can control permission to access: file read and or write, networking (i.e. both starting a connection and accepting a connection), printing, access AWT event queue, access system clipboard, bring up top level windows, permission to print, etc. I'm not sure the right place for this, but it would also be nice to limit how much memory or processor time can be used to partially trusted processes.

Basically, I'm agreeing with you but just saying some thought has already gone into the SecurityManger API, so it may be better to build on that?

- SourcError Smiling

EDITED...
I guess this is discussed already some in the Developer Guide under "Java Security". I don't understand it yet, but it seems you could implement a user friendly Policy manager GUI on top of what is supported already.

interesting... JSR121 Application Isolation API

Submitted by sourcerror on Sun, 11/19/2006 - 22:19.

FYI:

This is interesting... JSR121 Application Isolation API. (I ran across this while looking around just now).

- SourcError Smiling

Security enhancement

Submitted by MSV on Fri, 11/10/2006 - 09:15.

Hi Ben,

I think your proposal is a very good one. Implemtenting this setup would take a lot effort to current OS'es. Here we have a fresh strart.

Indeed some programs would like full access to user persistance space (files if you like a simple approach). Perhaps to catalog your documents / media files.

However your security proposal can be implemented quite easely. The way I see it.

In UNIX type OS you have a owner/group/other kind of permission per file. Directory are files as well. In Windows you have a user / group apporach. Where goups can contain other groups, thus enabeling enheritence. The UNIX type OS does not allow this kind enheritence.

The main problem is that when a program starts, it runs under the firing user account. thus having the same priviliges

I propose that each program is run under an own account. And that the program account can be assigend to groups like. "Documents" group or a "Media files" group.

There can be chosen to have an extra security token per file like so

[Document object name] User groups: all user R-
Single users: owner RW
program groups: Document catalogers R-
Document editors RW
Single programs: VIM RW

Or just combine the user and program privileges in one security base. Meaning for object access, progams and users are considered equal entities.

When a programs asks for access you can always choose "give full access". But the OS should give the files apporved. Thus creating a virtual FS to the program where it can only see the files authorized for the program or group it belongs to.

This would have the same effect as the "changed root", or chroot, in linux where a user, FTP for eg., or program, Webservers etc., are fooled in what is the root of the file system.

With chroot the user / program thinks it can see the root file system but in fact it is a specified folder with the same structure as the root file system. But the files are links to the actual files thus seeing only the files you secifiy by linking to them.

My proposal combines a chroot envirionment for every progams but eliminate the need for creating special envrionment for every program.

I'm looking forward to see other proposals/ reactions / feedback

Kind Regards,

MSV

Implications of using File Dialogs

Submitted by Matthias on Mon, 11/06/2006 - 09:18.

I can think of one application where this approach will lead to a problem. Programs such as media players that keep a library of all your music and video, or other search programs, will want to scan all or a part of your filesystem.

As soon as a user wants this type of functionality he will want to give the program full access to his disk.

How would one solve this issue in the above mentioned approach?

Totally different way ;)

Submitted by hlavac on Sat, 11/25/2006 - 19:18.

> How would one solve this issue in the above mentioned approach?

You should get rid of the concept of general files.

Have the data be objects with associated types, and grant program privileges according to the types of files, categories you have put them in etc.

In the same way, get rid of executable files - let operating system code and programs reside outside of the general data access APIs.