Re: PSA: don't make your polkit policies desktop centric

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 05.05.2014 14:44, Nikos Mavrogiannopoulos wrote:
> On Mon, 2014-05-05 at 14:21 +0200, Stef Walter wrote:
> 
>>>> The <allow_any>no</allow_any> prevents use of the service from remote
>>>> sessions such as ssh or Cockpit.
>>>>
>>>> The poorly named <allow_any> tag controls the default policy for users
>>>> logged in from any non-monitor+keyboard session. That is, sessions that
>>>> don't come from a 'seat'.
>>>>
>>>> So unless your service is changing seat specific hardware, you probably
>>>> want an <allow_any> tag that is similar or identical to <allow_active>.
>>>
>>> Erm, IMHO it should be the same as <allow_inactive>, if something is
>>> not allowed to be done from an inactive state (ie from a switched away session
>>> with fast user switching) it certainly should also not be allowed to be
>>> done over ssh.
>>
>> Technically you are correct. The best kind of correct.
>> In reality it depends on the service. Some services may want to prevent
>> use when inactive (ie: locked screen) simply for UI reasons, not security.
> 
> This is not always the case though, as I have a package with a policy
> that I intentionally discriminate ssh from active sessions. Maybe it is
> better to decide that on a per-package case, and may be better to fill
> bugs to the specific packages that you think it doesn't make sense to
> have such discrimination. A longer-term solution may be to better
> explain the situation in the polkit documentation (if it isn't already -
> I didn't check).
> 
> Otherwise with a blanket statement like the above we risk introducing
> security by-passes where we shouldn't.

Security is never a case of "always the case". So yes, if your package
has special needs then by all means express that in the policy you
distribute.

Yes, polkit default policy is distributed per package, and customizable
via rules from the sysadmin etc.

Cheers,

Stef
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux