The purpose of the executable permission

aardwolf · 2012-03-23 13:30:42

Hi,

What is the purpose behind the execute permission of Unix? Because if you can read it, you can always find a way to execute it anyway.

The read and write are pretty obvious.

If you can read a file, even if its execute permission isn't set and you don't have the rights to change the file permissions, you just copy it to your own machine, make it executable, and run it.

What does execute even mean? If it's Brainfuck code, then with read permissions your typical Brainfuck interpreter can execute it, no execute permission needed. Isn't running a Turing complete esoteric programming language considered executing? Or displaying an HTML file with JavaScript code in it...

There's probably something behind the execute permission that I don't know. The only way I come into contact with this permission, is in an annoying way: to enable it because it wasn't enabled already while I want to run it. What good (security) purpose does it serve in practice?

Thanks!

s1gma · 2012-03-23 13:55:12

Actually, you can even execute a binary without execute permission, as if it was an interpreted script (the interpreter being ld-linux) :

$ cp /bin/ls .
$ chmod ugo-x ls
$ ./ls
bash: ./ls: Permission denied
$ /lib64/ld-linux-x86-64.so.2 ./ls
# ... listing ...

I guess the use of this flag is to help shells, e.g not to clutter $PATH with files that are not meant to be executable, but are present in folders in $PATH.

My 2 cents.

aardwolf · 2012-03-23 13:56:50

s1gma wrote:

I guess the use of this flag is to help shells, e.g not to clutter $PATH with files that are not meant to be executable, but are present in folders in $PATH.
My 2 cents.

Good point! Thanks!

alphaniner · 2012-03-23 14:45:40

Maybe the main security aspect of the bit is limiting who can execute a file. Additionally, partitions can be mounted noexec. I did some brief testing, this prevents both standard (executable bit) execution and s1gma's method*:

data$ mount
...
/dev/mapper/VG0-lv_data on /home/testing/data type xfs (rw,noexec,...)
data$ pwd
/home/testing/data
data$ cp /bin/ls .
data$ ll ls
-rwxr-xr-x 1 testing users 109944 Mar 23 10:30 ls
data$ ./ls
bash: ./ls: Permission denied
data$ chmod a-x ls
data$ /lib64/ld-linux-x86-64.so.2 ./ls
./ls: error while loading shared libraries: ./ls: failed to map segment from shared object: Operation not permitted

So any partitions writable by non-priveleged users could be mounted noexec, preventing these exploits.

*Admittedly, I don't really understand what goes on here so it may not be noexec that causes it to fail.

Last edited by alphaniner (2012-03-23 14:49:33)

Leonid.I · 2012-03-23 16:12:26

From man 8 mount:

noexec Do not allow direct execution of any binaries on the mounted filesystem.  (Until recently it was possible to
              run  binaries  anyway  using  a  command like /lib/ld*.so /mnt/binary. This trick fails since Linux 2.4.25 /
              2.6.0.)

aardwolf · 2012-03-23 16:25:43

Leonid.I wrote:

From man 8 mount:

noexec Do not allow direct execution of any binaries on the mounted filesystem.  (Until recently it was possible to
              run  binaries  anyway  using  a  command like /lib/ld*.so /mnt/binary. This trick fails since Linux 2.4.25 /
              2.6.0.)

But that still doesn't stop you from, if you can read the file, copying it to your disk and setting it to executable there, right?

Leonid.I · 2012-03-23 20:59:01

Well, I was replying to alphaniner's post actually

Anyway, copying a file to your home dir of course allows execution (unless /home is mounted noexec), but then again, it's opensource, so you can build the program yourself...

Blµb · 2012-03-24 20:08:26

It isn't solely about security. You can execute anything you can read, it's always been this way.
s1gma is right in that it 'helps' shells etc. figure out what to execute

The 2 security aspects I can think of are:
a) You want an executable to be setuid for some user, but you only want people from a specific group to be able to execute it as setuid.
They can still execute it by copying, but the setuid flag gets lost, so they'll be executing it as themselves, rather than the user who owned the original file.

b) Help against "accidental" execution.
For instance, a good reason to mount something 'noexec' is because it might contain binaries from other machines, where you don't know what's going on.
So if you want to execute, you want to specifically get a snapshot of the file at your machine, then check if it's really what you want (sha1/md5 sum etc), then finally execute it - most likely by setting the execute permission, then running it.

Another use for it - in a completely different manner - is for example an init script directory, like you have it in slackware (or at least when I used slackware it worked that way).
Where all init scripts you wanted to start at boot time where simply marked executable, and the others you had to execute by hand using a shell (sh /etc/rc.d/foo start or whatever it used to be.)

Last edited by Blµb (2012-03-24 20:09:10)

Arch Linux

#1 2012-03-23 13:30:42

The purpose of the executable permission

#2 2012-03-23 13:55:12

Re: The purpose of the executable permission

#3 2012-03-23 13:56:50

Re: The purpose of the executable permission

#4 2012-03-23 14:45:40

Re: The purpose of the executable permission

#5 2012-03-23 16:12:26

Re: The purpose of the executable permission

#6 2012-03-23 16:25:43

Re: The purpose of the executable permission

#7 2012-03-23 20:59:01

Re: The purpose of the executable permission

#8 2012-03-24 20:08:26

Re: The purpose of the executable permission

Board footer