app permissions toegang tot mijn computer?

[tweakmember]

.

[ Voor 100% gewijzigd door tweakmember op 17-04-2019 09:58 ]

[Hero of Time]

Lijkt mij dat je dat per Anbox container instelt met wat het moet zien. Als je opgeeft dat het / als sdkaart moet laten weergeven, ipv /lege/map, dan ja, het ziet alles.

Had je de documentatie hierover al gelezen? Ik zou verwachten dat dit geen vraag is wat zelden gesteld zal worden, dus een FAQ sectie zou dit moeten beslaan.

[tweakmember]

.

[ Voor 101% gewijzigd door tweakmember op 17-04-2019 09:58 ]

[Hero of Time]

tweakmember schreef op donderdag 1 maart 2018 @ 20:54:
[...]

Dat is niet standaard zo opgegeven? nee toch? zover ik kan zien laat het alleen lege mappen zien van anbox zelf.
ik zou niet weten hoe ik het moet opgeven als sd kaart

Geen idee, ik ken het pakket verder niet.

[...]

Een FAQ of zelfs een Privacy Policy kan ik helemaal niet vinden over Anbox.

Edit: ow wacht ik zie wel het volgende staan: "Anbox puts Android apps into a tightly sealed box without direct access to hardware or your data."
https://anbox.io/ (naar beneden scrollen)

Bedoelen ze hiermee dan Anbox geen toegang heeft tot andere gegevens wat op de pc/laptop ect staat?

Dat staat er toch duidelijk? "without direct access to your data". Hoeveel duidelijker wil je dat hebben?

[MAX3400]

Ik heb toch enige bedenkingen maar die baseer ik vooralsnog even op mijn kennis van VMware / Hyper-V / XenServer...

Elke container voor een "virtuele omgeving" maakt wel gebruik van de kernel die op je host geinstalleerd is. Denk hierbij aan CPU/VT-instructies, toegang tot (bridged / NAT) network-stack, je (virtuele / fysieke) GPU en andere zaken. In principe heeft een virtuele omgeving geen toegang tot de user-stack van het host-OS maar je kan hier alleen zeker van zijn als je voldoende kennis hebt van zowel het host-OS alsmede de container/VM.

En hier wringt de schoen; ik heb kort de site van anbox doorgenomen maar de source-code staat op https://github.com/anbox/anbox en daar staat een duidelijke uitleg; middels QEMU en pipes, wordt toch daadwerkelijk de host aangesproken om bepaalde functionaliteit tussen host en VM te realiseren. Zoals hierboven gezegd; je hebt in principe geen directe access tot de user-stack (en dus je foto's, mails en andere zaken) maar met voldoende forks/ports, is dat waarschijnlijk wel mogelijk.

@Hero of Time jij bent iets meer thuis in de *nix-wereld; ondanks dat de QEMU wordt gebruikt, is het niet ondenkbaar dat een virtual network adapter in promiscuous mode kan/moet draaien en daardoor direct "tapt" van je host-traffic toch? Uiteindelijk is de virtual adapter een ethXX op je host met een (virtual) MAC-address.

Ja, het klinkt allemaal een beetje spooky/creepy maar over het algemeen zijn de "bekende" hypervisors goed gedocumenteerd en is er met grotere zekerheid te zeggen op welke manieren je wel/niet terug kan naar het host-OS en de bestanden die daarop staan. Met Anbox kan ik die zekerheid niet geven; enerzijds door de onbekendheid van mezelf met Linux-based virtualization, anderzijds door de beperkte documentatie van Anbox.

[Hero of Time]

MAX3400 schreef op donderdag 1 maart 2018 @ 22:14:
@Hero of Time jij bent iets meer thuis in de *nix-wereld; ondanks dat de QEMU wordt gebruikt, is het niet ondenkbaar dat een virtual network adapter in promiscuous mode kan/moet draaien en daardoor direct "tapt" van je host-traffic toch? Uiteindelijk is de virtual adapter een ethXX op je host met een (virtual) MAC-address.

Compleet ondenkbaar is het denk ik niet, maar wel enorm lastig om te misbruiken als het kan. Nu ken ik Qemu zelf ook niet, maar ben zeker wel bekend met hypervisors.

Als je een VM draait, is het niet noodzakelijk om de interface in promiscuous mode te zetten. Gebruik je NAT, dan wordt het verkeer heel anders afgehandeld. Pas als je gaat bridgen gaat de host interface in promisc modus. Maar dan kan de guest er nog steeds niets mee. De reden waarom de host interface in promisc draait, is omdat het verkeer dat niet direct aan hem is gericht moet ontvangen. Verkeer wordt vanaf een router naar een systeem gestuurd omdat er volgens de ARP tabel het doel MAC adres daar zou zijn. Een VM heeft immers een ander MAC adres dan de host, je gaat anders conflicten krijgen. Draait de interface niet in promisc mode, dan wordt verkeer dat voor de VM bedoelt is gewoon gedropt.

De Host vangt dus verkeer voor de VM en kan deze uitlezen. De VM echter kan niet het verkeer dat voor de Host is bedoelt, of voor een andere VM, zomaar uitlezen. De hypervisor zit daar namelijk nog tussen.

Bij containers werkt het iets anders, maar omdat ik ook daar geen ervaring mee heb, kan ik er geen oordeel over geven en uitleggen hoe het wel precies zit.

[MAX3400]

@Hero of Time Dank voor jouw toelichting/uitleg; dan zijn we er wel uit dat het lastig "lijkt" om de Anbox-container al voldoende veilig te bestempelen op dit moment. Waarschijnlijk wordt de soep niet zo heet gegeten als 'ie opgediend wordt, maar toch

@tweakmember misschien toch op zoek naar een andere Android emulator gebaseerd op bekendere / gedocumenteerde hypervisor? Dat scheelt dubbele troubleshooting (zowel van de hypervisor als alle dependencies) om je container werkend te krijgen.

[Hero of Time]

Ik heb zelf eens gekeken voor wat er nodig is om een Android app op je PC te laten draaien. Je hebt hiervoor eerst de Android SDK nodig, daarmee maak je een image oid waarmee je de apk kan starten. Standaard is het enorm traag en vreet het CPU. Door het via Qemu te draaien, kan de andere CPU architectuur veel efficiënter gemaakt worden waardoor je niet constant 100% CPU gebruik hebt.

Ik heb de tijd niet genomen om naar Anbox te kijken, maar ik vermoed dat het die stappen/combinatie voor je uitvoert zodat het makkelijker is om zo een app te draaien.