App Sandbox ในการพัฒนาแอปบนมือถือ — คืออะไร กลไกและหลักการทำงาน

App Sandbox คืออะไร?

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

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

ระบบปฏิบัติการบนมือถือนำ Sandbox มาใช้ก่อนระบบเดสก์ท็อป iOS ใช้ Sandbox ตั้งแต่เวอร์ชันแรกของ SDK (2008) ส่วน Android ใช้ตั้งแต่เวอร์ชัน 1.0 (2008) แต่มีการเสริมความแข็งแกร่งใน Android 4.3 (2013) ผ่าน SELinux ระบบเดสก์ท็อปกำลังตามมา: macOS นำ Sandbox มาใช้ในปี 2012 ส่วน Windows ใช้แอปที่แยกสภาพแวดล้อมแบบ UWP ใน Windows 8

การแยกสภาพแวดล้อมใน Sandbox ทำงานอย่างไร?

การแยกสภาพแวดล้อมใน Sandbox ทำได้โดยการผสมผสานกลไกหลายอย่างในระดับต่าง ๆ ของระบบปฏิบัติการ ในระดับ ระบบไฟล์ แต่ละแอปพลิเคชันจะได้รับไดเรกทอรีที่ได้รับการป้องกันของตนเอง ซึ่งเฉพาะแอปพลิเคชันนั้นเท่านั้นที่สามารถเข้าถึงได้อย่างเต็มที่ ในระดับกระบวนการ จะใช้รหัสผู้ใช้ (UID) ที่ไม่ซ้ำกันสำหรับแต่ละแอปพลิเคชัน ในระดับเคอร์เนล จะใช้การควบคุมการเข้าถึงแบบบังคับ (MAC) ผ่าน SELinux หรือกลไกที่คล้ายกัน

การแยกสภาพแวดล้อมของระบบไฟล์

แต่ละแอปพลิเคชันได้รับไดเรกทอรีรากของตนเองบนระบบไฟล์ของอุปกรณ์ ใน iOS ไดเรกทอรีนี้คือ /var/mobile/Containers/Data/Application/{UUID} ใน Android คือ /data/data/{package_name} แอปพลิเคชันสามารถอ่านและเขียนไฟล์ได้เฉพาะภายในไดเรกทอรีนี้เท่านั้น การเข้าถึงไฟล์ใด ๆ นอกเหนือจากไดเรกทอรีนี้จะถูกบล็อกในระดับเคอร์เนลของระบบปฏิบัติการ

ระบบยังมีไดเรกทอรีที่ใช้ร่วมกันพิเศษพร้อมการเข้าถึงแบบจำกัด ใน iOS ได้แก่ ไดเรกทอรี Documents สำหรับข้อมูลผู้ใช้ Library สำหรับการตั้งค่า และ Caches สำหรับไฟล์ชั่วคราว ใน Android ได้แก่ พื้นที่จัดเก็บภายใน (getFilesDir) และพื้นที่จัดเก็บภายนอก (getExternalFilesDir) ซึ่งการเข้าถึงไม่ต้องขออนุญาตเพิ่มเติม

การแยกสภาพแวดล้อมของกระบวนการและ UID

ใน Android แต่ละแอปพลิเคชันทำงานเป็น กระบวนการ Linux แยกต่างหากด้วย UID (User ID) ที่ไม่ซ้ำกัน UID จะถูกกำหนดเมื่อติดตั้งแอปพลิเคชันและยังคงไม่เปลี่ยนแปลงตลอดอายุการใช้งาน กระบวนการที่มี UID ต่างกันจะถูกแยกจากกันในระดับเคอร์เนล — ไม่สามารถเข้าถึงหน่วยความจำหรือไฟล์ของกันและกันได้ กลไกที่คล้ายกันทำงานใน iOS ผ่านเคอร์เนล XNU และระบบการป้องกัน

ระดับการป้องกันเพิ่มเติมใน Android มีให้โดย SELinux (Security-Enhanced Linux) ในโหมด enforcing ตั้งแต่ Android เวอร์ชัน 4.3 SELinux ใช้การควบคุมการเข้าถึงแบบบังคับ (MAC): ทุกการกระทำของกระบวนการจะถูกตรวจสอบว่าสอดคล้องกับนโยบายความปลอดภัยหรือไม่ โดยไม่ขึ้นกับสิทธิ์ของเจ้าของไฟล์ แม้ว่าแอปพลิเคชันจะทำงานด้วย UID root SELinux ก็สามารถบล็อกการเข้าถึงทรัพยากรบางอย่างได้

Sandbox ใน iOS

Sandbox ของ iOS ถือเป็นหนึ่งในระบบที่เข้มงวดที่สุดในบรรดาระบบปฏิบัติการบนมือถือ แต่ละแอปพลิเคชันถูกแยกสภาพแวดล้อมในระดับ คอนเทนเนอร์ — พื้นที่ระบบไฟล์ที่ได้รับการป้องกันซึ่งไม่สามารถเข้าถึงได้จากแอปอื่น iOS ใช้การผสมผสานระหว่างการควบคุมการเข้าถึงแบบบังคับผ่าน Sandbox Kernel Extension (Sandbox.kext) และกลไก entitlement สำหรับการให้สิทธิ์ขั้นสูง

โครงสร้างคอนเทนเนอร์ของ iOS

คอนเทนเนอร์ของแอปพลิเคชัน iOS ประกอบด้วยไดเรกทอรีหลายรายการที่มีระดับการเข้าถึงต่างกัน Documents — สำหรับข้อมูลผู้ใช้ที่ถูกบันทึกเมื่อสำรองข้อมูลผ่าน iCloud และ iTunes Library — สำหรับไฟล์การกำหนดค่าและแคช tmp — สำหรับข้อมูลชั่วคราวที่ระบบสามารถลบได้ทุกเมื่อ AppName.app — ตัวบัundle ของแอปพลิเคชันเอง ซึ่งเข้าถึงได้เฉพาะการอ่านเท่านั้น

การเข้าถึงข้อมูลของแอปอื่นถูกห้ามโดยเด็ดขาด iOS ไม่มี API สำหรับการอ่านไฟล์จากคอนเทนเนอร์ของแอปอื่น วิธีเดียวในการแลกเปลี่ยนข้อมูลคือผ่านกลไกของระบบ: UIActivityViewController สำหรับการแชร์ UIPasteboard สำหรับคลิปบอร์ด App Groups สำหรับแอปของนักพัฒนาคนเดียวกัน แต่ละกลไกเหล่านี้ทำงานภายใต้การควบคุมของระบบปฏิบัติการ

Entitlements และ App Sandbox ใน iOS

ความสามารถเพิ่มเติมนอกเหนือจาก Sandbox มาตรฐานมีให้ผ่าน Entitlements — ลายเซ็นดิจิทัลที่เพิ่มเข้าไปในลายเซ็นโค้ดของแอปพลิเคชัน ตัวอย่างเช่น entitlement com.apple.security.application-groups อนุญาตให้แอปในกลุ่มเดียวกันมีคอนเทนเนอร์ที่ใช้ร่วมกัน การแจ้งเตือน Push, iCloud, Apple Pay — ฟังก์ชันเหล่านี้ทั้งหมดต้องมี entitlements ที่เกี่ยวข้อง

สิ่งสำคัญที่ต้องทราบคือ entitlements ใน iOS ไม่เหมือนกับการอนุญาต (permissions) การอนุญาตจะขอจาก ผู้ใช้ ในขณะรันไทม์ (เช่น การเข้าถึงกล้อง) ในขณะที่ entitlements จะถูกตรวจสอบโดยระบบในขั้นตอนการติดตั้งและไม่สามารถเปลี่ยนแปลงได้โดยผู้ใช้ Entitlement ถูกกำหนดโดยนักพัฒนาและลงนามโดย Apple ในกระบวนการตรวจสอบแอปพลิเคชัน

Sandbox ใน Android

Android ใช้โมเดล Sandbox แบบหลายระดับที่建立在เคอร์เนล Linux แต่ละแอปพลิเคชันทำงานเป็น ผู้ใช้ Linux แยกต่างหากด้วย UID ที่ไม่ซ้ำกัน ซึ่งให้การแยกสภาพแวดล้อมพื้นฐานในระดับกระบวนการและไฟล์ ระดับเพิ่มเติม — SELinux สำหรับการควบคุมการเข้าถึงแบบบังคับ และ Permissions สำหรับควบคุมการเข้าถึง API ของระบบ

SELinux และการแยก UID

SELinux ใน Android ทำงานในโหมด enforcing ซึ่งหมายถึงการบังคับใช้นโยบายความปลอดภัย แต่ละแอปพลิเคชันจะได้รับบริบทความปลอดภัย (security context) และการเรียกของระบบทั้งหมดจะถูกตรวจสอบว่าสอดคล้องกับนโยบาย SELinux ใน Android มีกฎมากกว่า 1500 ข้อครอบคลุมระบบไฟล์ การสื่อสารระหว่างกระบวนการ ซ็อกเก็ต และการเรียกของระบบ

การแยก UID ป้องกันการเข้าถึงไฟล์ของแอปอื่นโดยตรง ตัวอย่างเช่น แอป A ที่มี UID 10001 ไม่สามารถอ่านไฟล์ของแอป B ที่มี UID 10002 ได้ แม้ว่าทั้งสองจะทำงานในนามของผู้ใช้โทรศัพท์คนเดียวกัน นี่คือหลักการพื้นฐานของ ความปลอดภัยแบบหลายผู้ใช้ ของ Linux ที่ปรับใช้สำหรับอุปกรณ์มือถือ

// การเข้าถึงไดเรกทอรีของแอปพลิเคชันใน Android
File appDir = context.getFilesDir();
File cacheDir = context.getCacheDir();
File externalDir = context.getExternalFilesDir(null);

// การพยายามเข้าถึงไดเรกทอรีของแอปอื่นจะทำให้เกิด SecurityException
// File otherApp = new File("/data/data/com.other.app/shared_prefs/");

// การใช้ FileProvider เพื่อการแชร์ไฟล์อย่างปลอดภัย
Uri contentUri = FileProvider.getUriForFile(
    context, "com.example.fileprovider", file
);

Android มีกลไกเพิ่มเติมสำหรับการแลกเปลี่ยนข้อมูลอย่างปลอดภัยระหว่างแอปพลิเคชัน ContentProvider — คอมโพเนนต์ของ Android ที่ช่วยให้แอปพลิเคชันสามารถให้สิทธิ์เข้าถึงข้อมูลของตนแก่แอปอื่นผ่าน URI ที่กำหนดอย่างเคร่งครัด FileProvider — วิธีการแชร์ไฟล์ที่ปลอดภัยโดยไม่เปิดเผยเส้นทางของระบบไฟล์

ข้อจำกัดและความปลอดภัยของ Sandbox

แม้ว่า App Sandbox จะเป็นกลไกการป้องกันที่ทรงพลัง แต่ก็มี ข้อจำกัดพื้นฐาน Sandbox ป้องกันการเข้าถึงในแนวนอน (แอปสู่แอป) แต่ไม่ป้องกันในแนวตั้ง (มัลแวร์ในระดับเคอร์เนลหรือการเข้าถึงอุปกรณ์ทางกายภาพ) เมื่อมีการเจลเบรก (jailbreak) หรือเข้าถึงรูท (root) Sandbox อาจถูกเลี่ยงได้เนื่องจากผู้ไม่หวังดีได้รับสิทธิ์ผู้ใช้ระดับสูง

ข้อจำกัดที่สอง — การอนุญาตที่เป็นอันตราย หากผู้ใช้อนุญาตให้แอปพลิเคชันเข้าถึงรายชื่อติดต่อและไมโครโฟน Sandbox ไม่สามารถป้องกันการรวบรวมข้อมูลนี้ได้ เนื่องจากแอปพลิเคชันใช้ API ของระบบที่ถูกต้องตามกฎหมาย การป้องกันในกรณีนี้จะขึ้นอยู่กับความตระหนักรู้ของผู้ใช้และการตรวจสอบของ App Store และ Google Play

ข้อจำกัดที่สาม — การโต้ตอบระหว่าง Sandbox บริการของระบบบางอย่าง (NotificationListenerService, AccessibilityService) มีการเข้าถึงข้อมูลของแอปอื่นในวงกว้าง ผู้ไม่หวังดีอาจใช้บริการเหล่านี้เพื่อเลี่ยง Sandbox หากได้รับอนุญาตที่เกี่ยวข้อง Google และ Apple อัปเดตนโยบายสำหรับบริการดังกล่าวอย่างต่อเนื่อง

แม้จะมีข้อจำกัด Sandbox ก็ยังคงเป็น องค์ประกอบสำคัญด้านความปลอดภัย ของระบบปฏิบัติการมือถือ ตามรายงาน Android Security Report (2024) การแยกสภาพแวดล้อมด้วย Sandbox ป้องกันความพยายามเข้าถึงข้อมูลระหว่างแอปได้มากกว่า 99% เมื่อรวมกับ Code Signing, App Review และการอนุญาตขณะรันไทม์ Sandbox จะสร้างการป้องกันหลายชั้นของอุปกรณ์มือถือสมัยใหม่