Hi All,
First, I apologise if this isn't a kernel question, but I think it is related.
Slackware 10 base, 2.6.15.6
I am normal user, in groups users and wheel. Why can I do this:
nick@linuxamd:nick$ which ls
/usr/bin/ls
nick@linuxamd:nick$ ls -lsa /usr/bin/ls
0 lrwxrwxrwx 1 root root 12 2004-07-22 22:52 /usr/bin/ls -> ../../bin/ls
nick@linuxamd:nick$ cd /bin
nick@linuxamd:bin$ sudo chmod 111 ls
nick@linuxamd:bin$ ls -lsa ls
76 ---x--x--x 1 root bin 72608 2004-03-16 02:08 ls
I shouldn't be able to execute 'ls' as I can't read it, shouldn't it?
Nick
--
"Person who say it cannot be done should not interrupt person doing it."
-Chinese Proverb
On Friday 17 March 2006 18:07, Felipe Alfaro Solana wrote:
> > I shouldn't be able to execute 'ls' as I can't read it, shouldn't it?
>
> Nop... you can execute binaries even if the read permission is not
> granted. Note that I said "binaries". Shell script files need read and
> execute permission, since they must be read by a shell interpreter in
> order to get executed.
Hi Felipe,
First, apologies as this isn't kernel issue (but related, I suppose).
Yes, I see now after much messing about. Why then are most binaries chmod
755? Who would need (why) to read a [system] binary?
Nick
--
"Person who say it cannot be done should not interrupt person doing it."
-Chinese Proverb
On 3/17/06, Nick Warne <[email protected]> wrote:
> Hi All,
>
> First, I apologise if this isn't a kernel question, but I think it is related.
>
> Slackware 10 base, 2.6.15.6
>
> I am normal user, in groups users and wheel. Why can I do this:
>
>
> nick@linuxamd:nick$ which ls
> /usr/bin/ls
> nick@linuxamd:nick$ ls -lsa /usr/bin/ls
> 0 lrwxrwxrwx 1 root root 12 2004-07-22 22:52 /usr/bin/ls -> ../../bin/ls
> nick@linuxamd:nick$ cd /bin
> nick@linuxamd:bin$ sudo chmod 111 ls
> nick@linuxamd:bin$ ls -lsa ls
> 76 ---x--x--x 1 root bin 72608 2004-03-16 02:08 ls
>
>
>
> I shouldn't be able to execute 'ls' as I can't read it, shouldn't it?
>
> Nick
You have x permission, you can execute. That's the rules.
Now a shell script, ...
On Friday 17 March 2006 18:12, Linda Walsh wrote:
> Don't confused the kernel's access with your access.
> Execute-only means user can't read it. The kernel isn't restricted
> by the file permissions.
Ah! I see. Explained perfectly.
Thanks,
Nick
--
"Person who say it cannot be done should not interrupt person doing it."
-Chinese Proverb
Nick Warne wrote:
> 76 ---x--x--x 1 root bin 72608 2004-03-16 02:08 ls
>
> I shouldn't be able to execute 'ls' as I can't read it, shouldn't it?
Of course you can execute it because you have execute permission. Lack
of read permission just prevents you from read()ing the file.
On Fri, 2006-03-17 at 18:11 +0000, Nick Warne wrote:
> On Friday 17 March 2006 18:07, Felipe Alfaro Solana wrote:
> > > I shouldn't be able to execute 'ls' as I can't read it, shouldn't it?
> >
> > Nop... you can execute binaries even if the read permission is not
> > granted. Note that I said "binaries". Shell script files need read and
> > execute permission, since they must be read by a shell interpreter in
> > order to get executed.
>
> Hi Felipe,
>
> First, apologies as this isn't kernel issue (but related, I suppose).
>
> Yes, I see now after much messing about. Why then are most binaries chmod
> 755? Who would need (why) to read a [system] binary?
Well, I guess you can't ptrace an executable that you can't read.
# cd /bin
# ls -l ls
-rwxr-xr-x 1 root root 80008 2006-03-02 15:08 ls
# chmod 711 ls
# ls -l ls
-rwx--x--x 1 root root 80008 2006-03-02 15:08 ls
$ cd /bin
$ ls -l ls
-rwx--x--x 1 root root 80008 2006-03-02 15:08 ls
$ gdb
GNU gdb 6.4-debian
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i486-linux-gnu".
(gdb) file /bin/ls
/bin/ls: Permission denied.
(gdb)
# chmod 755 ls
(gdb) file /bin/ls
Reading symbols from /bin/ls...(no debugging symbols found)...done.
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb)
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.
-- Steve
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
On Fri, 2006-03-17 at 10:43 -0800, Linus Torvalds wrote:
>
> 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.
Yep, I agree whole heartily. I should have stressed the "little" part
in the above quote. "might make your system a __little__ more secure.".
I didn't want to get into the details that you described, but you are
entirely right. I just wanted to note that it does stop someone at some
level. But it's more of an annoyance to someone with a little more
experience in hacking into a computer.
But since it does stop some amateur's does give it some weight to
actually do it. But it is far from actually protecting yourself from a
more devious cracker.
But thanks for the critical disclaimer.
-- Steve
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? Does the environment get cleared when you exec a suid
program? Or does the dynamic linker just notice euid != uid and ignore
the LD environment variables? If so then would adding the sgid bit and
making the binary owned by a powerless group effectively prevent this
attack vector to read it?
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
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
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
>> > 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.
>>
[..]
>> 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.
>>
>Yep, I agree whole heartily. I should have stressed the "little" part
>in the above quote. "might make your system a __little__ more secure.".
-rws--x--x 1 root root 1847788 Sep 16 14:58 /usr/X11R6/bin/Xorg
I never could figure out what this permission mask was good for.
Jan Engelhardt
--
On Friday 17 March 2006 21:44, Jan Engelhardt wrote:
> >Yep, I agree whole heartily. I should have stressed the "little" part
> >in the above quote. "might make your system a __little__ more secure.".
>
> -rws--x--x 1 root root 1847788 Sep 16 14:58 /usr/X11R6/bin/Xorg
>
> I never could figure out what this permission mask was good for.
Yes, my post was initiated by a question in this months RH magazine - somebody
asked why 'finger' on RH systems was chmod 0711 and how/why ordinary users
could still run it. Shadowman didn't know and I was stumped too.
Nick
--
"Person who say it cannot be done should not interrupt person doing it."
-Chinese Proverb
On Fri, Mar 17, 2006 at 06:11:01PM +0000, Nick Warne wrote:
>
> Yes, I see now after much messing about. Why then are most binaries chmod
> 755? Who would need (why) to read a [system] binary?
The system binaries are normally not considered secret. (You can
download source for any of them.) So why prevent anyone from reading them?
Reading the binaries are convenient for copying them, or backing them
up. This don't happen often, but there is no need to make life difficult
as these files contain no secrets.
Similiarly - lots of files in etc could be made root only. But
there is no need. Making more stuff root only also force people to
use root more often, which is a bad thing.
Helge Hafting