PDA

View Full Version : Need to sudo in shell script without password prompt...


brad_GNET
07-27-2005, 05:41 AM
Hello

I've written a shell script to alter a prefs file, which works great when you're sat in front of the Mac and can type in the password.

However I now need to roll this out across a number of other Macs. My plan was to do this over remote desktop.
This requires that the script runs without prompting for a password.
My plan was to change the shell user to the admin user that has an account on every Mac, then sudo up from there (since the password is consistent and can be included in the script). As yet I cannot pipe the password into sudo so it doesn't prompt for a password.

Any help very much appreciated...

acme.mail.order
07-27-2005, 09:21 AM
Reading the man page for sudo reveals that using the -S option reads the password from stdin, so `echo "password" | sudo -S whatever" should do your bidding.

However, it's usually considered a bad idea to leave passwords in cleartext scripts. What you can do instead is use the SUID bit. Run `chmod 4711` on the file, then chown to root. That sets the permissions to execute by everyone, read by owner (root) only, but assume the identity of the owner when it is run. Make sure your program is relatively bomb-proof, unless security isn't a big deal where you work.

dmacks
07-27-2005, 11:32 AM
use the SUID bit. Run `chmod 4711` on the file, then chown to root. That sets the permissions to execute by everyone, read by owner (root) only, but assume the identity of the owner when it is run.
SUID on scripts is disabled on OS X...it's a security hole.

derekhed
07-27-2005, 12:07 PM
Can you change the permissions on the preference file so that the user CAN edit it (i.e., your script)? Or does the program set it back...?

IMHO, if a security hole is plugged that causes people to create bigger ones (think: a password vetting scheme that is so convoluted that people write their passwords on stickies next to their monitor), then it isn't an improvement on the situation.

Now that SUID is disabled, what is the prefered method of solving these problems? I am sure they still arise. :confused:

DMCrimson
07-27-2005, 12:13 PM
http://www.macosxhints.com/article.php?story=20021202054815892

this works...

also, in my bashrc I've added the following:

EDITOR='/usr/bin/nano'
export EDITOR


Thus the command visudo used in hint above, will use nano as editor.
In Tiger, pico is just symlink to nano:
[dmcrimson][dmcrimson]$ file /usr/bin/pico
/usr/bin/pico: symbolic link to `nano'

Sidenote: do not go for this method if there's possibility of someone else using your account - it has potential to wipe your root with no questions...

giskard22
07-27-2005, 12:16 PM
If you want to improve the security of the script containing the password in clear text, you might be able to use Platypus. Platypus turns scripts into Mac applications, and it has an option to encrypt the script text.

acme.mail.order
07-27-2005, 08:18 PM
SUID on scripts is disabled on OS X...it's a security hole.
Must be new in Tiger. Works fine on 10.3, and it's something I'm going to have to re-enable when/if we upgrade. And it's less of a hole than putting passwords in scripts.

dmacks
07-27-2005, 09:45 PM
Must be new in Tiger. Works fine on 10.3
This setting was changed starting in 10.3.9.

The danger isn't that SUID is insecure, but that SUID <i>scripts</i> are insecure (due to the way the kernel executes scripts). So the solution that's been proposed many times is to use a compiled program that is SUID. It could even be a compiled program that does nothing but launch your actual script!

acme.mail.order
07-27-2005, 10:36 PM
... It could even be a compiled program that does nothing but launch your actual script!
So we've gone from something that is mildly insecure to something that is completely insecure? This is progress?

leamanc
07-27-2005, 10:50 PM
The easy way to solve your password dilemma is to simply run the script as root. You will not need to call sudo within a script run as root.

You could set up a cron job on the client machines to run the script as root. Both your script and a modified root crontab could easily be pushed out with ARD.

dmacks
07-28-2005, 06:24 AM
So we've gone from something that is mildly insecure to something that is completely insecure? This is progress?
If you think the compiled approach is completely insecure, you completely misunderstood it. Actually if you think it's anything other than "more secure than a SUID script" you completely misunderstood it.

foo (a compiled binary) is SUID root and runs foo-script, which is what you wanted to be SUID originally...now foo-script is running as root.

acme.mail.order
07-28-2005, 07:50 AM
No, i understand it fine. Here's the thought process:

Before, I could write a shell script, chown/chmod so it's owned by whoever (usually root) make it unmodifiable by normal users, and I'm in business. Easy to do, easy to update. The programming skill necessary to abuse the script suid system made the security issues very minor, far less than having passwords inside scripts.

Now, I either have to learn another programming language to make compiled binaries or (more likely in many cases I think) make ONE compiled binary that invokes other scripts as another user. This workaround creates a bigger security risk as it's a lot easier to abuse.

Security vs. convenience. So now I have to modify kernel settings on the company machines to put things back to a reasonable compromise.

dmacks
07-28-2005, 12:57 PM
make ONE compiled binary that invokes other scripts as another user. This workaround creates a bigger security risk as it's a lot easier to abuse.
How is this work-around a security risk?

giskard22
07-28-2005, 01:19 PM
Unless the app runs some complicated check on the integrity of the scripts it's going to run, all someone has to do is boot into Single-User Mode and replace the target scripts with ones of their choosing.

Any thoughts on my Platypus suggestion? I'm not an expert on UNIX by any means, but unless the encryption is garbage it seems like you could use the 'sudo -S' option with relative safety.

biovizier
07-28-2005, 01:39 PM
I read somewhere that the 'echo' / 'sudo -S' combination itself was considered insecure because the password shows up in clear text if you run 'ps'...

tnguyen
07-28-2005, 02:45 PM
if you want sudo without prompt password,


edit /etc/sudoers

and add:

username ALL=(ALL) NOPASSWD: ALL


save and that's it.

the username is the user you want to give doing sudo without password.

acme.mail.order
07-28-2005, 07:40 PM
all someone has to do is boot into Single-User Mode and replace the target scripts with ones of their choosing.

I'm thinking worse than that. Unless the program does decent user checking it could run ANY script as root. Hence 'completely insecure'

For example: before, I could write a simple script that invokes the locate updatedb function. I don't care who runs it. Put it in a more convenient place than the updatedb code and use suid.

Now, Uness the binary does a LOT of sanity checking, someone could write a script that starts the bash shell, launch it through the binary, and own the system.

Perhaps disabling suid on scripts was a well-intentioned idea, but it was a useful function that now needs a workaround. I see the workaround creating more problems than the original issue.

dmacks
07-28-2005, 09:51 PM
I'm thinking worse than that. Unless the program does decent user checking it could run ANY script as root. Hence 'completely insecure'
No. This not a "generic wrapper" that launches "some script fed to it", for example, launch-as-root some-script but rather the script-name is coded into the wrapper itself. As is well-documented in many places as the way to work around this kernel insecurity (since many years before Apple decided to force this upon its users).

One would need write access to the wrapper script (which would be owner=root, SUID, chmod 111) in order to cause it to sub-launch an arbitrary (other-than-intended) script, or write-access to the sub-launched script itself (which would be owner=root, chmod 500). i.e., one would need root. If you're hopeing to secure against actions by someone who already has root (by sudo, single-user mode, or other hackery), that ain't possible.

acme.mail.order
07-29-2005, 02:33 AM
Expand your horizons a bit. Picture the overworked sysadmin who has to now deal with one more security inconvenience. What he had worked fine, and he's not a fluent C programmer. Not having the time to write and compile code for every script written, a generic wrapper is made that WILL run anything fed into it. now we have a bigger security issue than with plain suid scripts.

My point is basically that as security and convenience is always a balancing act, lets not tilt it so far one way that it needs a good shove in the other. I had absolutely no problems with read-only suid scripts, so I'm continuing to use them. Now, if I worked at a university with hundreds of n'er-do-well students poking around that would be different :D

chris_on_hints
07-29-2005, 05:14 AM
hmmm.... sounds like this debate could run for a while...

Could you compile an applescript (a simple one just to launch a specified script using the terminal commands) and give it the SUID? Then you/we dont need to learn C or another programming language (which is over-kill if you only want to make a simple program to launch a script)

Otherwise, as was pointed out by leamanc, you can make the script owned by root and stick a call to it in cron / anacron so it is run by root, with no need for passwords etc. Obviously, this is only useful if the script needs to be run at specified intervals rather than on demand...

IMHO, these work arounds do sound like they have the potential to open up bigger security holes then you might like, especially if not done properly. acme is right - its all about the balance between security and convenience.

hayne
07-29-2005, 10:53 AM
Perhaps disabling suid on scripts was a well-intentioned idea, but it was a useful function that now needs a workaround.

Note that you can enable suid scripts via a sysctl call - I believe this was covered in an article on the main macosxhints site.

dmacks
07-29-2005, 03:45 PM
Expand your horizons a bit. Picture the overworked sysadmin who has to now deal with one more security inconvenience. What he had worked fine, and he's not a fluent C programmer.So because some folks are overworked and/or don't have the skills to solve a problem themselves or by searching the web (the solution has appeared here several times in fact!), Apple should leave a security hole open for everyone? Apple has decided "this hole is pretty risky and widely known but not obvious to newbies, is easy to block, and the block is easy to work-around safely, so we'll plug the hole by default". That seems to be their stance on all such things...make it easy for the newbie to be safe out-of-the-box. I happen to agree with this stance, as compared to Windows' "leave it open until someone learns it should be closed and how to close it" philosophy.

Not having the time to write and compile code for every script written, a generic wrapper is made that WILL run anything fed into it. now we have a bigger security issue than with plain suid scripts.
Hey, one is free to be as security-ignorant an admin as one's employer will tolerate. As an overworked admin, I *do* want a vendor to say "hey, a common way you might be doing things is a security hole, find a better way!"

My point is basically that as security and convenience is always a balancing act, lets not tilt it so far one way that it needs a good shove in the other. I had absolutely no problems with read-only suid scripts, so I'm continuing to use them. Now, if I worked at a university with hundreds of n'er-do-well students poking around that would be different :D
One is always free to not bother applying security patches, or to undo the security protections provided by them. One difference between a monolithicly-supplied system such as OS X and a completely modular package-based one such as most linux distros is that one has less-fine-grained control over individual changes such as this.