Although there already exists a hint dealing with how to run an application as another user, I'd like to share a different approach. Create a folder, call it Sandbox or something, and attach this folder action script:

This Applescript needs to be copied to ~/Library -> Scripts -> Folder Action Scripts or /Library -> Scripts -> Folder Action Scripts in order to be recognized.

What it does: For each application that you put in the Sandbox folder, this script modifies its settings so that it runs as the testuser when launched. In contrast to the setuid approach, you only need to enter your admin password once when adding the app to the folder, and not on every app launch. And having a Sandbox folder to me just seems more intuitive.

How it works: When the setUID and setGID bits are set on an application, the app will always run as its owner, no matter who launched it. By setting both setUID and setGID and changing the owner and group to our unprivileged testuser, we achieve that the app runs as said testuser.

Notes:

Avoid using root or any admin as the user unless you know exactly what you and the application are doing.

Although it would be possible, for instance, to work with another user's iPhoto Library by copying the iPhoto app into the sandbox, this is not the use I intended. I recommend against attaching a user account that is already being used for productive purposes.

I recommend you create some special user for the sandbox (non-admin of course; mine is called "testuser") whose exclusive purpose is to be used by the sandbox. This hint aims to provide untrusted apps with a secure environment where they can wreak havoc as they please and all they can damage is the "testuser" account.

When an application opens another application, the latter runs as the current logged-in user (you), not as the testuser

Hint Options

Click here to return to the 'Create a Sandbox for apps using folder actions' hint

The following comments are owned by whoever posted them. This site is not responsible for what they say.

Create a Sandbox for apps using folder actions
Authored by: SOX on May 27, '04 10:24:07AM

When an application opens another application, the latter runs as the current logged-in user (you), not as the testuser

that's a surprise, I did not know setuid worked that way. In any case this means this is not secure since it can get out of it's sandbox and run arbitrary shell scripts. Of course it will probably defeat either badly written dangerous programs or most garden variety malicious programs, neither of whic is likey to make the effort needed to get out of the sandbox.

Create a Sandbox for apps using folder actions
Authored by: stcanard on May 27, '04 11:55:56AM

This is actually done for security.

setuid is generally intended to grant elevated (root) privilige to an executable. By reducing the privilige (going back to the original owner) when calling other programs, it reduces the chance of a security breach.

Create a Sandbox for apps using folder actions
Authored by: jpbjpbjpbjpb on May 27, '04 11:28:46PM

That would be because it doesn't work that way. Once you run a setuid program, it, and anything it spawns runs as that user. It can't change back to your userid unless you've set it to run setuid root, and the hint explicitly mentions running the sandboxed applications as an unprivileged test user, not as root.

Create a Sandbox for apps using folder actions
Authored by: anjoschu on May 28, '04 03:45:50AM

SOX wrote:

I did not know setuid worked that way.

Actually, it's the same with sudo used in the other hint. Someone mentioned in the forums that it doesn't work with open, like in

sudo -u theuser open /Applications/TheApp

and that's right. Same here. I suspect that the applications launch each other via a system call or something that resets the privileges to the logged-in user. Hasn't there recently been talk about something called LaunchServices in connection with the current URL security flaw in Panther? Maybe you could tweak those with an APE haxie or something to keep spawned processes in the Sandbox, but I'm not sure. Anyone got an idea?
SOX wrote:

In any case this means this is not secure since it can get out of it's sandbox and run arbitrary shell scripts.

Exactly the problem. I am hoping since so many people are reading this, someone will come up with an idea on how to prevent apps from escaping.

Create a Sandbox for apps using folder actions
Authored by: ptejad on May 27, '04 05:08:32PM

This is a BAD, BAD idea. If you change this script to give all of the files in the folder root:admin ownership, then everything will always run as root, WITHOUT asking for authentication. I know that's what he intends here, but again, this is a BAD idea.

You always want these things to ask for authentication so that you KNOW when a script or program has elevated priveleges.

This would be a perfect payload for the latest round of vulnerabilities to be able to gain root access and wipe you out completely.

NEVER EVER use with root
Authored by: anjoschu on May 28, '04 03:26:30AM

Hi, I'm the author of this hint.

As ptejad pointed out, if you use this hint and change the user/group properties in the script to "root" or some admin account, you may end up in serious trouble.

In an earlier hint on running applications as another user (using sudo), you are still asked for the admin password each time you run the app. But here, you are asked only _once_ when adding the app. In combination with root, this makes a dangerous combination as apps could act as root without your intervention.

So: USE THIS SCRIPT ONLY WITH UNPRIVILEGED USERS. Not Admins. Not root.
For admin/root usage, the earlier hint would be better suided (haha) than this one (although personally I wouldn't want to run a non-shell app as root, either. What for?).

I would like to point out clear that this hint is definitely not unsafe per se. If you respect the never-root-or-admin warning, all is well.

I guess I don't completely understand why one would go to all this trouble â€” and run many of the risks listed above â€” when one could just set up a separate "sandbox" account and access it with FUS. One could even place restrictions on that account to further minimize the risks. Or am I missing something?

A program can simply call seteuid(getuid()) and it will break out of the sandbox. This is because when a setuid program is exec()'ed it changes the effective uid to the owner of the file, changes the saved uid to the previous effective uid and leaves the real uid unchanged. The seteuid() call allows a program then to change the effective uid to the saved uid or the real uid. The real uid can be found using the getuid() call.

Setuid is meant for running programs with higher privileges, not for running unknown programs with lower privileges.

Also, the script changes the setuid bits before changing the owner. This creates a race condition where the unknown program can be run by anyone with your credentials.