Kérdés:
Mennyire veszélyes az a tény, hogy a SELinux "Permissive" módban van? Mitől legyek óvatos?
j.d'oh
2016-07-03 16:12:45 UTC
view on stackexchange narkive permalink

Telepítettem egy bizonyos ROM-ot, amely SELinuxszal érkezik "Engedélyezett" módban. Ez az egyetlen (jó) ROM, amely megfelelően illeszkedik az eszközömhöz, és nincs mód a SELinux állapotának megváltoztatására.

Most már nem vagyok biztos benne, milyen következményei lehetnek egy ilyen döntésnek, és örülök, ha valaki meg tudná magyarázni nekem (gugliztam, és tudom, mi ez elméletileg ... csak nem a gyakorlatban). A mondott ROM gyökere a "letiltva" van, így állítólag nem gyökerezik az eszköz, de hogyan illik ez a SELinux nem vagyok benne biztos.

Biztosan állítja, hogy "nincs mód a SELinux állapotának megváltoztatására"? Megpróbálta kiadni a "setenforce 1" -t a terminál emulátortól (rootként)?
Nos, egy kicsit többet fogok kutatni erről, de igen, a ROM készítő utasításai miatt egészen biztos vagyok benne. Kicsit neofita vagyok, így nem vagyok 100% -ban biztos benne, miért (még mindig kutatnom kell), de a feltüntetett ok a rendszerindító letiltása ... http://forum.xda-developers.com/amazon-fire/orig -development / rom-cm-12-1-2015-11-15-t3249416
Egy válasz:
WhiteWinterWolf
2016-07-28 22:59:26 UTC
view on stackexchange narkive permalink

TL; DR: Nyugodtan ugorhat közvetlenül az alján levő következtetésre, ha úgy tetszik :)!

A SELinux célja az, hogy megakadályozza a privilégiumok fokozódását egy kötelező irányelv végrehajtásával. amely korlátozza mind a kiváltságos, mind a kiváltságos felhasználók lehetséges műveleteit.

A "felhasználók" kifejezés itt minden olyan folyamatot magában foglal, amely az eszközön fut, függetlenül attól, hogy az közvetlenül kapcsolódik-e a fizikai felhasználói műveletekhez (az ember, te ;)), mivel minden folyamat valamilyen rendszer "felhasználói" fiókot használ.

A Unix-alapú rendszerek engedélyeit történelmileg úgy kezelik, hogy az úgynevezett diszkrecionális hozzáférés-vezérlő (DAC) rendszert használja. Ebben a modellben:

  • Az olyan erőforrásoknak, mint a fájlok, vannak tulajdonosai, akik meghatározhatják a tulajdonukban lévő erőforrások hozzáférési jogait: ez lehetővé teszi számukra, hogy eldöntsék, egy adott erőforrásnak privátnak kell-e lennie (csak a tulajdonos fér hozzá) vagy ha meg kell osztani más felhasználókkal.
  • Ezen felül megvan a szuperfelhasználó (az úgynevezett root a Unix-alapú rendszereken), amely az adminisztrációs felhasználó, és hozzáférhet a rendszer mindenhez. Ezt a fiókot egy ember (tipikusan rendszergazda) interaktívan használhatja az eszköz karbantartására vagy javítására, de általában ezt a fiókot leginkább olyan háttér- vagy alacsony szintű szolgáltatások fogják használni, amelyek ilyen privilégiumszintet igényelnek: eszközillesztők, hálózati konfigurációs szolgáltatások, szolgáltatások minden felhasználó fájljaihoz kell hozzáférni, vagy a felhasználók közötti belső kommunikációt kell kezelnie.

Ez nagyon kedves és már jó biztonságot nyújt. Mi a helyzet azonban az ilyen körülményekkel:

  1. Mi történne, ha olyan hibát találnánk egy root néven futó szolgáltatásban, amely lehetővé tenné a támadó számára, hogy becsapja az ilyen szolgáltatást önkényes kód futtatása? Az ilyen támadók teljes hozzáférést kapnának az eszközhöz. Konkrét példaként megemlítve, egy ilyen hibát kiválthat egy speciálisan kialakított hálózati konfigurációs információ ( DHCP) vagy egy MMS telefonra küldése.
  2. Mi történne, ha néhány felhasználó nem megfelelően védi a magánforrásokat? Ezután ezeket a forrásokat rosszindulatúan elérhetik (olvashatják, esetleg módosíthatják vagy törölhetik) más kiváltságtalan felhasználók. Ez általában akkor van, amikor egy rosszindulatú alkalmazás fut a telefonon (függetlenül attól, hogy becsapták-e a telepítést, vagy ha magától jött ide egy hibát használva egy másik nem privilegizált alkalmazásban, egy böngészőben vagy e-mail kliensben) példány), és ez a rosszindulatú alkalmazás megpróbálja közvetlenül elérni az alkalmazások egyéb adatait vagy tárhelyeit (ezt megteheti a normálisan elérhetetlen adatokhoz való hozzáféréshez, vagy több helyre telepítheti magát az eltávolítás megnehezítése érdekében).
  3. ol >

    Itt jön a SELinux.

    A SELinux egy kötelező hozzáférés-vezérlő (MAC) rendszer. Míg a korábban leírt DAC rendszerben a felhasználók felelősek voltak a saját erőforrások megfelelő megfelelő beállításáért, a MAC rendszerrel a rendszerszintű (az operációs rendszerrel együtt biztosított) házirendet érvényesítik mind a kiváltságos, mind a kiváltságos felhasználók számára.

    Ez a következő két módon oldja meg a fent említett két kérdést:

    1. Mint mondtam, ez a házirend a kiváltságos felhasználókra is vonatkozik. Ez azt jelenti, hogy egy megfelelően megtervezett házirend alkalmazásával az eszköz hálózati konfigurációjának kezelésére tervezett szolgáltatás nem lesz képes mást tenni: például nem fér hozzá az SMS-hez, és az SMS-t kezelő szolgáltatás nem fér hozzá a hálózati konfigurációhoz , és egyikük sem férhet hozzá a felhasználó adataihoz, annak ellenére, hogy mindkettő a szuperfelhasználói fiókot használja.
    2. Az Android nemrégiben tartalmazott egy többfelhasználós funkciót, amelyet a SELinux hajtott végre, megakadályozva, hogy bármely felhasználó hozzáférjen más felhasználók adataihoz. De ezen túlmenően a SELinux házirend felelős az engedélyezett alkalmazások viselkedésének leírásáért is, és valószínűleg még akkor is, ha egyes erőforrások nincsenek megfelelően védve a DAC rendszer használatával, a SELinux segítséget nyújt, és még mindig megakadályozza a rosszindulatú alkalmazások közvetlen hozzáférését hozzájuk. >

    A DAC és a MAC rendszerek nem zárják ki egymást, éppen ellenkezőleg, a MAC rendszer (SELinux) a DAC rendszer második védelmi rétegeként működik (a hagyományos Unix-szerű engedélyek). A SELinux feladata minden olyan tevékenység blokkolása, amely ellentétes a házirenddel, amelyet csak a DAC rendszer ismerne el.

    Az a trükkös, hogy egy ilyen házirendet nagyon bonyolult lehet megírni: valóban meg kell takarja le minden eszköz alkatrészeit minden lehetséges felhasználáshoz, minden helyzetben. Valójában, függetlenül attól, hogy bizonyos cselekedetek jogosak lehetnek-e a helyzetedben: ha nem szerepel a házirendben, akkor tilos . A rosszul megtervezett házirendeknek ezért véletlenszerű következményei lehetnek, például az alkalmazás összeomlása, a használhatatlan funkcionalitás stb.

    Ezért az Android SELinux első szállítási verziói alapértelmezés szerint „Engedélyezett” módba foglalták. Ebben a módban a SELinux naplózza az irányelvsértéseket, de nem kísérli meg blokkolni a társított tevékenységet. Az eredményül kapott naplófájlok elemzésével lehetővé válik a házirend kijavítása és továbbfejlesztése, egészen addig a pontig, amikor az egyetlen fennmaradó irányelvsértés valóban rosszindulatú vagy nem kívánt viselkedés. Ezen a ponton a SELinux „kényszerítő” módba kapcsolható: mostantól nemcsak naplózni fog, hanem blokkolni is fog minden jogsértő műveletet.

    Következtetés

    A SELinux egy enyhítési technika. Ez nem akadályozza meg a támadókat abban, hogy belépjenek az Ön telefonjába, de biztosítja, hogy miután odaértek, a lehető legkevesebb dolgot tudják megtenni, ideális esetben semmi hasznosat, így mindenekelőtt elhárítják a telefon támadásának minden érdeklődését.

    Régebbi a ROM, annál nagyobb a biztonsági hibák száma, amelyek megnyitják az ilyen hozzáférést. A SELinux hatékony módszer lenne a minimális biztonság megtartására ezen ismert sebezhetőségek ellenére, azonban a megfelelő működés érdekében a SELinux egy összetett házirendre támaszkodik.

    Ha a ROM-ot alapértelmezés szerint "Engedélyezett" módban látja el a SELinux, ez valószínűleg azt jelenti, hogy a benne foglalt irányelv nem elég megbízható ahhoz, hogy biztonságosan átválthasson "Kényszerítés" módba.

    Ha elég technikus vagy és hozzáférsz a telefonnaplóhoz ( dmesg legalább, de általában másolják őket a logcat fájlba is: vannak olyan alkalmazások, amelyek lehetővé teszik az utóbbi megtekintését, de az Android verziójától függően root hozzáférést igényelhetnek), ellenőrizheti, hogy talál-e "avc" -t bejegyzések: ezek azok az üzenetek, amelyek arról árulkodnak, hogy a SELinux éppen most észlelt egy házirendbe ütköző műveletet.

    Íme egy példa a CyanogenMod webhelyéről vett bejegyzésekre:

      type = AVC msg = audit (1363289005.532: 184): avc: denied {read} for pid = 29199 comm = "Trace" name = "online" dev = "sysfs" ino = 30 scontext = staff_u : staff_r: googletalk_plugin_t tcontext = system_u: object_r: sysfs_t tclass = file  

    Ha nincs, csak néhány közülük, vagy bármilyen okból úgy gondolja, hogy nem akadályozza meg a telefon használatát , megpróbálhatja átkapcsolni a SELinuxot "kényszerítés" módra. Régebbi CyanogenMod ROM-okon ez egyszerű és lehetséges volt egyszerűen a rejtett opció használatával a GUI-ban (nem kell gyökeret eresztenie a telefonra vagy telepítenie kell egy adott alkalmazást), nem tudom, hogy más ROM-ok is ugyanazt kínálják-e funkció, de mivel Ön a CyanogenMod címkét használta, feltételezem, hogy szerencsés lehet;).

@j.d'oh: A hozzászólások nem bővített viták, létrehoztam egy [új csevegőszobát] (https://chat.stackexchange.com/rooms/43343/discussion-between-j-doh-and-whitewinterwolf) hogy megpróbálja megoldani kérdéseit.


Ezt a kérdést és választ automatikusan lefordították angol nyelvről.Az eredeti tartalom elérhető a stackexchange oldalon, amelyet köszönünk az cc by-sa 3.0 licencért, amely alatt terjesztik.
Loading...