Now to fix archivers [LWN.net]

Now to fix archivers

Posted Feb 27, 2009 16:00 UTC (Fri) by hppnq (guest, #14462) [Link]

There are two suggestions for tagging any file as untrusted in the original article: SELinux tagging and having an 'untrusted downloads file area'.

These two "tagging" methods indicate that you already know which files are trusted and which files are not trusted. So the question remains.

As to when one would restore the original bits, I suggested a dialog for doing exactly that in my original post.

And I asked the reasonable questions: what problem do you think you have solved, and how many times will you solve it?

There is nothing very insecure about a user downloading or even unpacking an archive -- except of course if you suddenly start to treat certain file attributes, like execute bits or mime types, in a new and special way.

Now to fix archivers

Posted Feb 27, 2009 16:42 UTC (Fri) by liljencrantz (subscriber, #28458) [Link]

How many times will this problem be solved? How many times can any problem be solved? At most one, of course. If a problem is solved, it is by definition solved and in no need of being solved. But in this case, it is a superbly silly question that makes me wonder if you understand the reason why we have computer security mechanisms at all. Your question seems to assume that the problem of computer security is a problem with one single solution that will resolve every issue for the rest of eternity. Not going to happen.

The problem that is partially solved is the problem of computer security. Specifically, it slightly improves the security in the situation of an Internet connected desktop computer with a non-experienced user, where it is currently far too easy to use social engineering to infest a great number of machines with trojans because of security policys that currently make it far to easy to run arbitrary executables downloaded from the Internet.

What has been proposed is another partial solution, and I'm sure more partial solutions will be created in the future. It's an endless balance between security and convenience.

Now to fix archivers

Posted Feb 27, 2009 18:23 UTC (Fri) by hppnq (guest, #14462) [Link]

I am afraid you do not really understand what I mean. I was asking how many times you expect users to go through what could be easily perceived as a pointless dialog, and what exactly is accomplished by going through this dialog.

Those who believe that we can use the execute bit to indicate a certain level of trust are indeed forced to also take into account previously completely unrelated things, like permissions of archived files. Remember the security problem addressed here is about a kind of file that used to only be meaningful in a desktop environment. By requiring that desktop launchers be actual executables we have not really solved the actual problem at all, but I am all of a sudden stuck with a whole bunch of executables and a security policy that says "You trust all your executables".

There is no dialog on earth that could repair this.

So how would your dialog handle malicious RPM scripts?

Now to fix archivers

Posted Feb 27, 2009 23:43 UTC (Fri) by liljencrantz (subscriber, #28458) [Link]

Ok. Rereading your comment, it still seems to me that my interpretation is by far the more natural one. But let's move on.

The simple answer to the question of how many times the question should be asked is simple: As long a no executable file is created, zero. If an executable file is created, the user should be prompted for confirmation once. The exception to this is with .desktop files, for which the prompt is shown when the file is first executed, and not when saved. Preferably, when a user is asked for confirmation and and gives it, the untrusted flag should be stripped; if the file is indeed evil, the damage is already done.

As for evil RPM:s, they are already handled by the package managers of today - packages that are not signed by a known key will not install without an extra override switch.