|
Bugzilla – Full Text Bug Listing |
| Summary: | AUDIT-0: fprintd 0.4.1 (finger print dbus service) | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Dominique Leuenberger <dimstar> |
| Component: | Security | Assignee: | Marcus Meissner <meissner> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | krahmer, meissner, security-team |
| Version: | 13.1 Milestone 1 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | described fix | ||
|
Description
Dominique Leuenberger
2012-11-30 08:38:12 UTC
putting it in the queue how important is this for current gnome submits? (In reply to comment #1) > how important is this for current gnome submits? Not that important in general... the 'issue' popped up as part of bug 772948 where we identified that the gdm pam config uses the new name (pam_fprintd) and we ship the old pam_fprint. So, none of the current gnome packages is blocked by it. The 'wish' is to have it properly integrated in Factory, which will require some more changes in yast_fingerprint and possibly some other places (I'm working on identifying them). There's a conceptual bug inside pam_fprintd which allows anyone to bypass pam_fprintd, using DBUS signals: http://stealth.openwall.net/xSports/darklena.c Depends on bnc#804392 Would it make sense to have net.reactivated.fprint.device.verify as auth_admin? It should only be called from pam module and similar privileged code anyways? needinfo As a start I think this makes sense... once we run across a usecase where the 'verify' privilege is really required by a user, we can re-visit this. (I am not entirely sure if enrollment would not want to make use of this as well..) ok, then lets try it this way; I think Marcus was keeping track of the polkit rules? yes did you look at the DBUS services inside? are they OK too? Yes, the seem OK. However I attached a fix to be on the safe side, in case some services allow to pass weird usernames through PAM. Please include. Created attachment 542285 [details]
described fix
.
one more ... net.reactivated.fprint.device.verify no:no:auth_admin_keep net.reactivated.fprint.device.enroll no:no:yes net.reactivated.fprint.device.setusername no:no:auth_admin_keep enroll to "yes" for logged in and actiev desktop user? enrolling is probably also specifically for root? lets try out this set: net.reactivated.fprint.device.verify no:no:auth_admin net.reactivated.fprint.device.enroll no:no:auth_admin net.reactivated.fprint.device.setusername no:no:auth_admin and verify it covers the usecases. see comment#7, I'd like to have this auth_admin. But in any case, enrolling should ensure that user can only enroll for their own username. the device-claim ensures that normal users cannot override their username, so thats ok. However, enrolling must not be called from a PAM or other privileged context (which is not the case yet) This is an autogenerated message for OBS integration: This bug (792095) was mentioned in https://build.opensuse.org/request/show/177394 Factory / polkit-default-privs is in factory, so you can go ahead with fprintd submission if neeeded still finally done bug 850807 shows that it now queries the root password everytime. I think we need to go to no:no:yes :( should be solved now, permissions are changed |