Metr0pl3x on Nostr: Evolving the Mobile Security Distro Boris LukashevBoris Lukashev Boris Lukashev Chief ...
Evolving the Mobile Security Distro
Boris LukashevBoris Lukashev
Boris Lukashev
Chief Technology Officer at InferSight
Published Jun 23, 2023
My LinkedIn feed is permeated with posts about the dangers of mobile computing, the malware delivery stacks known as app stores, and the sieves of confidential information generally seen as "phones." Having had "smart" devices since their inception and working in the security field; I've been fortunate enough to watch the state of the art, discourse, and consumer demand for security of these systems (which underpins privacy) evolve from the start. As far as i can tell, vendor effort to implement boundaries, reinforce them, and proof their standing posture is directly commensurate to consumer demand for the things that depend on this technical infrastructure - user privacy/data security/personal risk aversion.
Coming from the offensive security side of the house, i rely on GrapheneOS (previously known as AndroidHardening, and initially CopperheadOS) and have done so since the project started producing stable daily driver images almost 10 years ago, to provide the added logical constraints around execution context (sandboxing through massively improved SELinux, under the skin) sufficient to make privesc by an attacker with foothold undesirable while keeping their low-privilege level access to a mostly useless level. The design of the stack isolates entities (apps) and their permission scopes to the maximum level of granularity feasible without breaking functionality. Binary hardening at build and runtime reinforces the barriers to access by means including a more rigorous memory model handling dynamic allocations (and frees to avoid reuse concerns), modest hardening of the Linux kernel sources beneath userspace, and compile-time hardening via (LLVM's coarse-grained) CFI and other compiler/config mechanisms. The effect of these reinforcements is to provide standoff against attacks leveraging the properties of heaps and stack pivots seeking to bypass the privilege restrictions which therefore enforce the mechanics providing user privacy. All that "security tech" boils down to "peace of mind" for the non-technical user.
Unfortunately, efforts like this are incredibly rare and generally unsupported by "upstream" - the team over at Open Source Security, Inc. have been driving the state of the art for the defensive model in the Linux space for ~2 decades and eventually had to form a commercial org to support their own work because the industry outright refused, and the user-driven funding was insufficient to keep the lights on much less grow and improve on the effort anything near what they're doing today. Had the user-base backed them, with well-reasoned arguments to Linux maintainers and some level of financial support, to push at least partial adoption upstream; the entire world would be a safer place today from the standoff this sort of work brings from attacks and their knock-on effects (cost, however its measured).
Today, GrapheneOS stands at the precipice of an evolution: the project is coming under the structured leadership of a dedicated foundation which will permit it to stabilize, grow roots, and acquire the talent so desperately needed to push forward the state of this art. With change comes uncertainty, and with it, instability at a critical juncture of effort - the project operates on donations which are the mechanism for funding (at a labor rate unsuited for survival already) the core development and structural work making any of this possible.
I know that plenty of my colleagues in #infosec use GrapheneOS for similar reasons to me and the considerations/problems they would have to go through were this effort to unravel... Lets not repeat our mistakes, and step up to support this valuable effort while it becomes a full-fledged security distribution in the larger ecosystem of Linux.
Take it from someone who's seen how the sausage is made: you do not want to try to maintain a hardened AOSP fork all alone - I've 908c/2.4T allocated to buildbots right now... how about you? The world is a better place for the work these folks have done and are doing; so if you have some spare coin or some time to help out, please consider donating, lending a hand, or even just propagating this message. Freely available, polished, and hardened mobile runtimes are a precious commodity which we cannot afford to have taken for granted.
https://www.linkedin.com/pulse/evolving-mobile-security-distro-boris-lukashev
Boris LukashevBoris Lukashev
Boris Lukashev
Chief Technology Officer at InferSight
Published Jun 23, 2023
My LinkedIn feed is permeated with posts about the dangers of mobile computing, the malware delivery stacks known as app stores, and the sieves of confidential information generally seen as "phones." Having had "smart" devices since their inception and working in the security field; I've been fortunate enough to watch the state of the art, discourse, and consumer demand for security of these systems (which underpins privacy) evolve from the start. As far as i can tell, vendor effort to implement boundaries, reinforce them, and proof their standing posture is directly commensurate to consumer demand for the things that depend on this technical infrastructure - user privacy/data security/personal risk aversion.
Coming from the offensive security side of the house, i rely on GrapheneOS (previously known as AndroidHardening, and initially CopperheadOS) and have done so since the project started producing stable daily driver images almost 10 years ago, to provide the added logical constraints around execution context (sandboxing through massively improved SELinux, under the skin) sufficient to make privesc by an attacker with foothold undesirable while keeping their low-privilege level access to a mostly useless level. The design of the stack isolates entities (apps) and their permission scopes to the maximum level of granularity feasible without breaking functionality. Binary hardening at build and runtime reinforces the barriers to access by means including a more rigorous memory model handling dynamic allocations (and frees to avoid reuse concerns), modest hardening of the Linux kernel sources beneath userspace, and compile-time hardening via (LLVM's coarse-grained) CFI and other compiler/config mechanisms. The effect of these reinforcements is to provide standoff against attacks leveraging the properties of heaps and stack pivots seeking to bypass the privilege restrictions which therefore enforce the mechanics providing user privacy. All that "security tech" boils down to "peace of mind" for the non-technical user.
Unfortunately, efforts like this are incredibly rare and generally unsupported by "upstream" - the team over at Open Source Security, Inc. have been driving the state of the art for the defensive model in the Linux space for ~2 decades and eventually had to form a commercial org to support their own work because the industry outright refused, and the user-driven funding was insufficient to keep the lights on much less grow and improve on the effort anything near what they're doing today. Had the user-base backed them, with well-reasoned arguments to Linux maintainers and some level of financial support, to push at least partial adoption upstream; the entire world would be a safer place today from the standoff this sort of work brings from attacks and their knock-on effects (cost, however its measured).
Today, GrapheneOS stands at the precipice of an evolution: the project is coming under the structured leadership of a dedicated foundation which will permit it to stabilize, grow roots, and acquire the talent so desperately needed to push forward the state of this art. With change comes uncertainty, and with it, instability at a critical juncture of effort - the project operates on donations which are the mechanism for funding (at a labor rate unsuited for survival already) the core development and structural work making any of this possible.
I know that plenty of my colleagues in #infosec use GrapheneOS for similar reasons to me and the considerations/problems they would have to go through were this effort to unravel... Lets not repeat our mistakes, and step up to support this valuable effort while it becomes a full-fledged security distribution in the larger ecosystem of Linux.
Take it from someone who's seen how the sausage is made: you do not want to try to maintain a hardened AOSP fork all alone - I've 908c/2.4T allocated to buildbots right now... how about you? The world is a better place for the work these folks have done and are doing; so if you have some spare coin or some time to help out, please consider donating, lending a hand, or even just propagating this message. Freely available, polished, and hardened mobile runtimes are a precious commodity which we cannot afford to have taken for granted.
https://www.linkedin.com/pulse/evolving-mobile-security-distro-boris-lukashev