I would feel more secure if there were two passwords for the Librem 5’s unlock screen: one for an untrusted/restricted environment for use in public; one for a trusted environment in private. Instead, in place of that since such an implementation does not exist, I currently manage my identities, devices, and passwords using physical isolation: I bring out my Librem 5 in public; I keep my Librem 14 in my bedroom/bathroom.
The only time I ever bring out my Librem 14 in public is when I also bring my PureOS live image on a USB drive, in which I boot from that instead of Qubes OS. This practice also reinforces that PureOS is only for public use.
I’m sure he’s speaking about the user password. The phone usually stays on and you often have to type in the user password and rarely the LUKS one.
And I agree that there should be a solution that addresses this threat. I want to be able to use my user password in front of other people without danger that they can change something on sudo level with same password.
I primarily meant the latter, but the former is also possible by two installations of PureOS within the same drive, provided that the boot manager (assuming GRUB) also supports touch screen input.
The realistic solution I am thinking about would be to have two user accounts on the Librem 5: one of them could be a “guest” account; the other one is the administrative/root account. I have yet to read any documentation or mentions of this anywhere.
The idealistic solution is that the unlock screen accepts two passwords and automatically logs in to the associated account depending on the inputted password.
On the Librem 5, you can have as many user accounts as you want - and I think you can even re-instate the standard Linux login window (choose user to log in as).
AIUI, the GUI on the Librem 5 for creating extra user accounts isn’t there yet (not adaptive), so you need to create the user account from the shell (and that does work fine) or maybe use a dock.
The problem is …
the screen unlock is not necessarily logging in. If it is logging in, yes, you can probably get that approximate behaviour but if it is just unlocking (which seems to me the more likely “public” scenario) then it would be more complicated. You would kind of be saying that if you “log in” to the user that is not currently logged in then it should log out the current session and log in again, whereas if you “log in” to the user that is currently logged in then it should just unlock.
Of course, if you reinstate the standard login window, you can also choose from the various options, such as: after one user’s session locks, you can log in as a different user and come back to the original locked session later. That would be a more manual process but approximately meets your security requirement.
A complication with all this is that if, while the phone is in operation, you make and receive calls and you make and receive texts then they may end up filed under whatever user is logged in at the time, which means that you don’t have a very coherent record comprising call logs and text conversations.
Likewise, your contacts would be all over the place - but I guess that is fixable if you instead go for a distributed contact store (cloud or LDAP or something like that - even if hosted on the phone itself).
The solution would be at the login window that you referenced. Instead of listing various users, it would only show the on-screen keyboard. This design would hide the amount of users and groups, but it also makes a very important assumption: each password is as unique as each user.
The shared modem problem cannot exist with how I currently operate: in public, only the cellular hardware kill switch is inactive; in private, only the Wi-Fi hardware kill switch is inactive.
Things like calls and SMS are handled by another hidden user that’s always active as far as I know. So it’s no issue at all to receive them. Things just need to be written somewhere where the different users have access. In additional I would give users the right to read it or not, depending on what the phone owner wants (similar to the option to read notification on lockscreen or just the title without content).