• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Major Tiger AppleScript security hole?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Major Tiger AppleScript security hole?


  • Subject: Re: Major Tiger AppleScript security hole?
  • From: Chris Page <email@hidden>
  • Date: Sat, 25 Jun 2005 03:31:04 -0700

On Jun 24, 2005, at 05:52, Stephen Jonke wrote:

I was unclear on su, and as I noted in another message this isn't as bad as I first thought, however, I'm not entirely convinced it is the right behavior anyway. If it is normal, then why is that if you su to a different user and then try to delete one of your files with "rm" or anything else (other than an applescript) it doesn't work - permission denied. I would think that if you su to another user then your access rights would be the same as that user, and the unix commands all behave that way. Applescript does not.

Here's the deal:

1. Finder is running as user Foo. User Foo can delete the file using Finder.

2. You send an Apple event to Finder, telling it to delete a file.

3. Finder deletes the file, because it is running as user Foo, who, as we've already established, has permission to delete the file.

That is, when you invoke "ls" or "kill" you're launching a new ls/kill process with your permissions, but when you send an Apple event to an existing process, that process operates as the user who launched it.

This isn't unique to AppleScript. The same is true if you send a message to an IP port attached to an existing process. That's why, for example, HTTP servers typically act with restricted permissions, so they don't allow random individuals on the Internet to access every file on the computer.

Along these lines, AppleScript has always had a per-application flag to indicate whether to allow remote events, and Finder has this flag set to disallow events sent from remote computers.

Note that sending events to Foo's "Finder" on the same machine is only possible when I login inside Terminal from the user Foo account. If I login to the non-admin account via Login Window, events sent to "Finder" go to the non-admin user's Finder, not Foo's Finder. (Using "fast user switching" so both users are logged in.)

What would be interesting to know is whether the non-admin account can send the "quit" event to Foo's Finder by identifying it by process serial number.

Note that, although the non-admin user can see Foo's processes via "ps -a", using "kill" on one of Foo's processes results in a permissions error.

--
Chris Page - Software Wrangler - Dylan Pundit

  Open Source Dylan Compilers: <http://www.gwydiondylan.org/>
  Dylan Blogging: <http://homepage.mac.com/chrispage/iblog/>
  Dylan Stuff: <http://www.cafepress.com/chrispage>

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >Re: Major Tiger AppleScript security hole? (From: "J. Stewart" <email@hidden>)
 >Re: Major Tiger AppleScript security hole? (From: Stephen Jonke <email@hidden>)

  • Prev by Date: Re: [OT] politically commentary; [was] Not as bad as thought
  • Next by Date: Re: posix path of string
  • Previous by thread: Re: Major Tiger AppleScript security hole?
  • Next by thread: Mount volume flaky/broken in Tiger?
  • Index(es):
    • Date
    • Thread