Assigning to atwilson@ for triage.

Alex: is there an actual customer request behind this? Would be great to flesh out the use cases a bit more.

Marcus, assigning to you to figure out what (if anything) we want to do here. I could think of a bunch of different things we could do:

1) Just blanket prevent all deletions of device-wide certs from the cert manager.
2) Add a policy to prevent deletions of device-wide certs from the cert manager.
3) Add a policy to control what users can do in the cert manager in general (prevent using the cert manager entirely, block cert import, block cert deletion, etc).
4) Some more extensive controls on certs (for example: we could bind a cert to the user and/or extension that created it, and only let that user + extension modify/remove it).

These all have implications for people trying to do troubleshooting (for example, might be nice to be able to remove a device wide cert and re-provision it in case your cert is expired for some reason, but that would be prevented if we just prevented users from deleting device certs).

Pavol and I can provide context/input from the eng side as needed.

Yes, we have at least two customers asking for this feature for different reasons.

The first is a customer wants to prevent users from making any changes in public session mode. They have device certs pushed to the device and do not want a random logged in user to be able to access the cert manager and delete certificates

The second customer wants to prevent signed in users from deleting any device certificates. The concern is focused on preventing accidental deletion of device wide certs. They still want to users to be able to see device certs to troubleshoot issues (we recommended blacklisting the cert manager url to prevent any access and this FR came from it to block just deletion).

BTW, not really possible to blacklist the cert manager URL since it's not a real URL (it's a polymer page).

Plan is to create a new policy (AllowCertificateDeletion) and have the server set this policy by default for public sessions.

Marcus, your call whether this is worth putting together a one-pager for - probably not, since it's pretty straightforward. I'm making myself the owner and will give to one of our nooglers next quarter to tackle.

Good bug for a noogler to tackle

Merge with 877424. Therefore this bug includes three tasks:

(1) Adapt UI so tht the user cannot change Wifi settings that are managed by policy (see 877424)
(2) Implement AllowCertificateDeletion policy so that user cannot delete (user and device) certificates, if he is not allowed to do so.
(3) Trigger implementation of AllowCertificateDeletion policy into CPanel.

Copy-pasting from e-mail discussion to keep the discussion here.

Note: This is only about the certificates part.

---
Summary:
I think the bool "disallow deleting device-wide certs bool policy" is easy to implement, clear, and achieves the goal we need (it makes sure that one user / one PS user can not mess up the device state).

The "disallow deleting enterprise certs bool policy" comes from a different angle, and would additionally not allow users to mess up their own profile, at the cost of a higher implementation complexity (checking the metadata with [1]).

The "enum deciding which certs may be deleted" option combines both (with a slightly increased implementation complexity again).

Personally, I don't think a "disallow deleting all certs" policy is a good idea, because the user can manually import client certs if they want to (see "Detail" section below), and they should be able to delete them again.

TBH, I'd go with the first option for now, as I don't think protecting people from messing up their own profile is a goal that justifies a more complex implementation. But please also talk to Drew about this :-)

---
Detail:

As you said (in the e-mail), we could create a bool policy to disallow manually deleting device-wide certificates (those on the "system" token). If some users should be able to do it (e.g. the admin), it should be a user policy. I *think* we usually preset user policies for public sessions (they are called "device-local account policy" in that case) on the server side.

As you also say (in the e-mail, and in Comment #9), another approach would be to have a more generic enum or bool policy. If we decide to go this way, it helps to think about how client certificates can end up on the device:
(1) Imported by a policy-installed extension through the enterprise.platformKeys API, into the chaps-provided"system" token. These are device-wide. Currently, any affiliated user (public sessions also count as affiliated) may delete these. IMO, It definitely makes sense to disallow deleting these, because deleting these potentially harms the whole device (e.g. loses network connectivity).

(2) Imported by a policy-installed extension through the enterprise.platformKeys API, into the chaps-provided "user" token. These are per profile. IMO, It could make sense to disallow deleting these - however, I'm not clear on how useful that would be. The user can only harm themselves, so this preventing this would be protecting them from browsing the certificate manager and deleting random stuff.

(3) Imported manually through chrome://settings/certificates using the "Import and Bind" button. These are per profile and also end up on the chaps-proivded "user token".
IMO, we should keep it allowed to delete these - the user has manually imported them after all.

(4) Imported manually through chrome://settings/certificates using the "Import" button (without "and Bind"). These are per profile and end up in the user's software NSS database (a SQLite db in the user home).
IMO, we should keep it allowed to delete these - the user has manually imported them.

If we think about it this way, we could either use a bool policy e.g. "AllowDeletingEnterpriseCertificates", which when set to false, would diallow deleting certs of kind (1) and (2).
Or we could have an enum policy as you say, and probably have something like
DISALLOW_DELETE_ENTERPRISE_CERTS
ALLOW_DELETE_ENTERPRISE_USER_CERTS -> (2) may be deleted
ALLOW_DELETE_ENTERPRISE_CERTS -> (1) and (2) may be deleted.

If we decide to do this, in code, we can distinguish between "enterprise" and "user-imported" certs using metadata stored by the KeyPermissions class. Probably we'll have to make the "IsCorporateKey"[1] function accessible from outside.

[1] https://cs.chromium.org/chromium/src/chrome/browser/chromeos/platform_keys/key_permissions.h?l=214&gs=kythe%253A%252F%252Fchromium%253Flang%253Dc%25252B%25252B%253Fpath%253Dsrc%252Fchrome%252Fbrowser%252Fchromeos%252Fplatform_keys%252Fkey_permissions.h%253Froot%253Dchromium-chromeos%2523ZomvErPGQMsvv%25252F1Xv0DkYJ9ojmOOgP3oN8uLZpxkwVc%25253D&gsn=IsCorporateKey&ct=xref_usages

BTW, re Comment #9: What's the scope of this crbug currently? The title only says "Prevent deletion of device certificate from certificate mangager", but that comment says this is also about preventing some editing in the UI (?)

pmarko@ Thanks for the detailed feedback!

The UI stuff is completely different from this bug and handled in ( crbug.com/877424 ), but both are designated as possible noogler tasks for Nikita.
I don't know yet, if he will tackle both of them before focusing on printing tasks.
ultrotter@: What's your opinion on this? I could also tackle either of them, but I'm also happy to assist.

Alex can probably help with this.

Current status:
- ui has no access to whether a certificate is from the user or from the policy
- need to pass this information so that a decision can be made on whether the user can delete it

IIRC this was about device-wide certificates (certificates stored in the "system" token).
Currently all such certificates can only be installed through an extension which has been force-installed by policy, if the user is affiliated.

Did you mean to say that the UI has no access to whether a certificate is a user-specific or a device-wide certificate?

I got slightly confused :)

Apologies for coming late to this, but I have a couple of questions based on a CL I was asked to review, which does not appear to distinguish between policy installed certificates and user installed certificates (https://chromium-review.googlesource.com/c/chromium/src/+/1404078).

1. Does it ever make sense to allow a user to delete a policy installed certificate?

2. Does it make sense to disallow users to remove a certificate they installed? Allowing a user to install a certificate but not remove it seems like bad UI.

Thanks for your feedback Steven.

1. a) Policy-installed CA certificates currently can't be removed (they come from a different CertsSource in CertificateManagerModel which does not even implement removal[1]).
1. b) Policy-installed Client certificates are currently not officially supported, but they "work" by being imported into the user's "user" slot.
If a user deletes such a certificate (which is possible today), it will simply be re-imported on the next session start. But, because policy-provided client certificates are not officially supported, I wouldn't mind changes in behavior here (such as simply not allowing deletion) if it happens as a side-effect.

2. Yeah, the UX is werid, which is why I was also arguing against this previously.
What might make sense is disallowing deleting certificates which were imported using the chrome.enterprise.platformKeys API, but this is harder to implement.
So simply "disallow deleting certs", or even "disallow managing certs" might be easier, and good enough for admins who just want to offload cert management completely to an extension.


[1] https://cs.chromium.org/chromium/src/chrome/browser/certificate_manager_model.cc?type=cs&q=certssource&sq=package:chromium&g=0&l=330

One alternative I could imagine that would maybe make people more comfortable while still allowing for a "don't mess with user certs" mode would be an enum policy

ManualClientCertificateManagementAvailability
0: Allow Manual Client Certificate Management
1: Allow Manual User-specific Client Certificate Management only (only for the "user" token or the public slot, not for the "system" token)
2: Disallow Manual Client Certificate Management

This would make it explicit that this policy is only about client certificates, and Value 1 would disallow import and/or deleting client certificates.

Hi everyone, I was one of the requestors of this feature on behalf of my client (a global enterprise)...

I mostly agree with the #10 comment which sums it all up nicely. Policy disallowing deleting device-wide certs would perfectly fit our current needs. We don't mind users "messing" with their own certs.

One more note: If the policy will be a on a user/public session level, we need to prevent non-managed accounts (@gmail.com etc.) from deleting system token certs as well. Otherwise we'd have to disable signing from non-corporate domains, effectively preventing the corporate-owned personally-enabled (COPE) device model.

Happy to further clarify anything if necessary

I would be much more comfortable with restricting certificate management entirely, i.e. the alternative suggested in comment #22. I can pretty much guarantee that if we provide a UI that allows adding certs but not deleting them, a bug about that will get created :)

Otherwise I think we should do the extra work to only apply the restriction to certs imported by chrome.enterprise.platformKeys.