Re: Ownership and permissions for applications: security issues?
Re: Ownership and permissions for applications: security issues?
- Subject: Re: Ownership and permissions for applications: security issues?
- From: Greg Guerin <email@hidden>
- Date: Fri, 14 Sep 2007 10:03:15 -0700
Steve Checkoway wrote:
>> It would be less troublesome to create an Installer package.
>
>Oh absolutely. Of course, for commercial stuff, you have to pay for a
>license and even more to the point, this was about drag installed
>applications.
Well, it was also about self-correcting drag-installed apps. Or
self-defending drag-installed apps. That is, where some (or most) of the
functionality of the installation phase is in the app itself (code or
state), and where it runs any code on a more or less regular basis. For
example, self-checking permissions or ownership of elements within the
app-bundle, self-correcting permissions or ownership of user files, and so
on.
The main problem with this is self-referential trustworthiness. If the app
performs app-integrity checks on itself, that procedure can be subverted,
i.e. made untrustworthy. There is no way to really escape from this
self-referential loop, either. Is this stage of the self-integrity
checking untrustworthy? Well, let's wrap another self-referential check
around it. Pretty soon you've got checks on checks on checks, when what
you really need is to install the app ONCE in a trustworthy fashion (e.g.
owned by root, not writable except to admins, etc.) and be done with it.
Any changes that undermine access-control integrity can still be checked
for, but at most should just warn the user: Hey, this app may be
compromised, you might want to reinstall it from a trustworthy source.
My feeling is that unless it's an unrecoverable structural change or a huge
hole, I would also give the user the option to not get future warnings. As
a developer, it's not always possible to foresee all the ways that users
will legitimately tweak your app, and as long as they aren't doing
something overtly dangerous or stupid, I'm inclined to let them do it. If
they act against your advice, as embodied in the warnings of the app, then
it's their own problem. It's the "sharp knives" problem: they're not toys
and if you misuse them you can kill things.
You can't make something trustworthy by wrapping it in more layers of
untrustworthiness. You have to start with trustworthiness, and then ensure
that every stage thereafter doesn't undermine what came before.
Trustworthiness is a foundation, not a surface-covering.
Hmm, that ended up more of a rant than I intended. Sorry about that.
Anyway, it's always a balance of tradeoffs. There isn't one answer for all
situations, because the exposures and the consequences of a compromise vary
for every situation. Just making an app have 555 or 444 permissions
throughout, without altering ownership, counts for nothing in the overall
exposure profile. It may seem like it's a useful countermeasure for an app
to defend itself, but it's so easy to subvert all it really does is prevent
legitimate Finder actions by everyday users.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden