chmod u+s confusion

chmod u+s confusion

[Chris Largret]

Hey,

I've used chmod to set suid for a file before and thought I had a good
grasp of how it worked. Recently I've found myself trying to set it for
a script. Here's what I see ($ denotes user account, # is root):

$ echo -e '#!/bin/sh\n\nwhoami'>whoami.sh
# chown root:root whoami.sh
# chmod 4755 whoami.sh
$ ./whoami.sh
chris
# chmod u+s `which whoami`
$ whoami
root

[Note: u+s is equivalent to 4xxx, sorry for the change-up]

So... why doesn't this make whoami.sh run the 'whoami' program as root?
It's worked for the programs whoami, and is a common mode set on
cdrecord.

Thanks for your help (and enlightenment).

--
Chris Largret <http://daga.dyndns.org>

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: chmod u+s confusion

[David Fierbaugh]

I'd have to actually do a little playing around to make sure, but I believe 
that whoami is specifically written to NOT take SUID into account. It figures 
out exactly who ran the process which called it.

This prevents faking out whoami into saying everyone is root.

Why?
Let's say you have a script that runs whoami to determine what 
access/control/etc a user should be given. If an attacker could manage to 
fake whoami into always saying the user was root by using suid, then they now 
have administrative access to whatever that script does.

This would be a bad thing.

You might also want to take a look at /bin/id

--David

On Friday 07 April 2006 09:41, Chris Largret wrote:
> Hey,
>
> I've used chmod to set suid for a file before and thought I had a good
> grasp of how it worked. Recently I've found myself trying to set it for
> a script. Here's what I see ($ denotes user account, # is root):
>
> $ echo -e '#!/bin/sh\n\nwhoami'>whoami.sh
> # chown root:root whoami.sh
> # chmod 4755 whoami.sh
> $ ./whoami.sh
> chris
> # chmod u+s `which whoami`
> $ whoami
> root
>
> [Note: u+s is equivalent to 4xxx, sorry for the change-up]
>
> So... why doesn't this make whoami.sh run the 'whoami' program as root?
> It's worked for the programs whoami, and is a common mode set on
> cdrecord.
>
> Thanks for your help (and enlightenment).
>
> --
> Chris Largret <http://daga.dyndns.org>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.linux-learn.org/faqs
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: chmod u+s confusion

[Chris Largret]

On Fri, 2006-04-07 at 08:42 +0000, David Fierbaugh wrote:
> I'd have to actually do a little playing around to make sure, but I believe 
> that whoami is specifically written to NOT take SUID into account. It figures 
> out exactly who ran the process which called it.
> 
> This prevents faking out whoami into saying everyone is root.

I probably should have mentioned that this was just a PoC for what I was
trying to do. I'm actually trying to have the script create a file
someplace like /etc/cron.hourly. It has limited uses (and only my user
and root will be able to run it -- root group), but the script is
refusing to create the file.

> Why?
> Let's say you have a script that runs whoami to determine what 
> access/control/etc a user should be given. If an attacker could manage to 
> fake whoami into always saying the user was root by using suid, then they now 
> have administrative access to whatever that script does.
> 
> This would be a bad thing.
> 
> You might also want to take a look at /bin/id

/usr/bin/id (where my id program is placed) still returns my username.

Thanks for the reply, but I'm still stumped :)

> > $ echo -e '#!/bin/sh\n\nwhoami'>whoami.sh
> > # chown root:root whoami.sh
> > # chmod 4755 whoami.sh
> > $ ./whoami.sh
> > chris
> > # chmod u+s `which whoami`
> > $ whoami
> > root

--
Chris Largret <http://daga.dyndns.org>

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: chmod u+s confusion

[Chris Largret]

On Fri, 2006-04-07 at 15:48 +0000, David Fierbaugh wrote:
> I would look at permissions of the folder you're trying to create the file in. 
> That seems like the likely candidate.
> 
> Can your script append to a file if it already exists? Should be a small 
> change to the code to do this, and might help diagnose the problem.

Found the answer on linuxsecurity.com
(http://www.linuxsecurity.com/content/view/119415/49/)

Any program that is set to run with the same privileges as its user can
be a huge security hole, so the kernel programmers have set out to
alleviate this threat a little. From my own tests, it appears to be
impossible to run a shell script (or any program through a system()
call) except as the user who is running the program/script. Any commands
processed by a prompt have their privileges downgraded to the executing
user.

I had tried my suid test with SH and Perl scripts as well as with a
quick C program. The Perl script and C program both used a system() call
to run "whoami" (in order to verify if the UID had changed due to the
use of SUID). The use of the system() call was forced to run as the
standard user, which gave the appearance of failure. It wasn't one.

The verdict: Use a compiled program and do things the right way if you
want to set the SUID bit. Avoid system() calls (even if they are only as
a test).

--
Chris Largret <http://daga.dyndns.org>

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: chmod u+s confusion

[Kari Hurtta]

> Hey,
> 
> I've used chmod to set suid for a file before and thought I had a good
> grasp of how it worked. Recently I've found myself trying to set it for
> a script. Here's what I see ($ denotes user account, # is root):
> 
> $ echo -e '#!/bin/sh\n\nwhoami'>whoami.sh
> # chown root:root whoami.sh
> # chmod 4755 whoami.sh
> $ ./whoami.sh
> chris
> # chmod u+s `which whoami`
> $ whoami
> root
> 
> [Note: u+s is equivalent to 4xxx, sorry for the change-up]
> 
> So... why doesn't this make whoami.sh run the 'whoami' program as root?
> It's worked for the programs whoami, and is a common mode set on
> cdrecord.
> 
> Thanks for your help (and enlightenment).
> 

Bash (/bin/sh) may be own check if it is run on root.

But there is also another problem with running setuid scripts.

It is following:

Lets assume that script is  named as "Script"

and file Script have first line

#!/bin/interpreter


When kernel gets execve("Script", ... ) system call, it check what
loader it should use. When program start with #! kernel instead
runs program given on that line and giving script file name as argument.
So it is like
	/bin/interpreter Script

is called.


Now there is problem (perhaps also other problems). If Script
is replaces with another file between /bin/interpreter is started
and when  /bin/interprete opens file given as argument, then
/bin/interpreter is opened and interpreting wrong file.

This is specially problem if Script is setuid root. Then /bin/interpreter
is execured as root.  Then it is better that file, what /bin/interpreter
is opened, is same than for which kernel started /bin/interpreter as root.


I do not know how linux hanles that. My impression that many systems
do not honor setuid bit on scripts because of this.


/ Kari Hurtta




-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs