Sandboxed app storage and encryption at rest

natoal

Do apps in PixelOS and GOS have sandboxed storage access? And if so does that mean that no other programs except admins may access the contents of their directories? I understand that currently even in GOS, Private Space is not encrypted at rest after first unlock

I was wondering how difficult it would be to program a barebones notes app that was both sandboxed and encrypted at rest. Iirc Standard Notes had that feature, but it is riddled with bugs. That would mean less reliance on buying a specific phone with a specific OS/skin and their own variations of 'Private Space' that certain manufacturers have either removed or added at their own whims

ryrona

natoal Do apps in PixelOS and GOS have sandboxed storage access? And if so does that mean that no other programs except admins may access the contents of their directories?

Only the app itself can access its app data. No other app can, nor you as a user. If an app opt-in to backup support, the built-in backup app can access the data, but otherwise no other app can.

Apps can store files so they are accessible to other apps, if they want. If they do, the files will show up in the Files app. You still need to grant that other app access to that specific file though.

natoal I understand that currently even in GOS, Private Space is not encrypted at rest after first unlock

True, the encryption key for the private space will remain loaded in memory after the private space has been unlocked, until you reboot your phone.

This does not mean apps outside of the private space can access data or files from within the private space, they cannot. Unless you as the user specifically choose to share the file into or out of the private space using the system file picker or share functionality.

natoal I was wondering how difficult it would be to program a barebones notes app that was both sandboxed and encrypted at rest.

All apps are sandboxed. All app data is encrypted with the encryption key for the current user profile, but this is to prevent someone with physical access to your phone and advanced forensics tools to access the data, not to prevent other apps from access it, other apps cannot access it. If you need encryption for this app specifically, you can put the app in its own user profile, and reboot the phone once you have finished using the app.

natoal

ryrona

So the sandboxing of apps is only to prevent malicious apps from peeking where they aren't supposed to and a forensic with physical access to an AFU phone can still read that data anyway? And I suppose Private Space in its current state in AFU mode is useless in preventing that form of attack too?

ryrona

natoal So the sandboxing of apps is only to prevent malicious apps from peeking where they aren't supposed to

True. Malicious or compromised apps.

natoal and a forensic with physical access to an AFU phone can still read that data anyway?

Most likely, yes. There are other protections in place, but they often can bypass those using kernel exploits of similar. And the encryption key is loaded, so can theoretically be read out using the right equipment, even in the absence of usable exploits.

natoal And I suppose Private Space in its current state in AFU mode is useless in preventing that form of attack too?

Files and data in any unlocked profile should be considered to be accessible to a forensic with physical access to the device, yes.

That is why GrapheneOS implements a security feature that reboots your phone if screen is not successfully unlocked within a certain number of hours, in order to hopefully unload encryption keys and clear all RAM memory before the phone has been taken to a forensic with the right knowledge and equipment.

natoal I was reading this part of StandardNotes' explanation of its "encryption at rest" feature and it seems to be reliable and not security theatre

Individual apps can of course choose to encrypt their data one additional time, with an encryption key they can unload even if the user profile is still running. Nothing prevents that. It is just, for most use cases and threat models, this is not needed. Putting all apps with sensitive data in the private space or a secondary user profile, and reboot the phone once done with them, is enough for even most high threat scenarios.

natoal

I was reading this part of StandardNotes' explanation of its "encryption at rest" feature and it seems to be reliable and not security theatre (though the prevalence of bugs makes me doubtful). Then it occurred to me that it might not be so difficult to create a similar but minimalist app if a library for the encryption process existed. For example with web design you have bootstrap templates, with Android you have UI libraries (from what I've heard) and even ROM editors (games) use tools other developers have built. Sorry if this sounds like gibberish, I don't have much experience of any language beside HTML and that's not even a true coding language. So, I was thinking if it was almost as simple as copy pasting certain parts and just proof reading it while referring to documentation... does it sound awfully idealistic and simple?

A passcode is a device-specific secret you can configure that increases the level of protection on your local device. When you add a passcode, a set of keys are generated using the same procedures used to generate your account keys from your account password. Your passcode keys are never saved to disk, either in encrypted or unencrypted form, and are generated each time you start the application, and reside in memory until you lock or quit the application.

When you lock or quit the application, all working memory is deleted. When the application is re-opened, it will need to generate your passcode keys in order to decrypt and display your data. To generate your passcode keys, the application will prompt you for your passcode. Without your passcode entered on launch, it is not possible for the application to generate your passcode keys, and thus not possible for it to decrypt your account keys (if applicable) or notes data.

natoal

ryrona

Hang on, how do scanners like Malwarebytes assess the threat of unknown apps if they are sandboxed? Couldn't apps write malware onto their allocated directory? I know the type of sandboxing is different at least because Malwarebytes doesn't work in iOS

Edit: Oh yeah, perhaps the All Files Access permission allows them to circumvent this

Fupira

natoal Scanners like Malwarebytes cannot access the app internal data, so if an app writes remotely loaded, malicious code into its internal space and executes it, Malwarebytes can't detect that.
That is one of the reasons why anti-malware software isn't generally recommended for Android devices.
They can merely detect certain apps and possibly analyze their APK. Beyond that, they have no access to other apps and especially not their internal data.

"Access All Files" allows them to read everything in your phones "Shared" space, the space you can view with the Files app - excluding the Android folder's sub-folders of other apps.

natoal

Fupira

I found a link that sheds some light on app-specific storage, but couldn't find any comprehensive explanation on the mechanisms with which Malwarebytes 'scans' Android devices. I hope it's alright to ask for a source as I'm way out of my depth and you seem more knowledgeable than me?

It appears that some may have been lulled into a false sense of security with the Malwarebytes app on their phones... Its reputation as an unmatched scanner might lead one to the assumption that all malicious apps will be detected. This means that programs of dubious repute such as Lucky Patcher are not safe to install even if Malwarebytes deems them safe