setuid bit and unix scripts

[Yohhan]

Does the setuid bit not work for shell scripts?

I need a script to execute with the priviledges of the owner. So I use the setuid bit. However, this doesn't seem to work. I set the permissions exactly as they're set on the passwd program, but the script won't run under those permissions... it's running under the "other" set of permissions instead of with the permissions of the owner. Almost like the setuid bit did nothing at all.

Does this has something to do with the fact that scripts are executed under subshells? When I capture a list of the running processes, passwd shows the UID of root, while my script shows my own UID.

 

[drag]

The OS specificly disables setuid bit for scripts. It's a security risk, if you run a script as another user it also means that you can edit it. Once you edit it then you can set it up so that you can open up a shell using those permissions.

For example if you setup a script to run as root, it's very easy for a user to exploit that script and open a shell with root permissions without going thu proper security first. It leaves your OS ripe for crackers.

One thing you can do instead is setup sudo. You can use visudo to set it up so that certain commands within the script are allowed to run with "sudo command" allowances.

Setuid is very dangerous to play around with, it's was once a common weakness for Unix systems to run many setuid programs, in fact just having one can be considured a security risk unless you realy realy have to.

Another example is that newer versions of cdrecord are setup to not to run if they have the setuid bit set. It was found that cdrecord had a exploitable flaw that could be exploited only when it was run as setuid and it was very common for people to do that in order to burn cds. (edit: actually I found out this feature is disabled on the kernel level in 2.6.8 series kernels due to the security risk...)

What are you trying to do? There is probably a better angle of attack that you can do. 90% of the time there is several other solutions to any one problem.


edit:
why you shouldn't run setuid scripts.

 

[Yohhan]

I'm trying to make a "drop box" script. The idea was to copy files from the home directories of other users into my home directory. The users need to be able to execute the script, but they shouldn't be allowed to read it. They simply run it and specify some options and a directory. The script then copies these files into the target directory which is in my home ~/. Once the files are copied, the users who copied them over shouldn't be able to access anything inside.

The setuid bit seemed like the right way to go, since they briefly need permission to copy files into my home folders.

Another idea I had was setting up a separate group for all users who need to run this script, and give them special permissions while running the script. However, I don't want them having access after the script runs, so I tried to insert a chgrp command at the end of the script, to disallow further access. However, it doesn't look like you can chgrp a file to a group to which you do not belong... unless you're root. So I'm back to the same problem.

 

[drag]

Well you can setup the sudoers file to do it.

Not completely sure on the syntax of the file, but you edit using the visudo command.

Like this (pretending you want them to copy their files to a folder named "deposit" in your home directory):

#! /usr/bin/env bash
# usage cpyohhan filename
/bin/cp $1 /home/yohhan/deposit/$1.`date +%s`
# note that %s in date is a GNU extension.

Name it cpyohhan, put it into /usr/local/bin
make the ownership yours and set the permissions: r-x------

Then in your sudoers file with the visudo command you add this line:
%cpyohhan ALL = (yohhan) NOPASSWD: /usr/local/bin/cpyohhan

And that will allow anybody that belongs to the group cpyohhan to execute the script /usr/local/bin/cpyohhan with your user's permissions, without being prompted for a password.

So then they can go "sudo cpyohhan filename"

OR you can go a entirely different route.

You can setup a third directory somewhere, were people can freely copy files to, but can read them. Probably setting the permissions of the folder for users of a group to write, but not read. Then setting up a cron job for your user that goes into the directory and moves the files to your home directory, and it gets ran every minute or so.

A script like this:
#! /usr/bin/env bash
if ls /path/to/that/directory/??* # ??* is to avoid the . and .. files
then
mv /path/to/that/directory/* ~/deposit
fi

Or something like that.

 

[Yohhan]

Thanks, I'll look into that.

One question for you.

#! /usr/bin/env bash

What's the advantage to this over just doing (no env):

#! /usr/bin/bash

 

[drag]

It should work on all Unix/Unix-like boxes that have a bash shell.

If you go:
#!/bin/bash
#!/bin/sh

that will only be reliably functional on Linux box. For instance on a OpenBSD box it needs to have a space between #! and the command, and usually bash isn't installed in /bin/

#! /usr/bin/bash
is better, it's a bit more generic and will work most of the time. But if they have bash installed in /usr/local/bin it won't work.

#! /usr/bin/env bash
should work on any box that has bash installed and findable in their path.

It also works with other commands genericly, like python or perl when running scripts.
#! /usr/bin/env perl
#! /usr/bin/env python

is much more likely to work then if you just ran
#! /usr/bin/bash

the assumption in scripts about the location of bash shell, or running bash commands under a #! /bin/sh (since most linux distros sym link sh to bash) is a pet peive of many *BSD people.
(at least it's my understanding that env should be located in /usr/bin/ very often)

 

[Yohhan]

Got it, thanks.

 

[n0cmonkey]

Originally posted by: drag
It should work on all Unix/Unix-like boxes that have a bash shell.

If you go:
#!/bin/bash
#!/bin/sh

that will only be reliably functional on Linux box. For instance on a OpenBSD box it needs to have a space between #! and the command, and usually bash isn't installed in /bin/

The space is unnecessary.

$ more cpp
#!/bin/sh
# $OpenBSD: cpp.sh,v 1.7 2004/02/10 02:02:22 espie Exp $

the assumption in scripts about the location of bash shell, or running bash commands under a #! /bin/sh (since most linux distros sym link sh to bash) is a pet peive of many *BSD people.
(at least it's my understanding that env should be located in /usr/bin/ very often)

Using non-standard bourne commands is evil.