From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: chmod 111
Date: Fri, 17 Mar 2006 18:44:33 UTC
Message-ID: <fa.CnxpikLFGmpY6aoa+q4RCsqd+1U@ifi.uio.no>
Original-Message-ID: <Pine.LNX.4.64.0603171036240.3618@g5.osdl.org>

On Fri, 17 Mar 2006, Steven Rostedt wrote:
>
> 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 you system a little more secure.

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.

			Linus

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: chmod 111
Date: Fri, 17 Mar 2006 20:12:33 UTC
Message-ID: <fa.dKMXudOp5sEUZjlvnB9c7XM88N4@ifi.uio.no>
Original-Message-ID: <Pine.LNX.4.64.0603171202240.3618@g5.osdl.org>

On Fri, 17 Mar 2006, Phillip Susi wrote:
>
> Linus Torvalds wrote:
> > 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.
> >
>
> What prevents you from injecting a shared library and manipulating a suid
> executable?

Suid executables do not accept LD_LIBRARY_PATH.

> Does the environment get cleared when you exec a suid program?

No, but the startup environment can tell if it's suid, and refuse to load
anything but the fixed environment, so it's _effectively_ cleared for a
subset of the environment strings.

Suid executables also get some special handling by the kernel (it will,
for example, refuse to dump core for them - another way to get readable
information from an executable). Similarly, you can't ptrace a suid
executable (a _third_ way of getting information from a execute-only
binary in general).

So suid executables are a separate issue: they actually _do_ have security
protection (regardless of whether they are marked "readable" or not).

And finally don't get me wrong - you _can_ build up security around the
executable bits, but it has to be a lot more involved than just assuming
that being unreadable means that nobody can see what a binary does. So for
example, you _can_ create a system where you only have a certain subset of
binaries that will be run (no debuggers), and where user-supplied binaries
simply won't execute (mounting any user-writable area no-exec, and make
sure that none of the executable loaders like /lib/ld.so will load a
non-exec image).

But in general, I'd say that is only applicable in some embedded
environments (you could have a special chroot'ed jail environment where it
could be very hard to read the binaries that you expose in the jail
environment, for example). It's not useful in something that gives shell
access and allows the user to create his own executable program files.

		Linus