There is one issue I have with this. While this is close to the sudo-mode of temporary authorization grants, it doesn't work that way as the whole session has full access via file.so.

It would be great if this could work with just the application which initially requested the privilege.
With this, the whole session has full root-level access to literally everything on the system.

In D10141#197039, @fvogt wrote:

There is one issue I have with this. While this is close to the sudo-mode of temporary authorization grants, it doesn't work that way as the whole session has full access via file.so.

How exactly? Is there any way for an application to choose a slave process instead of being assigned one at random?
Till now what I have observed is after a successful authentication only the slave process is authorised to perform the action and not the application itself. So if a malicious app wants to perform some kind of privileged file operation then it has to (somehow) pick up a slave that had been already authorized. And even if that were possible the slave will still show a confirmation dialog.

It would be great if this could work with just the application which initially requested the privilege.
With this, the whole session has full root-level access to literally everything on the system.

I do understand having authorization persist for the entire session means disaster but when kauth generates the policy file this option only results in "auth_admin_keep".
Polkit's manpage says : auth_admin_keep - Like auth_admin but the authorization is kept for a brief period (e.g. five minutes).

Also when I execute pkcheck --list-temp after authenticating a file operation started by dolphin the output I get includes these lines

subject:          unix-process:9532:1210162 (file.so [kdeinit5] file local:/run/user/1000/klauncherTJ7042.1.slave-socket local:/run/user/1000/kioslavetestAX7208.3.slave-socket)
expires:          4 min 47 sec from now (Fri Feb  9 21:43:47 2018)

This suggests auth_admin_keep results in temporary authorization of one particular process for 5 minutes and not for the entire user session.
So can you explain me one more time why you think persistence=session is a bad idea? Do correct me if I got anything (or everything?) above wrong.

In D10141#203545, @chinmoyr wrote:

In D10141#197039, @fvogt wrote:

There is one issue I have with this. While this is close to the sudo-mode of temporary authorization grants, it doesn't work that way as the whole session has full access via file.so.

How exactly? Is there any way for an application to choose a slave process instead of being assigned one at random?

There isn't. Which makes any mitigation attempt impossible.

Till now what I have observed is after a successful authentication only the slave process is authorised to perform the action and not the application itself. So if a malicious app wants to perform some kind of privileged file operation then it has to (somehow) pick up a slave that had been already authorized. And even if that were possible the slave will still show a confirmation dialog.

Yes, this is a design issue and why I don't think this can ever be made secure without disabling Persistence completely.

It would be great if this could work with just the application which initially requested the privilege.
With this, the whole session has full root-level access to literally everything on the system.

I do understand having authorization persist for the entire session means disaster but when kauth generates the policy file this option only results in "auth_admin_keep".
Polkit's manpage says : auth_admin_keep - Like auth_admin but the authorization is kept for a brief period (e.g. five minutes).

Also when I execute pkcheck --list-temp after authenticating a file operation started by dolphin the output I get includes these lines

subject:          unix-process:9532:1210162 (file.so [kdeinit5] file local:/run/user/1000/klauncherTJ7042.1.slave-socket local:/run/user/1000/kioslavetestAX7208.3.slave-socket)
expires:          4 min 47 sec from now (Fri Feb  9 21:43:47 2018)

This suggests auth_admin_keep results in temporary authorization of one particular process for 5 minutes and not for the entire user session.
So can you explain me one more time why you think persistence=session is a bad idea? Do correct me if I got anything (or everything?) above wrong.

Session refers to two independant things: The time from login to logout and all processes started by the user.
The latter meaning is the issue.
Now imagine you have a proprietary application running on wayland. It can just wait until you try to make a change using the kauth helper and then just
inject its own files somewhere. Currently it does not even have to be a change, reading a file is enough as the helper does not care.

In D10141#203664, @fvogt wrote:

In D10141#203545, @chinmoyr wrote:

In D10141#197039, @fvogt wrote:

There is one issue I have with this. While this is close to the sudo-mode of temporary authorization grants, it doesn't work that way as the whole session has full access via file.so.

How exactly? Is there any way for an application to choose a slave process instead of being assigned one at random?

There isn't. Which makes any mitigation attempt impossible.

There actually kind of is, kio has this "special" mode called KDE_FORK_SLAVES in which slaves are directly forked by the app instead of by klauncher. I'm not sure how much that would help here. Maybe @dfaure can shed some light?

In D10141#203726, @aacid wrote:

In D10141#203664, @fvogt wrote:

In D10141#203545, @chinmoyr wrote:

In D10141#197039, @fvogt wrote:

There is one issue I have with this. While this is close to the sudo-mode of temporary authorization grants, it doesn't work that way as the whole session has full access via file.so.

How exactly? Is there any way for an application to choose a slave process instead of being assigned one at random?

There isn't. Which makes any mitigation attempt impossible.

There actually kind of is, kio has this "special" mode called KDE_FORK_SLAVES in which slaves are directly forked by the app instead of by klauncher. I'm not sure how much that would help here. Maybe @dfaure can shed some light?

The issue is that file.so decides whether to use the helper or not, so this doesn't actually help.

@fvogt @lbeltrame @davidedmundson Any remaining objections?

No objections from me - as long as the feature is disabled correctly, which it currently isn't.

See also https://phabricator.kde.org/T8075#136728.

In D10141#242463, @fvogt wrote:

No objections from me - as long as the feature is disabled correctly, which it currently isn't.

See also https://phabricator.kde.org/T8075#136728.

https://cgit.kde.org/kio.git/commit/?id=65ab5e9a0c041ffa600afeb65d14b8a487b301a5
I hope this correctly disables it?