Auto Reboot security issue

vvf69107

Unlocking a secondary profile is sufficient to reset auto reboot time!

matchboxbananasynergy

Hey. Correct. That's intended. Unlocking any profile successfully. Imagine if you were using a secondary profile for a few hours only for the phone to reboot suddenly for no reason; wouldn't be great.

vvf69107

matchboxbananasynergy
what if a profile has no/ a weak password?

vvf69107

matchboxbananasynergy
combined with issues mentioned here GOS has barely any protection against shoulder surfing i guess...

vvf69107

matchboxbananasynergy

settings for this would be great. not every user can install apps so why should everyone be able to reset the counter?

Vogelhaus

What if the main profile has no/ a weak password? That is absolutely up to the user.

A 6 digit pin is enough with throtteling, and should not be a pain to enter

vvf69107

Vogelhaus what's the point of a seperated profile impacting the whole device security this much.

matchboxbananasynergy

vvf69107 There's https://grapheneos.org/features#pin-scrambling, though that depends on how someone is looking at you.

For shoulder surfing, using the fingerprint is likely the best way to go about it. If you're about to leave the phone unattended, you can either reboot it, or use lockdown mode to disable biometrics until the next unlock.

matchboxbananasynergy

vvf69107 A lot of people daily drive secondary user profiles, and the primary use case for multiple user profiles in AOSP is for distinct people to be able to use the phone. I don't think that GrapheneOS wants to kill that use case off.

With what you're proposing, you're essentially saying that if someone who doesn't have access to the owner profile is using the phone, they're on a constant timer.

I think it makes a lot more sense to properly secure your profiles with an adequate lock method, and if you can't trust other users on the device (in case of multiple people having profiles) to implement an adequate lock method, don't allow them to have profiles on your phone.

vvf69107

matchboxbananasynergy trusting others can't be an argument here. And i'm not saying every profile should be locked out but some should.
GrapheneOS allowing up to 16 profiles makes it even more important.

vvf69107

Please unsolve this thread..

Pin Scrambling is relatively useless in my opinion, because you can still see which numbers are pressed.

matchboxbananasynergy

vvf69107 Pin Scrambling is relatively useless in my opinion, because you can still see which numbers are pressed.

I think you misunderstand the feature. It's not meant to protect against someone looking at the screen. It's meant to protect by someone predicting your PIN by looking at where your fingers move to. Since the numbers are scrambled every time, it doesn't matter if they see your fingers move to the bottom left, as the number there might be 1 or 9 or 4 or 0.

matchboxbananasynergy

vvf69107 I'm not sure I understand the request here, so let me see if I can rephrase it to make sure we're on the same page.

What you're essentially suggesting would be to make it so unlocking some profiles wouldn't reset the auto reboot timer, and those profiles would be set by the user?

If you have a concrete design for how that could be implemented, please open an issue on GitHub. I think it is unlikely that it will be considered because features like these are best left as simple as possible, but the first step towards a change of that nature being considered is being able to provide a specific implementation idea of exactly how this would work, along with its pros and cons.

https://github.com/GrapheneOS/os-issue-tracker

As for the thread being solved, I solved it because your initial inquiry sounded like you misunderstood how auto reboot works and didn't expect secondary user profiles to reset the timer.

vvf69107

matchboxbananasynergy I understand the pin scrambling, but most people (and cameras especially) can see the big numbers.
sorry for calling it useless, but i think we'd also need the ability to disable pin Highlighting etc

vvf69107

matchboxbananasynergy i was actually surprised and very annoyed/ disappointed. i get your point, but would still consider this a vulnerability, because encryption related things are usually up to the main profile. i wouldn't expect from anyone that they secure all their up to 16 profiles as much as the main profile.

Chalko

vvf69107

User failure to properly secure a profile is not an OS vulnerability if the tools are provided to do it.

vvf69107

Chalko you should be able to have unsecured profiles without affecting the whole device.. also the user is not informed about this in the docs i think..