Whenever you authenticate on the system, a program called sudo is called to give your application or shell root privileges. Unfortunately, sudo includes a 'grace period,' wherein it will allow you to run privileged tasks repeatedly without a password. This presents a problem in OS X, where another application (such as a widget) could hijack your privileged access after you authenticate for some unrelated task (see this thread on macosx.com for more information about this particular vulnerability).

Fortunately, the grace period can be removed so that you will have to type your sudo password every time you want to perform a privileged task. This makes for a much more secure system, preventing other applications or widgets from being able to hijack this access. Simply add this line to your /etc/sudoers file:

Defaults:ALL timestamp_timeout=0

[robg adds: To edit the sudoers file, you'll need to use a special program called visudo, which must itself be run as root via sudo (got that?). So just type sudo visudo, and edit away (it's a version of vi).]

visudo just does some sanity checks before it writes to disk. If you happen to not know vi, you can just edit it with emacs, pico, etc. Just don't do anything crazy, and make sure you keep a backup in case you end up making a mistake and need to revert.

Note that if you don't use 'visudo' and you introduce a syntax error into the /etc/sudoers file, you will need to resort to single-user mode to fix it since 'sudo' will not work if there is a syntax error in the /etc/sudoers file

The version of visudo on Panther is compiled with with an enveditor option that obeys the EDITOR variable in the shell. Set visudo to use emacs (or whatever editor) as the default by exporting a new EDITOR variable.

As an emacs guy, I've always done this in emacs. All the benefits of visudo, without the syntax of vi.

Once the grace period is zero, there is really no concern about TTY tickets--you're going to have to enter the password each time anyway, regardless of which TTY you're on.

requiretty prevents someone from using sudo through a program that doesn't allocate a controlling terminal, like "ssh hostname command". Since background programs [usually] don't have controlling TTYs, that prevents them from using sudo at all--even prompted... of course, without a TTY, there's nowhere to prompt, and you've set ticket lifetime to zero, yes?

insults is a critical security feature. It belittles the operator for entering a bad password, and thus encourages use of the correct password each time sudo is used.

Yes insults does not really need to be there. I just did a copy paste of what my servers have set.

I tested this, and since the tty_tickets and timestamp_timeout=0 are set as defaults, some installs have asked me to login multiple times.

This may have been due to the way the installs worked, but without the above, running sudo once allows any tty access to the same ticket of authority and can keep it open as long as it wants, or until the process is killed.

I am of the belief this works in the same fashion as any *NIX OS, less I am wrong.

By default, you've got "timestamp_timeout" amount of time from a password prompt to invoke "sudo" again without being prompted for a password.

With "tty_tickets", you're ticket is only good on a single TTY, if you change TTYs but are still within the timeout period, you'll have to type your password.

So, by setting "timestamp_timeout" to 0, you must always enter a password, even if you do two sudos in a row on the same TTY:

sudo true ; sudo true

tty_tickets isn't much help in securing things, because all Cocoa/Carbon apps run under the same TTY ("console"). So the only way to prevent something from taking advantage of you authenticating an installer is to clear the timeout and key the password multiple times instead.

It Would Be Nice if you could set up timestamp_timeout on "console" to 0, but keep it at several minutes for /dev/tty*, so that your Terminal.app, xterm, iTerm.app, and so on windows work as usual.

And yes, this is all standard-on-all-UNIXes behavior of sudo. The unusual thing is the way Apple has automatic sudo in several spots in the GUI. (And I'll give them credit for just using sudo, rather than inventing yet another tool for the job. Though it did expose the timestamp_timeout risk in a way that most sudo-ers don't anticipate--I've tightened up sudo on all my systems as a result.)

Um, sudo doesn't drop the ticket when you exit the shell (it doesn't even run at this point).

But nevertheless, the tty_tickets option should be sufficient to disallow a malicious widget to run as root without losing the comfort of only having to authenticate about every 5 minutes.

On a side remark, even with the sudo security issue solved, a malicious widget could still do quite some damage, like removing your home directory, so you should still be careful about which widgets you install.

If you are using bourne shell then a file in your home directory called .logout with a line sudo -k in it will work.
.bash_logout is the name for the bash shell.
This will only work if the scripts use exit at the end of them.

Another sudo config that is a good idea is redirecting sudo's logging. Add the following to /etc/sudoers (as stated above, please edit this file with visudo, there is good reason to do so, and no reason not to):

Defaults:ALL !syslog
Defaults:ALL logfile=/var/log/secure.log

The above redirects sudo logs to /var/log/secure.log (rather than the default, /var/log/system.log), which can only be read using sudo/by root, as opposed to /var/log/system.log, which can be read (without sudo) by anyone in the admin group.

Changing logging will ensure that if you don't set timestamp_timeout to 0, malicious applications can't monitor system.log to see when a sudo session is authenticated (to try and piggy-back onto it).
A good write up of this can be found at http://adbas.net/OSX_Vuln.txt (I have no connection with this site).

Doing this hint makes some programs that rely on the grace period to fail. for example carbon copy cloner 2.3 does not work if you have performed this change. it gives an error about requiring a tty to perform sudo.

Just a quick note, 'visudo' is not a version of vi and has nothing to do with vi. The command is simply a syntax checking wrapper that uses whatever EDITOR you have set. That might be vi, or nano, or emacs, or perhaps even BBEdit. Makes no difference to visudo.