[system settings] allows to change lock security without asking for passcode

[Olga Kemmet]

Steps to reproduce:

1. Go to system settings
2. Set up a passcode (currently marked as 4-digit PIN code)
3. Tap on SET
4. Now tap immediately on "Swipe (no security)"

5. Actual result: the setting switches to "Swipe (no security)" without asking for the just set up passcode

Expected result:
Every time user sets up a passcode/passphrase and wants to switch between the different lock security options, he has to confirm the last set passcode/passphrase (except for SWIPE).

<https://wiki.ubuntu.com/SecurityAndPrivacySettings#phone-locking>: "All “Unlock the phone using:” options, except the current one, should end with an ellipsis, because switching between any two will involve further input in the form of a dialog: “Switch to Swipe”, “Switch to Passcode”, or “Switch to Passphrase” as appropriate."

Bug #1413681 may be a duplicate of this bug.

[Pat McGowan (pat-mcgowan)]

Actually as long as the app is open the user is not prompted to change the security mode

[Michael Terry (mterry)]

That's expected behavior. Policykit is caching the authentication for us for a few minutes (I forget how many). The caching is only in practice effective for swipe mode because the other modes still need the old password to switch to the new password (that part doesn't go through policykit).

We *could* stop it from caching by modifying the policykit config. But by default (and on the desktop) it caches the authentication for the 'SetPasswordMode' method on AccountsService.

[Matthew Paul Thomas (mpt)]

Caching credentials is useful where you are repeatedly doing something that requires authentication, for example installing a lot of apps. But that's not the case here: you might switch lock security once, and then change your mind, but that's about it. Combined with the inconsistency of swipe vs. anything else, I think caching here is more surprising than useful.

[Michael Terry (mterry)]

I'm going to demote to at least High, although I personally consider it Medium. The Critical assessment was made when it was thought that this was a security problem. If you really really think this is Critical, please re-mark it as such.

[Matthew Paul Thomas (mpt)]

I agree, it's a bit confusing but hardly Critical. I actually think it's Low.

[Noemí (noemi-gallego)]

I don't think this is a low issue, because someone can take your phone while it is unblock, change from 4-digit code or passphrase without being asked for the previous code, and then establish a new code which you won't know.
I think you would increase the priority of these bug.

[Pat McGowan (pat-mcgowan)]

Wile the caching in this case is unexpected changing the behavior would require a patch to polkit as it hard codes the expiration time to 5 mins.

Note that in order for this to be an issue the following must occur:

- device owner sets a new passcode
 - if the screen timeout causes a suspend (defaults to 2 mins) a code must be entered in the login screen
 - if the owner presses the power button then a code must be entered in the login screen
 - if the polkit timeout expires (5 mins) a code must be entered in settings

So the second user would need to get possession of the phone within 2-5 mins after the owner changed the code, and immediately set security to swipe, then set security to a new code. Trying to set a new code directly will also prompt for the old code.

[Pat McGowan (pat-mcgowan)]

Th settings panel performs a trySetSecurity which if it succeeds (there is no prior code or passphrase or its cached) then the action proceeds without a prompt for the previous code. If we can distinguish between having no code and having it cached we could fix this in settings.

[Noemí (noemi-gallego)]

I flashed the device today to the last version. First time you change from 4-digit code to swipe it asks you for your previous code but in you repeat this action it doesn't.
I think this is something that should be fixed please.

[John McAleely (john.mcaleely)]

I can see that 'low' might not be quite right, given that a user who observes this bug might worry about the phone's security in other areas.

However, I don't think it is more than 'medium', given the preconditions pmcgowan notes in #7. I think we should consider this for fixing in some future version of Ubuntu.

[Michael Terry (mterry)]

So here are the options I can imagine off the top of my head (spoiler alert, #4 is my vote):

1) Always ask for a code, if AccountsService doesn't ask us to authenticate, just don't use the given code. This is bad because if the user entered the wrong code, things will still work. And the user will be left wondering if we do any security at all.

2) We could always authenticate directly via policykit on our side before asking AccountsService to change the password type. This would be a duplication of authentication effort and code on our end. So not ideal.

3) We could ship an override for AccountsService/policykit so that it won't keep authentication tokens around for these actions. That's a big system-wide hammer for this local problem, so I'd prefer not to muck with such configuration.

4) We could ask policykit to revoke our authentication after completing any interaction with AccountsService. I've never used that API before, but I *think* that would be the same thing as #3 but just for us. This is my vote, assuming it works like I think it does.

[Noemí (noemi-gallego)]

Hi,
I've checked that after killing security task, the code is asked again, which is much better.
Although today I have this other problem when entering the code (Find video attached). When I tried to enter the numbers, they were deleted instantly.
I also got the system logs so you can see what was happening.
I found something weird on them. Because the mobile when off at 4 in the morning, but when turning it on at 9.20, the time registered was 13.20. That was the time bug happened.
Then I rebooted the device again and the time was correctly written on system logs.
I attached this file too.
Regards

Video: https://mega.co.nz/#!tsVEEbZY!8mqwONpkm36q8rrxSxsImxzH3KpRgOeH9dGVCwTPJi8

[Jonas G. Drange (jonas-drange)]

@noemi-gallego, thanks for the video. Could you attach the file
/home/phablet/.cache/upstart/application-legacy-ubuntu-system-settings-.log
as well? Thanks

[Noemí (noemi-gallego)]

@Jonas- Of course. Find it attached.

[John McAleely (john.mcaleely)]

Folks, I've moved the different looking bug in comment #12 to the new bug #1413681. Can we stay on the issue of timeouts on this bug please.

[John McAleely (john.mcaleely)]

@mterry, are you set up to prepare a fix?

and can someone raise the prio of this at least to medium, and milestone triage it.

[Michael Terry (mterry)]

@John, I'm working on it, yes. It's a little more involved than I hoped. (i.e. larger than a few lines)

[Noemí (noemi-gallego)]

@John- Thank you for the new bug

[Pat McGowan (pat-mcgowan)]

bump to allow landing

[Matthew Paul Thomas (mpt)]

Verified fixed in Ubuntu 15.04 r248.