From: Nick Warne <nick@linicks.net>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Phillip Susi <psusi@cfl.rr.com>,
Steven Rostedt <rostedt@goodmis.org>,
Felipe Alfaro Solana <felipe.alfaro@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: chmod 111
Date: Fri, 17 Mar 2006 20:27:43 +0000 [thread overview]
Message-ID: <200603172027.43968.nick@linicks.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0603171202240.3618@g5.osdl.org>
On Friday 17 March 2006 20:11, Linus Torvalds wrote:
> 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.
Well, I thought after making my post and read the first few replies that I
made 'dork of the week' post.
But now I am glad I did post. I have learnt a lot.
Thanks everybody. A real insight to the sub-system.
Nick
--
"Person who say it cannot be done should not interrupt person doing it."
-Chinese Proverb
next prev parent reply other threads:[~2006-03-17 20:28 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 [this message]
2006-03-17 20:56 ` Willy Tarreau
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=200603172027.43968.nick@linicks.net \
--to=nick@linicks.net \
--cc=felipe.alfaro@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--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