Re: FSCopyObjectAsync: useless and crippled
Re: FSCopyObjectAsync: useless and crippled
- Subject: Re: FSCopyObjectAsync: useless and crippled
- From: Mitch Tishmack <email@hidden>
- Date: Sun, 15 May 2005 09:35:59 -0500
Disclaimer: I am a Unix Systems Administrator by day, and a Batman
Cocoa Developer by night. I will speak to the security aspects,
because I deal with this on a day by day basis. This thread has
devolved into a general unix security thread and this will be my only
post. Only to get my viewpoint on why this is a bad idea.
On May 14, 2005, at 6:43 PM, email@hidden wrote:
Apple's authentication services provides a framework for
arbitrarily fine-grained control over permissions (read up on the
policies framework). The problem is that no one ever takes the
time to set it up. They just ask for authentication services for
"root" and start whacking away.
Largely because of the perceived lack of a difference - as you
noted, on Unix you're either root or a nobody. Asking for a
specific privilege might be handy if you're passing privileges
around between apps, but if it's within the same app, ultimately
what you need (whether you *want* it or not) is root, so why beat
around the bush about it? (devil's advocate again)
Root shouldn't be used to copy user files. There are better methods
in other "unix" systems to get around the root or nothing approach.
RBAC in Solaris for example. But you can setup rbac in the same way
you listed, instead of running commands as the user they need to run
at, people take the short way out and use root. Give someone root
access to mv and cp and you have basically thrown security out the
window with the baby still inside. The same goes for sudo.
The other problem is that OS X / Next is built on BSD. And, like
in most Unix systems, one's permission environment (file access,
process UIDs, etc.) is based solely on your current EUID. So to
change permissions for any of the underlaying Unix APIs, you only
have one choice -- first change your EUID -- which changes the
premissions for everything your process can do. The only
alternative I see would be to dump Unix.
As I understand it Mach and BSD are on the same level in current
Darwin... Apple should probably expose the finer-grained Mach
privilege model better, and obsolete the BSD side. We're starting
to see something towards this, with ACLs in the file system at
least...
ACL's aren't a new concept. BSD has had them for years, as has Sun.
They were meant to augment the standard security model. I have only
used them for exceptions to the rule of user-group-nobody access.
Namely because they are a very tricky beast to get right, and this is
how they were presented to be used. Obsoleting BSD would be a bit
rash. Permissions are there for a reason, to deny access to those
that do not need it. Not to be ignored like we are in a single user
operating system.
Another method to aid the euid problem is to fork() off a subprocess
and let that process deal with the changes to uid. I personally hate
this approach however.
But the biggest argument against such a change is this: if a trojaned
app were to be allowed to run and then implicitly present this
authentication dialog to the user, absolutely nothing (permissions
wise) is stopping it from overwriting system applications with some
of its own. This is a HORRIBLE security idea and shouldn't be
implemented by any operating system. Permissions are the
responsibility of the user and administrator (if applicable). The
application is supposed to honor those permissions, not hope for the
api to ignore the permissions behind the scenes. mv and cp behave
this way, our apps should too.
If your current user doesn't have read access to a file. You throw up
a dialog stating I can't open that file since you don't have
permission to access it. The same goes for writes. Users have home
directories for a reason; allowing them to look into others' home
directories or system directories is not a wise decision.
Mitch
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden