Community
Participate
Working Groups
Build Identifier: M20110909-1335 During installation of the OProfile plug-in, if the system doesn't have consolehelper-gtk installed, an alternative available of adding a line to the /etc/sudoers file, that gives a specific user the ability to run only opcontrol as root. From that point forward, that user now has the ability to exploit security flaws that may exist in opcontrol, possibly giving that user unfettered access to the system as root. Several security bugs have been found and fixed in opcontrol, but there may be more lurking, and future versions may open up new security holes. As a remediation, the least that should be done is to warn the person installing the plug-in of this situation, and ask them to verify that they are OK with this situation before proceeding. Reproducible: Always Steps to Reproduce: N/A
I was hoping to drop sudo entirely and rely on PolicyKit instead. OTTOMH I'm not sure about the status of that, though. Jeff/Roland, do you know the status?
According to conversations in the CQ, the license is under review. A decision should be made within the next few weeks.
Thanks for the update, Roland. I'd really like to see us use PolicyKit as the main (only?) privilege escalation method as it's mature, audited, and available in almost every modern distro we care about.
Using PolicyKit will present some challenges for a remote implementation of the plug-in. Over the longer term, there's a proposal for OProfile to switch to using the perf_events kernel interface, and if that code goes upstream, we will no longer need any authentication mechanism, because perf_events can be used as a normal user, at least for profiling their own program (not system-wide).
(In reply to comment #4) > Using PolicyKit will present some challenges for a remote implementation of the > plug-in. ISTR Jeff saying something about this working but I could be dreaming :) > Over the longer term, there's a proposal for OProfile to switch to using the > perf_events kernel interface, and if that code goes upstream, we will no longer > need any authentication mechanism, because perf_events can be used as a normal > user, at least for profiling their own program (not system-wide). That would rock!
We now use policykit instead of consolehelper for authentication when using the opcontrol command. (the consolehelper script will likely be removed). If our goal is to not rely on prefixing sudo in the Runtime, I see two options : 1) Use just the standard instance of the opcontrol binary I don't see why there needs to be multiple instances of opcontrol on the same system. I can understand other tools that have been built with a different toolchain, but opcontrol mainly interacts with the kernel and I don't really see the benefit. 2) End user would need to provide their own policykit .policy file along with a script that wraps the opcontrol binary around a pkexec call to safely use it wherever it may be located. This is exactly what we're doing for the standard installation "/usr/bin/opcontrol".
(In reply to comment #6) > We now use policykit instead of consolehelper for authentication when using the > opcontrol command. (the consolehelper script will likely be removed). > > If our goal is to not rely on prefixing sudo in the Runtime, I see two options > : > > 1) Use just the standard instance of the opcontrol binary > > I don't see why there needs to be multiple instances of opcontrol on the same > system. I can understand other tools that have been built with a different > toolchain, but opcontrol mainly interacts with the kernel and I don't really > see the benefit. > > 2) End user would need to provide their own policykit .policy file along with a > script that wraps the opcontrol binary around a pkexec call to safely use it > wherever it may be located. > > This is exactly what we're doing for the standard installation > "/usr/bin/opcontrol". Hi Roland, I don't know if you are aware of the new "operf" command which integrates perf_events into Oprofile, resulting in later running with no root privileges. Such as new command is still in a branch of Oprofile git but it is expected to be merged into master before Eclipse Juno release. More information here: http://comments.gmane.org/gmane.linux.oprofile/10155 That being said, IMO we must move to operf instead of opcontrol because it will get away all these installation procedures. Our team is willing to work hard on such as migration (or at least make operf and opcontrol coexist peacefully in the plug-in) to be included on Linux Tools 1.0.0. What do you say?
> Hi Roland, > > I don't know if you are aware of the new "operf" command which integrates > perf_events into Oprofile, resulting in later running with no root privileges. > Such as new command is still in a branch of Oprofile git but it is expected to > be merged into master before Eclipse Juno release. More information here: > http://comments.gmane.org/gmane.linux.oprofile/10155 > > That being said, IMO we must move to operf instead of opcontrol because it will > get away all these installation procedures. Our team is willing to work hard on > such as migration (or at least make operf and opcontrol coexist peacefully in > the plug-in) to be included on Linux Tools 1.0.0. > > What do you say? That's great news. With that being the case, we can look forward to eventually dropping the "sudo" execution, and I'm guessing even the policykit support. I'll test this out as well.
Keep in mind that userspace operation is possible only if you're not doing system-wide profiling (which operf is capable of).
I was a bit ahead of myself when mentioning the dropping of policykit/sudo. In reality it would still be needed for loading the oprofile module. I suppose we could have options for system-wide profiling, but currently, OProfile is meant to work on a particular binary.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
I haven't been involved with this project for some years, so if this bug is no longer relevant, please feel free to close it.
(In reply to Corey Ashford from comment #13) > I haven't been involved with this project for some years, so if this bug is > no longer relevant, please feel free to close it. Thanks Corey. The current OProfile plug-in supports OPerf and has long supported PolicyKit. I will close this bug as fixed.
Thanks Jeff!
