Hi,
On Fri, Mar 17, 2006 at 12:11:35PM -0800, Linus Torvalds wrote:
(...)
> 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.
Personnally, I'm used to limit all permissions to the least needed. And
particularly, no executable except shell scripts have the read permission
for others. I must say that I do this in reduced environments (less than
20 MB root image) where it improves security : when I was a student,
I found it so much useful to simply copy every shell or suid program
to disassemble them or simply try to crash them and dissect their
cores that I know I couldn't have gotten some root priviledges if at
the beginning I could not have had access to this precious information.
Also, during a security audit, I had the opportunity to abuse a web
server to retrieve application executables in which paths and IP
addresses were hard-coded. Once again, this would not have been
possible with a chmod -r.
But users should be aware that information provided under /proc/self
to those binaries is reduced. Bash does not support /dev/stdin and
friends if it is unreadable, because it replaces this with
/proc/self/fd/0 which is unreachable.
That said, I tend to agree with you. Every now and then we see
a /proc or ptrace exploit or something like this which lets you
dump the binary, so chmod -r is not the universal solution to
local attacks.
> Linus
Cheers,
Willy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
