LinuxAnswers DiscussionThis forum is to discuss articles posted to LinuxAnswers.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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? (:
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 :-)
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.. (:
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.
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.
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.
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?
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 "#!".
@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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.