LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   LinuxAnswers Discussion (http://www.linuxquestions.org/questions/linuxanswers-discussion-27/)
-   -   DISCUSSION: SUID - HOWTO (http://www.linuxquestions.org/questions/linuxanswers-discussion-27/discussion-suid-howto-321485/)

krishvij 05-08-2005 09:52 PM

DISCUSSION: SUID - HOWTO
 
This thread is to discuss the article titled: SUID - HOWTO

Artanicus 06-15-2005 03:42 AM

Um, please do correct me if im wrong, as this is confusing me severely..
We fisr make the script, and suid it, yes, that I can understand. The thing is, why do the commands used have to be suid too?
exec suid script > child process with uid 0 > exec the commands as uid 0
So why are the tools suid too? A thought comes to mind, that now that the tools are suid, any user can use adduser and so on with the suid binaries?
What am I getting wrong here? (:

krishvij 06-16-2005 03:23 AM

Hi Artanicus,

Thanks for your comment. Would like to clarify a few things here. What I have used is just an example to understand the concept of SUID. It is not to be taken as is and applied onto the production systems. Basic idea is to make people understand the concept of SUID.

One part of what you have said is right. If you apply whatever I have said in my example as is, then yes, anyone and everyone can use the suid'd useradd, chpasswd etc without being root. This is actually a security loophole. so, probably u can just copy these binaries into the home directories of each user who needs to use it and make them as SUID instead of making the /usr/bin binaries as SUID. Further, the same things can also be done by using sudo in a more secure way.

With regard to your query of a process execing another one, the same UID's do not pass on.That means, if adduser.sh is suid'd as root, then it will run as UID 0. But, if it calls useradd and if useradd is not suid'd, then useradd will take the UID of the user and so, it will not be able to write to the /etc/passwd file. Just try out the same example by setting SUID for just the adduser.sh and then execute. You will find that the users will not be added. Of course, login as an unpreviliged user and try it out :-)

Artanicus 06-16-2005 03:40 AM

Thanks this clarified alot.. (:

Only one question remains, why suid the script in the first place if the only real root tools we are using are suid too? Can't the script run suid binaries if it isn't suid itself?

Sorry for the troublesome questions, but your great article confused me a tad, but on some level I now understand how suid works, thanks for that.. (:

krishvij 06-16-2005 06:41 AM

Hi Artanicus,

There is no need for the adduser.sh to be suid'd. Guess I got a little bit carried away while writing this article :-). It is not necessary for adduser.sh in my example to be suid'd. It will still work. Good to note that the info helped you. That gives me a lot of satisfaction and also, makes me believe that the effort I spent on writing that article was worth it.

oriate 06-17-2005 07:13 AM

Hi,krishvij,
As you said,such a program cannot get a root shell:
#include <unistd.h>

int main()
{
char *name[2];
name[0] = "/bin/sh";
name[1] = 0;

execve(name[0],name,0);
}

I tried, yes, I cannot get root shell, but how do buffer flow get root shell using suid ?
Thx

krishvij 06-18-2005 12:33 AM

every process is just a running instance of a program. it needs to have a UID/GID (just like an ID card) while running so that the OS can decide what the process can access and what it can't.

in unix/linux, when a user executes a program, the OS checks if it has a SUID/SGID set on it. If it is set, then it looks at the owner/group owner of the program, gets the corresponding UID/GID and then, runs the process with these UID/GID. Otherwise, it starts the process by exporting the logged in user's UID/GID.

oriate 06-18-2005 06:43 AM

Can you explain how "buffer flow" get the root shell?
Thx

donald.j.wood 06-21-2005 02:36 PM

There is a big problem with this example beyond the fact that SUID is not required. SUID/SGID is considered insecure, and as such the Linux kernel ignores the bit when running shell scripts.

oriate 06-21-2005 10:49 PM

Quote:

Originally posted by donald.j.wood
There is a big problem with this example beyond the fact that SUID is not required. SUID/SGID is considered insecure, and as such the Linux kernel ignores the bit when running shell scripts.
I am sorry, I cannot much understad you.
"shell scripts" do you mean "shell code" ?
But how does the kernel know whether a piece of code is shell code?

Michael Slade 02-28-2009 07:38 AM

Please do not follow the directions in this post
 
This post demonstrates a clear misunderstanding of setuid and it security implications. If followed, the directions given will allow any user with local access to the machine, to change the password of any other user, including root. Thus it essentially disables all security.

When most programs have their setuid bit set, they will execute as the owner of the program file rather than the executing user. The exceptions are scripts - basically any programs whose first line starts with "#!".

I won't explain further than this, but please see http://en.wikipedia.org/wiki/Setuid if you want to know more.

Mick.

ackitkeys 12-15-2010 12:13 PM

Quote:

Originally Posted by oriate (Post 1700316)
Hi,krishvij,
As you said,such a program cannot get a root shell:
#include <unistd.h>

int main()
{
char *name[2];
name[0] = "/bin/sh";
name[1] = 0;

execve(name[0],name,0);
}

I tried, yes, I cannot get root shell, but how do buffer flow get root shell using suid ?
Thx


Code:

#include <sys/types.h>
#include <unistd.h>

int main()
{
        setuid(0);
        setgid(0);

        char *name[2];
        name[0] = "/bin/sh";
        name[1] = 0;

        execve(name[0],name,0);
}


kvmreddy 12-21-2010 01:23 PM

@Michael Slade
When most programs have their setuid bit set, they will execute as the owner of the program file rather than the executing user. The exceptions are scripts - basically any programs whose first line starts with "#!".

Above statemet is mostly correc, but one exception is perl script, which can start with #!.
Check bellow link, there I explained with an example.

http://bashscript.blogspot.com/2010/...rmissions.html


All times are GMT -5. The time now is 02:20 AM.