OSNews

BTW, GUI alternatives are no better. E.g. it is way too easy for one X11 app to crash the whole sessions (in fact, much easier than to crash WinXP GUI).

I am not sure about MacOS X here, but since it follows basically same coding paradigms, I would not be surprised it shares same problems.

In reality, I believe that bad security of GUIs is somehow caused by its very purpose:

Advanced GUI is about sharing between applications (mouse, keyboard, clipboard, objects etc...). Wherever is sharing, there is insecurity. Security is about isolation - but not many users would welcome "isolated" GUI.... "

I don't think it's so much that issue. Sure, applications can share data. However, to do so they need to do it over approved channels and every application should have to approve what from itself can be shared. The one thing you can't get around is sharing with the kernel - but that typically happens by request of the application so that's not really an issue.

But when another application wants to get data from the application, there should be a function that application (or even the kernel) calls into the application its trying to get data from and say 'hey, i'd like this access, can I have it?' with a default of denying access (for applications that don't code the function - default to secure) - threads and processes spun off from the application would be a challenge to answer for (likely default of approve for threads and deny for processes). And that would have to go for everything the application controls (e.g has opened, creates, etc.).

It's practical and it would work. And the security it would provide would work wonders - though not seen by the average user. You'd be able to quickly eliminate a lot of bad software (virii, trojans, keyloggers, etc.) as they would have to (a) break into the API to get what they currently get and (b) they'd be denied outright by the security.

Sure there would be some challenges with getting it working right, and developers would have to learn some new tricks too. But in the end, it would provide a security that is very well needed.

Additionally, the simple fact that an application is getting data from another application (e.g. keystrokes, etc.) does not prohibit this. Your base layer (e.g. the GUI API) would be able to get the application approved to receive that data from the OS/App providing it. The application would be able to act just as it does not, except with the security. Copy/Paste would be one bit that would likely have to be approved when going from one application (e.g. Notepad) to another (e.g. Wordpad, Vi, Emacs, etc.), but not within itself - the same instance of the program.

IMO, this sounds nice in theory, just like micro-kernels do.

In practice, things are not that simple. First, malware usually employs some bugs in applications. E.g. if application is going to "open" access via clipboard and has a bug in conversion function, it is vulnerable. Plus, bug still can be in the API.

Also, this "opening" is sometimes quite impossible. E.g. consider sharing of mouse. Any single GUI API I know supports something called "mouse capture" - when application activates it, it gets mouse messages until capture is released.

If any application "forgets" to release capture, GUI is basically frozen.

Well, not in Win32, where it is fixed by basically releasing the capture by API when all mouse buttones are released, but AFAIK X11 has exactly this problem.

And this is just example of what I mean by sharing. You could find many more examples of similar sharing - and no, you cannot establish some "open channel" security here. Even apps that do NOT capture the mouse at all are affected.