Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Create a Sandbox for apps using folder actions Apps
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:

property theUser : "testuser" -- change this
property theGroup : "testuser" -- usually same as user (on Panther)

on adding folder items to thisFolder after receiving theseItems
  repeat with oneItem in theseItems
    set thePath to quoted form of POSIX path of oneItem
    set chUserBit to "sudo find " & thePath & 
     " -perm -u+x -exec chmod u+s {} \\; ; "
    set chGrpBit to "sudo find " & thePath & 
     " -perm -g+x -exec chmod g+s {} \\; ; "
    set chOwner to "sudo chown -R " & theUser & ":" & 
     theGroup & " " & thePath
    try
      do shell script chUserBit & chGrpBit & chOwner 
       with administrator privileges
    on error m
      display dialog m
    end try
  end repeat
end adding folder items to
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
[robg adds: I haven't tested this one...]
    •    
  • Currently 2.40 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (5 votes cast)
 
[13,268 views]  

Create a Sandbox for apps using folder actions | 10 comments | Create New Account
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.

[ Reply to This | # ]

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.



[ Reply to This | # ]
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.

[ Reply to This | # ]
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.



[ Reply to This | # ]
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.



[ Reply to This | # ]
Create a Sandbox for apps using folder actions
Authored by: anjoschu on May 28, '04 03:02:37AM

ptejad wrote:

If you change this script to give all of the files in the folder root:admin ownership, then everything will always run as root

I fully understand your concerns. That's why I warned in the notes:

Avoid using root or any admin as the user

ptejad wrote:

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

That's right IF you actually choose to ignore the warning and put in a root/administrator account. Actually the intended use of this hint is to run applications with lowered privileges.

ptejad wrote:

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

Sorry, but that's just not right. If you use the hint as recommended, you could actually increase your security by lowering the privileges of certain apps.

But you've got a point in that I probably didn't stress the importance of this enough, so let me repeat:

DO NOT ENTER ROOT OR ANY ADMIN USER OR GROUP IN THE SCRIPT

Thanks for pointing that out.



[ Reply to This | # ]
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.



[ Reply to This | # ]
Create a Sandbox for apps using folder actions
Authored by: Han Solo on May 28, '04 12:08:18PM

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?



[ Reply to This | # ]
Yes... and no...
Authored by: anjoschu on May 28, '04 01:09:51PM

Hi.

You're right of course in that FUS works well, too. Here, you also create a sandbox user (see the notes), but you need not FUS to it to run apps in the sandbox user space.

This hint is definitely _not_ a security risk unless you choose to ignore the warning about root. Au contraire.



[ Reply to This | # ]
UNSAFE!
Authored by: hast on Jun 08, '04 01:33:46AM

Not safe!

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.



[ Reply to This | # ]