status of kde/plasma kiosk framework in kf5

[David Faure]

On mercredi 7 décembre 2016 15:13:02 CET David Edmundson wrote:
> > > i also kinda hacked my own secure environment where shell access is not
> > 
> > allowed by placing a .desktop file in
> > .local/share/kservices5/ServiceMenus/
> > that allows me to open a terminal in the current folder ^^
> > 
> > > dolphin shouldn't allow this.. right?
> > 
> > Konsole's desktop file has a key X-KDE-AuthorizeAction=shell_access that
> > tells klauncher to refuse to start it when such restriction is in effect.
> > 
> > I'll cc David Faure as KIO master whether he knows how to prevent the
> > system from picking up custom applications and services in the user's
> > home.
> > I thought that the .desktop files needed to be marked executable but that
> > doesn't seem to be the case. David? Maybe "run_desktop_files" restriction
> > helps here?
> > 
> > We have the key
> 
> run_desktop_files
> 
> This should prevent loading any .desktop files in .local

Not exactly. It prevents executing application desktop files from
random places like $HOME/Desktop even when they are marked as executable (1),
and it prevents the messagebox offering to make the file executable, from 
appearing if it's not (2), as well as preventing the user from using the 
properties dialog to make desktop files executable (3).

But any desktop file that is in a standard path for app desktop files 
is allowed (see KDesktopFile::isAuthorizedDesktopFile). This includes 
~/.local/share/applications and ~/.local/share/kservices5/ServiceMenus/.

The security idea behind this is to prevent desktop files masquerading as 
"normal files" and executing random commands when the user thinks he's just 
opening a file. But if the user installs a file into ~/.local/share/applications
or indeed ~/.local/share/kservices5/ServiceMenus/ then he/she should expect 
that file to be executed, so in the non-kiosk case, this should be OK.

Given the way that KDesktopFile::isAuthorizedDesktopFile is written, the kiosk 
setting run_desktop_files is currently only about files *outside* standard dirs, 
so it won't help for ServiceMenus.

Is this a bug? Should KDesktopFile::isAuthorizedDesktopFile refuse executing 
files from $HOME, even in standard locations like ~/.local/share/applications, 
if run_desktop_files is not authorized? Or do we need a different KIOSK setting 
for this because there are use cases for both?

(1) see KDesktopFile::isAuthorizedDesktopFile in kconfig
(2) see krun.cpp in kio
(3) see kpropertiesdialog.cpp in kio. Hmm, there's possible another bug there, 
the permissions dialog always appears, allowing people to make desktop files 
executable, what is blocked by run_desktop_files is the desktop-files-plugin, 
i.e. modifying the Exec line.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5