Sudo question
 

Hi everyone. I have a question with regards to the sudo command (please forgive me if I should be posting this in the newbies section). What I need to know is if there's a way to log in as sudo for one command only (instead of for the default 5 minutes). I've put together a script which will update my locate database. The script will enter my admin password to run locate.updatedb but the problem is that I'm then logged in as sudo for five minutes afterwards. If, for example, I'm doing something in Terminal just after running the script, I don't want to do something as super user by mistake. (Shrug) Call me paranoid. While I'm at it, I noticed in the man page on sudo the following: "Running shell scripts via sudo can expose the same kernel bugs that make setuid shell scripts unsafe on some operating systems (if your OS supports the /dev/fd/" Does that apply to someone running OS 10.1.2? Thanks.

From what I've been able to discover, you'd have to recompile the sudo command with a lower (1 sec?) timeout.

Of course you'd first need to get the correct code to compile. This is something I don't think I'd like to try.

Although, the man for sudo shows that you can add -k or -K to the command to "invalidate the user's timestamp"...I'm not sure if this means that the command you do with sudo that time is it and next time you have to enter a password. Need a little more expertise to answer that one.

sudo -k not implemented?
 

on my OS X 10.1.2, sudo -k is not implemented

% sudo -k ls /var/db/netinfo/local.nidb/
usage: sudo -V | -h | -L | -l | -v | -k | -K | [-H] [-S] [-b]
[-p prompt] [-u username/#uid] -s | <command>
% sudo -K ls /var/db/netinfo/local.nidb/
usage: sudo -V | -h | -L | -l | -v | -k | -K | [-H] [-S] [-b]
[-p prompt] [-u username/#uid] -s | <command>

***[ correction: wrong sudo usage, see follow up post below ]

i would be extremely cautious with your approach, as it could very well expose security holes.

also, i read some recommendation somewhere to absolutely recompile sudo for a zero second timeout so you have to enter the pw every sudo.

that would be my approach. it can't be too hard to recompile with one #define changed.

Actually, you want to split that sudo command up:

The sudo -k simply tells sudo to forget that the user recently authenticated to it.

blb,

thanks. i somehow missed that 'OR' of the sudo switches

i think i'm going blind

SWEET! That sudo -k did it! Now I can run the script without having to enter my password, and it un-sudos itself when it's done. Thanks a lot!

TiMan,

just curious, could we see how you implemented this? without revealing any of your specific site particulars, that is.

it would be a good example, and perhaps someone could find holes in it.

i'm not paranoid (enough)

thanks

Sorry, I didn't even think to post the script. Bear in mind it's the second one I've written, so it's actually just odds and ends from other scripts I've seen on Macosxhints. I don't know how to do the last line as a shell script yet; being able to say "Shell" and have the following command entered as if you were typing it into the command line is from a scripting addition I downloaded off of Macscripter.com, sorry I can't remember exactly which one. Could someone tell me how to do the last line as pure shell script? Anyway here it is:

do shell script "echo 'adminpassword' | sudo -S /usr/libexec/locate.updatedb"
Shell "sudo -k"

Of course, adminpassword should have your actual admin password. Oh by the way, this is an APPLESCRIPT which is nice because I can just click it or put it in my menu bar via the script widget from the apple scripting website, and I'm not sure yet, but I think I could put it into a cron job using Cronnix too. Any comments and/or suggestions would be appreciated.

i like my cheese swissy
 

yep. big security hole.

'adminpassword' is a hardcoded string embedded in a text file?

holy flurking schnit!

passwords should never be spelled out in files. passwords should only exist in the mind.

or encrypted in a file with the encrytion pw in the _mind_

i think you're trying to protect something with an unprotected something, which is what crackers look for.

and this is for updating the locate database?! very snarky.

cron is already setup to run /etc/daily , daily, at some ungodly hour of the am. and cron runs things with root power, which is why only root has access to the cron scheduler file.

i suggest you:

a. modify cron to run /etc/daily during your systems uptime

b. delete all files related to this endeavor

c. tell all your friends and family that you're sorry

d. or, at least remove the pw's from the files and file this project away in
~/howNotToDoThings

***
i think this is the kind of endeavor that leads to passwords littered in text files, which you have to _maintain_ by the way.

what if your system is breached and you have to change your admin/root pw?

how many scripts have the pw embedded in them that you have to find and change?

or worse, someone else, cleverly, has found them this way and caused your breach!
***

let's find a more reasonable way for you to update your locate database securely.

sincere regards,

mervTormel

--
mel torme's fatter, younger brother

Hey thanks for the good laugh:D I didn't mention that as an Applescript, I was planning on saving this as a run only script so my password wouldn't be readable (at least I don't THINK it would be). Besides, with a password like "adminpassword" who'd have guessed it anyway? Please let me know if there are still holes in my head, I mean my idea. Thanks

hardcoded text, even in a binary application, is findable/readable, since the compiler pools it into the strings section of the code.

still, you have the maintenance issue if you are breached. not a good practice.

:eek: Well, I guess I can put THAT idea to rest afterall. Thanks!

I just want to say that having read this series of posts, it makes me aware of the need, as a UNIX newbie, to be very careful about what I get my system to do and to check out my scripts with those in the know before going 'live'.

It is a good reminder!

Thanks guys & gals!

Get password from dialog
 

Would this be a security issue if you were getting the password from a dialog, setting thePassword to it and then using:

do shell script "echo '" & thePassword & "' | sudo -S command"

(with proper character escape I assume)?

I have another questions related to that actually:

If you have never used sudo ever on your machine (which can be simulated by typing "sudo -K" at the terminal), the first time you run sudo, you get a message (privacy, yada yada yada). This shows up as an error in do shell script. Any way to deal with that gracefully?

Navajo

Interesting...

A. I don't think we have the ability to hide typed chars in dialog boxes, a security issue

B. the script is a process in memory, and therefore could be dumped, and leave messy things, like a cleartext pw, around to find.

This illuminates an important issue. We need some hook to secure password dealings that would behave like the authorization dialogs we've seen asking for admin pw. I am assuming that those dialogs are secure (encrypted?)


Regarding sudo' warning, you would have to figure out how to redirect that output to somewhere, like /dev/null

Good find.

Secure password
 

For secure passwords in AppleScript studio (which appears to be what this thread is now about):

A) In AppleScript Studio, you can have a secure text field. It was discussed on the AppleStudio mailing list. You make a regular text field in Interface builder. In the show info, there is a Custom Class section. Select SecureText Field and you are done.

B) The password has to be somewhere unencrypted at some point. I guess the key is to keep it in memory for as short a period of time as possible. Using sudo, you can do pretty much that:

Ask for the password in a bullet text field
Take password and use it in the following applescript:

set whoami to ""
set thePassword to text field "secure" of window

try
set whoami to (do shell script "echo '" &thepassword & "' | sudo -S whoami")
end try

set thePassword to ""

if whoami is "root" then
set isAdmin to true
else
set isAdmin to false
end if

This way, thePassword exists for a brief period of time. Later, there might be a way to call sudo with no parameters and let sudo do the check to see if the user is authorized:

try
-- something like that, not sure if this works (or maybe sudo -S whoami):
-- sudo will ask for password (and fail) if required
set whoami to (do shell script "sudo whoami")
end try

if whoami is "root" then
set isAdmin to true
else
set isAdmin to false
end if


The other option I see is to use the Security framework as described at http://www.stepwise.com/Articles/Tec...-03-26.01.htmlon Stepwise by Brian Hill from within AppleScript. Of course, I have no clue how to do it.

navajo,

excellent.

but where's the failure branch when that authorization don't get the right pw?

o i think i c

it's built in, if it fails, whoami is not root.

My head is spinning! If you get that script figured out, I'd love to see it!

Redirecting StdOut/StdErr
 

Novajo (et al):

The AppleScript command:
do shell script "echo '" & thePassword & "' | sudo -S command"

is just invoking a shell interpreter on the string
"echo '"& the Password & "' | sudo -S command"

So you can redirect output/error messages the same way you do in the shell.
In bash it would be
"echo '"& the Password & "' | sudo -S command >/dev/null 2>&1"

and I think it's even the same in tCsh.

regarding do shell script and passwords
 

As I mentionned above, apparently the Right Way of doing things for authenticating and running commands with privileges in Mac OS X seems to be to use the SecurityFrameworks,as discussed at http://www.stepwise.com/Articles/Te...1-03-26.01.html. I noticed that if you run a do shell command, it appears in ps -alx with its arguments. I could not intercept my "echo password | sudo -S command", but I could intercept others (e.g. sleep 10) so I am guessing one could get the password that way.

Last night (even though I should have been reading my book "Overcoming procrastination", but that can wait), I used the SecurityFramework code of Brian Hill and made it a subclass NSButton in AppleScript (NSAdminButton). It seemd to work well, even though I have not tested it much. One thing though is that by calling "authenticate" for my NSAdminButton, I get **the real authenticate** dialog of Mac OS X, not one of my own. Then , all you have to do is to call the commands directly with something like:

call method "command" of object "adminbutton" with parameters "/usr/sbin/whatever"

or something like that. That I have not implemented yet though, but since everything else is working (the dialog is pretty indeed), I suspect it will be a relatively simple.