> > >BTW - how has this hideous fault remained in OSX for so long? Surely > > >there's an equivalent of 'sudo -k' - a way the finder can explicitly > > >drop priveleges? > > > > It's Apple's Authorisation services, not the unix privilege mechanism > > that are behind the problem. > > Yes, but such authorisations can be explicitly revoked (same principle > as `sudo -k`). Craig's question: why doesn't this occur? > > PS. I haven't tried this stuff. I wonder if a login hook can be used to > "effectively" fix this?
After that 1 minute window expires, Authorisation Services does revoke BBEdit/Finder/Everything's authorisation to edit these files. So it's not _so_ bad, except it still has plenty of opportunity to set another program/script to run at startup as root. Which could do anything to you. Also, for that minute or so, it has full unquestioned write access to the NetInfo database in /private/var/db/netinfo/local.nidb/ ... it's a trivial matter to search through and remove the string "authentication_authority ;ShadowHash;" (plus several non-printing characters) and all of a sudden, you stop needing passwords to login to accounts, which may/may-not include FileVaulted ones. Bad, bad... The only reason Apple hasn't patched this fault already HAS to be that nobody's bothered exploiting it yet -- especially if it's just a change to /etc/authorization. Which equates to 'security through obscurity'. They have issued 5 security updates since 10.3. Can you describe the required fix Shay? Google aint cooperating. Ryan
