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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.