Re: Major Tiger AppleScript security hole?
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