From: Willy Tarreau <willy@w.ods.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Phillip Susi <psusi@cfl.rr.com>,
Steven Rostedt <rostedt@goodmis.org>,
Nick Warne <nick@linicks.net>,
Felipe Alfaro Solana <felipe.alfaro@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: chmod 111
Date: Fri, 17 Mar 2006 21:56:21 +0100 [thread overview]
Message-ID: <20060317205621.GF21493@w.ods.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0603171202240.3618@g5.osdl.org>
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
next prev parent reply other threads:[~2006-03-17 20:58 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-17 17:46 chmod 111 Nick Warne
[not found] ` <6f6293f10603171007vbf752e5n8a3d6f2d65e0a1e7@mail.gmail.com>
2006-03-17 18:11 ` Nick Warne
2006-03-17 18:26 ` Steven Rostedt
2006-03-17 18:43 ` Linus Torvalds
2006-03-17 18:55 ` Steven Rostedt
2006-03-17 21:44 ` Jan Engelhardt
2006-03-18 12:42 ` Nick Warne
2006-03-17 19:38 ` Phillip Susi
2006-03-17 20:11 ` Linus Torvalds
2006-03-17 20:27 ` Nick Warne
2006-03-17 20:56 ` Willy Tarreau [this message]
2006-03-18 14:09 ` Helge Hafting
2006-03-17 18:12 ` Joshua Hudson
[not found] ` <441AFBF5.7010009@tlinx.org>
2006-03-17 18:14 ` Nick Warne
2006-03-17 18:18 ` Phillip Susi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060317205621.GF21493@w.ods.org \
--to=willy@w.ods.org \
--cc=felipe.alfaro@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nick@linicks.net \
--cc=psusi@cfl.rr.com \
--cc=rostedt@goodmis.org \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox