Re(2): Authorization once, and .dmg
Re(2): Authorization once, and .dmg
- Subject: Re(2): Authorization once, and .dmg
- From: "Peter Lovell" <email@hidden>
- Date: Thu, 17 Oct 2002 17:27:14 -0400
>
>>Users really like drag-and-drop installs that just work or self repair.
>
>
>
>Will they still like it if it's used as a vehicle to introduce a virus?
>
>
Perhaps less well, but in order to exploit this, the virus would
>
need write access to the application bundle. Would need to delete
>
the existing tools owned by root. Would need to carefully
>
emulate the verification process used. And finally, would need
>
to spoof the user into re-authorizing the tools.
>
>
The user can minimize such risks by placing the application in
>
a write protected directory or only authorizing during the install
>
or first run process. You need admin privileges to install or
>
repair, but not on each run.
>
>
Conditioning the user to authenticate every time they run common
>
applications seems like a far greater risk. It's relatively easy
>
for a trojan horse to replace any one of these applications and
>
ask the user to authenticate.
>
I'm in full agreement with Peter S on this one.
There are certainly some delicate issues to consider but workable
solutions exist. Not easy, but workable. We have to deal daily with
problems related to FIPS certification and it's not easy. Root canals are
easier.
For the benefit of those needing to secure their stuff, here's a way to
do it....
1. generate a validation code for all binaries during build
2. use "-noprebind" so that optimization will not break the validation code
3. have a self-repair mechanism to create a setuid helper app etc in a
protected directory
4. validate the application, the helper and any extensions EVERY time you run
5. don't execute if any validation check fails
6. if the helper app is broken, out-of-date etc, then get user authorization
to create a new version from the validated copy
The /Library/Application Support directory seems to be a good place to
store this stuff. Create your own folder in there and protect it as you
feel appropriate. One nice advantage of this is that, for multi-partition
drives with several versions of OS X, each partition has its own library
so you can customize for each version (10.1, 10.2 etc) if necessary. This
was a BIG help in getting settings correct for KEXTs under Jaguar.
Regards.....Peter
p.s. major credit is due to Paul Lalonde for creating several parts of
this mechanism
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.