![]() Unfortunately, that reasoning is flawed in two respects.įirst, no script or tool in an autoupdater should ever attempt to delete such a key symbolic link at the root level of the boot volume. This claim is based on the fact that, when tested on a Mac with SIP enabled, the bug wouldn’t have become apparent. Several wise people have laid part of the blame on SIP, which is a bit like blaming a sprinkler system for causing a fire. To perform this, the script or tool would have to be running as root, and this bug is prime evidence that Google’s update quality assurance was woefully inadequate. That Google should have released an auto-update, which it knew would be rapidly deployed across millions of Macs, that contained a script or tool which attempted to delete a key symbolic link within macOS, should also be cause for grave concern. Had that been observed here, the bug should have become manifest on that test system alone, and others not updated until the bug was fixed. In a studio full of Macs, it’s a wise plan to update one test system first, and verify that isn’t adversely affected as a result. This is also a good illustration of how automatic updating can be dangerous. That might be true if it contained no vulnerabilities, but not only is that a false assumption, but its vulnerabilities become even better known. We tend to assume that, just because an old version of macOS was fairly safe when Apple stopped providing security updates for it, then that’s the way it remains. Here, without even the protection afforded by SIP, Yosemite and earlier shouldn’t be exposed to the risks of the Internet, regardless of the browser that’s being used. Once Apple stops providing security updates for a version of macOS, it accumulates a list of known vulnerabilities and is ripe for exploitation by malware. If it is necessary to be able to use essential hardware or software, then again that Mac must be treated as very special. ![]() Running old and unsupported versions of macOS which lack protections like SIP is also not something to do without a great deal of care. Above all else, this prevents inadvertent modifications being made to your system, regardless of how well protected you might feel that Mac is from malware. If the only way that you can use a particular video card or other hardware/software is by turning SIP off, then you shouldn’t think of risking that Mac in general use.īy far the best strategy for macOS security involves, at its centre, keeping SIP enabled fully and at all times. Exposing a Mac with SIP disabled to the slings and arrows of the Internet isn’t something that you should ever choose to do. If for any overriding reason you need to run a Mac with SIP turned off, or not fully on (there are degrees which are controlled in Recovery Mode), then that Mac must be treated as very special. ![]() System Integrity Protection is intended to do exactly what its name declares: protect the integrity of macOS. In case you know anyone who’s still affected by this, a complete set of solutions is available here.Īs is so often the case, there are lessons for all of us from this unusual problem. Without the /var symbolic link, the affected Mac is unable to boot normally. As the Keystone updater also cast aside the last protection on that symbolic link by running as root, it was able to delete that vital link. However, many of the affected Macs were running with SIP disabled, apparently to enable support for third-party video cards. As that’s normally protected by SIP, if your Mac was running with SIP enabled, it couldn’t do that, and no harm was done. Google’s rogue Keystone update erroneously attempted to remove the /var symbolic link on the startup volume.
0 Comments
Leave a Reply. |