Bugzilla – Bug 744251
AUDIT-0: spice-gtk setuid binary
Last modified: 2019-02-14 17:21:38 UTC
spice-gtk, which is a dependency to gnome-boxes, installs polkit files and one suid bit helper. Currently the package resides in home:dimstar:gnome-boxes/spice-gtk and is submitted to Virtualization/spice-gtk (SR#102156). Please review and add exception so the rpmlintrc file can be dropped again.
what's the purpose of the setuid binary? please package without setuid bit until audited. What polkit privileges are used and for what purpose?
The binary getting suid is called spice-client-glib-usb-acl-helper, apparently a bridge between glib and polkit. The polkit 'warning' is spice-gtk.x86_64: I: polkit-untracked-privilege org.spice-space.lowlevelusbaccess (??:no:auth_admin_keep) The privilege is not listed in /etc/polkit-default-privs.* which makes it harder for admins to find. If the package is intended for inclusion in any SUSE product please open a bug report to request review of the package by the security team spice-gtk.x86_64: I: polkit-cant-acquire-privilege org.spice-space.lowlevelusbaccess (??:no:auth_admin_keep) Usability can be improved by allowing users to acquire privileges via authentication. Use e.g. 'auth_admin' instead of 'no' and make sure to define 'allow_any'. This is an issue only if the privilege is not listed in /etc /polkit-default-privs.* ==> <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE policyconfig PUBLIC "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN" "http://www.freedesktop.org/standards/PolicyKit/1.0/policyconfig.dtd"> <policyconfig> <vendor>The Spice Project</vendor> <vendor_url>http://spice-space.org/</vendor_url> <icon_name>spice</icon_name> <action id="org.spice-space.lowlevelusbaccess"> <description>Low level USB device access</description> <message>Privileges are required for low level USB device access (for usb device pass through).</message> <defaults> <allow_inactive>no</allow_inactive> <allow_active>auth_admin_keep</allow_active> </defaults> </action> </policyconfig> ====> Needed for the pass through of USB Devices to the virtual machines that are to be managed.
let me guess... the setuid binary opens raw usb devices on behalf of the user, using polkit for authorization? Used to be the job of resmgr. A setuid binary for that isn't nice.
This is an autogenerated message for OBS integration: This bug (744251) was mentioned in https://build.opensuse.org/request/show/181541 Factory / spice-gtk
*** Bug 995795 has been marked as a duplicate of this bug. ***
Ping? Is everyone supposed to add the suid bit every time the package is updated?
(In reply to Jiri Slaby from comment #14) > Is everyone supposed to add the suid bit every time the package is updated? Security team has not approved a setuid root for this binary.
(In reply to Andreas Stieger from comment #15) > (In reply to Jiri Slaby from comment #14) > > Is everyone supposed to add the suid bit every time the package is updated? > > Security team has not approved a setuid root for this binary. Yes, indeed, so because somebody has not approved that, is everyone supposed to add the suid bit every time the package is updated?
I think you are reversing causality here. The setuid bit is not approved because we consider the implementation insecure. In the absence of a secure implementation, the functionality should not be used. Please let us know if you have substantial changes to look at.
@security-team: moving to tumbleweed. Still feel free to close if it does not pass the audit.
*** Bug 1055977 has been marked as a duplicate of this bug. ***
accidently re-opened without comment?
*** Bug 1063165 has been marked as a duplicate of this bug. ***
*** Bug 1016292 has been marked as a duplicate of this bug. ***
*** Bug 1072029 has been marked as a duplicate of this bug. ***
*** Bug 1077351 has been marked as a duplicate of this bug. ***
I understand the security problems by set s bit. but 6 years with a lot of people have this problem why not go another way if this bit will not be set because of security? could we not generate a new group for this file. "usb-spice-redirection" so people who need this could add this to user who need this functionality. other users would still not have access. this would be a compromise for security AND gave the high advantage not every update (tumbleweed) set by hand the accessrights. why is this bug marked as resolved fixed? i reopen it, because for me this problem still exists.
(In reply to simon becherer from comment #25) > could we not generate a new group for this file. > "usb-spice-redirection" > so people who need this could add this to user who > need this functionality. other users would still not > have access. That is a usual work-around. Please present a package proposal that does that. > this would be a compromise for security AND gave the > high advantage not every update (tumbleweed) set by > hand the accessrights. Are you are not aware of /etc/permissions.local? > why is this bug marked as resolved fixed? Because the request was to have it setuid root, which was not approved. The audit is completed, so it's a WONTFIX really. > i reopen it, because for me this problem still exists. It is a bug tracker to organize the developer work, not a helpdesk ticket tracker. The only new information presented is the proposal for a separate group, no new code shown for an audit.
Hey Simon, > could we not generate a new group for this file. > "usb-spice-redirection" > so people who need this could add this to user who > need this functionality. other users would still not > have access. a somewhat shorter group name would probably be better. We do have the "trusted" group predefined that allows execution of things like crontab setuid root. This one could be reused. But a new one is also fine. > this would be a compromise for security AND gave the > high advantage not every update (tumbleweed) set by > hand the accessrights. This specific bug here was for reviewing the spice-gtk package and deciding whether we can add the setuid bit. It was decided that we don't want that in a general form. If you want to introduce the separate group then the first step would be to open a separate bug for the spice-gtk package maintainers describing your request. Alternatively you can invest time yourself and adjust the package accordingly, submitting it to the spice-gtk devel project. Once the new group is in place and working as desired you can reopen this AUDIT bug, or create a new AUDIT bug for spice-gtk. Then we from security can inspect it again and finally whitelist it.
I reviewed this setuid helper in a follow-up review in bug 1083025. It is basically okay, but a bit strange in its design. We can whitelist it as soon as there is a separate group setup for it. I am therefore closing this AUDIT bug and will split off a separate bug for tracking the group issue.
that split bug is bug 1101420.