About iSH’s pending removal from the App Store

Re:About iSH’s pending removal from the App Store by fiddlerwoaroof on Sunday November 08, 2020 @04:58PM (#25029474)

I think JavaScript/Clojurescript is the exception because they control the runtime and JIT: whether or not you buy their explanation, I think the reason they state is that this is to enable sandboxing. This is at least plausible to me: to have effective sandboxing, you need to restrict the APIs that a device can call, which means blocking the ability to generate and run arbitrary machine code on-device.

[ Parent | on HN ]

Re:About iSH’s pending removal from the App Store by roblabla on Sunday November 08, 2020 @07:24PM (#25030336)

> to have effective sandboxing, you need to restrict the APIs that a device can call, which means blocking the ability to generate and run arbitrary machine code on-device.

Please, no, this is not how security and sandboxing works at all. Otherwise, the moment you have an arbitrary code vulnerability, you'd get full access to everything.

The way effective sandboxing works is by giving a process a set of capabilities/permissions, what have you, that is enforced by the kernel. Those permissions can be "can I open files", "can I talk to the camera subsystem", etc. Then, even if you somehow manage to generate the right function call at runtime, the call will fail. And to be clear, this is how apple's own security works.

[ Parent | on HN ]

Re:About iSH’s pending removal from the App Store by fiddlerwoaroof on Sunday November 08, 2020 @08:29PM (#25030602)

Wouldn’t you have this as part of a defense in depth strategy? Apple’s public vs. private APIs and similar things seem to indicate that at least part of their security model involves static analysis of binaries and only allowing a set of approved APIs.

[ Parent | on HN ]

Re:About iSH’s pending removal from the App Store by saagarjha on Monday November 09, 2020 @04:26AM (#25032968)

Apple's static analysis to detect private API usage is not very clever; you can get around it with some fairly trivial tricks.

[ Parent | on HN ]

Re:About iSH’s pending removal from the App Store by roblabla on Monday November 09, 2020 @04:53PM (#25040414)

No, it's not a security mechanism period. Public/Private APIs aren't part of the security model, it's a way to prevent app breakage in their ecosystem due to applications using unstable APIs.

[ Parent | on HN ]

Re:About iSH’s pending removal from the App Store by josephcsible on Sunday November 08, 2020 @05:02PM (#25029503)

> This is at least plausible to me: to have effective sandboxing, you need to restrict the APIs that a device can call, which means blocking the ability to generate and run arbitrary machine code on-device.

This isn't true. You can sandbox arbitrary machine code by restricting the process it runs in (this is how seccomp works on Linux).

[ Parent | on HN ]

Re:About iSH’s pending removal from the App Store by yoz-y on Sunday November 08, 2020 @07:24PM (#25030339)

But iSH isn’t running arbitrary machine code, it’s a x86 emulator running Linux inside. It’s more sandboxed than a JS runtime, which actually does compile down to machine code.

[ Parent | on HN ]