Desktop malware risk gets raised and patched

Posted Feb 26, 2009 18:36 UTC (Thu) by tshow (subscriber, #6411)
In reply to: Desktop malware risk gets raised and patched by drag
Parent article: Desktop malware risk gets raised and patched

The problem is that once you've downloaded the file, it automatically gets assigned the same trust level as all of your other files.

Why not take advantage of the multiuser nature of the underlying system? Make any program that can download things (email clients, web browsers, instant messenger programs, IRC clients...) run as a separate user, and save files under that username.

It could be something as simple as your user name with :untrusted appended to it.

It wouldn't be too hard to train Gnome and KDE to know that files from user "username" are normal, but files owned by "username:untrused" have come from the great wilds beyond the fence and require the user to bless them explicitly before they can be executed. The underlying system doesn't need training at all if the umask is set properly.

It uses the existing infrastructure, and it requires relatively few changes to work. Most of the effort is in the setup; adding a user would require setting up two accounts, one of which (the untrusted account) would be a locked no-login account with no home directory.

From the command line, the user could "bless" files with chown(1), and I suspect the "stupid people get what they deserve" rule applies to someone who opens a terminal and directly invokes a downloaded script without vetting it. For actual executables, you'd be foiled by the lack of group/other execute permission in the umask if you tried to run it.

On the GUI side, all that really needs to be done is the launchers need to check to see if the uid of the file is suspicious (which they ought to be doing anyways...), and if so, bring up an appropriate dialog, that could be one of:

- the file is owned by some other (non-root) user on the system and is effectively executable, do you want to [make & run owned copy] [run] [cancel]

- the file is owned by your untrusted alter-ego, and is not executable, do you want to [take ownership & open] [open], [cancel]

- the file is owned by your untrusted alter-ego, is executable or contains a script, dialog has a big picture of your parents looking stern, [pick up the soap][flee]

It might even be worth saying you simply can't bless executable files owned by your untrusted alter-ego without dropping to the command line and using chown.

The other part of this is that making magic executables with .desktop was a mistake. It wouldn't have been hard to use "shabang" to make .desktop files legitimately executable through the standard system, at which point they'd even (!) work properly from the command line, and they'd inherit the security mechanisms built around file access. Every alternate path to execution in the system is another possible point of failure for security.

Desktop malware risk gets raised and patched

Posted Feb 26, 2009 19:10 UTC (Thu) by drag (guest, #31333) [Link]

Well the nice thing about taking advantage of Selinux (or Smack, or Apparmor, or some desktop-specific LSM layer) is that you can apply the security contexts to applications without having to do extensive rewriting of them or whatnot.

So typically a application is launched when you double click on a file. As long as that application gets launched as a separate process then it's (relatively) easy to isolate that process and restrict it's movements. As long as the program behaves itself this should be all completely transparent to the end user and would not require any rewrite of the application, barring any bugs. That is you get the security 'for free' without bugging the user with dialogs or having applications run in a odd manner. This should work with very little impact to the end user and should apply (relatively) easily to most programs.

Now the problems you run into are programs that try to 'optimize' things by launching new instances in threads. Programs like your web browser.

The other way this breaks down is if you have a running program and you go to open up a file through the application file dialog. You can get around this by making the file dialog aware of what is going on and adding a notification to bug the user or something like that. That shouldn't be terrifically difficult for the KDE and Gnome applications, but it would be troublesome for applications that use their own file dialogs (OO.org, for example).

----------------------------

The other way to go about it would be trying to take advantage of some of the work going into trying to standardize the anti-virus stuff.

That is efforts to get on-demand scanning into the kernel were the kernel can intercept files being accessed and defer to a userland program, which then can allow or disallow the access.

Then you can intercept the programming accessing a risky file and then pop up a dialog warning the user.

Or you could program that into nautilus, konquerer, and the file dialogs to check that stuff..

But I don't like that because that's annoying and will be just another dialog for a user to ignore. They downloaded the file and while it may be risky they still want to find out what is in it... so by opening it in a application is the only way they could know what it really is. So your forcing the end user to make security decisions without allowing them the information they need to make the correct decision. If they make a bad decision and it's a malicious file then it still gets read into a program with full user privileges. So it's a bit of a mess.