← Back to team overview

ubuntu-phone team mailing list archive

Re: Sharing dynamic informations between the user session and the greeter

 

On Wed, Mar 12, 2014 at 6:42 AM, Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael Terry wrote on 10/03/14 13:48:
> >
> > On Mon, Mar 10, 2014 at 7:51 AM, Matthew Paul Thomas ...
> >> Sorry, I was using "greeter" too loosely as a synonym for "login
> >> screen", i.e. the screen that lets you choose between multiple
> >> accounts.
> >>
> >> Ubuntu on a phone currently does not use a login screen, because
> >> there are never multiple user accounts to choose from. Instead,
> >> when starting the phone, you go directly to the lock screen
> >> (a.k.a. "welcome screen") for the only account.
> >
> > Eventually we want to allow users to have encrypted home
> > directories on the phone.  (Which is currently blocked by this
> > very same problem of not having a proper greeter.)  With encrypted
> > home directories, we have to have a login screen for the user must
> > enter a password/pin.
>
> I don't see how that follows. Most active phones spend much more time
> asleep than powered off. That's just as true when a phone is stolen
> than at any other time. Therefore any encryption, password, or PIN
> requirement will be ineffective unless it applies to the locked state
> just as it does to any login screen. And therefore, if the device is
> single-user, we could still take you directly to the lock (Welcome)
> screen on startup, skipping the login screen.
>

I agree that if you are encrypting your disk, the easiest hack around that
is to just steal the phone while you are logged in, since your data is only
encrypted while you are logged out.  We could "secure" you when you lock by
just logging you out and thus bringing you to the login screen.

But I don't see how (with the current encryption options we have), we can
merely lock the user session and still have your data encrypted.

And again, on the first boot, we can't log in as an encrypted user.  So the
login screen must support all these features anyway, unless we say "you
must first login to have full phone features".  Which could be a valid
thing to do.  But Design preferred not to do that last time we talked about
it.

A further note is that if we use a separate lock screen (i.e. run it as the
user), we open ourselves up to a whole new class of attacks, where an
attacker can crash the lock screen or get it to hide itself somehow.  A
login screen wouldn't grant access in such scenarios.


> ...
> >
> > Lockscreens are problematic from a security perspective, due to
> > technical details.  Running the PAM stack as a user (i.e. being a
> > PAM "server") has never worked quite like we want.  In order to
> > work when run as a user, PAM modules (like fingerprint, ldap, or
> > pin) have to run separate daemons as root to talk to, which
> > doesn't usually thrill the security team.  And the pin module
> > we're planning to use for the phone doesn't work in a user context
> > (i.e. it doesn't use a root daemon; could add one, but 4-digit pins
> > would probably be pretty easy for a user to brute-force
> > programmatically then).
> >
> > ...
>
> Those seem like problems you have to overcome anyway, so that people can
> change their PIN or password in System Settings.
> <https://wiki.ubuntu.com/SecurityAndPrivacySettings#phone-locking>


Actually, to change your PIN you only need your password (which is actually
a separate field from your PIN).  Now to be fair, on the phone, I imagine
we'll just say password=PIN.  (Though the phone is still slightly protected
from brute-force attacks since apparmor/click lock it down more.)

-mt

References