Hacker News new | past | comments | ask | show | jobs | submit login

And why did Apple shut down the app regardless? Was it not properly patched? Did Apple not care?





Because zoom’s patch will only help users still using and updating zoom while those who have uninstalled zoom are still vulnerable (because the uninstalled leaves the web server behind)

"(because the uninstalled leaves the web server behind)"

For cripes sake...


It bothers me that people weren't more upset about this part.

I’m sure Apple is as upset as anyone else. It effectively breaks their sandbox model so they’ll probably be working hard on a way to plug that hole gracefully.

>It effectively breaks their sandbox model

The sandbox only applies to software devs that want to use it or those that wish to sell through the Mac App Store. I don't think Zoom is in the MAS at all (I don't see it in a quick search anyway), and a standalone installer is free to do whatever it wants and can convince users to go along with (up to and including, in principle, bypassing SIP though since that significantly raises the effort bar I've only ever seen niche stuff request it). And it's completely legitimate to want to run a server on your system too, there is no hole. Zoom simply acted as malware, taking actions without user permission.


SIP cannot be disabled by anything running in the current boot session. Once the root volume is mounted, the SIP flags are set in the mountpoint. The root volume obviously cannot be unmounted while it is booted from.

Not after Catalina.

Future versions of macOS will require signed software (notarized as per Apple terminology), even outside of the store.

What is new in security at WWDC.


I don't fully understand the difference. But signed is different from notarized. Notarized means you uploaded the binary to Apple. Previously, you can sign without doing that.

I haven't looked enough to understand what is gained by notary. Does Apple want to search your binary for maliciousness or rulebreaking (potentially even at a later date) so that it might revoke the notarization/signature?


In order to avoid repeating myself, from WWDC 2019:

"Advances in macOS Security"

https://developer.apple.com/videos/play/wwdc2019/701/

"All About Notarization"

https://developer.apple.com/videos/play/wwdc2019/703


Thanks.

Some of this stuff seems a tad disingenuous. Like preventing debugging. The debugger APIs on Mac already pop up a password prompt, limiting the usability in malware (and actual use, like trying to debug over ssh). Meanwhile, a culture of producing separate binaries for debug and for end users (debug builds lacking optimization, allowing additional permissions) is in my experience a great way to fail to reproduce legit customer-facing bugs during development and have greater difficulty diagnosing them when they occur on a real live user machine.


As far as I understand, notarization is intended to catch malware before it can be distributed. The traditional signing mechanism can protect users against malicious software because Apple can pull certificates used to sign malware.

Notarized≠signed. I suggest you watch the videos that you've posted; they go into detail about the changes in macOS Catalina and when they apply.

On the go now, I will post the video minutes and slide pages afterwards.

Signed is not the same to Sandboxed on macOS, afaik.

It's not, but sandboxing requires code signing.

Watch the security talk. macOS is on the path to adopt iOS permissions model and long term roadmap is to apply the sandbox to everything, with the option to explicitly disable it on per-case basis.

A path similar to how Windows 10 is now converging the Win32 and UWP sanbox models, or how ChromeOS sandboxes GNU/Linux processes.


> macOS is on the path to adopt iOS permissions model and long term roadmap is to apply the sandbox to everything

I do not see where this is mentioned.


I will show it later then.

That will be the Mac books death.

Many open source projects will not participate in this.

If this kills brew you will also loose a lot of devs.


iPhone and iPad don't seem to have suffered from lack of open source projects.

Neither do game consoles or the large population using Windows based systems.

I never cared for brew on the occasional moments I get to use Apple computers, XCode and default tooling is more than enough.

Which is like what the large majority of developers targeting Apple devices actually care about.


The MacBook is a general purpose computing platform. The iPhone and iPad are not. Locking down the Mac will make it unusable for many, many people. It will indeed be the death of the platform, as most devs abandon it entirely.

As a Mac user who develops high performance scientific applications portable between all UNIXen (Linux/Mac/BSD), I still can write my code pretty easily on the platform.

I personally don't use Homebrew, et al. but, I have a Linux VM which handles that stuff pretty well.

I didn't develop a Mac specific "application" though.


The large majority of devs that buy Macs aren't UNIX FOSS devs, rather devs that care about Apple platform.

My experience has been the opposite. Of all the people I've worked with using Macs, all of them were developing cross-platform open source software. I've yet to meet a single developer making MacOS applications.

They would better off sponsoring OEMs that try to keep BSDs and GNU/Linux hardware alive then.

On my Mac circle it is all about store apps and Web apps (Java/.NET Core based).


This doesn't match my experience so far, could you point me to your sources for this claim?

Just like you, my experience so far.

Then again, I only hang around with Mac devs that target iDevices and macOS, using Objective-C, Swift, C++ and Web.


This doesn't kill package managers like Homebrew.

There is no real sandbox model on Macs if you don’t go through the Mac App Store, only code signing to detect that the app hasn’t been tampered with and to validate the author.

Until Catalina, which will more aggressively use permissions and require all software to be notarized.

Neither statement is true.

There is still the same control-click to open non signed software and there is still no aggressive permission model outside of the App Store.


There is, but even the control click will only allow you to open signed software. Unless you build the software yourself (I'm not sure how homebrew still works) you cannot run it if it's not been notarized by Apple.

Firefox was broken on Catalina for a while, even though the main app was notarized. Some internal binary wasn't notarized, and no amount of control clicking would get Firefox to work until Mozilla notarized everything in the build.


For users who know what they are doing:

https://forums.macrumors.com/threads/unsigned-apps-catalyst-...

  sudo spctl --master-disable

The users who really know what they're doing are going to refuse to disable system integrity protection. I paid a shitload of money for the T2 chip, secure signed boots, a virus-free environment and complete peace of mind from malware. No way I'm turning that off on a work machine.

I have a Raspberry Pi for hacking, I'm happy to root the hobby computers, not the work ones.


That's why if find postings like this dangerous. If an author is asking someone to run a command, they really need to explain what the command does and what the tradeoffs are.

The command doesn’t do anything by itself from what so can tell. It just enables the option to run unsigned code.

I find it weird that you don't expect root privileges on devices you do work with.

It seems like this conflates the notion of having root privileges with turning off security. There is no meaningful connection between the two save in situations where there is no meaningful way to control said security layers save destroying them.

For example refusing to boot a bootloader that isn't signed doesn't require your oem to hold the only possible key that can be used to sign said bootloader.


Which are a very tiny percentage of typical Mac users.

As it should be. The vast majority of users should only run signed software. That leaves the ones who know what they are doing a way to bypass it.

You mean those that after doing that just perform "curl | sh" as it has become trendy among the younger UNIX generation?

I would not be surprised at all if this episode has some concrete ramifications in 10.15. It could take the shape of something akin to iOS’ location permissions for applications that want to run a server, or even a first-party framework for accomplishing the thing Zoom was trying to do, but it’s probably safe to say what Zoom was doing won’t be possible next year.

Because macos has no decent concept of package management or containerization.

I mean. The issue at hand was that they purposely left the webserver behind to auto reinstall if a zoom link was clicked. This was an intended feature, and the same could have been done on Linux or Windows. Package management or containers are irrelevant to this conversation.

A package manager would typically have removed the web server, too.

Sure, the "package managers" on Linux, Windows, and macOS all behavior in pretty similar fashions. A manifest of files that the installer knew at time of install. That doesn't stop a program from installing anything else at run time, or even in the installer (since they can define what to remove in a lot of cases). This wasn't an "accident," it was purposely left behind with the intention of being used to onboard users easily even after they removed the client. This would have pretty much been an issue on every platform (had it been implemented on other platforms). And please, don't tell me "but Docker!" Docker, at present, isn't really usable with GUI applications yet.

And please, don't tell me "but Docker!" Docker, at present, isn't really usable with GUI applications yet.

But Flatpak! Flatpak applications can be sandboxed and you can install/remove applications as one unit.


Is Flatpak still open to the issues outlined at http://flatkill.org/?

If so, it doesn’t seem much better.


A package manager would be designed to remove any non user hostile features. Intentionally hostile behavior would be unaffected. One might hope that the packager, the person that is, might have refused to include software from incompetent or hostile developers.

Something an app store due to volume and default allow pending mostly automated checks has a problem with.


As far as I know most traditional package managers only remove files and folders declared in the package. Not files installed somewhere else during the install script or created by the binary when it runs.

Files installed elsewhere during the install script are treated as config files and can be purged, no?

that is explicitly incorrect. macos has a very nice and effective way of packaging all the components needed by an app into tidy bundles.

the problem in this case is that the developers just couldn't be assed even trying.


Not really, If you have a standard app that can be dragged into the trash, sure. If you have a kernel extension, or a launch deamon or any application data you store locally you cannot clean up after yourself without a custom uninstaller. Windows is far ahead in its centralized Add&Remove Programs area.

Not really, If you have a standard app that can be dragged into the trash, sure. If you have a kernel extension, or a launch deamon or any application data you store locally you cannot clean up after yourself without a custom uninstaller.

This is false. Kernel extensions can be part of the application bundle and will be unloaded and removed when the bundle is removed.

Installing KEXTs in an application bundle allows an application to register those KEXTs without the need to install them permanently elsewhere within the system hierarchy. This may be more convenient and allows the KEXT to be associated with a specific, running application. When it starts, the application can register the KEXT and, if desired, unregister it on exit.

For example, a network packet sniffer application might employ a Network Kernel Extension (NKE). A tape backup application would require that a tape driver be loaded during the duration of the backup process. When the application exits, the kernel extension is no longer needed and can be unloaded.

Source: https://developer.apple.com/library/archive/documentation/Da...

You can also launch agents that are part of your application bundle:

https://developer.apple.com/documentation/servicemanagement/...

It is true that you cannot remove application data, but that is a feature (maybe users want to retain the data) and also does not happen in e.g. Linux package managers.


I am not sure it is false if you want it loaded on startup.

No, the de vintentionally circumvented the bundling and containerization that exists, and MacOS couldn't prevent it. That said, Windows and Linux can't prevent it either, in common configurations.

macOS has a very good concept of package management and containerization. It's just optional because people get even more up in arms when their old software doesn't work any more.

Apple also makes a fantastic computing platform with very good mandatory isolation, namely, iOS. If you're interested in isolation in preference to compatibility with traditional desktop software, an unjailbroken iPad Pro with Smart Keyboard is a pretty good option.


I don't think it's just old software that might break. One must also consider the software not yet to be written. If the isolation is too constraining for some type of application that really needs a privilege, and isolation is mandatory, then some amount of innovation will just have to happen somewhere else or not at all.

Remember old school Mac was full of hacks upon hacks upon hacks, many by third parties, and there was cool stuff in there too. The App Store mentality has caused everyone to overreact and think that every third party app on the planet will turn into the worst conception of Win98 era malware overnight if unconstrained, when this is just one outcome among many possible.


Probably to not allow it to run if the users didn't update Zoom.



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: