Adam Williamson wrote:
> I think it's sensible, yeah. It's not really much bureaucracy; I don't
> think it would ever be a good idea to introduce a new privilege
> escalation mechanism without FESco knowing about it...
Right now we're in a phase where a lot of stuff (system-config-*, several
parts of KDE and some other stuff) is getting ported from running the whole
app under consolehelper or kdesu to PolicyKit mechanisms. This is generally
seen as a *good* thing. It'd be really annoying to have to go through a
FESCo vote for every single one of those.
At the very least, I'd suggest adding the following clause to that
paragraph:
"Any mechanism which requires administrative authentication to perform the
privileged action (e.g. auth_admin policy in PolicyKit, kdesu etc.) is NOT a
privilege escalation mechanism for the purposes of this paragraph."
Rationale: Such a policy does not impact the system's security as you have
to enter the root password before doing anything dangerous, so none of the
invariants under "Requirements" can be violated. And additionally, you can
always as a user run the whole app under e.g. kdesu and thus "escalate your
privileges" using the root password, so it doesn't make sense to police apps
providing such a mechanism. What really matters for security is what you can
do WITHOUT the root password. This is not really clear from the policy as
written now, adding the suggested sentence would clarify it.
(That said, I don't see even the clarified policy as being necessary. We
have a set of guidelines, maintainers should follow them, why do we have to
police them? As I explained before, there is no evidence that this is
necessary or useful. The PackageKit issue was caused by lack of a policy,
not lack of enforcement.)
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
