Re: [Nautilus-list] Idea for Nautilus and GMC.

[Zak McGregor <zak mighty co za>]

On 23 May 2001 22:27:25 -0300
Evandro Fernandes Giovanini <efgbr terra com br> wrote:

> what if someone distributes a malicious elf/a.out binary as
> foo-1.5-2.i386.rpm the user will open the file with gmc/nautilus and
> instead of telling the user "no viewer capable of opening this file"
(or
> whatever it says when someone runs a binary w/o the execute bit) it
will
> set the execute bit and run the file. boom!
> 
OK people. Nautilus or GMC or chmod setting the executable bit on an
executable file is exactly the same thing. Why does no-one here want
chmod to pop up a warning or force the user to be root before setting +x
to the file? One great strength of Linux/un*x-like systems is the
permissions on files, which means that on a decently setup box, minimal
damage can be caused by a normal-level user.

Anyway, the point is, the difference that is causing all the fuss here
is that with chmod +x I have to get to a command-line, type in chmod +x,
and then ./filename to run the file (for example), while the drive here
is for Nautilus, GMC, whatever to make the action of setting the
executable bit for the user, instead of steps 1 and 2 above. In other
words, the end result is the same, but the methodology is different.
Concerns about it lowering the overall security of a system or making
email-propagated viruses a reality are just unfounded - this idea
facilitates these problems only as much as chmod does, no more.

Where the difference does come into play is in the perception of how
easy it becomes to execute a program. Nautilus et al would just provide
an interface to chmod, to all intents and purposes. It is not magically
bestowing on the user powers to circumvent any security level
restrictions the user has. It is not giving the user any rights which he
doesn't already have on the system.

Problems will arise if any app decides to chmod +x and execute files
without the user's consent, without prompting. *That* would be a
different story altogether.

Now, for apps executed in such a way via Nautilus or GMC, perhaps it
would be a good idea to have a sort of chrooted environment for those
files to run in, and have the application revert the status of the file
*back* to whatever it was prior to the execution of it via whichever
interface was used to invoke it? That way, the clueless would only be
able to execute it via the interface, which would run it in a clean
environment and also protect the user from inadvertently running the
executable via any other means. If the user wants to run the program
through any other means, he would have to do the chmod +x himself,
leaving the situation no worse off than without these ideas implemented
in Nautilus...

Just another few cents from me...

Ciao

Zak

--
====================================================================
Zak McGregor
http://www.carfolio.com - Specifications of cars online. Over 7000!
--------------------------------------------------------------------
Of course my password is the same as my pet's name.  
My macaw's name was Q47pY!3, but I change it every 90 days.
====================================================================