ทุกครั้งที่คุณติดตั้งแอปบน Android ไม่ว่าจะเป็นเกม แอปธนาคาร หรือโซเชียลมีเดีย สิ่งหนึ่งที่เกิดขึ้นอย่างเงียบ ๆ เบื้องหลังคือระบบสร้าง "กล่องทราย" หรือ Sandbox ให้กับแอปนั้นทันที กล่องนี้จะกักแอปไว้ไม่ให้ยุ่งเกี่ยวกับแอปอื่น ป้องกันไม่ให้แอปที่เป็นอันตรายขโมยข้อมูลหรือโจมตีระบบได้โดยตรง

แล้ว Sandbox ใน Android มีที่มาอย่างไร? เริ่มต้นตั้งแต่เมื่อไหร่? และพัฒนาการมาเป็นอย่างไร? บทความนี้จะพาคุณย้อนดูประวัติศาสตร์ของระบบความปลอดภัยที่สำคัญที่สุดชิ้นหนึ่งในโลก Android

จุดเริ่มต้น: Android 1.0 (2008) — Sandbox ถูกฝังอยู่ตั้งแต่วันแรก

สิ่งที่น่าทึ่งคือ Application Sandbox เป็นส่วนหนึ่งของ Android ตั้งแต่วันแรกที่เปิดตัว ในปี 2008 ไม่ใช่ฟีเจอร์ที่ถูกเพิ่มเข้ามาทีหลัง

หัวใจของ Sandbox คือการที่ Android อิงสถาปัตยกรรมความปลอดภัยจาก Linux Kernel โดยตรง ระบบจะกำหนด UID (User ID) เฉพาะ ให้กับแอปแต่ละตัวตั้งแต่ขณะติดตั้ง เปรียบเสมือนแต่ละแอปคือ "ผู้ใช้" คนละคนในระบบ Linux

ผลที่ได้คือ:

• แอป A ไม่สามารถอ่านหรือแก้ไขไฟล์ของแอป B ได้
• แต่ละแอปรันอยู่ใน process แยก มี memory address space ของตัวเอง
• ข้อมูลส่วนตัวถูกเก็บไว้ใน /data/data/<package_name>/ ซึ่งมีสิทธิ์อ่าน-เขียนเฉพาะแอปนั้น

ระบบนี้เรียบง่าย ตรวจสอบได้ และอิงบนหลักการ UNIX ที่ผ่านการพิสูจน์มาหลายทศวรรษ

พัฒนาการตามเวอร์ชัน: แข็งแกร่งขึ้นทุกรุ่น

Android 4.3 Jelly Bean (2013) — SELinux เข้ามาเสริม

ก่อนหน้า Android 4.3 การแยก Sandbox ทำได้ผ่าน UID เพียงอย่างเดียว ซึ่งถือเป็น Discretionary Access Control (DAC) คือเจ้าของไฟล์เป็นคนกำหนดสิทธิ์เอง

Android 4.3 นำ SELinux (Security-Enhanced Linux) เข้ามาใช้เป็นครั้งแรก ในโหมด "permissive" คือยังไม่บังคับใช้เต็มรูปแบบ แต่เริ่มบันทึกและเตรียมโครงสร้างไว้

Android 4.4 KitKat (2013) — SELinux เริ่มบังคับใช้บางส่วน

เริ่มบังคับใช้ SELinux กับบาง domain สำคัญ เช่น installd, netd, vold และ zygote

Android 5.0 Lollipop (2014) — SELinux บังคับใช้เต็มรูปแบบ

นี่คือการก้าวกระโดดครั้งใหญ่ SELinux เปลี่ยนจาก permissive เป็น enforcing mode อย่างสมบูรณ์ กับทุก domain มากกว่า 60 domains ระบบเปลี่ยนจาก DAC มาเป็น Mandatory Access Control (MAC) ซึ่งแม้แต่ root process ก็ยังถูกจำกัดโดย policy ของ SELinux

นอกจากนี้ Android 5.0 ยังแยก WebView ออกเป็น package แยกต่างหาก ลดพื้นผิวการโจมตีผ่านเบราว์เซอร์

Android 6.0 Marshmallow (2015) — แยก user boundary และเพิ่มความเป็นส่วนตัว

SELinux ถูกขยายให้แยก app ข้ามขอบเขตของ physical user แต่ละคนได้ด้วย รวมถึงเปลี่ยนค่าเริ่มต้นของสิทธิ์ directory ของแอปจาก 751 เป็น 700 ซึ่งปลอดภัยกว่า (สำหรับแอปที่กำหนด targetSdkVersion >= 24)

และที่สำคัญที่สุดคือการนำระบบ Runtime Permission มาใช้อย่างเป็นทางการ แอปต้องขออนุญาตผู้ใช้ทุกครั้งที่ต้องการเข้าถึงสิทธิ์ที่ละเอียดอ่อน เช่น กล้อง, ตำแหน่ง, รายชื่อผู้ติดต่อ แทนที่จะขอทีเดียวตอนติดตั้ง

Android 8.0 Oreo (2017) — Seccomp filter ครบทุกแอป

Seccomp-BPF (Secure Computing with Berkeley Packet Filter) ถูกบังคับใช้กับทุกแอป ระบบนี้ทำหน้าที่กรอง System Call ที่แอปสามารถเรียกใช้ได้ ลดโอกาสที่แอปจะหลุดออกจาก Sandbox โดยการโจมตีผ่าน kernel

นอกจากนี้ WebView rendering process ยังถูก isolate ด้วย seccomp อีกชั้น ห้ามเข้าถึง permanent storage และ network โดยตรง

Android 9 Pie (2018) ขึ้นไป — ความปลอดภัยเชิงลึก

การแยก process ของ media codecs ออกมาเป็น sandbox ย่อย ๆ ที่เรียกว่า hardware isolated processes ลดความเสี่ยงหากพบช่องโหว่ใน media stack การเพิ่ม Namespace isolation และมาตรการ defense-in-depth อีกหลายชั้น

สรุปพัฒนาการ Sandbox ตาม Android Version

สถาปัตยกรรม Sandbox ในปัจจุบัน

Sandbox ของ Android สมัยใหม่ประกอบด้วยหลายชั้น:

┌─────────────────────────────────────────────┐
│              Application Layer              │
│  (แต่ละแอปใน process + UID แยกของตัวเอง)    │
├─────────────────────────────────────────────┤
│           Runtime Permission System         │
│      (ขอสิทธิ์จากผู้ใช้ขณะรันโปรแกรม)       │
├─────────────────────────────────────────────┤
│         SELinux (Mandatory Access Control)  │
│    (policy บังคับทุก process แม้แต่ root)    │
├─────────────────────────────────────────────┤
│          Seccomp-BPF Filter                 │
│      (จำกัด system call ที่เรียกได้)          │
├─────────────────────────────────────────────┤
│           Linux Kernel (UID/GID DAC)        │
│     (รากฐานของการแยก process และไฟล์)        │
└─────────────────────────────────────────────┘

การสื่อสารระหว่างแอปต้องผ่านช่องทางที่กำหนด

เนื่องจากแอปอยู่คนละ Sandbox จึงต้องใช้กลไก IPC อย่างเป็นทางการ เช่น:

• Intent — ส่งคำสั่งหรือข้อมูลระหว่างแอป
• Content Provider — แชร์ข้อมูลแบบมีโครงสร้าง
• Binder IPC — สื่อสารระดับต่ำระหว่าง process
• Shared Storage / MediaStore — แชร์ไฟล์ผ่านพื้นที่กลาง

ข้อสรุป

Android Application Sandbox ไม่ใช่ฟีเจอร์ที่เพิ่งเกิดขึ้น แต่เป็นรากฐานที่ฝังลึกตั้งแต่ Android 1.0 ในปี 2008 อิงบนหลักการ UNIX ที่พิสูจน์แล้วหลายทศวรรษ จากนั้นถูกเสริมความแข็งแกร่งในทุกรุ่น ด้วย SELinux, Runtime Permission, Seccomp และ hardware isolation

ระบบนี้คือเหตุผลสำคัญที่ทำให้ Android สามารถรองรับแอปหลายล้านตัวจากนักพัฒนาทั่วโลก โดยยังคงความปลอดภัยสำหรับผู้ใช้ปลายทางได้ในระดับสูง

อ้างอิง: Android Open Source Project (source.android.com), Android Security Model (ACM 2021), SELinux in Android (AOSP Documentation)

บทความ Power by Claude.ai