Issue #18 April 2006

Ask Shadowman

It's been a very busy month in these parts. We've released a spiffy new version of Fedora and had a conference about it. We've stated our intention to purchase JBoss, and subsequently watched the blogging history of JBoss change before our eyes. Fun, fascinating, exciting times.

So why in the name of Great Caesar's Ghost is Shadowman still obsessing about the permissions of a handful of stupid executables?

For those of you who joined late... last month, Shadowman posed some questions. Why are executables set to have permissions of 755, when they'd run just as well with permissions of 111? Why is finger set to have permissions of 711? And why can't Shadowman just leave well enough alone, anyway?

It's like a thread hanging out of a nice cable-knit sweater. It annoys you, so you pull it. And you pull it and you pull it and you pull it. And then, next thing you know, you're standing there in your skivvies, holding a fistful of yarn.

So Shadowman's gonna keep pulling on that thread, and we'll see where it leads. And then you'll never have to hear about any of this nonsense ever again. Shadowman's honor.

Got a question that you'd like Shadowman to answer? Ask him.


Gav wrote in:

I don't know why linux's perms on finger are 711 but on HP-UX they are 755, not an answer but it may help.

Ritesh wrote in:

Shadowman, maybe it's RH/Fedora specific and you have a good reason to do that. But at least under Debian it is 755.

Meehan wrote in:

The permission on the 'finger' command is set to -rwx--x--x probably because of a mistake. It's not that way in SuSE's distributions.

To which Shadowman replies:

Okay, so that helps. It's entirely possible that we're insane, and that somewhere along the way someone set the permissions on /usr/bin/finger to be 711, and nothing ever broke, so no one has touched it since. At least that's an explanation that makes sense to Shadowman. And since no one has yet given Shadowman a better answer, that's the one we're going with: "someone changed it, only the fates know why, and only an idiot would worry about it a minute longer."

But what about Shadowman's initial confusion that executables could only be run if the executable files themselves could be read? Lots of answers on this one.

Ian poses the question more directly:

The question could be put the other way. Why do other binary applications have 755 permissions when they only require 111?

George Hacker responds succinctly:

Concerning your answer - you *can* execute a program without read permission. Compiled programs work without read permission because when they are exec()-ed by the shell kernel loads them into memory and executes their binary code. The only time you need read permission on a program to execute it (in addition to execute of course) is when it is a script of some sort: bash, perl, etc. In this case the interpreter is exec()'s and your code has to be readable by the interpreter to run it.

And Grant elaborates further:

Maybe because some 20-odd percent of the executables in /usr/bin (e.g. the scripts) would stop working if you blithely changed them to 711...

gimfc4* file /usr/bin/* | wc -l
2042
gimfc4* file /usr/bin/* | grep script | wc -l
434

To which Shadowman replies:

Now we're getting somewhere. Some programs in "/usr/bin" are binaries, but some are just plain old scrips.

Binary executables that don't require an interpreter can be executed so long as the execute bit is set for a user running the program. Since finger is a binary, it can thus run perfectly happily with permissions of 711.

Scripts, however, are not binaries, and must therefore be read by the user in order to be fed to the interpreter than runs them.

In practice, this means that some 20 percent of "executables" must have read permissions set as well. But what about the other 80 percent? Why wouldn't they be set to 711, like finger -- or even 111, for that matter?

As usual, the readers do better homework than Shadowman ever does.

Nick wrote in:

This is strange. I was under the same assumption as you. I have mailed the Linux Kernel Mailing List with the question.

So on LKML, Nick asked the question:

Why then are most binaries chmod 755? Who would need to read a [system] binary?

To which Steven Rostedt replied:

Well, I guess you can't ptrace an executable that you can't read.

# cd /bin
# ls -l ls
-rwxr-xr-x 1 root root 80008 2006-03-02 15:08 ls
# chmod 711 ls
# ls -l ls
-rwx--x--x 1 root root 80008 2006-03-02 15:08 ls

$ cd /bin
$ ls -l ls
-rwx--x--x 1 root root 80008 2006-03-02 15:08 ls
$ gdb
GNU gdb 6.4-debian
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i486-linux-gnu".
(gdb) file /bin/ls
/bin/ls: Permission denied.
(gdb)

# chmod 755 ls

(gdb) file /bin/ls
Reading symbols from /bin/ls...(no debugging symbols found)...done.
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb)

So I guess if you need to debug a system binary, you need it readable. But I guess that can also be a security problem, and having system binaries not readable might make your system a little more secure.

At which point Linus himself intervened, and said:

NOTE! The kernel does not guarantee that you can't read execute-only binaries.

In particular, it's fairly easy to create a shared library that replaces a system library (LD_LIBRARY_PATH) and then just dumps out the binary image.

So anybody who thinks that 0111 permissions are somehow "more secure" than 0755 is just setting himself up for disappointment. You're much better off just having all binaries be 0755 and getting the security through other means.

Basically, you should think of the "executable" bit as a way to say "this file is appropriate for execve(), and btw, that does imply that we'll need to read it into memory too". You should _not_ depend on it for security, although dropping the readability bits will mean that certain -trivial- programs won't be able to read it.

For example, making a binary unreadable is a perfectly good way to stop a web browser or other interface from exporting it outside the machine: but it's not so much about security as about _accidental_ leaking.

So from a security standpoint, you're much better off thinking "executable means readable", than lulling yourself into some false sense of security.

All of which makes Shadowman say:

There you have it. It's perfectly possible to set your executables to have permissions of 111, but it prevents you from doing potentially useful things like debugging with ptrace. Not only that, but it doesn't even buy you any protection, because the kernel can easily be made to read the binary file image anyway. Linus says so.

Finally, let's give the last word to the gentleman who went straight to The Source to answer the question for himself.

Burt wrote in:

I don't know why, but here's how it works (in the 2.4 kernel anyhow:)

open_exec from exec.c:
                if (!(nd.mnt->mnt_flags & MNT_NOEXEC) &&

                    S_ISREG(inode->i_mode)) {
                        int err = permission(inode, MAY_EXEC);
                        if (!err && !(inode->i_mode & 0111))
                                err = -EACCES;
                [ other checks ]

Inside vfs_permission (called by permission):
        if (((mode & mask & (MAY_READ|MAY_WRITE|MAY_EXEC)) == mask))
                return 0;

So the file either has to have the right execute bit set, or has to have at least one execute bit set (in the case of CAP_DAC_OVERRIDE).